Support X25519Kyber768Draft00 or X25519Kyber768

[mikkorantalainen]

OpenSSL should support at least one quantum safe encryption method for TLS connections. It seems that modern user agents (web browsers) are already converging to support X25519Kyber768Draft00 as documented at https://pq.cloudflareresearch.com/ so it would be a good option.

X25519Kyber768Draft00 with TLS identifier 0x6399 is already supported by release version of Chrome and Edge. Firefox support is currently compiled in release versions but the feature is hidden behind user accessible config setting security.tls.enable_kyber and that config setting will probably default to true in near future.

The X25519Kyber768Draft00 is a combination of X25519 (already supported by OpenSSL) and Kyber, where half (256 bits) of the session key is transferred via X25519 and the other half via Kyber in a single handshake. The handshake data transmission overhead compared to plain X25519 is about 2 KB and server needs about 4 KB of additional RAM to compute the Kyber part with an optimized algorithm.

The final protocol X25519Kyber768 is expected to have minor differences in the implementation of Kyber so that should already be expected if X25519Kyber768Draft00 is implemented. Web browsers are expected to support X25519Kyber768Draft00 in short term and X25519Kyber768 in long term.

Google has already implemented the required code in their fork of OpenSSL called BoringSSL, see google/boringssl@e491eeb for an example. Google has published their modifications with ISC License which is trivially compatible with OpenSSL license.

Basically I'm asking for a feature to allow using TLS 1.3 encryption method X25519Kyber768Draft00.

(I originally reported similar issue against HAProxy here: haproxy/haproxy#2603 and got response that HAProxy simply uses OpenSSL directly so they cannot implement support for X25519Kyber768Draft00 in their code.)

[beldmit]

It's doable by liboqs with proper algorithms selection and oqsprovider.

[martinschmatz]

@mikkorantalainen Just FYI - in the context of work on #21633, based on the discussion in #22203 and based on the NSA mandate to 'support and prefer' Q-safe. we're already working on a revision of the group selection algorithm on the server side (keeping backward compatibility to the current algorithm).

This will be enabled by using a newly introduced '!' prefix for those groups in the list for which key shares are requested:
On client side, a '!' prefix means: Send a client share for this group (-> 'will arrive as "keyshare list" on server side')
On server side, a '!' prefix means: This group has higher priority (-> 'is part of "requested keyshare" list on server side').
If no '!' prefix is used in any of the groups in the list, the existing algorithm will be used for backward compatibility.

For the server side group selection algorithm, 4 possibilities exist, with sequence is priority (=> read table below like so: If entries in the client side list have overlap with the the server side list, do the overlap action; if not, use the next line and repeat):

   Client                  Server                    If they overlap
1) keyshare list           requested keyshare list   Use leftmost group_id from server requested keyshare list
2) supported groups list   requested keyshare list   HRR with leftmost group_id from server requested keyshare list
3) keyshare list           supported groups list     Use leftmost group_id from server groups list
4) supported groups list   supported groups list     HRR with leftmost group_id from server groups list

Therefore, for example, if a client sends a keyshare for a legacy group, but would also support a Q-safe 'group', the server would trigger a HRR for the Q-safe 'group' (and with that a round-trip) even if it would support the legacy group.

Code is already 'wiggling' nicely, needs more tests and cleanup, but is intended for a PR soon.

[martinschmatz]

And yes, basic support for Q-safe 'groups' is readily available using liboqs and oqsprovider. I recommend to build/use the latest OpenSSL version along with the former two.

Remark (as this seems to be of interest for you): Was tested successfully with HAproxy.

[wlallemand]

Remark (as this seems to be of interest for you): Was tested successfully with HAproxy.

Great to know, I'll try to document this on the HAProxy wiki.

[martinschmatz]

@wlallemand FYI & completeness - For simplicity, I did the verification for HAproxy in Docker containers (to avoid 'pollution' of my system), but that can easily be replicated on VM or bare-metal. I tested with both Ubuntu v24.04 and UBI (~=RHEL) v9.4 as base OS and got HAproxy via the Ubuntu supplied package for both OS cases (HAProxy version 2.8.5-1ubuntu3).
I used liboqs v0.10.0 and OQS OpenSSLv3 provider v0.6.0 in combination with OpenSSL 3.0.13 (Rem: does not support Q-safe sigalgs).

[wlallemand]

@martinschmatz okay, thanks for the details, that's useful!

[t8m]

@nhorman It looks like this was marked inactive by a mistake.

[nhorman]

yup, miss on my part, thank you for catching @t8m

[baentsch]

@wlallemand FYI, haproxy has been fully PQ-enabled since 2020, but we dropped continued support for it due to apparent lack of interest in that package last year. Any contribution to change its PQ integration support level very welcome.

Edit/add: All it should need is simple openssl config option tweaks to activate oqsprovider and there are several, possibly stalled statements of interest to update/re-activate it in the form of a Dockerfile, e.g., in open-quantum-safe/oqs-demos#273 and open-quantum-safe/oqs-demos#182, but maybe even better would be an explanation/sample config in the HAProxy wiki for your users to find this.

[Arne19]

Hi, first thanks everyone for your work on OpenSSL!

The latest news are that these standards will be official standarized and supported by NIST:

CRYSTALS-Kyber Module-Lattice-Based Key-Encapsulation Mechanism Standard
CRYSTALS-Dilithium Module-Lattice-Based Digital Signature Standard
FALCON Stateless Hash-Based Digital Signature Standard

How is the progress of OpenSSL officially supporting these? Is it still worth installing the oqsprovider or should we wait for the OpenSSL support?

[baentsch]

How is the progress of OpenSSL officially supporting these? Is it still worth installing the oqsprovider or should we wait for the OpenSSL support?

This question somehow implies difficulties installing oqsprovider, right? Could you share what they are/how oqsprovider might need to be improved to ease these?

In general though I'm also interested in the OpenSSL teams' position on this topic -- and whether and which support one may provide to aid in this.

[Arne19]

I plan to install OpenSSL from source and the oqsprovider on a running system with a normal Debian installation with OpenSSL installed from the packagemanager. The problem was not to find it in the tutorial how to switch from an OpenSSL installation from package manager to a self build one from the source. Or maybe I've overseen it?

But it's not only about difficulties, it would be much easier when OpenSSL would support it directly without an extra installation of a oqsprovider.

[baentsch]

But it's not only about difficulties, it would be much easier when OpenSSL would support it directly without an extra installation of a oqsprovider.

ACK. Three options then IMO: 1) Someone adds bespoke code to default provider enabling MLKEM, MLDSA, Falcon and all required hybrids (that are not firmly spec'd AFAIK); 2) Package managers integrate OpenSSL with oqsprovider readily configured for use (as has been done by @beldmit for example); 3) one adds a Makefile target to OpenSSL to build, install and configure in oqsprovider in a source code build--this might be not very hard as oqsprovider already is a git subproject for testing purposes--and seems to be the fastest way to get what you're looking for @Arne19 .

[mikkorantalainen]

I plan to install OpenSSL from source and the oqsprovider on a running system with a normal Debian installation with OpenSSL installed from the packagemanager. The problem was not to find it in the tutorial how to switch from an OpenSSL installation from package manager to a self build one from the source. Or maybe I've overseen it?

You can simply uninstall the official package and then build and install the same software with some other means.

Or if you just want the official version + some patches, you can do as follows:

mkdir ~/tmp
cd ~/tmp
apt source openssh-server
cd openssh-*

# apply the patches you want, note that the build process will also apply patches in directory debian/patches

debchange -i
debchange --release
debuild

You probably need packages build-essential and devscripts installed. Or maybe ubuntu-dev-tools if you don't mind using a bit more storage space for non-essential packages and don't want to go looking for some minor development packages if needed.

After debuild has successfully finished, the custom packages appear in one directory above your current working directory and you can install them with apt install ./path/to/filename.deb. This style doesn't require uninstalling the old package first because apt will take all the required steps automatically.

[Arne19]

@baentsch @mikkorantalainen Thanks a lot for your explainations! I will try this out.

[bwesterb]

We just deployed X25519MLKEM768 at Cloudflare and are planning to turn off X25519Kyber768Draft00 once its usage dropped. Chrome is planning to switch from X25519Kyber768Draft00 to X25519MLKEM768 by default in the coming month. Chrome derivates will follow suit. Firefox is rolling out support for X25519MLKEM768 as we speak.

[t8m]

We aren't going to support these draft Kyber based algorithms. We are already working towards supporting MLKEM768 based hybrid algorithms soon. I am closing this issue.

[bwesterb]

@t8m Do you have a issue number we can follow?

[t8m]

No, not yet, we did not finish the planning yet. @nhorman can you please link the issue for hybrid ml-kem once it is opened?

[baentsch]

We just deployed X25519MLKEM768 at Cloudflare

Is this supported at any CF server or is there a recommended specific server/port we could use for interop testing, @bwesterb ? Asking as we just switched those tests over to google... Last question: Would you please give us notice before switching off the Kyber stuff so we can turn those off before that impacts our CI again (both at OQS and at OpenSSL)? Or would you recommend we rather remove them right away?

[bwesterb]

Is this supported at any CF server

Yes, it's supported on all customer domains, except where customers turned off TLS 1.3 and/or enabled strict FIPS mode (for now). You can use cloudflare.com port 443 if you need a specific endpoint. Don't forget to set server name (SNI).

Last question: Would you please give us notice before switching off the Kyber stuff so we can turn those off before that impacts our CI again (both at OQS and at OpenSSL)? Or would you recommend we rather remove them right away?

I'll send an email to the tls wg mailinglist before we switch off X25519Kyber768Draft00 (0x6399). I'd be surprised if that happens before mid 2025.

[mattcaswell]

No, not yet, we did not finish the planning yet. @nhorman can you please link the issue for hybrid ml-kem once it is opened?

In the meantime you might be interested in our Proof-of-concept work with ML-KEM (this is likely to be replaced by subsequent work, so won't be merged):

#25403

We recently created an ml-kem feature branch. There are no pull requests against it yet, but when there are you will be able to see a list of them here:

https://github.com/openssl/openssl/pulls?q=is%3Apr+is%3Aopen+base%3Afeature%2Fml-kem

[BugOfBugs]

t8m n't going to support Kyber

Why?

[baentsch]

t8m n't going to support Kyber

Why?

As @t8m mentioned, Kyber is not a standardized algorithm; ML-KEM is.

[BugOfBugs]

Did not mention "standard". Mentioned "draft". So, refusal should be not terminal. Should add "yet".
Will implement, when becomes standard?

[paulidale]

No, it is terminal. The project has a policy that mandates that only algorithms standardised at a national or international level will be accepted. The drafts will never be standardised and thus will not be accepted.

[BugOfBugs]

Why not standardise?

[mattcaswell]

Why not standardise?

They have standardised. The standard based on Kyber is now called ML-KEM which we are implementing here:

#25848

Hence this issue is closed. We won't implement Kyber, we will implement the standardised version ML-KEM.