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.
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]
