# [RFC] OpenSSL provider-based algorithms and post-quantum cryptography support - Thread: https://externals.io/message/132434 - Original archive: https://news-web.php.net/php.internals/132434 - Started by Timo Poppinga on 2026-09-05T10:05:49+00:00 - Messages: 2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #132434 — Timo Poppinga — 2026-09-05T10:05:49+00:00 URL: https://externals.io/message/132434#132434 Hi internals, I'd like to start a discussion about improving support for modern OpenSSL provider-based asymmetric algorithms in ext/openssl, in particular post-quantum cryptography (PQC). This is related to the following existing issues: https://github.com/php/php-src/issues/22862 https://github.com/php/php-src/issues/23421 With recent OpenSSL versions, standardized post-quantum algorithms such as ML-KEM, ML-DSA and SLH-DSA are available through the EVP/provider APIs. However, PHP's OpenSSL extension currently exposes asymmetric cryptography largely through a fixed set of OPENSSL_KEYTYPE_* constants and does not expose the generic KEM encapsulation/decapsulation operations provided by OpenSSL. Rather than adding individual PHP constants and APIs for each PQC algorithm, I would like to explore exposing the underlying OpenSSL provider model more generically. The initial idea is to cover: * asymmetric key generation using an OpenSSL algorithm name; * provider-backed algorithms which do not have a dedicated OPENSSL_KEYTYPE_* constant; * generic KEM encapsulation and decapsulation; * support for provider-backed signature algorithms such as ML-DSA and SLH-DSA through the existing signing APIs where possible. An important goal would be to keep this generic rather than making the PHP API specific to ML-KEM or other currently standardized PQC algorithms. This would allow future algorithms and potentially third-party OpenSSL providers to use the same API. I should also mention that I am probably not the right person to implement the C side of this proposal myself. My C experience is somewhat rusty and, given that this concerns security-sensitive cryptographic functionality, I would strongly prefer the implementation to be done or at least closely guided and reviewed by someone who is already familiar with ext/openssl and its internals. From my current understanding, the implementation effort should be relatively contained, since the cryptographic primitives themselves are already implemented by OpenSSL. The main task would be exposing the corresponding existing EVP/provider functionality through ext/openssl and integrating it consistently with PHP's existing OpenSSL APIs. That said, I don't want to underestimate the details involved in safely exposing these APIs, particularly around key handling, provider compatibility, error handling and maintaining compatibility with the OpenSSL versions supported by PHP. 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. Thanks, Timo --- ## #132435 — Ayesh Karunaratne — 2026-09-05T10:57:56+00:00 URL: https://externals.io/message/132434#132435 · In reply to: #132434 > 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.