[noise] ECDH Authentication - Signatures vs Authenticated Encryption

[Jason A. Donenfeld]

Hi guys,

I'm working on a kernel space VPN using some noise-like ideas. I'd like to
keep the number of back-and-forths in the protocol to an absolute minimum.
I want perfect forward secrecy, but I value fewer-round trips over identity
hiding. So I just use simple ECDH for that:

1. client -> server:
   client ephemeral public key
2. server -> client:
   server ephemeral public key
3. client -> server:
  vpn data encrypted with symmetric authenticated encryption using as its
key HKDF(client ephemeral private key * server ephemeral public key)
4. server -> client:
  vpn data encrypted with symmetric authenticated encryption using as its
key HKDF(server ephemeral private key * client ephemeral public key)

So far so good?

I'd obviously like steps 1 and 2 to be properly authenticated with the long
term keys of the client and server. The most obvious way to do that is with
a signature algorithm:

1. client -> server:
   client ephemeral public key | SIGNATURE(client ephemeral public key,
client longterm private key)
2. server -> client:
   server ephemeral public key | SIGNATURE(server ephemeral public key,
server longterm private key)

This seems to work, but in practice it makes my codebase a bit more
cumbersome, as in addition to the simple curve25519 function for ECDH, I
now have to bring in the family of ed25519 functions. I see that noise
avoids signatures by using authentication encryption with ECDH derived
shared secrets. What I'm wondering is - would the below work correctly
(securely), as steps 1 and 2:

1. client -> server:
   key1 = key2 = HKDF(client longterm private key * server longterm public
key)
   AUTHENTICATED_ENCRYPTION(client ephemeral public key, key1)
2. server -> client:
   key2 = key1 = HKDF(server longterm private key * client longterm public
key)
   AUTHENTICATED_ENCRYPTION(server ephemeral public key, key2)

Is this valid? Is there something else I need to keep in mind here?

Thanks,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150610/7824e2e0/attachment.html>