Re: [Cfrg] Requirements for curve candidate evaluation update

Phillip Hallam-Baker <> Thu, 14 August 2014 12:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 44F761A0ABF for <>; Thu, 14 Aug 2014 05:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8yeyA5Kx-OO8 for <>; Thu, 14 Aug 2014 05:16:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A19381A0AD0 for <>; Thu, 14 Aug 2014 05:16:24 -0700 (PDT)
Received: by with SMTP id 10so918521lbg.34 for <>; Thu, 14 Aug 2014 05:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DY6xr71UJhaUiaWG0Mv+VkBHuZ+KtDjXErIwNaJL/Fg=; b=An+7LWSPwvVlS9hAKbT8GomhNN5U1KLWV8Y4cmlLVm1pNH0eRERVkulEWXQ1CytaS6 DgRtuHwtlxq/CGVTW141yHbdW0e50i7YgzJefrXQbLTIUf9+y7gfpLZT1ulqNVHuxQ+S K4iajbW+p4rmAR8WAQd73d58PQplgFR0L4MUV2jqyA3b259361jRG2WygLCvTofPC0XH BE+TK99aEecfK/aOSqRv7fPFTzpCHACc4TyQXPDcOO3cLsnfOPG5bbQOWdEN+UtINjbT ntD2pEmE23yfO6d0SuYuDvO2YHE02QZNTHTt9lHXgescIyKtEHLp8H+SfhLTpZfHlA9I A5sw==
MIME-Version: 1.0
X-Received: by with SMTP id lk9mr4743756lac.21.1408018582859; Thu, 14 Aug 2014 05:16:22 -0700 (PDT)
Received: by with HTTP; Thu, 14 Aug 2014 05:16:22 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Thu, 14 Aug 2014 08:16:22 -0400
X-Google-Sender-Auth: UUo5Z0d39Z9LT43iEpglq5sxjdo
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Benjamin Black <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [Cfrg] Requirements for curve candidate evaluation update
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, 14 Aug 2014 12:16:40 -0000

On Wed, Aug 13, 2014 at 11:00 PM, Benjamin Black <> wrote:
> "The use of ECC to date in open standards based systems is so
> insignificant that we really should not think twice about blowing it
> all up and starting from scratch."
> ECDHE is the default kx for Google, Microsoft, Facebook, Twitter, and many
> other large service providers. Perhaps you mean ECDSA.

No, I see no reason to consider that use as relevant at all to the
decision of what the preferred curves should be for the industry for
the future.

ECDHE does not create legacy issues because it is by definition always
a direct negotiation between two parties who both know what they are
doing. So transition is simply specifying a new cipher suite.

Transition in the PKIX part of TLS is really hard because a curve is
only useful if everything under the sun supports it.

The issue is not who uses is but what the switching costs are. I am
looking at the parts of the problem with the highest switching costs.

> "And it really makes no sense to want to do that
> and be shooting yourself in both feet by using signature keys for
> encryption or vice versa."
> Which encryption do you mean here?

Encryption of static data and key exchange really should be separate
from signing.

One protocol design aspect that bleeds in here is how the key exchange
works. There are two mechanisms that can be used for doing ephemeral
keys (leaving out mutual auth for the moment)

A) Encrypt the ephemeral key under the server's public key.

B) Server returns an ephemeral key and client nonce signed by its
private key. [Or alternatively authenticated under a MAC derived from
a master session key]

>From a proof point of view, both seem equally secure but A is actually
a lot better than B because it allows for depth in security.

I want the security of the connection to be protected by both the
master keys and the ephemerals. So breaking an ephemeral only allows
an attack if the master key is also compromised. Sending an
authenticated key across en-clair is a lot weaker than using
encryption. What we should do is this:

A1) As for A but derive the session key from a hash of both the master
session secret and the result of the ephemeral agreement.

So if we have a WF-256 key we can still use a WF-128 ephemeral for
forward secrecy without reducing the security overall.

As a practical matter, we don't need to worry about the WF-192 key at
all, nobody will ever use it. And nobody is going to use less than
WF-256 with PKIX. It is however possible that DNSSEC would use WF-128
keys because of the different mode of use. Curve 25519 might well be
the right match there.