<div dir="auto">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.</div> <div class="gmail_quote"><div dir="ltr">On Thu, 24 May 2018, 20:30 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">Thanks, sorry about that! 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 8:30 PM Justin Cormack <<a href="mailto:justin@specialbusservice.com" target="_blank" rel="noreferrer">justin@specialbusservice.com</a>> wrote: > You are missing the fourth line with se on that pattern > On Thu, 24 May 2018, 18:51 Nadim Kobeissi, <nadim@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 • <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>