<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 16, 2016 at 12:55 AM, 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"><div><br></div><div>I realised this morning that old school modexp-DH can be either "balanced" or "unbalanced".  If the group prime and generator are agreed to ahead of time by Alice and Bob, then the system is "balanced".  But if the parameters are dynamic and sent by Alice in the handshake, then it becomes "unbalanced".  I believe that TLS uses modexp-DH this way for forward secrecy.<br></div></div></div></div></blockquote><div><br></div><div>Validating "regular DH" parameters dynamically is generally a bad idea, so people mostly use fixed groups for DH.<br></div><div><br></div><div> </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>Great minds.  This is actually similar to my original thoughts on using New Hope.  Initially, I was thinking of special "qa" and "qb" tokens but once I found a way to implement "qa = e", and "qb = e, dhee" I set it aside in favour of making the least number of changes to the structure of Noise.</div></div></div></div></blockquote><div><br></div><div>Right, this is just an adaptation of your idea.</div><div><br></div><div>More options to consider:</div><div><br></div><div> * Currently, we have "e" and "s" tokens which represent handshake data, and "dh**" tokens which perform a crypto op and call MixKey().  It might be good to keep that distinction, instead of having an "ekem2" token that does both, for clarity and because it allows deferring the crypto op, e.g. if you want to exchange values but defer computation for DoS resistance.</div><div><br></div><div>Is it reasonable to have 2 ekem exchanges in a handshake (one started by the initiator, one started by the responder?  If not, the crypto op could just be named "ekem".  If so, it needs to distinguish which computation it's referring to ("ekem21" vs "ekem12", for example?).  Hmm.</div><div><br></div><div> * Maybe we should clarify which tokens are data and which are computations in the notation, e.g. capitalization?</div><div><br></div><div><br></div><div>Noise_XX(s, rs):                 Noise_XXekem(s, rs):</div><div>  -> e                             -> e, ekem1, s</div><div>  <- e, DHEE, s, DHSE              <- e, ekem2, DHEE, EKEM21, s, DHSE</div><div>  -> s, DHSE                       -> s, DHSE</div><div><br></div><div><br></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><br></div><div>NTRU / NTRU Prime could be used for skem or ekem, but NewHope could only be used with ekem?</div><div><br></div><div>Ideally cryptographers would invent DH-equivalent PQ schemes, and we could eliminate the "kem" stuff entirely, but for now maybe this would work?</div><div><br></div><div><br></div><div>Trevor</div><div> <br></div></div></div></div>