<div dir="auto">You are missing the fourth line with se on that pattern</div> <div class="gmail_quote"><div dir="ltr">On Thu, 24 May 2018, 18:51 Nadim Kobeissi, <nadim@symbolic.software> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 • <a href="https://symbolic.software" rel="noreferrer noreferrer" target="_blank">https://symbolic.software</a> Sent from office On Thu, May 24, 2018 at 7:30 PM Nadim Kobeissi <nadim@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: > <a href="https://noiseexplorer.com/patterns/KN.noise.html" rel="noreferrer noreferrer" target="_blank">https://noiseexplorer.com/patterns/KN.noise.html</a> > <a href="https://noiseexplorer.com/patterns/IK.noise.html" rel="noreferrer noreferrer" target="_blank">https://noiseexplorer.com/patterns/IK.noise.html</a> > 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 • <a href="https://symbolic.software" rel="noreferrer noreferrer" target="_blank">https://symbolic.software</a> > Sent from office > On Thu, May 24, 2018 at 6:10 PM Trevor Perrin <<a href="mailto:trevp@trevp.net" target="_blank" rel="noreferrer">trevp@trevp.net</a>> wrote: > > On Thu, May 24, 2018 at 12:05 PM, Nadim Kobeissi > > <nadim@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 <a href="mailto:Noise@moderncrypto.org" target="_blank" rel="noreferrer">Noise@moderncrypto.org</a> <a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a> </blockquote></div>