[noise] ECDH Authentication - Signatures vs Authenticated Encryption

[Jason A. Donenfeld]

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.

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.

But along that line, couldn't the "key-compromise impersonation" attack be
warded off just by adding signatures to my original two step exchange?

(By the way, anyone have a good implementation of Trevor's
Curve25519-Signatures spec?)

Jason

On Friday, June 12, 2015, Trevor Perrin <trevp at trevp.net> wrote:

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


-- 
Jason A. Donenfeld
Deep Space Explorer
fr: +33 6 51 90 82 66
us: +1 513 476 1200
www.jasondonenfeld.com
www.zx2c4.com
zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150613/e05d1e39/attachment.html>