Hi Trevor, Mike,<div><br></div><div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>But along that line, couldn't the "key-compromise impersonation" attack be warded off just by adding signatures to my original two step exchange?</div><div><br></div><div>(By the way, anyone have a good implementation of Trevor's Curve25519-Signatures spec?)</div><div><br></div><div>Jason<br><br>On Friday, June 12, 2015, Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jun 10, 2015 at 6:49 AM, Jason A. Donenfeld <<a href="javascript:;" onclick="_e(event, 'cvml', 'Jason@zx2c4.com')">Jason@zx2c4.com</a>> wrote:<br>
><br>
> 1. client -> server:<br>
>    key1 = key2 = HKDF(client longterm private key * server longterm public<br>
> key)<br>
>    AUTHENTICATED_ENCRYPTION(client ephemeral public key, key1)<br>
> 2. server -> client:<br>
>    key2 = key1 = HKDF(server longterm private key * client longterm public<br>
> key)<br>
>    AUTHENTICATED_ENCRYPTION(server ephemeral public key, key2)<br>
<br>
<br>
You're assuming both parties knows the other's long-term public key.<br>
So I'll stick with that.<br>
<br>
Noise would chain the DH calculations together, so all later keys<br>
depend on earlier DHs.  Assuming you changed to do that, you'd be<br>
proposing something like below, in the terminology of [1]:<br>
<br>
  -> dhss, e         # client does static-static DH, encrypts an ephemeral<br>
  <- dhse, e, dhee   # server does static-ephemeral DH, encrypts an ephemeral<br>
<br>
<br>
Relying on the static-static ephemeral for client authentication means<br>
a "Key-compromise impersonation" weakness: if the client's long-term<br>
key is compromised, the attacker can impersonate anyone else *to* the<br>
client.<br>
<br>
It seems like you don't exchange any application data until the first<br>
round-trip is complete.  So the "HandshakeXS" pattern from [1] might<br>
be suitable:<br>
<br>
HandshakeXS:<br>
  -> e, dhes<br>
  <- e, dhee<br>
  -> s, dhse<br>
<br>
Which incrementally constructs a "TripleDH", as Mike points out.<br>
<br>
This transmits the client's long-term public key in the third message<br>
(which can also contain appplication data).  You could optimize<br>
slightly by omitting the transmission of "s" (the client's long-term<br>
public key), since you're assuming that's already known to the server:<br>
<br>
  -> e, dhes<br>
  <- e, dhee<br>
  -> dhse<br>
<br>
Is that about what you want?<br>
<br>
<br>
Trevor<br>
<br>
<br>
[1]<br>
<a href="https://moderncrypto.org/mail-archive/noise/2015/000112.html" target="_blank">https://moderncrypto.org/mail-archive/noise/2015/000112.html</a><br>
<a href="https://moderncrypto.org/mail-archive/noise/2015/000119.html" target="_blank">https://moderncrypto.org/mail-archive/noise/2015/000119.html</a><br>
</blockquote></div></div><br><br>-- <br>Jason A. Donenfeld<br>Deep Space Explorer<br>fr: +33 6 51 90 82 66<br>us: +1 513 476 1200<br><a href="http://www.jasondonenfeld.com" target="_blank">www.jasondonenfeld.com</a><br><a href="http://www.zx2c4.com" target="_blank">www.zx2c4.com</a><br><a href="http://zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc" target="_blank">zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc</a><br>