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.