[noise] wire guard handshake properties?

[David Wong]

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.

So I’m not sure what your friend had in mind

David
On Fri, Jun 8, 2018 at 3:24 PM dawuud <dawuud at riseup.net> wrote:

>
> Hi.
>
> A friend of mine recently suggested that the Wire Guard noise handshake, IK
> allows an adversary to retroactively identify sessions belonging to a
> compromised
> client key. Is this true?
>
> IK(s, rs):
> <- s
> ...
> -> e, es, s, ss
> <- e, ee, se
>
> Looking at this handshake pattern, it seems to me that in order to decrypt
> 's' in the first handshake message, the adversary would need the server's
> private
> key since the client's ephemeral private key has been destroyed.
>
> If this is correct then shouldn't this be articulated in the security
> properties section
> before more developers decide to use it?
>
> I'm sure IK is tempting because:
> 1. symmetrical computational overhead
> 2. zero-RTT encryption
>
>
> David
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180608/8218ea1f/attachment.html>