<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 27, 2016 at 6:46 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">Cool, quick feedback:<br>
<br>
* This currently mixes the "fg" notation with "dh??" notation, but<br>
the "fg" notation would be more consistent with changing from "dhee??"<br>
to "ee", "ss", "es", "se", so we need to think more about that.<br></blockquote><div><br></div><div>Once (if?) the core specification changes, I will of course update the extensions to match.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* If we change the existing notation so that "es" or "se" indicate<br>
the initiator's value by the first character, then it may make sense<br>
to allow "fg" and "gf" tokens that follow the same rule.<br>
<br>
* It's awkward to use f and rf for the state variables that match<br>
both "f" and "g" tokens. I would think there should be g and rg<br>
variables, so that this is handled consistently with s and e.<br></blockquote><div><br></div><div>Both of these were less awkward when it was just "f" and "dhff". :-)<br><br></div><div>I've been working on the implementation for Noise-C (not pushed yet due to a bug in my test vector generator). Right now the code does this:<br><br> case NOISE_TOKEN_F:<br> case NOISE_TOKEN_G:<br></div><div> if (token == NOISE_TOKEN_F)<br></div><div> set-kex-object-into-alice-mode;<br></div><div> else<br></div><div><div> set-kex-object-into-bob-mode;<br></div> ... rest of the code is the same for both ...<br></div><div> break;<br></div><div><br></div><div>So I'm not sure anything is really gained by separating "f" into "f" and "g". The "alice mode" and "bob mode" flags can be intuited by a rule such as "first f is alice, second f is bob". Everything else is a problem for the back-end implementation of the kex algorithm.<br><br></div><div>The public key value sizes may be different in New Hope, but the Noise-C code doesn't actually care what the sizes are until after the alice/bob mode is set.<br><br></div><div>This design may be a quirk of how I've implemented Noise-C though. I'm keen for someone else to try implementing New Hope in Noise to see what other code shapes arise.<br></div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* You mention allowing reuse of the hybrid ephemeral values. This<br>
isn't covered by the pseudocode, which will generate a fresh value<br>
every handshake. That's simpler and perhaps safer, since<br>
implementations don't have rotate keys via timer or other logic. So<br>
could we get by without ephemeral reuse, for now?<br></blockquote><div><br></div>I'm fine with that. For New Hope, it is only the public "a" value that is shareable - not the "key" part of the ephemeral key. But New Hope "a" generation is still pretty fast, so the value of reusing it is minimal. Other algorithms might have different trade-offs.<br></div><br></div><div class="gmail_extra">Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div>