Support X25519Kyber768Draft00 or X25519Kyber768 about openssl HOT 8 OPEN

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.

from openssl.

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

from openssl.

@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.

from openssl.

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.

from openssl.

@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).

from openssl.

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

from openssl.

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

from openssl.

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

from openssl.