<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">On Sun, Aug 28, 2016 at 5:27 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span></span>We previously discussed whether to treat a DH+PQ scheme as:<div> (A) A hybrid DH function that redefines the "e" token to send a hybrid DH+PQ key, and redefines "dhee" to call MixKey() on the combined DH+PQ output. </div><div> (B) Separate functions triggered by their own tokens ("f" and "dhff", for example).</div><div><br></div><div>Your current spec is in-between:  It calls MixHash() and MixKey() separately for the PQ values, instead of concatenating them with the DH values, but the sequence of calls is determined by redefining the rules for "e" and "dhee", instead of by separate tokens.</div></div></div></div></blockquote><div><br></div><div>I did explore (A) and started to code it up in a trial branch.  The "Discussion" section of the proposed extension talks about why it didn't really work.  In summary, the virtual DH function becomes odd: NewHope only works on dhee, but not dhes, dhse, or dhss - the virtual DH function needs to be split apart for some tokens but not others.  The trial implementation got very messy very fast.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>It makes sense for SymmetricState to process the PQ and DH values independently, particularly for MixKey():  We've designed the KDF to produce secure output if any MixKey() input is secure, and we want to ensure the PQ scheme can't worsen the DH.</div></div></div></div></blockquote><div><br></div><div>Agreed. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>But if we're going this route, I wonder if we should go all the way to (B):</div><div>[...snip...]<br></div>(Assuming "f" is encrypted we have to move it after the "dhee", as shown here, to not violate pattern validity.  Your spec doesn't encrypt "f", in which case the transformation is simpler - "e, f, dhee, dhff, ...").  <div><br></div><div> * The pattern name continues to determine the SymmetricState calls, as currently.</div><div><br></div><div> * This avoids redefining the existing "e" and "dhee" tokens.</div><div><br></div><div> * The pattern notation makes the the exact sequence of steps more clear.</div></div></div></div></blockquote><div><br></div><div>I'm not against this idea.  Using tokens gives more flexibility as to where the extra fs operations occur.  In New Hope, Alice is the one that can pre compute parameters.  Which means that it can make more sense if the responder sends the first f token instead of the initiator; e.g.<br></div><div><br><div>Noise_XXreversehfs</div><div>  -> e </div><div>  <- e, dhee, f, s, dhse</div><div>  -> f, dhff, s, dhse</div><div><br></div><div>That type of pattern isn't possible with a straight doubling of e and dhee.  But would be possible with a token-based approach.<br></div><div><br></div></div><div>However, I was trying to keep the system orthogonal in that adding a new feature to Noise applies equally to existing patterns.  New cipher and hash algorithms, features like PSK's and SSK's, etc, operate independently of the pattern.<br><br></div><div>My goal was "existing behaviour plus this one new thing" - Noise_XX_25519+NewHope is still essentially XX in its structure.  Adding new explicitly named patterns like XXhfs kind of breaks this - now we have patterns that only work with specific combinations of non-pattern parameters.  Maybe it is unavoidable - NewHope already only works with interactive patterns and not one-way patterns.<br><br></div><div>If we defined a "default hfs transformation", then existing patterns could be accommodated.  For instance, the presence of a forward secrecy algorithm name might implicitly apply the default transformation of "e -> e, f", "e, dhee -> e, dhee, f, dhff" if the pattern doesn't already involve f.  If that isn't what the user requires then they can define a new pattern.<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Naming and separator chars</div></div></div></div></blockquote><div><br></div><div>I have no preference one way or the other on this.  All of the proposals so far are awkward in different ways.  Whatever consensus decides.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Encrypting the forward-secrecy values</div><div>[...snip...]<br></div>I'm not sure I've thought this through, but maybe this argues for encrypting the PQ public values?</div></div></div></blockquote><div><br></div><div>Sure.<br><br></div><div class="gmail_quote">Although, as I outlined in the thread "Oddity with IKnoidh, IXfallback, and PSK's", fallback patterns can get odd if values needed to perform the fallback are encrypted too early in the handshake.  But fallback scenarios already define specific pairs of patterns, so a PQ Noise Pipes need only choose a combination that works even if other combinations don't.</div><div class="gmail_quote"><br></div>Cheers,<br><br></div></div><div class="gmail_extra">Rhys.<br><br></div><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote"><span></span></div></div></div></div>