Add support for the post-quantum ML-KEM KE algorithm in openssl plugin

[geedo0]

Original Discussion Thread

Is your feature request related to a problem? Please describe.

Post-Quantum (PQ) cryptography aims to mitigate the threat quantum computing poses to confidentiality of our data in transit. In mid-2024, NIST is expected to standardize the PQ algorithm ML-KEM (formerly known as Kyber). An IETF draft has been submitted for registering this algorithm in IANA's IKEv2 parameter registry. We would like to contribute an additional implementation of this algorithm in the openssl plugin.

Currently, strongSwan-6 supports this algorithm in the oqs plugin by using the Open Quantum Safe library liboqs directly. This library comes with a strong disclaimer around usage in a production. While there are talks to transition the OQS project to something more production ready with its recent membership in the Linux Foundation, it's still unclear what exactly that means (new library, supporting PQ in existing work, or improving liboqs itself). Some signs signal towards continued development of OQS's OpenSSL-3 provider which uses the OpenSSL KEM API.

This feature request proposes using AWS-LC (an OpenSSL derivative) as a means to provide PQ confidentiality while providing a path toward future PQ algorithm implementations in upstream OpenSSL.

Describe the solution you'd like

The openssl plugin can be updated (here) to conditionally provide support for the 3 different ML-KEM algorithms KE's. It will register an implementation which will be able to handle arbitrary KEM algorithms.

AWS-LC currently provides implementations for Kyber Round 3 with plans to add support for the NIST standardized ML-KEM algorithms as soon as they are available. This is exposed via the EVP KEM API which is similar (but not identical) to the KEM API in OpenSSL-3. Implementations for these KE's can be implemented in a new source file openssl_kem.c which would implement all KEMs using the KEM API.

Describe alternatives you've considered

Alternative 1: Create a stand-alone AWS-LC plugin. This plugin would offer very limited functionality on its own (just the ML-KEM KEs and eventually ML-DSA signatures). Our hope is to encourage re-use with upstream OpenSSL when it provides support for ML-KEM. We also don't anticipate to add significant functionality that is unique to AWS-LC so this plugin would have limited utility.

Alternative 2: Add the implementation to the oqs plugin. The oqs plugin happens to link in libcrypto and can be coaxed into calling the libcrypto APIs for PQ implementations. This is messy and mixes concerns without benefit.

Additional context

While the AWS-LC KEM API is similar to OpenSSL-3's API, it is not identical. The only KEM implemented by OpenSSL using this API is RSA. It is OpenSSL policy not to introduce non-standardized algorithms in their library so we won't have a full accounting of the differences until they release. In any case, these differences can be abstracted away within the openssl_kem.c implementation similar to how such differences are handled in other parts of the openssl plugin.

We are in a transition period between two versions of the same algorithm "Kyber Round 3" and "NIST ML-KEM". The naming of the constants in key_exchange.h and their IANA code points will change. We will hold-off on the PR proposed by this issue until the final ML-KEM standard is available and implemented in AWS-LC.

strongSwan requires a set_seed method to seed a DRBG that generates test vectors matching the Kyber Crystals KATs. AWS-LC will implement a "derandomized" version of the KEM APIs to support this use case. The random bytes can then be generated "on the outside" and passed directly through the KEM API to achieve the same effect. We've learned that NIST plans to include a standardized version of this API in their final standard so we will wait for the exact specification of that to align on the interface.

This feature request focuses on confidentiality of data-in-transit using ML-KEM. It does not address the PQ threat against authenticity which requires PQ signatures such ML-DSA (formerly known as Dilithium). This is because data-in-transit is a current threat due to store-now-harvest later attacks. Exploiting authenticity would require an attacker possessing a quantum computer during connection initiation. AWS-LC does support Dilithium, but it is not included in the default build.