<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 9, 2016 at 6:55 AM, 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"><span class="gmail-">On Fri, Oct 7, 2016 at 4:25 PM, Rhys Weatherley<br>
<<a href="mailto:rhys.weatherley@gmail.com">rhys.weatherley@gmail.com</a>> wrote:<br>
</span><span class="gmail-">> I have updated the hfs and New Hope extensions.  The main changes are:<br>
><br>
> - Use the token naming conventions from revision 31 of the Noise<br>
> specification.<br>
> - Replace the "f, g, fg" token set with "f, ff".<br>
><br>
> <a href="https://github.com/rweather/noise_spec/blob/forward_secrecy/extensions/ext_hybrid_forward_secrecy.md" rel="noreferrer" target="_blank">https://github.com/rweather/<wbr>noise_spec/blob/forward_<wbr>secrecy/extensions/ext_hybrid_<wbr>forward_secrecy.md</a><br>
> <a href="https://github.com/rweather/noise_spec/blob/forward_secrecy/extensions/ext_newhope.md" rel="noreferrer" target="_blank">https://github.com/rweather/<wbr>noise_spec/blob/forward_<wbr>secrecy/extensions/ext_<wbr>newhope.md</a><br>
<br>
</span>Looks roughly right, definitely worth a close read and trial<br>
<span class="gmail-">implementation.</span></blockquote><div><br></div><div>I have updated both Noise-C and Noise-Java to include support for revision 31 and hybrid forward secrecy.  They can be used as a "reference implementation" to help others to implement hfs.  Noise-Java is probably a "purer" implementation of hfs - Noise-C needs some cleanups after all my post-quantum experiments.  Test vectors for hfs can be found here:<br><br><a href="https://raw.githubusercontent.com/rweather/noise-c/master/tests/vector/noise-c-hybrid.txt">https://raw.githubusercontent.com/rweather/noise-c/master/tests/vector/noise-c-hybrid.txt</a><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">  Quick comments:<br>
<br>
 * It's not immediately obvious that "r" could be empty in<br>
GENERATE_KEYPAIR_F, until you read further.  Also - should it be "rf"?<br></span></blockquote><div><br></div><div>Fixed. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
 * In ReadMessage(), formatting is off.<br></span></blockquote><div><br></div><div>There were so many nested "if ... then ... else" clauses in there that I was trying to split the "f empty" and "f not empty" cases for greater clarity.  I'll think about how to reword it.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
 * Do we want to allow re-use of the "f" value?  I was leaning away<br>
from that, but not sure.<br></span></blockquote><div><br></div><div>I downgraded it a little to 'reuse parts of "f"' rather than all of it to potentially support New Hope's shared "a".<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">

 * Are bullets 2 and 5 in "Pattern Validity" necessary?<br></span></blockquote><div><br></div><div>Possibly not.  The strictness was due to following the pre-message order of "e, f" in section 4.2.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
 * The "Future Directions" stuff needs more work, of course.<br></span></blockquote><div><br></div><div>Yes.  Suggestions welcome for alternative text.<br></div></div><br></div><div class="gmail_extra">Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div>