<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 16, 2016 at 11:41 PM, Rhys Weatherley <span dir="ltr"><<a href="mailto:rhys.weatherley@gmail.com" target="_blank">rhys.weatherley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Sat, Jul 16, 2016 at 8:34 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-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> * Maybe we should clarify which tokens are data and which are computations in the notation, e.g. capitalization?</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div><div><br></div><div>Noise_XX(s, rs):                 Noise_XXekem(s, rs):</div><div>  -> e                             -> e, ekem1, s</div></span><div>  <- e, DHEE, s, DHSE              <- e, ekem2, DHEE, EKEM21, s, DHSE</div><div>  -> s, DHSE                       -> s, DHSE</div></div></div></div></blockquote><div><br></div></span><div>Arrgh!  My handshake is shouting at me! :-)<br></div></div></div></div></blockquote><div><br></div><div><div>Some people found it confusing that the patterns combine message fields ("e", "s") with pure computation steps ("dh**").</div><div><br></div><div>If we keep adding more tokens that confusion might grow, which is why I was thinking about notation to distinguish them.  But I'm not sure about this.</div></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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><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><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><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><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><br></div><div>This loses some flexibility.  For example, with your separate tokens, we could do the regular dhee *before* sending the second f, and encrypt f:</div><div><br></div><div>Noise_XXf(s, rs):</div><div>    -> e, f</div><div>    <- e, dhee, f, dhff, s, dhse</div><div>    -> s, dhse</div><div><br></div><div>But encrypting the second NewHope value doesn't seem that useful - it doesn't make the protocol indistinguishable from random, because the first NewHope value is still in clear.</div><div><br></div><div><br></div><div>To apply the "doubling" approach to post-quantum auth:</div><div><br></div><div> * PQ signature schemes exist.  Ignoring PQ, a "sig" token that signs h with s is an obvious extension to Noise, though there's things to think about (e.g., do we allow a static elliptic curve key to be used for both DH and signatures?).</div><div><br></div><div>Anyways, a "sig" transformation would convert "dhse" -> "sig":</div><div><br></div><div> Noise_XX(s, rs):                 Noise_XXsig(s, rs):</div><div>  -> e                             -> e, </div><div>  <- e, dhee, s, dhse              <- e, dhee, s, sig</div><div>  -> s, dhse                       -> s, sig</div><div><br></div><div>So we could "double" the "s" token to contain a regular and PQ public key, and double the "sig" token to contain a regular signature, followed by a PQ signature.</div><div><br></div><div><br></div><div> * For schemes like NTRU Prime where we can encrypt to a static public key, we could double "dhes" so that it calls MixKey() on the DH output, then sends an NTRU Prime #2 message and calls MixKey() on the NTRU Prime output.  Instead of XX, we'd use a pattern like this:</div><div><br></div><div>    -> e</div><div>    <- e, dhee, s</div><div>    -> s, dhes</div><div>    <- dhes</div><div><br></div><div>Note that this pattern is worse than XX, since XX can authenticate "faster":</div><div><br></div><div>    -> e</div><div>    <- e, dhee, s, dhse</div><div>    -> d, dhse</div><div><br></div><div>So having separate tokens allows combining the faster authentication from XX with slower PQ authentication, which was my "skem" proposal:</div><div><br></div><div>Noise_XXskem(s, rs):</div><div>  -> e, ekem1</div><div>  <- e, ekem2, DHEE, EKEM21, s, DHSE, skem1</div><div>  -> skem2, SKEM21, s, DHSE, skem1,</div><div>  <- skem2, SKEM21</div><div><br></div><div>But that's a lot more complicated...</div><div><br></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><br></div><div><br></div><div>Trevor</div></div><div><br></div></div></div></div>