<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 19, 2015, at 1:44 PM, Ben Harris <<a href="mailto:ben@bharr.is" class="">ben@bharr.is</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">On 20 Oct 2015 5:06 am, "Jason A. Donenfeld" <<a href="mailto:Jason@zx2c4.com" class="">Jason@zx2c4.com</a>> wrote:<br class="">
><br class="">
> Hi folks,<br class="">
><br class="">
> I've got a few naive question about Goldilocks.</p><p dir="ltr" class="">I'll take a stab from the point of view of an outside observer. </p><p dir="ltr" class="">><br class="">
> Why would somebody use Curve448? Curve25519 is 126bits,</p><p dir="ltr" class="">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. </p></div></blockquote><div>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.</div><div><br class=""></div><div>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.</div><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">> How come Curve448 is receiving much attention, but Curve41417 is not?<br class="">
> Is 448 faster? More easily implemented in a secure fashion?</p><p dir="ltr" class="">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.</p><p dir="ltr" class="">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).</p>
</div></blockquote></div>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.<div class=""><br class=""></div><div class="">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.</div><div class=""><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">— Mike</div></div></body></html>