[PHP-DEV] [RFC] OpenSSL provider-based algorithms and post-quantum cryptography support

[email protected] (Timo Poppinga)
Newsgroups php.internals
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.