[noise] Noise Explorer

Thu May 24 12:29:52 PDT 2018

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