[noise] Noise Explorer

[Nadim Kobeissi]

Hello everyone,
I will try to respond to all the comments.

Regarding "tokenless" messages: I understand their original intended
purpose and agree that it would be nice to have them for all 22 deferred
patterns. Now that we have a preliminary analysis of the deferred patterns,
I will proceed to add two "tokenless" messages to each deferred pattern and
to re-run the analysis. In fact, I will also go through the fundamental
patterns again and add an extra "tokenless" message to each fundamental
pattern that only currently has one "tokenless" message, just to make
everything line up neatly.

This will result in a greatly increased verification cost, so probably
expect results by the end of the week. Nevertheless, it's good to have at
least rolled out revision 34 support with some solid results already for
deferred patterns.

Trevor suggests two useful questions here:
> * The deferred pattern ends up with same security properties for
sender and recipient as the fundamental pattern
> * The deferred pattern is identical up until the point where an
authentication gets deferred

These two questions will automatically be answerable once "tokenless"
messages are added, given that the results for the fundamental patterns all
already exist.

Finally, Trevor asks:
> That's interesting, could you give a quick summary of the new
authentication grades?  I'm curious what we failed to capture in the
Noise spec, and whether we should add these details in the next spec
(34).

Here is a very quick summary of the changes to the authenticity properties:
0: Same as 0 in the original specification.
1: Same as 1 in the original specification, but does not hold if the sender
also initializes a separate session with a compromised principal.
2: Same as 2 in the specification, but does not hold if the sender also
initializes a separate session with a compromised principal.
3: Same as 1 in the original specification.
4: Same as 2 in the original specification.

Karthik has already answered some of the other comments. Thank you, Karthik!

I will now get to work on making sure every Noise Handshake Pattern in the
compendium has two "tokenless" messages, and re-run the analyses that need
re-running.


Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office
On Wed, May 23, 2018 at 8:18 PM Karthikeyan Bhargavan <
karthik.bhargavan at gmail.com> wrote:

> > 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

> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise