Re: [Cfrg] On "non-NIST"

On Sat, Feb 28, 2015 at 12:17 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Sat, Feb 28, 2015 at 7:41 AM, Paul Hoffman <paul.hoffman@vpnc.org>
> wrote:
> > On Feb 28, 2015, at 12:59 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>
> wrote:
> >>
> >> Paul Hoffman <paul.hoffman@vpnc.org> writes:
> >>
> >>> The term "non-NIST" is predictive, and the crypto community kinda
> sucks at
> >>> predictions. We have no idea what NIST will do in the future if a
> bunch of
> >>> IETF WGs adopt specific elliptic curves that are not P256/P384.
> >>
> >> Why is NIST seen as the ultimate arbiter of what's appropriate though?
> >
> > Not "the", but "an". The reason is that NIST controls what can and
> cannot be given a FIPS-140 certification, and that certification is
> considered important both by companies who want to sell to the US Govt and
> companies that use their certification as a statement that "we did it
> right". If you make an HSM that uses an algorithm not allowed by NIST, you
> cannot get it certified in the CMVP regime. Thus, when NIST is slow to keep
> up with the best practices adopted by the community, it becomes a roadblock
> to deploying better crypto.
>
> This is factually untrue: CMVP certified modules are permitted to
> implement other algorithms: they just can't be in FIPS mode when those
> are used. I also don't see how NIST approval or lack thereof slowed
> down RC4 deployment or accelerated SHA1 replacing MD5.
>
> The reality is lots of new designs are using Curve25519 and Ed25519.
> That's because of factors like simple design of APIs, high
> performance, and very good security. Standards body acceptance is not
> a concern here. Just as the reality is that E-521 was picked by
> Brazil, while the new GOST is still being worked on, and the upper
> size limit is just a random number. But never mind reality: we've got
> to expose "signs of strength". We need big numbers for marketing:
> never mind attackers can't break authentication in the future, while
> mobile devices already struggle to validate certificates. We need to
> vote on endianness: nothing more needs to be said.
>
> Is anyone surprised we've become a punchline?
>
> Sincerely,
> Watson Ladd
>
> >
> > This is why we hope that, when this RG finally moves on both the the
> curve and the signing algorithm, NIST adds those to its list of acceptable
> crypto for the FIPS 140 testing. If they don't, people can still deploy it,
> but deployment will be hampered.
> >
> > --Paul Hoffman
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > http://www.irtf.org/mailman/listinfo/cfrg

US NIST chose P521
Brazil chose P521

Isn't that a pattern emerging?