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]
