<div dir="ltr"><div class="gmail_quote">On Sun, Jul 17, 2016 at 9:56 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;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think at that point it might be simpler to run two Noise_XX() handshakes in parallel and mix them with SSK's.  Or just switch completely to a post-quantum "XX" and drop the classical handshake.<br></div></div></div></div></blockquote><div><br></div></span><div>I'm not sure how much confidence we have in current PQ schemes resisting *classical* cryptanalysis, must less PQ cryptanalysis.  So I'm opposed to deploying current PQ encryption schemes by themselves.</div></div></div></div></blockquote><div><br></div><div>Fair enough. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>How about we apply some KISS?  The odd one out is ekem: there is a need for adding another ephemeral-only exchange for obtaining extra forward secrecy from a different algorithm.<br><br></div><div>Noise_XXf(s, rs):<br></div><div>    -> e, f<br></div><div>    <- e, f, dhee, dhff, s, dhse<br></div><div>    -> s, dhse<br></div><div><br></div><div>Where "f" stands for "forward secrecy ephemeral".<br></div></div></div></div></blockquote></span><div><div><br></div><div>That's not bad, though if we're pushing for simple patterns, just "doubling" the DH functions deserves a closer look.  I.e., for NewHope:</div><div><br></div><div>"e" = sends an unencrypted DH value, then sends a (potentially encrypted) NewHope value.  The first occurrence of "e" sends NewHope message #1, the next "e" by the other party sends NewHope message #2.</div><div><br></div><div>"dhee" = calls MixKey() on the DH output, then calls MixKey() on the NewHope output.</div></div></div></div></div></blockquote><div><br></div><div>Looks fine to me.  With a note that "potentially encrypted" is only possible if there is a PSK, because otherwise encryption doesn't start until the "dhee" token.  However, encrypting the New Hope ephemeral is probably not worth the effort as you said further down.</div><div><br></div><div>There are also issues in fallback patterns with encrypting public keys with PSK's too early in the handshake as I found with IKnoidh / IXfallback.  That problem may also happen with IK / XXfallback if the PQ ephemeral public key was encrypted.  We might end up in a situation where you can use Noise Pipes with PQ or PSK but not both.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>So for PQ auth, the doubling approach loses some real flexibility in the auth case, since it constrains us to using "regular" auth that complies with whatever limits the PQ scheme has.</div><div><br></div><div>OTOH, PQ forward-secrecy is the more immediate goal, so maybe it's better to use doubling to just keep things simple for now, and hope that more flexible PQ schemes are invented if/when PQ auth becomes important?</div></div></div></div></div></blockquote><div><br></div><div>Agreed.  Cross that road when we come to it.</div><div><br></div></div><div>Cheers,</div><div><br></div><div>Rhys.</div><div class="gmail_extra"><br></div></div>