Re: [Cfrg] Curve manipulation, revisited

[David Gil <[e-mail]>]

On Thursday, December 25, 2014 4:15 AM, Adam Langley
<[e-mail]> wrote: [reordered]

> I don't plan on supporting any larger curve that this WG may
> produce (even more so if it's an "ugly" curve). If nothing
> else, P-384 isn't going away.

I will.

In particular, w.r.t. Yahoo's eventual release of an End-to-End
messaging extension, we will generate EC keys for extension users
on a curve subgroup with log2(#K) >= 376. The additional computational expense is, frankly, negligible.

(And this will likely be a larger deployment, w.r.t. number
of keys, than even TLS -- though vastly smaller in number of
crypto operations.)

--

> I'm skeptical that a larger curve is actually useful. I think
> ~128 and ~192 bit [security strength] curves have shared fate
> to the point where the risks from supporting any extra curve
> outweigh the benefits.

I disagree.

It's absurd to ignore the fact that the organization with the most mathematicians working on ECC[^fbfw] does not trust a bit-length
256 curve for data they consider important. See [NSA Suite B
Cryptography][suiteb].

Do we have any reason to believe that we're so much smarter than
them?

--


[^fbfw]: I would say "for better or for worse", but it is clearly
for the worse.

[suiteb]: https://www.nsa.gov/ia/programs/suiteb_cryptography/