Re: [RFC] OpenSSL provider-based algorithms and post-quantum cryptography support
| From: | Ayesh Karunaratne | Date: | Sat, 05 Sep 2026 10:57:56 +0000 |
| Subject: | Re: [RFC] OpenSSL provider-based algorithms and post-quantum cryptography support | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132435@lists.php.net to get a copy of this message | ||
> I am happy to work on the RFC, API design, documentation and testing,
> and to help with the implementation where I can. I would particularly
> appreciate involvement from someone already working on ext/openssl for
> the actual C implementation.
>
> I am currently preparing an RFC and would especially appreciate feedback
> from people familiar with ext/openssl on the general direction and API
> design before finalizing the proposal.
>
> In particular, I'd be interested in opinions on whether provider-based
> key support and the KEM API should be addressed in a single RFC or split
> into separate proposals.
Hi Timo,
Sebastian sent an email a while ago with similar motivation. It
unfortunately did not get any traction, but I'm glad this was brought
up again:
https://externals.io/message/130673
Similar to how ext-curl integrates libcurl into PHP, I personally
believe that, ideally, ext-openssl should remain as close as possible
to OpenSSL, without introducing our own APIs. Userland libraries can
abstract the complexities and provide purpose-built and intuitive
APIs. This simplifies our work in the integration, and provides an
easy verification path for ext-openssl development.
ext-openssl not only lacks PQC APIs, but also several other features
and changes introduced in OpenSSL 3.5 and 4. It can be quite a big
task, and I'd be really happy to help in any ways I can too.
Thank you,
Ayesh.