<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 17, 2015 at 10:29 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 * Added a HASHLEN constant and allowed 32 or 64 byte hashes (e.g.<br>
SHA512, BLAKE2b).  If you want >128-bit security with the 448 curve,<br>
you would choose a 64 byte hash so that h remains collision-resistant,<br>
in which case we might as well use the full output for the chaining<br>
key, which is possible now that we've separated ck from k.<br><br></blockquote><div><br></div><div>So just to clarify -- this means that in some cases, ck is 64 bytes and k is 32 bytes? And k is then calculated from the truncation of the second HMAC?</div><div><br></div><div>Sounds okay. Though, if keeping ck 32 bytes, use of a 64 byte HASH could then remove the need for a second HMAC. (On the other hand, there's some idea that truncating HKDF makes things more secure in this case?)</div></div>
</div></div>