[RFC] OpenSSL provider-based algorithms and post-quantum cryptography support View as Markdown

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