On Thu, Feb 13, 2025, at 8:51 AM, Paragon Initiative Enterprises Security Team
wrote:
> OpenSSL 3 introduced a KEM API, which is an abstraction for the kinds
> of cryptographic operations used by the NIST post-quantum cryptography
> standards (i.e., FIPS-203).
>
> KEM stands for "Key Encapsulation Mechanism". It's the preferred way to
> do asymmetric cryptography. Even RSA-KEM is safer than how most people
> experience RSA encryption.
>
> The relevant functions are EVP_PKEY_encapsulate() and EVP_PKEY_decapsulate().
>
> https://github.com/openssl/openssl/blob/4b4333ffcc8e4ecbf5c70214769c77c7a1bb684f/crypto/evp/kem.c#L225
>
> https://github.com/openssl/openssl/blob/4b4333ffcc8e4ecbf5c70214769c77c7a1bb684f/crypto/evp/kem.c#L262
>
> Currently, these APIs only seem to support classical cryptography (ECC,
> RSA), but that is one of the APIs that will enable post-quantum
> cryptography for software using OpenSSL in the future.
>
> We intend to send a pull request later this year to include PHP
> functions in the OpenSSL extension that look like this:
>
> function openssl_kem_encaps(OpenSSLAsymmetricKey $pk): array;
> // 0 -> shared secret (typically 32 bytes)
> // 1 -> KEM ciphertext for decaps
> function openssl_kem_decaps(OpenSSLAsymmetricKey $sk, string
> $kemCiphertext): string;
> // Returns a shared secret or throws an exception upon decryption
> failure.
>
> I don't know if this change needs an RFC or not, but I wanted to start
> the discussion just in case.
>
> Security Team
> Paragon Initiative Enterprises <https://paragonie.com/security>
I am also fully on board with including quantum-safe crypto mechanisms, but I
believe it should go through an RFC. If for no other reason than just in this
thread we're already discussing ways to make the API more ergonomic, which
means there's no obviously-correct consensus on the API, and an RFC is the
standard process currently for working through that.
I also echo what others have said about array returns. No. Make it a readonly
object with well-named public properties. ('sk', 'pk', etc. are not
well-named.)
--Larry Garfield
