Re: [TLS] Safe ECC usage

Santosh Chokhani <> Mon, 30 September 2013 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BAB0D21F9B08 for <>; Mon, 30 Sep 2013 12:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UKKbt3UEKq8I for <>; Mon, 30 Sep 2013 12:27:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A81A021F9AA2 for <>; Mon, 30 Sep 2013 12:27:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.90,1009,1371096000"; d="scan'208";a="6967927"
Received: from unknown (HELO ([]) by with ESMTP; 30 Sep 2013 15:27:33 -0400
Received: from ([fe80::d8df:b0bd:28be:ad62]) by ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Mon, 30 Sep 2013 15:27:32 -0400
From: Santosh Chokhani <>
To: Adam Langley <>, Kyle Hamilton <>
Thread-Topic: [TLS] Safe ECC usage
Thread-Index: AQHOus0hxRWfY2/0v0+mMH+5HrNeJpncmboAgAIQIACAAAYSwA==
Date: Mon, 30 Sep 2013 19:27:31 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 19:27:38 -0000


Simply copying RSA template and thus the key usage bits should not yield the behavior you mention.  RSA certificates should set the key encipherment bit.  EC type certificates should not set that bit; the appropriate bit is key agreement.

So, either someone or software is doing that mental translation.

Products should not use a certificate for ECDH or DH key agreement if the key encipherment bit is set.

-----Original Message-----
From: [] On Behalf Of Adam Langley
Sent: Monday, September 30, 2013 11:03 AM
To: Kyle Hamilton
Subject: Re: [TLS] Safe ECC usage

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.


TLS mailing list