[noise] ECDH Authentication - Signatures vs Authenticated Encryption

[Trevor Perrin]

On Sat, Jul 4, 2015 at 10:30 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Hi folks,
>
> Sorry for all the noise (hah), but I've just finished a week of
> binging on crypto papers, and I have a better idea of what I'm looking
> for. Please -- if my novice inquiries are getting tiresome, do feel
> completely free to send me an email onlist or offlist

This is fine - the spec needs to be reviewed against use cases and
probably some test implementation, people's experiences here are
helpful.


> A client knows the server's IP address, port, and public key.
> A server has a list of public keys it will accept, but doesn't know
> from where each will be connecting.
> Assuming a UDP-based connection-less setup.
>
> I believe this setup here is a candidate for HandshakeXK:
>
> HandshakeXK:
>   <- s
>   ******
>   -> e, dhes
>   <- e, dhee
>   -> s, dhse
>
> There is a major problem with this, however, that I alluded to before.
> I have two additional requirements:
>
> 1. Silence: a server or a client simply will not respond to any
> invalid or unauthenticated packets.

It seems like you want the first message authenticated from the
client's public key, and have pre-knowledge of the server's public
key.  So you could modify above to authenticate the first message
using static-static DH: does this work?

  <- s
  ******
  -> e, dhes, s, dhss
  <- e, dhee, dhes

This doesn't have a name yet, but it's perhaps another class of
protocols we could add.


> I'd like to avoid using signatures, to keep things simple, but if I
> must use a signature in the end, then I must. What's the proper way to
> address these two requirements within noise? Plus, there's an issue of
> replay, when doing authentication before the handshake has completed,
> though perhaps timestamping (YUCK!) could be used here...

Replay of the first message is a real problem.  No great solution I
know short of timestamps or blacklists.


Trevor