<div dir="ltr">Sorry about the partial message.  Darn email client.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 31, 2017 at 11:40 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"> * Rekey capability:<br>
   - Encryption with MAXNONCE is used to rekey by default, though we<br>
allow definition of a more specialized rekey for ciphers like<br>
AESGCM-SIV where we'd rather use the cipher key directly with AES,<br>
instead of going through the whole key-derivation / SIV process.<br>
   - Up to application if/when/how to use this.<br>
   - Would still like to analyze more, but this is probably good [1].<br></blockquote><div><br>REKEY() looks good.  The only nitpick I have is with "returns a new 32-byte cipher key".  I think in the next revision we should consider adding KEYLEN and MACLEN constants to the Noise specification.  Right now it is hard-wired for 256-bit keys and 128-bit MAC's, but that assumption may not hold forever.  Consider:<br><br></div><div>Noise_XX_448_Threefish512EAX_<wbr>BLAKE2b<br><br></div><div>That is, 512-bit Threefish in EAX mode.  KEYLEN = MACLEN = 64 (MACLEN may be truncated, but not necessarily only to 16).<br><br></div><div>Eventually we'll have to think about larger key and MAC sizes.  Then REKEY() becomes "returns a new KEYLEN-byte cipher key".<br><br></div><div>That's all I have for now - the other changed sections look A-OK.<br></div><div><br></div><div>Cheers,<br><br></div><div>Rhys.<br></div><br></div><br></div></div></div>