I think what you pointed out is correct. If you don’t have access to the private key of either the responder s or initiator e then you can’t see the initiator s. <br><br>So I’m not sure what your friend had in mind<br><br>David<br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 8, 2018 at 3:24 PM dawuud <<a href="mailto:dawuud@riseup.net">dawuud@riseup.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi.<br>
<br>
A friend of mine recently suggested that the Wire Guard noise handshake, IK<br>
allows an adversary to retroactively identify sessions belonging to a compromised<br>
client key. Is this true?<br>
<br>
IK(s, rs):<br>
<- s<br>
...<br>
-> e, es, s, ss<br>
<- e, ee, se<br>
<br>
Looking at this handshake pattern, it seems to me that in order to decrypt<br>
's' in the first handshake message, the adversary would need the server's private<br>
key since the client's ephemeral private key has been destroyed.<br>
<br>
If this is correct then shouldn't this be articulated in the security properties section<br>
before more developers decide to use it?<br>
<br>
I'm sure IK is tempting because:<br>
1. symmetrical computational overhead<br>
2. zero-RTT encryption<br>
<br>
<br>
David<br>
_______________________________________________<br>
Noise mailing list<br>
<a href="mailto:Noise@moderncrypto.org" target="_blank">Noise@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
</blockquote></div>