<div dir="ltr">Hi JP,<div><br></div><div>Bringing this back onto the noise list, as you actually bring up some very relevant issues for there.</div><div><br></div><div>Jason<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 4, 2015 at 10:03 AM, Jean-Philippe Aumasson <span dir="ltr"><<a href="mailto:jeanphilippe.aumasson@gmail.com" target="_blank">jeanphilippe.aumasson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jason,<div><br></div><div>had a look at the WG protocol (sorry for the delay). Was wondering about the data keys derivation:</div><div><br></div><div><div>temp1 = PRF(initiator.chaining_key, [empty])</div><div>temp2 = PRF(temp1, 0x1)</div><div>temp3 = PRF(temp1, temp2 || 0x2)</div></div><div><br></div><div>Here there's a secret (chaining_key) and you want to derive two keys from this value such that breaking either of the derived keys doesn't compromise the other derived key nor the root key. This can be achieved by just doing PRF(key, 1) and PRF(key, 2), or even key := PRF(key, 'meh') and doing key1 := key[:32] and key2 := key[-32:], assuming key is 64 or more bytes long.</div><div><br></div><div>The roadmap includes a point "Decide on Curve25519 vs Curve448 and Blake2b vs Blake2s". Guess the most important is consistency of security levels; all primitive with a level ~128 bits, or ~224 bits, etc. In terms of speed, on x86_64 BLAKE2s is faster when the messages hashed are ~64 bytes or below, otherwise BLAKE2b is faster. I don't have figures but I guess it's similar for 64-bit ARM (and NEON-enabled ARM).</div><div><br></div><div>Only looked at the .md docs so far, will peek at the code once I've some time.</div><div><br></div><div>Hope it helps,</div><div><br></div><div>JP</div><div><br></div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 14, 2015 at 7:12 PM Jason A. Donenfeld <<a href="mailto:Jason@zx2c4.com" target="_blank">Jason@zx2c4.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">By the way, if you get around to proving an equivalence between keyed BLAKE2 and NMAC, you'll be able to piggyback on the HKDF paper's security proofs that it's suitable as an randomness extractor...
</div><div class="gmail_extra"><br></div><div class="gmail_extra">It seems like it would be relatively straightforward. Keyed BLAKE2 sets the keylen parameter, and then it does a full block, and only after that does it hash in the ordinary data. That seems to me fairly close to a nested structure. But I'm not sure. Anyway, something to think about if one night, late, you're yearning to write some LaTeX.</div></div></blockquote></div></div></div></blockquote></div></div></div></div>