Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

On Thu, Jun 26, 2014 at 8:49 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Viktor Dukhovni <viktor1dane@dukhovni.org> writes:
>
>>If we have an opportunity to advance the state of the art, and use (subject
>>to CFRG review, ...) new EC techniques based on lessons learned after ECDSA,
>>that are more performant and less prone to implementation errors, then there
>>is a good reason to add new curves.
>
> If we're going to do that then we need to have something like the
> AES/SHA-3/PHC competition to decide on a suitable curve (and whatever other
> deckchairs are going to be rearranged in TLS 1.3), not just take the first
> trendy thing that pops up.  I have a great deal of respect for djb and he
> designs some really good stuff, but with the thought of having to implement
> huge amounts of new material for TLS 1.3 (after already having had to do it
> for 1.2) I really, really don't want to have to start again from scratch if,
> in two years' time, someone finds some issue in 25519 and/or the other bits
> that are being thrown in.  Using the oldest SSL algorithms that come to mind,
> 3DES, DHE, and HMAC-SHA1, I'm pretty confident that I'm, as I quoted a
> cryptographer earlier, "unlikely to be surprised".  Introducing several trendy
> new algorithms all at once gives me nothing like that level of confidence.

Already happened: Curve25519 was published in 2006. Since then quite a
few people have come up with new proposals, and the CFRG had a meeting
this spring to pick between them. Yes, this wasn't a formal contest,
but there has been a lot of work on new curve shapes, and Curve25519
has well-validated implementations, very good performance, and meets
all security criteria.

Furthermore, this is much more like picking a prime for DH, then
picking a block cipher: there are many bad choices, but
well-understood criteria for picking good ones. Because validation is
essential (*ahem*) we need a dictionary of supported options, and
because of the criteria you can play fun games to get extra speed.

The difference in shape eliminates a lot of pain for implementers. No
more special cases, no more validation and having to force callers to
handle errors that they might not be prepared to handle. It's a big
step forward in closing perennial issues in ECC implementations.

Furthermore, you can just rip the guts of NaCl out, the way you did to
support ECC in cryptlib. Only NaCl doesn't have the timing attack
vulnerability the EC functionality in cryptlib does. It's not much
more complicated than going from P-256 and P-224 to include P-384.

If you don't want to support it, fine: implement only P-256.

Sincerely,
Watson Ladd
>
> Peter.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin