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

[Michael StJohns <[e-mail]>]

On 6/5/2015 10:06 PM, Simon Josefsson wrote:
> Michael StJohns <[e-mail]> 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:
> https://tools.ietf.org/html/draft-josefsson-tls-ed25519-00
>
> 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 
root.

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.

Mike