Support X25519Kyber768Draft00 or X25519Kyber768
mikkorantalainen opened this issue · comments
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.)
It's doable by liboqs with proper algorithms selection and oqsprovider.
@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.
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.
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.
@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).
@martinschmatz okay, thanks for the details, that's useful!
@nhorman It looks like this was marked inactive by a mistake.
yup, miss on my part, thank you for catching @t8m