Re: [Cfrg] Comparing ECC curves

Watson Ladd <> Thu, 24 July 2014 01:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 605391A03D6 for <>; Wed, 23 Jul 2014 18:10:47 -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 nKNngPvHFywo for <>; Wed, 23 Jul 2014 18:10:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 304701A03F2 for <>; Wed, 23 Jul 2014 18:10:42 -0700 (PDT)
Received: by with SMTP id 10so1344103ykt.3 for <>; Wed, 23 Jul 2014 18:10:41 -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=7ZQ3raNANwN6As5TEY6vm6L44ttpCqHpopRwss4hmvE=; b=h1fgpLbp/qdInw9CefB2JE1wNPQFBlVuilFXRUy78sQzQdeehod/raaCPb5aZd9jlP zl2aH8ZaKqEPSZLnD9bXZGdDc2tajJ1jagZqbUx6iYyrzN8fZdPV0OO81o1wSjmhoX+A LB3qBAgDZqbPT2twyX8M/ttlg//2j6TEi7l9DhHbtLRZ3S8lzentUssAq5NdtU3uOUIZ FOX/jIclrb/VrhRnUbf8ptx/CZQcKpyA1H9bWysfGpxaFrky27M+WBtSENce9u1CTOSK 9Xk4C2Ae/Oxpt2gC8aDeuv81RTf4dG2t6eG9+6VHnn8XlF51sENlKafSM722XlwXF74s 3VuQ==
MIME-Version: 1.0
X-Received: by with SMTP id d32mr7262285yhb.66.1406164240998; Wed, 23 Jul 2014 18:10:40 -0700 (PDT)
Received: by with HTTP; Wed, 23 Jul 2014 18:10:40 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 23 Jul 2014 18:10:40 -0700
Message-ID: <>
From: Watson Ladd <>
To: Phillip Hallam-Baker <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [Cfrg] Comparing ECC curves
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Jul 2014 01:10:47 -0000

On Wed, Jul 23, 2014 at 4:17 PM, Phillip Hallam-Baker
<> wrote:
> On Wed, Jul 23, 2014 at 6:33 PM, Benjamin Black <> wrote:
>> On Wed, Jul 23, 2014 at 3:28 PM, Phillip Hallam-Baker
>> <> wrote:
>>> 3) Do we need to consider 2^192 work factor?
>>> I can't see any case where I am interested in a work factor of 2^192.
>>> Either I am willing to make some concession to performance or I want
>>> it gold plated and 2^256. I would quite like to see the 2^192 work
>>> factor nuked.
>> Phillip,
>> This was our conclusion, as well. If you haven't seen it, here's the NUMS
>> TLS draft which only specifies the twisted Edwards curves at 128 and 256 bit
>> security levels:
> Just trying to push back on the idea we need the options .. :-)
> Similarly, I am not interested in a set of curves that is
> hyperoptimized for TLS and can't be used for S/MIME. When we were
> discussing random curves, changing the curve was pretty much the same
> as changing the key. Now that we are doing the close to powers of 2
> curves with highly optimized code, changing the curve is like changing
> to a whole new algorithm.
> As far as the code is concerned it is better to think about them as
> choosing between ECDHE-25519 and ECDHE-256p rather than ECDHE with a
> named curve. Changing the curve is going to select a different
> implementation.
> The end product I want from this is a set of backup public key
> algorithms that can be made a RECOMMENDED algorithm with a view to
> making them a MUST algorithm replacing RSA-2048 at some point in the
> future. I want to encourage dedicated hardware support, etc. etc.

Why will that happen with these curves when it didn't with the NIST
curves vs. RSA?
Yes, I'm aware of patent issues that used to exist, but this was an
unforced error in
standardization: RSA is of a similar vintage.

> This means that I really don't want TLS to go and choose something
> that is going to fail if we try to apply it to S/MIME or PGP. We can
> use DH for email encryption but only one of the keys can be ephemeral.
> The recipient key is going to have to be static.

Not being at IETF 90 I can't comment on the standardization, but I
certainly can comment
on the cryptography. All protocols use ECDH and signatures, and any
twisted Edwards curve
will work for both. The only debate is how to represent points for
ECDH, which exact prime to use,
and the exact curve to use. There are many implemented, functioning
systems using Curve25519
and Ed25519 and friends, without any problems.

(What you propose for email encryption is in fact what ECIES does,
which is what OpenPGP does)

> I would suggest as a way forward here we look at the protocol
> requirements for TLS, PKIX and S/MIME as they represent the two poles
> of protocol design. I would be rather surprised to find IPSEC, SSH
> etc. to have dramatically different requirements to TLS. S/MIME and
> PGP on the other had are store and forward which makes them very
> different beasts. I would also separate out TLS and PKIX because one
> is a single protocol and the other is infrastructure.
> [DNSSEC does actually have a different requirement from PKIX, data
> size, but that is probably not going to be a deciding factor between
> curves]

Point compression can dramatically shrink keys. The patent expires next Tuesday,
and Curve25519 never infringed upon it.

However, DNSSEC still uses RSA, despite ECC existing and making sizes
much smaller.

> It would clearly be nuts for the IETF to choose a curve that does not
> work well for TLS. But I don't see the differences between the curves
> on TLS being so great that we should accept a curve that we can't use
> in every reasonable protocol.

That won't happen.

Watson Ladd
> _______________________________________________
> Cfrg mailing list

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