Re: [TLS] Safe ECC usage

Adam Langley <> Mon, 30 September 2013 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52A2E21F9B5A for <>; Mon, 30 Sep 2013 08:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JDn-AAg7S0uw for <>; Mon, 30 Sep 2013 08:03:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22c]) by (Postfix) with ESMTP id 3CC0521F9BB6 for <>; Mon, 30 Sep 2013 08:03:22 -0700 (PDT)
Received: by with SMTP id eo20so4588516lab.17 for <>; Mon, 30 Sep 2013 08:03:21 -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=YYcUAMSCD4vtkGViwo5MD7zsw2hGJaDayZUlWEEs5fk=; b=vXL8wrHBOrkFJ6TxPBxA9id3f4Uk0ZymqOfH0vepG0diSWxbK8V3ZlnU4mClc+eoGa hqpGcFuwtsUiu+1YLSpi8ShsMuivuDgeh9j2Jj6/ceD9wxhAMh3NqBmXnmFH1Jsdtg1N xisxHAvOhgyAMM3nChJDs+85vyXIIVCYGRU0AvLUlkA/129Ql74yAdpxZwh1Z/uxrlJV umMn8eLAG9Vr6xYA6xAbw5MIRkHaapw9rhDTyAHS13/10qrtxuAvIz3e0+a8hRngIffm bxlJq4nbdWlQ596ms3TRd1txDHVWqvbkkNgc26tOHSgpLj4NvPViFsrnGJ5HdwANDTlE 6j6A==
MIME-Version: 1.0
X-Received: by with SMTP id a9mr2180027lah.41.1380553401056; Mon, 30 Sep 2013 08:03:21 -0700 (PDT)
Received: by with HTTP; Mon, 30 Sep 2013 08:03:20 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 30 Sep 2013 11:03:20 -0400
X-Google-Sender-Auth: DpwfUArUkXzJGO7CMKUkLCG0pss
Message-ID: <>
From: Adam Langley <>
To: Kyle Hamilton <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [TLS] Safe ECC usage
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 15:03:23 -0000

On Sun, Sep 29, 2013 at 3:33 AM, Kyle Hamilton <> wrote:
> Or perhaps apply your (admittedly much better than mine) intellect to figure
> out how to create a single public key from a single private key which can be
> used for both signing and key derivation, thus permitting consolidation of
> both into a single X.509 Certificate structure?  The lack of this is in fact
> a major impediment to using self-signed certificates as containers for
> curve25519 public keys.

Current ECDSA deployments involve an ECDSA key in an X.509 certificate
and ephemeral, ECDHE keys being generated by the server as needed.
These ephemeral keys are signed by the ECDSA key.

A similar design would have an Ed25519 key in the X.509 certificate
and curve25519 used for ECDHE. I don't believe there's anything needed
to get that working save for switching out the algorithms.

(It is the case that some ECDSA certificates have both the signature
and key derivation bits set in the key usage. This means that OpenSSL,
at least, will allow it to be used for both ECDSA and fixed-ECDH. I'm
not aware of anyone who actually wants that however. As far as I've
seen, it's just the result of copying an RSA certificate template and
forgetting to update the KeyUsage.)

> Granted, I've been severely out of touch for quite a while, and it's
> possible that (e.g.) Ed25519 permits the use of the same public key in this
> manner (even though Ed25519 has a peculiar recordkeeping requirement which
> makes it less than ideal).

Ed25519 and curve25519 are the same curve so it is technically
possible to use an Ed25519 public key, with a bit of thought, as a
curve25519 key. However, I wouldn't recommend it. TLS certainly
doesn't need that.

> (Also, while I've hopefully got your attention, have you any plan to create
> an x64 ABI for Curve25519?  I'm currently having to use it via a COM wrapper
> I hacked up in C#, 64-bit processes calling via COM to a 32-bit process
> which exports only one function that COM doesn't mandate: curve25519(). This
> is insecure to COM-debug capable processes at the very least, as it requires
> that the caller provide the caller's private key over a public data bus.)

There are several implementations of curve25519 in SUPERCOP, including
amd64, asm versions (amd64-51); 64-bit, C code (donna_c64) and
portable C code (ref10). It would be pretty simple to convert the
ref10 code to C# if you wished.