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

Watson Ladd <> Fri, 27 June 2014 04:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 64C091B306F for <>; Thu, 26 Jun 2014 21:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Slyhizwy5tIb for <>; Thu, 26 Jun 2014 21:15:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83C111B2F49 for <>; Thu, 26 Jun 2014 21:15:33 -0700 (PDT)
Received: by with SMTP id 200so2564420ykr.30 for <>; Thu, 26 Jun 2014 21:15:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wOW9O4ZzwLV65mddLFhvzsQGgJR6sBLE2EqW2nLdz0g=; b=KOn4nfLBI2wMhM9arxAsm8qIAuFQvUcbwa/nVj2O9QHImL3BtSmP3+Lsv/NWP4+6ZH djvP7gS2ksqiUzpnRNubUm+Nn9CkUME0Zf7VST31VwxEkN6gHpEw5UorU8NTrnNHNFJG ZRvmQXYzt4NeqlB/SiJX7j32cHeBaDt8l3fG+YlwPT4Go/dHWNi2MChyOjmEJlmpz+Jd lj184n5HflyeSqPmOHMIEBigpgFlWrRj5WA+egD9BJs/+jR8Lruw0EeM2DCUCaLxFSpT UrnmPlII2kLfGo06YawZVlt91GVzELxGSczomqryYiW/uMIoWuAqKXwIOx94eKNkf4P/ QcHw==
MIME-Version: 1.0
X-Received: by with SMTP id u47mr28349221yhl.66.1403842532888; Thu, 26 Jun 2014 21:15:32 -0700 (PDT)
Received: by with HTTP; Thu, 26 Jun 2014 21:15:32 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 26 Jun 2014 21:15:32 -0700
Message-ID: <>
From: Watson Ladd <>
To: Peter Gutmann <>
Content-Type: text/plain; charset=UTF-8
Cc: "<>" <>
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 04:15:38 -0000

On Thu, Jun 26, 2014 at 8:49 PM, Peter Gutmann
<> wrote:
> Viktor Dukhovni <> 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.

Watson Ladd
> Peter.
> _______________________________________________
> TLS mailing list

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