[noise] ECDH Authentication - Signatures vs Authenticated Encryption

[Trevor Perrin]

On Sat, Jun 13, 2015 at 1:49 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Hi Trevor, Mike,
>
> Thanks for your feedback. One thing that's not so appealing about a
> HandshakeXS is that it requires the server to respond (and store data)
> without authenticating the client at all first. This is a problem for me
> implementation wise, as in fact this code is running in the kernel (!!), and
> I'd like it to be both totally silent unless there's a valid client, and I'd
> like it to totally avoid allocations, unless there's a valid client.

The client's first message can always be replayed, so unless you want
the server to manage a replay backlist (probably dangerous) or do
something with pre-published ephemeral keys (probably too complicated)
this isn't really achievable.


> I guess, though, this could be solved just by appending signatures to each
> message? That mostly looses the identity hiding aspect, but I guess that's
> okay.

A signed first message can still be replayed.

You're right that a signed first message would not be vulnerable to
KCI against the server in the way a static-static DH would.  But given
that a signed first message is still vulnerable to replay, still
doesn't have forward-secrecy, doesn't have identity-hiding, and adds a
signature, I'm not sure that benefit outweighs the costs.

So I'd like to see if your case can be handled without signatures.
I'm working on another Noise draft and I'd like to simplify and focus
on the DH-only case.

My previous suggestion could be simplified (as I think Mike suggested):

TripleDH with mutually-known static keys:
  -> e, dhes
  <- e, dhee, dhes

But if you want some client-auth in first message, you could use the
static-static DH (just keep in mind that the auth in first message is
replayable and vulnerable to KCI):

QuadrupleDH with mutually-known static keys:
   -> e, dhes, dhss
   <- e, dhee, dhes

Do either of those work?


Trevor