Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126400
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 13 Feb 2025 16:34:35 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <57890163-60fa-47aa-9150-e8015ba9b28d@app.fastmail.com>
In-Reply-To: 
 <CAKws9z2-e8YnGbdpp0BJvEBEiEsqHQMzyAo+Vee4naXy5mK40w@mail.gmail.com>
References: 
 <CAKws9z2-e8YnGbdpp0BJvEBEiEsqHQMzyAo+Vee4naXy5mK40w@mail.gmail.com>
Subject: Re: [PHP-DEV] Update OpenSSL Extension to Support KEMs
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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