[noise] Noise Explorer

[Trevor Perrin]

On Wed, May 23, 2018 at 1:47 PM, Nadim Kobeissi <nadim at symbolic.software> wrote:
>
> Second, unlike the regular patterns, the deferred patterns are not
> described in the specification with extra, "tokenless" message arrows
> (which indicate protocol messages with no new key exchange or negotiation
> operations.) Therefore, they do not appear in the compendium with tokenless
> messages either.


The "tokenless" messages were just used in security tables to indicate
cases where the sender's post-handshake messages have different
security properties than their last handshake message.

In theory you could work this out automatically, e.g. by
experimentally adding tokenless messages, re-running your process, and
if you get any different results with "tokenless" messages then you'd
display them.

That would be a good test for all patterns - otherwise I am just
manually trying to work out the security properties, and that's
exactly what we want to automate...  But of course, it would add more
time to your runs.

Anyways, thanks for starting on the deferred patterns, once we've
handled the "tokenless" aspect I want to compare all the deferred
patterns vs the fundamental pattern they were derived from.  If we
could do this in the next few days it would be wonderful to have more
confidence in the new patterns before publishing rev34.  There's a few
checks we could make:
 * 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

I'm sure we could check some other invariants about the relationship
between fundamental / deferred patterns, but we'd have to think more.

---

About your earlier statement:

> With regards to the results we have already, they match the ones in your existing table, but are more nuanced since we added two more authenticity grades (3 and 4), since our security model includes a compromised principal.

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

Trevor