Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS

Michael StJohns <> Wed, 10 June 2015 17:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ECDA11ACE6B for <>; Wed, 10 Jun 2015 10:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fwl4LboSnyvL for <>; Wed, 10 Jun 2015 10:27:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4739F1B2EFB for <>; Wed, 10 Jun 2015 10:27:18 -0700 (PDT)
Received: by qkx62 with SMTP id 62so28721194qkx.3 for <>; Wed, 10 Jun 2015 10:27:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Y7HL+QVdAy5iYy9Qc+aTdbn8t0dt2rmLjkSQ6dEb0Ms=; b=fnwCbibgq3Lh53SWQIivsMatHQcGlTg8/6W31LUaiKU9PLtDg/LVwNJqUfjCNMZcCd bRqvROQGRGmqXZP1KgHefvExygamI3AorCwM7CKAR4Byu1JIcHCFMCvA8JKPkt1tJMMh DaLfM+2rj6zVk6zDfQ718U7mZ5HOcq2ajUlsOZSHv97BbseLLyLnqqDJkJcZzFLiCs1l ig5pA5w0pR2wNDrnrxNryXDBN4SPnacdwFfH6zYz3uhxxMMtmSeYY7Qy3WGOv1KY9DII swotAWUfA40pZ6MICEpOd1D0eWkha62ahgNFeTuVoM57TwyEBVBirT/eMEuQ+NdM97Ca 5q1g==
X-Gm-Message-State: ALoCoQkT9WXmnDWrL/zFVJ0yWSLVP/86OVn5nnHY4Qc/GBmYB9OfTy2r9jnWww/kSSc9/21zNqat
X-Received: by with SMTP id 132mr5849949qhs.2.1433957237530; Wed, 10 Jun 2015 10:27:17 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 106sm4410855qge.22.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 10:27:16 -0700 (PDT)
Message-ID: <>
Date: Wed, 10 Jun 2015 13:27:17 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Simon Josefsson <>
References: <> <> <> <20150601125302.GA19269@LK-Perkele-VII> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS
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: Wed, 10 Jun 2015 17:27:20 -0000

On 6/5/2015 10:06 PM, Simon Josefsson wrote:
> Michael StJohns <> writes:
>> Instead, get a new allocation and write a document that looks like
>> RFC5480 for the ED and Curve public keys.  You want certificate
>> representations for *both*.
> I've started this for EdDSA:
> Are you saying it would be useful to also specify certificate formats
> for Curve25519 ECDH keys?
> /Simon

Sorry - I missed this in the pile.

And yes for Curve25519.

Here's my thoughts:

Usually, you have a certificate with a public key in it that's used to 
sign an ephemeral (EC)DH public key.  The EPK is used to derive a shared 
secret and everything downstream is derived from that.   The session 
keys trace their authentication back through the shared secret, through 
the EPK and through the signature over the EPK to the certificate's 
public key.   And the public key in the certificate chains back to some 

With key agreement keys such as ECDH, Curve25519 or DH, what you can do 
instead is to use the key in the certificate with the other side's 
certificate key, to derive one half of the total shared secret and the 
senders EPK with the receiver's ephemeral private key to derive the 
second half.  Concatenate those and then derive your downstream keys 
from them.

(e.g.  ECDH (PermPrivate1, PermPublic2) || ECDH (EphemPrivate1, 
EphemPublic2) )

The certificate keys chain as before, so that you know that the first 
half of the shared secret is derived from authentic data and is itself 
authentic.  Combining the first half of the shared secret with the 
second half still gives you authentic data (but results in a varied 
shared secret for each call).  And that means downstream keys derived 
from the combined shared secrets can still be traced back to the 
certificate authentication root.

The nice thing about this scheme (It's called a C(2,2) scheme in NISP 
SP800-56A parlance), is that you don't need to sign anything during a 
key agreement handshake.  You still need traditional signature schemes 
over the certificates, but you don't actually need them in the handshake.

There are other schemes where one side only has ephemeral keys (e.g. 
client without cert) where this still works - you end up with:

ECDH (PermPrivate1, EphemPublic2) || ECDH (EphemPrivate1, EphemPublic2)

This just works with the existing EC Prime and F2M curves as the key 
pairs can be used with both ECDSA and ECDH.

In any event, going ahead and creating a certificate format for 
Curve25519 at the same time you do ED25519 probably makes sense given 
the two algorithms are family members and appear to share a representation.