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 Encapsulati
>
>
> to include PHP functions in the OpenSSL extension that look like this:
>>
>> function openssl_kem_encaps(OpenSSLAsymmetricKey $pk): array;
>>
>
> The name should be more openssl_pkey_encapsulate
>
>
I just did a bit more checking and we should consider having required kem
operation as select
Hi,
> We intend to send a pull request later this year
>
Just note that there are some bigger internal changes being done on
separation of backend starting with
https://github.com/php/php-src/commit/d662ab5f08af83297dc64499edf0b79182d79e91
which should ultimately result in usage of custom libctx
On 2/13/25 06:51, 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
I have no issue with adding more functions to the OpenSSL extension,
but they need to be very clearly documented and have an obvious API.
Cryptic names such as $pk or $sk cannot be used. While I really hate
array return types, if you must use it then it must be clearly
documented. It cannot just be
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 ho
