[noise] Noise Explorer

[Justin Cormack]

Thats why testing is important! It is good that you picked up an error even
if it was mistaken... For an earlier release we had a machine readable
list, it would be nice if we could automate more of the spec generation
from a base list of patterns.

On Thu, 24 May 2018, 20:30 Nadim Kobeissi, <nadim at symbolic.software> wrote:

> Thanks, sorry about that!
>
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> Sent from office
>
> On Thu, May 24, 2018 at 8:30 PM Justin Cormack
> <justin at specialbusservice.com>
> wrote:
>
> > You are missing the fourth line with se on that pattern
>
> > On Thu, 24 May 2018, 18:51 Nadim Kobeissi, <nadim at symbolic.software>
> wrote:
>
> >> Hello everyone,
>
> >> I just noticed something:
>
> >> X1X1:
> >>       -> e
> >>       <- e, ee, s
> >>       -> es, s
> >>       <-
> >>       ->
>
> >> In this pattern, a static key is sent by the initiator (in the third
> >> message) and never used. According to Katriel's suggestion of
> invalidating
> >> Noise Handshake Patterns that would send unused key shares, this
> >> description of X1X1 would be invalid.
>
> >> What should be done? Modify X1X1, or annul Katriel's proposed
> restriction?
>
> >> Nadim Kobeissi
> >> Symbolic Software • https://symbolic.software
> >> Sent from office
> >> On Thu, May 24, 2018 at 7:30 PM Nadim Kobeissi <nadim at symbolic.software
> >
> >> wrote:
>
> >> > Dear Trevor,
>
> >> > Here is the exact text of the grades in question in today's Noise
> >> > specification:
>
> >> > Authenticity grade 1: "Sender authentication vulnerable to
> key-compromise
> >> > impersonation (KCI). The sender authentication is based on a
> static-static
> >> > DH ("ss") involving both parties' static key pairs. If the recipient's
> >> > long-term private key has been compromised, this authentication can be
> >> > forged. Note that a future version of Noise might include signatures,
> >> which
> >> > could improve this security property, but brings other trade-offs."
>
> >> > Authenticity grade 2: "Sender authentication resistant to
> key-compromise
> >> > impersonation (KCI). The sender authentication is based on an
> >> > ephemeral-static DH ("es" or "se") between the sender's static key
> pair
> >> and
> >> > the recipient's ephemeral key pair. Assuming the corresponding private
> >> keys
> >> > are secure, this authentication cannot be forged."
>
> >> > The issue lies in that the above two paragraphs do not specify whether
> >> > there is an opening for a malicious principal to mess with things.
> Observe
> >> > message C in the following two results:
>
> >> > https://noiseexplorer.com/patterns/KN.noise.html
> >> > https://noiseexplorer.com/patterns/IK.noise.html
>
> >> > In IK, message C is resistant to key compromise impersonation even if
> its
> >> > sender (the initiator) negotiates a separate session in parallel with
> a
> >> > compromised principal Charlie, who is controlled by the attacker
> >> > unbeknownst to the sender.
>
> >> > In KN, message C is also resistant to key compromise impersonation,
> but
> >> > unlike message C in IK, this property does not hold if Charlie also
> enters
> >> > the fray in a similar manner.
>
> >> > In the current Noise specification, both KN and IK are given the
> similar
> >> > grade for authenticity. That is the problem and the reason for the
> >> expanded
> >> > authenticity grading system. In Noise Explorer's system, grades 3 and
> 4
> >> > essentially are short hand for "1 and 2 but with maintained key
> compromise
> >> > impersonation resistance even when negotiating with a compromised
> >> > principal."
>
> >> > Now, I understand your suggestion with regards to pairing these grades
> >> with
> >> > corresponding confidentiality queries, but this raises two questions
> in my
> >> > mind:
>
> >> > 1. The confidentiality queries in question are written and formalized
> to
> >> > deal with message secrecy and forward secrecy two properties that do
> not
> >> at
> >> > all touch upon authenticity. Shouldn't we strive to therefore working
> on
> >> > separating these properties formally?
>
> >> > 2. There is also the question of reduced precision. Instead of having
> >> > authenticity grades "1, 3-5" and grade "2, 3-5", why not settle for a
> >> > system where we obtain precise grades for authenticity, independently
> from
> >> > having to look at a confidentiality/message secrecy/forward secrecy
> >> result?
>
> >> > Nadim Kobeissi
> >> > Symbolic Software • https://symbolic.software
> >> > Sent from office
> >> > On Thu, May 24, 2018 at 6:10 PM Trevor Perrin <trevp at trevp.net>
> wrote:
>
> >> > > On Thu, May 24, 2018 at 12:05 PM, Nadim Kobeissi
> >> > > <nadim at symbolic.software> wrote:
> >> > > > Hello everyone,
> >> > > > I've been following up on all of these discussions very closely,
> but
> >> > have
> >> > > > not said anything because I've been working furiously on getting
> all
> >> the
> >> > > > formal results for all 22 deferred patterns *with* two "tokenless"
> >> > messages
> >> > > > out. I'm afraid that with the addition of two "tokenless" messages
> to
> >> > every
> >> > > > single model, the cost of verification increases dramatically.
> Things
> >> > are
> >> > > > still going to take quite a long time -- I wish we weren't nearing
> >> > June, at
> >> > > > least I'd have a use for the free radiators I now have in my
> apartment
> >> > due
> >> > > > to this -- quite a lot of finely tuned dedicated hardware is now
> >> dealing
> >> > > > with the formal verification load.
> >> > > >
> >> > > > An important clarification: Trevor says the following:
> >> > > >> Thinking more on rev34, it would probably be irresponsible to
> publish
> >> > > >> *without* security tables for all the deferred patterns...  So
> I'd
> >> > > >> love to work out how to get your output processed into some
> tables
> >> > > >> like the current ones (or possibly changed around a bit,
> depending on
> >> > > >> that discussion).  Or really: for you to work that out, so I
> could
> >> > > >> just copy-and-paste :-)....
> >> > > >
> >> > > > Trevor, the security tables for 20 of the deferred patterns are
> >> already
> >> > > > available on Noise Explorer's website. They simply do not include
> the
> >> > > > "tokenless" messages. Just a note in the event that you missed
> that.
> >> :-)
> >> > > >
> >> > > > Regarding the discussions on security properties, I'm personally
> >> > currently
> >> > > > satisfied with the recognition that any deferred pattern that
> opens
> >> up a
> >> > > > potential UKS attack will simply never qualify towards
> authenticity
> >> > grades
> >> > > > 3 and 4 (as defined by Noise Explorer) and will always be
> restricted
> >> to
> >> > a
> >> > > > maximum of 1 or 2 (as defined by Noise Explorer, see my previous
> email
> >> > > > where I list a "very quick summary" of the additions to the
> >> authenticity
> >> > > > properties.)
>
> >> > > Hmm, the way I think about it, no patterns should ever open up a
> >> > > potential UKS attack?  Also, the deferred patterns should end up
> with
> >> > > the same properties as their corresponding fundamental pattern,
> since
> >> > > they perform the same operations.
>
> >> > > Looking more closely at your numeric grades, I think your two new
> >> > > authentication grade numbers just correspond to the Noise
> >> > > authentication grades 0-2, except you use 2 new numbers based on the
> >> > > confidentiality grade it's being paired with:
>
> >> > > ("NE" for Noise Explorer):
>
> >> > > NE 0 -> spec(0, 0-2)
> >> > > NE 1 -> spec(1, 0-2)
> >> > > NE 2 -> spec(2, 0-2)
> >> > > NE 3 -> spec(1, 3-5)
> >> > > NE 4 -> spec(2, 3-5)
>
> >> > > In other words, I don't think these new NE grades encode new
> >> > > information.  So I'm not yet convinced they improve things versus
> the
> >> > > Noise spec's system, seems like we could map your 3->1, and your
> 4->2,
> >> > > and bring things into alignment?
>
> >> > > Trevor
> >> _______________________________________________
> >> 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/20180524/e5ff99d9/attachment.html>