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

From: Peter Gutmann <[email-masked]>
Date: Fri, 27 Jun 2014 03:49:09 +0000

Viktor Dukhovni <[email-masked]> 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.

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 26 Jun 2014 21:15:32 -0700

> 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
> [email-masked]
> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Jun 2014 05:28:19 +0000

On Thu, Jun 26, 2014 at 09:15:32PM -0700, Watson Ladd wrote:

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

I don't think Peter's response is *that* unreasonable, we don't
need to pick up our toys and move to another sandbox.

There is perhaps room for differences of opinion on the subject of
whether Curve25519 does or does not represent state of the art, or
as-yet unproven novelty.  I don't feel qualified to engage in debate
on that issue.  Rather, on the specific question of yet more curves
of the same type as before, it seems to me that the advantage is
likely negligible, and I don't see significant likelihood of
widespread or timely adoption.

At least with 25519, if it is deemed reasonably sound, there are
multiple reasons why it might be preferable to the previous generation
of curves.  Whether we should expect more surprises than with
traditional curve shapes, is a difficult question.  The main
plausible objection is perhaps that curves over fields with
characteristic very close to a 2-power are somehow too special,
and may admit non-generic attacks.  Are there additional ways in
which 25519 is substantially non-generic?

-- 
	Viktor.