[noise] ECDH Authentication - Signatures vs Authenticated Encryption

[Trevor Perrin]

On Wed, Jun 10, 2015 at 6:49 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> 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)


You're assuming both parties knows the other's long-term public key.
So I'll stick with that.

Noise would chain the DH calculations together, so all later keys
depend on earlier DHs.  Assuming you changed to do that, you'd be
proposing something like below, in the terminology of [1]:

  -> dhss, e         # client does static-static DH, encrypts an ephemeral
  <- dhse, e, dhee   # server does static-ephemeral DH, encrypts an ephemeral


Relying on the static-static ephemeral for client authentication means
a "Key-compromise impersonation" weakness: if the client's long-term
key is compromised, the attacker can impersonate anyone else *to* the
client.

It seems like you don't exchange any application data until the first
round-trip is complete.  So the "HandshakeXS" pattern from [1] might
be suitable:

HandshakeXS:
  -> e, dhes
  <- e, dhee
  -> s, dhse

Which incrementally constructs a "TripleDH", as Mike points out.

This transmits the client's long-term public key in the third message
(which can also contain appplication data).  You could optimize
slightly by omitting the transmission of "s" (the client's long-term
public key), since you're assuming that's already known to the server:

  -> e, dhes
  <- e, dhee
  -> dhse

Is that about what you want?


Trevor


[1]
https://moderncrypto.org/mail-archive/noise/2015/000112.html
https://moderncrypto.org/mail-archive/noise/2015/000119.html