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

Viktor Dukhovni <> Fri, 27 June 2014 05:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B79CD1B315A for <>; Thu, 26 Jun 2014 22:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uutq8aSoBO24 for <>; Thu, 26 Jun 2014 22:28:21 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF6101B2F1B for <>; Thu, 26 Jun 2014 22:28:20 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 0DA0E2AB299; Fri, 27 Jun 2014 05:28:19 +0000 (UTC)
Date: Fri, 27 Jun 2014 05:28:19 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Jun 2014 05:28:22 -0000

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

> > 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.
> If you don't want to support it, fine: implement only P-256.

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?