Re: [Cfrg] Curve manipulation, revisited

[Adam Langley <[e-mail]>]

> I don't think this is quite right. Imagine we could improve the square
> root in Pollard rho to cube root via some algebraic geometry. Then
> 255/3=85, but 448/3=150. Even ignoring the possibility of algorithmic
> improvements, progress in computing power may mean data that has to be
> confidential for centuries needs a larger curve. The NSA did pick P384
> for a reason.

If we are positing a cube root algorithm for discrete-log, can't we
posit a 4th root one?

But, yes, there is a possibility of an attack that's *just* right:
weak enough not to break a larger curve but strong enough to break a
smaller one. On the other hand, each additional curve dilutes
implementation resources and implementation bugs happen. I'm judging
that the risk of a bug due to the additional curve is larger than the
benefit of hedging against that specific sort of analytic breakthough.

And, if you want to keep data safe for centuries, isn't post-quantum a
requirement?

On Thu, Dec 25, 2014 at 8:38 PM, David Gil <[e-mail]> wrote:
> 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.

I think my argument here is the same as above. (Although, in this
situation, you would have the advantage of being able to use the
simplest, clearest code possible because performance isn't a concern.)

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

TOP SECRET just needed to have a bigger number than SECRET :)


Cheers

AGL

-- 
Adam Langley [e-mail] https://www.imperialviolet.org