[curves] Curve448

[Michael Hamburg]

> On Oct 19, 2015, at 1:44 PM, Ben Harris <ben at bharr.is> wrote:
> 
> On 20 Oct 2015 5:06 am, "Jason A. Donenfeld" <Jason at zx2c4.com <mailto:Jason at zx2c4.com>> wrote:
> >
> > Hi folks,
> >
> > I've got a few naive question about Goldilocks.
> 
> I'll take a stab from the point of view of an outside observer.
> 
> >
> > Why would somebody use Curve448? Curve25519 is 126bits,
> 
> Some want an "extra strength" curve to buffer against the possibility of a discovery that improves attacks on EC, but doesn't totally break it.
> 
Yeah.  And especially, someone who today is using NIST P-384 (or other >256-bit curves), and is interested in a more modern design but might hesitate to migrate to the “weaker” Curve25519.

There isn’t any concern that Curve25519 might get broken, unless of course someone manages to build a quantum computer.  DJB’s security estimate still holds.
> > How come Curve448 is receiving much attention, but Curve41417 is not?
> > Is 448 faster? More easily implemented in a secure fashion?
> 
> Mike is doing a great job marketing 448. I've seen a few talks he has done, and he is always communicating new things he is working on with Decaf.
> 
> 448 is a different prime to most of the others (potentially helping against future attacks), and unlike the Mersenne primes the exponent is composite which improves implementation. It is a 3 mod 4 which is good for a few reasons (Elligator papers go into it more - 25519 is 5 mod 8 so that isn't the end of the world anyway).
> 
From my point of view, 448 is about as fast as 414, so you might as well use the bigger field.  It’s also a marketing issue — so far as I know, DJB never published a 64-bit C implementation of 414.

I don’t expect that the 448 prime would resist future attacks any better than 2^255-19, except by being larger.  It has a different shape, but we don’t know any attacks based on prime shape except for side channels.

On a related note, now that X448 is getting finalized, I’ll try to get an implementation out in short order.  It should be pretty straightforward to make a fast one and a single-file one, since that’s how the Decaf branch works (X448 is different from decaf, of course, because it uses different encodings for everything).

Cheers,
— Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20151019/8a39a8b9/attachment.html>