[noise] ECDH Authentication - Signatures vs Authenticated Encryption

[Michael Hamburg]

If the parties know each others’ long-term public keys, though, that third message is redundant, right?  But I guess you can’t use triple-DH in this case.  You’d need either a signature or a static-static DH to authenticate the client if you want to do so in the first flow.

— Mike

> On 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.
> 
> 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 <mailto:trevp at trevp.net>> wrote:
> 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/000112.html>
> https://moderncrypto.org/mail-archive/noise/2015/000119.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 <http://www.jasondonenfeld.com/>
> www.zx2c4.com <http://www.zx2c4.com/>
> zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc <http://zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc>
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org <mailto:Noise at moderncrypto.org>
> https://moderncrypto.org/mailman/listinfo/noise <https://moderncrypto.org/mailman/listinfo/noise>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150613/01a0c3f4/attachment.html>