SUSE’s strategy on implementing post quantum cryptography (PQC) has been to adopt standards and upstream implementations when they become available, and deliver support to customers via maintenance or newer product revisions.
Standardization status
Contents
Cryptography and protocols on top of it needs to interoperate world wide between a wide range of third parties. This requires that they are standardized before they can be deployed for large scale production purposes.
What is the standardization status so far:
Low-level ciphers
- ML-KEM – PQC safe key exchange mechanism using module lattices, standardized in FIPS 203.
- ML-DSA – PQC safe digital signature algorithm using module lattices, standardized in FIPS 204.
- SLH-DSA – PQC safe digital signature algorithm using stateless hashes, standardized in FIPS 205.
- LMS – PQC safe stateful hash defined in FIPS 186.
- XMSS – PQC safe stateful hash defined in FIPS 186.
The first 3 standards have been published in August 2024 and are available for FIPS 140-3 validation. The stateful hashes have been certified in 2020, use is however not mandatory as the SHA algorithms still are considered post quantum safe with sufficient lengths.
Other low-level ciphers are in the standardization process, like Frodo KEM.
Protocol level ciphers
Various protocols need to define how the PQC low-level ciphers are used and integrated. Standardization of those take a while, so various are in a draft state, but likely will be going into standards as they are now.
During the transition time there will be hybrid ciphers used to allow use a combination of both proven working ciphers and relatively new PQC ciphers, to be both safe in a post quantum world and also for potential cryptographic issues in the PQC ciphers.
- X.509: Certificate storage definitions are in a draft state.
- TLS: A hybrid ML-KEM 768 / X25519 key agreement is in standardization and available as draft.
- IKEv2: A similar hybrid ML-KEM 768 / X25519 key agreement is in standardization and available as draft.
- openssh / SSHv2: Also a hybrid ML-KEM 768 / X25519 key agreement is proposed and implemented in openssh 10 and newer.
There is currently no secure boot draft standard.
SUSE Implementation status
SUSE has been integrating and updating components as they become available. Notably openssl 3 was using the openquantumsafe library liboqs via a provider in openssl 3 versions before openssl 3.5.
The TLS libraries like gnutls, mozilla-nss and also the GO runtime focus on implementing the draft TLS cipher x25519mlkem768 which likely will be used in the near future.
For IKEv2 for IPSEC there is also a proposed a x25519mlkem768 hybrid key exchange as draft standard, available in strongswan 6.0 and newer versions.
For SSH there is also a x25519mlkem768 hybrid key exchange proposed, available in openssh 10.0 and newer. This openssh version is not yet available in SUSE Linux Enterprise products.
| SLES/SL Micro version | ML-KEM | ML-DSA | SLH-DSA | X.509 | TLS x25519mlkem768 |
|---|---|---|---|---|---|
| SLES 15 SP6 | liboqs openssl 3 + oqs provider go1.24 and newer |
liboqs openssl 3 + oqs provider go1.24 and newer |
liboqs openssl 3 + oqs provider go1.24 and newer |
liboqs openssl 3 + oqs provider |
go1.24 and newer mozilla-nss |
| SLES 15 SP7 | same | same | same | same | same |
| SL Micro 6.0 and 6.1 | same | same | same | same | same |
| SLES 16.0 and SL Micro 6.2 | openssl libgcrypt leancrypto liboqs gnutls go1.24 and newer mozilla-nss |
openssl leancrypto liboqs gnutls |
openssl leancrypto liboqs |
openssl gnutls |
openssl go 1.24 and newer mozilla-nss gnutls |
SUSE Strategy going forward
SUSE’s strategy going forward is that of a quick adoption of both standards and upstream implementations. We will use future product deliveries and also maintenance feature updates to improve SUSE’s PQC coverage.
(Visited 1 times, 1 visits today)
