<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc solid;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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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><div>Arrgh!  My handshake is shouting at me! :-)<br><br></div><div>I don't think it helps to say "keys are generated here and computation happens there".  "ekem21" is where the result of the computation is mixed into the chaining key, but the actual computation can happen as soon as the side is in possession of a local private key and a remote public key relevant to the "dhxy" or "ekemxy" token. e.g. Ahead-of-time computation in a background thread on multi-core CPU's.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div> * Schemes like NTRU Prime allow reusable keys.  We might be able to extend our naming convention for that with "skem".  I.e., you could do mutual post-quantum auth as well as forward-secrecy with something like:</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></div></div></blockquote><div><br></div><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><br></div><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><br></div><div>The "f" algorithm doesn't have to be post-quantum.  I can see a use for "25519+448" where 448 is used to add extra forward secrecy to strengthen 25519-based handshakes: 128-bit level authentication with 224-bit level secrecy.<br><br></div><div>Here, "dhff" is the point where the computation is mixed in, but it is implementation-specific as to where it is convenient to perform that computation.  Maybe "mixff" instead of "dhff" if you don't want to imply that the algorithm is DH.<br><br></div><div>This could be extended to SKEM by adding "g", "dhgg", "dhfg", and "dhgf" tokens where "g" is fulfilling the "s" role for the post-quantum part of a mixed handshake.<br></div><div><br></div><div>I had a quick look at SIDH: it is more balanced with keypairs generated separately from each other.  The wrinkle is that Alice and Bob use different algorithms to generate their private keys and to perform the later shared secret computations.  But we could handle that with some rule: "the initiator is Alice and the responder is Bob; reversed for fallback patterns".  If SIDH is used for ekem only, then the rule can be "whoever goes first is Alice".<br></div><div><br></div><div>Cheers,<br><br></div><div>Rhys.<br><br></div></div></div></div>