[noise] Noise Explorer

Trevor Perrin trevp at trevp.net
Thu May 24 01:22:03 PDT 2018


On Wed, May 23, 2018 at 5:55 PM, Karthikeyan Bhargavan
<karthik.bhargavan at gmail.com> 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.

Thanks Karthik,

Is this just a terminology difference?

The Noise spec discusses two security "properties" for each payload, in 7.4:

"""
Each payload is assigned an "authentication" property regarding the
degree of authentication of the sender provided to the recipient, and
a "confidentiality" property regarding the degree of confidentiality
provided to the sender.
"""

The difference between these properties is which party they're being
provided to.

I think you're objecting to the terms "authentication" and
"confidentiality" for this, because you view authentication as
relevant to both parties ("sender authentication", "receiver
authentication").

If we relabelled the two properties in the Noise spec to something
like "recipient security properties" (instead of "authentication") and
"sender security properties" (instead of "confidentiality"), would
that clear things up and match your categories?

Trevor


More information about the Noise mailing list