** Description changed: openssh upstream recently posted[1] about a series of patches made available for openssh stable releases to enable the sntrup761x25519-sha512 post-quantum key-exchange algorithm. This bug is a placeholder to evaluate this opportunity, and check which ubuntu releases could benefit from this. Given the version numbers in that post, it looks like jammy and noble could benefit. 1. https://lists.mindrot.org/pipermail/openssh-unix- dev/2025-August/042030.html + + + SRU: + + [ Impact ] + + * This upload backports two post-quantum (PQ) hybrid key exchange methods + from openssh 10.0.0p1 on questing into openssh 9.6p1 on noble: + + - "sntrup761x25519-sha512" (IANA-registered name for the existing + [email protected] method), and + - "mlkem768x25519-sha256" (ML-KEM-768 + X25519 hybrid, the standardized + method used by current OpenSSH and other SSH implementations). + + * OpenSSH's SSH transport negotiates a key exchange method between client + and server. Noble's 9.6p1 already ships the vendor-named + [email protected] hybrid, but it predates the + IANA-registered name and the FIPS-standardized ML-KEM-768 based method. + Peers that advertise only the standardized names (recent upstream + OpenSSH, OpenSSH-compatible stacks and other vendors) therefore cannot + negotiate a PQ hybrid exchange with an unpatched noble system, and the + session silently falls back to a non-PQ method such as curve25519-sha256. + + * The consequence for users is that sessions from/to noble offer no + protection against a "harvest now, decrypt later" quantum adversary, + where traffic is recorded today and decrypted once a cryptographically + relevant quantum computer exists. This matters for an LTS, where + sessions are long-lived and the recorded traffic remains sensitive for + years. + + * The upload fixes this by registering the two hybrid methods and putting + them at the top of the default KexAlgorithms list (both client and + server), matching current upstream OpenSSH and the same enablement + already done for later Ubuntu releases. It is a low-risk, additive + change: it only adds new names/implementations to the existing KEX + framework and makes them preferred; the previous methods remain + available, and negotiation gracefully falls back for peers that do not + support the new names. + + Bug-Ubuntu: https://bugs.launchpad.net/bugs/2120496 + + [ Test Plan ] + + * The regression suite shipped in openssh-tests is extended by this upload + and is run by the existing autopkgtest (debian/tests/regress). It + provides automated coverage for both new methods: + + - ML-KEM-768 known-answer tests (KATs): + regress/unittests/crypto/test_mlkem.c exercises seeded keypair + generation, encapsulation and decapsulation against fixed vectors and + verifies the resulting public key, secret key, ciphertext and shared + secret hashes. + - KEX round-trip tests: regress/unittests/kex/test_kex.c now runs + do_kex("mlkem768x25519-sha256") and do_kex("sntrup761x25519-sha512"), + performing a full client/server key exchange for each new method. + + Run them with: + apt-get install openssh-tests + (cd regress && ./unittests/crypto/test_crypto) + (cd regress && ./unittests/kex/test_kex) + or the full suite via: + autopkgtest -s . -- apt + + * Manual verification that the methods are offered and negotiated: + + ssh -Q kex | grep -E 'sntrup761x25519-sha512|mlkem768x25519-sha256' + sshd -T | grep -i kexalgorithms + + Negotiation (against a peer running this package): + + ssh -vvv -o KexAlgorithms=mlkem768x25519-sha256 localhost true 2>&1 \ + | grep 'kex: algorithm' + ssh -vvv -o KexAlgorithms=sntrup761x25519-sha512 localhost true 2>&1 \ + | grep 'kex: algorithm' + + Both should report the requested method as the negotiated "kex: + algorithm". Repeat as client and as server (e.g. sshd on the host) to + cover both directions, and, if possible, verify interoperability against + a second implementation that offers the standardized names. + + * No special environment is required beyond a running sshd; the autopkgtest + covers the automated portion. + + [ Where problems could occur ] + + * Because the new methods are placed at the head of the default + KexAlgorithms list, every connection between an updated peer and a + peer that also offers them will now use the new code path. A defect in + the shared-secret derivation would cause handshake failures or, worse, + a client/server disagreement on the derived key. Mitigation: the ML-KEM + KATs and the kex round-trip tests pin the exact output and exercise the + full handshake. + + * Handshake size/performance: PQ KEMs carry larger public keys and + ciphertexts (ML-KEM-768 public key is 1184 bytes, ciphertext 1088 + bytes), so KEXINIT and the KEX payloads are larger and the handshake + costs more CPU than a plain curve25519 exchange. If a regression here + were present it would show up as increased latency/CPU on connection + setup, or as failures against middleboxes that size-limit packets. + This is the same behavior as current upstream OpenSSH defaults. + + * New code surface: the upload adds a vendored libcrux ML-KEM/ML-DSA + implementation (~27k lines, libcrux-mlkem-mldsa.c and + libcrux_internal.h) to libssh, which links into ssh and sshd. Although + it is only reachable through the new KEX path and is covered by the + KATs, it is new code in a security-sensitive path and is the main place + a memory-safety or logic regression could hide. + + [ Other Info ] + + * This is an enablement/hardening backport rather than a bug fix. It is + deliberately a deviation from the "bug fixes only" SRU norm because it + is a security-relevant interop change requested and reviewed on the + tracking bug; the same change has been accepted for later Ubuntu + releases. The LP bug (#2120496) notes the low regression risk and the + consensus to proceed; the ML-KEM method was additionally requested in + that bug. + + * Two patches are added in debian/patches and both are marked + "Forwarded: no" (they are backports of upstream work to the 9.6p1 + stable codebase): + - sntrup761x25519-sha512.patch + - mlkem768x25519-sha256.patch + + * No user-visible configuration changes are required. Administrators who + want to opt out can still restrict KexAlgorithms in ssh_config / + sshd_config, since the pre-existing methods are unchanged and remain in + the default list. + + * Hardware/arch note: the libcrux implementation used is the portable C + extraction, so behavior is identical across architectures; no + architecture-specific enablement is needed.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2120496 Title: Consider enabling sntrup761x25519-sha512 post-quantum algorithm for stable releases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2120496/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
