-
-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support X25519Kyber768Draft00 or X25519Kyber768 #24622
Comments
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: 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):
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 Remark (as this seems to be of interest for you): Was tested successfully with |
Great to know, I'll try to document this on the HAProxy wiki. |
@wlallemand FYI & completeness - For simplicity, I did the verification for |
@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 |
@wlallemand FYI, Edit/add: All it should need is simple |
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 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. |
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. |
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 . |
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:
You probably need packages After |
@baentsch @mikkorantalainen Thanks a lot for your explainations! I will try this out. |
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 identifier0x6399
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 configsetting security.tls.enable_kyber
and that config setting will probably default totrue
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 viaX25519
and the other half viaKyber
in a single handshake. The handshake data transmission overhead compared to plainX25519
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 ifX25519Kyber768Draft00
is implemented. Web browsers are expected to supportX25519Kyber768Draft00
in short term andX25519Kyber768
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.)
The text was updated successfully, but these errors were encountered: