Reference for posterity: https://www.openssh.org/pq.html Web archive URL: https://web.archive.org/web/20260312035624/https://www.openssh.org/pq.html
" OpenSSH has offered post-quantum key agreement (*KexAlgorithms*) by default since release 9.0 (April 2022), initially via the sntrup761x25519-sha512 algorithm. More recently, in OpenSSH 9.9, we have added a second post-quantum key agreement mlkem768x25519-sha256 and it was made the new default scheme in OpenSSH 10.0 (April 2025). " On Thu, Mar 26, 2026 at 12:51 PM Watson Ladd <[email protected]> wrote: > On Thu, Mar 26, 2026 at 8:46 AM Paul Wouters > <[email protected]> wrote: > > > > On Mon, 23 Mar 2026, Loganaden Velvindron wrote: > > > > >> To the broader question, I think that the IETF should avoid adopting > algorithms > > >> that haven't seen a sufficient level of vetting. This could be > provided by CFRG > > >> or, as you observe, by a multi-year international NIST competition. > > >> > > > There are also open source projects like OpenBSD which have integrated > > > sntrup761 in hybrid mode > > > within OpenSSH for a long time. > > > > > > With security companies like Qualys constantly trying to find new > > > vulnerabilities in openssh, > > > I'm pretty sure that they would have found a vulnerability in > > > x25519sntrup761 kex codebase by now ? > > > > > > NIST is a good option, but maybe we could get the perspective of folks > > > like Markus Friedl (openssh) or Damien Miller (openssh) > > > in the Crypto Review Panel ? > > > > The reason x25519sntrup761 is informational and not standards track is > > the lack of vetting that has happened. Two developers is not the level > > of vetting we should strife for as minimum. > > SNTRUP was an entry into the NIST PQ competition. It did receive > extensive vetting, even if it was not selected (as the competition was > ongoing when OpenSSH made its choice). > > > > > Also, even openssh is sunsetting x25519sntrup761 by preferring > x25519mlkem, > > meaning for "store now, decrypt later", x25519sntrup761 will be entirely > > unused. > > > > Paul > > > > _______________________________________________ > > TLS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
