[noise] Noise Explorer

[Karthikeyan Bhargavan]

> This looks to me a bit like an unknown key-share attack against the initiator:

It looks like a UKS yes, I didn’t call it that because the two of the three parties aren't authenticated.
As far as I know, none of the static-key-based authenticated patterns in Noise has a UKS (Nadim’s analysis should confirm this)
primarily because of the handshake hash including the initiator's and responder’s static public keys (if they are known at this point in the protocol).

Would be fun to see if they appear in one of the PSK/Signature/Deferred patterns.

-Karthik

> 
>  - the initiator A thinks they have a session with the responder B, and
>  - there is indeed a session with the same key at the responder B, but
>  - B thinks that that session is in fact with the adversary E.
> 
> Are there (authenticated) Noise protocols for which the above can happen? If so, is that intentional?
> 
> best,
> Katriel
> 
> On Wed, 23 May 2018, at 6:55 PM, Karthikeyan Bhargavan wrote:
>>> Also, can you explain the attack where there is the comment
>>> "However, if the responder carries out a separate session with a separate,
>>> compromised initiator, this other session can be used to forge the authenticity
>>> of this message with this session's initiator." - not quite clear how
>>> this works…
>> 
>> I believe this scenario (attack is too strong a word) generally occurs 
>> in stages when the initiator is not (yet) authenticated;
>> so the attacker can forward the initiator’s message over its own 
>> connection to the responder,
>> and the responder’s responder (intended for the attacker) can be 
>> forwarded by the attacker to the initiator.
>> Consequently, even if this the second flight (response) is authenticated 
>> by the responder, and hence provides
>> sender authentication, it does not provide receiver authentication.
>> 
>> More generally, I would like to see “receiver authentication” included 
>> in the authenticity goals (perhaps as level 3?)
>> This property means that if Bob receives a message from Alice, he knows 
>> that Alice intended to send this message to Bob and not to someone else.
>> Currently, receiver authentication is buried in the text of the secrecy 
>> properties and this feels less than ideal.
>> 
>> -Karthik
>> 
>> 
>>> 
>>> Justin
>>> _______________________________________________
>>> Noise mailing list
>>> Noise at moderncrypto.org
>>> https://moderncrypto.org/mailman/listinfo/noise
>> 
>> _______________________________________________
>> Noise mailing list
>> Noise at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/noise
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise