Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

[Peter Gutmann <[e-mail]>]

Fedor Brunner <[e-mail]> writes:

>Also Adam Langley thinks that NIST continually pick algorithms that aren't
>suited to software implementations.
>https://www.imperialviolet.org/2012/10/21/nist.html

Another problem with the NIST standards is that, once you go beyond basics
like AES, SHA-2, and so on, you have a neverending stream of oddball modes and
mechanisms that no standard protocol ever uses, or arguably needs.  However
since it's specified by NIST, standards groups, who are often heavily stacked
with US contributors, feel the need to force them into all manner of standards
because they feel they need USG approval for them.  

This applies particularly to things like TLS, less so for protocols like SSH
(if I had a penny for every time I've heard "we can't do <straightforward
common-sense approach> because there's no NIST-approved way to do it" or "we
need to do <some boneheaded silly-walk> because that's what the NIST standard
says"...).  In other words while the SSH effort is driven by purely technical
considerations, things like TLS are driven by a combination of technical
considerations and "what NIST has standardised so we can get it FIPS certified
for our USG customers".

This dual technical+political approach is not a good way to design a standard.

Peter.