Re: [Cfrg] On "non-NIST"

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Feb 25, 2015 at 2:31 PM, Paul Lambert <[e-mail]> wrote:

>
>
> On 2/25/15, 10:38 AM, "[e-mail]"
> <[e-mail]> wrote:
>
> >
> >
> >On Wed Feb 25 18:05:47 2015 GMT, Paul Hoffman wrote:
> >> On Feb 25, 2015, at 7:46 AM, Stephen Farrell
> >><[e-mail]> wrote:
> >> > I do "prefer" that CFRG document only one of those as being
> >> > the usual non-NIST choice for >128 bit work factor.
> >>
> >> 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.
> >>Unfortunately, I suspect current NIST folks also have no idea what NIST
> >>will do in that case either. In the past, NIST has sometimes (but not
> >>always) responded to pressure from the real world about crypto
> >>algorithms and modes; let's hope for the best here.
> >
> >Sure, I agree it'd be good if NIST also annoint the output from this cfrg
> >process. But right now non-NIST is the correct distinguishing term for
> >what I meant. I see no reason that term will be needed in an RFC though
> >if that helps assuage some sensitivity somewhere in the universe :-)
>
> Branding is very important Š  "non-NIST" is adversarial and will
> discourage adoption.  NIST is also not the only Government agency
> recommending specific curve parameters.
>
> The NIST and other recommended Small Weierstrass curves are all based on
> the late 90¹s technology and requirements.
>
> The CFRG recommendations for Œnew curves¹ represent significant
> improvements based on more contemporary mathematical techniques and
> industry requirements. The well identified benefits and more modern
> aspects of the recommendations should be emphasized.
>
>
Further, NIST is holding a workshop on ECC curves specifically asking what
it can do to encourage deployment. So we are pushing against an open door
here.