<div dir="ltr"><div class="gmail_extra"><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Jason,<div><br></div><div>had a look at the WG protocol (sorry for the delay).</div></div></blockquote><div><br></div><div>Thanks for taking the time to look at it! I really appreciate it. Some aspects of it are directly Trevor's noise, and others are my own incantation. Addressing the noise parts below.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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></blockquote><div><br></div><div>Yes, and in fact, here "PRF" is actually HMAC-Blake2b, due to the "randomness extraction" discussions we had prior. Trevor is quite intent on using HMAC, since BLAKE2 doesn't have a proof that keyed-BLAKE2 is an acceptable randomness generator.</div><div><br></div><div>But for data key derivation, you're completely right. In this case, we could forgo the three uses of HMAC (for six total uses of BLAKE2), and instead just turn the whole thing into:</div><div><br></div><div>temp1 = Keyed-BLAKE2b(initiator.chaining_key, [empty])</div><div>sending_key = temp[0:31]</div><div>receiving_key = temp[32:63]</div><div><br></div><div>Or even easier:</div><div><div><br class="">temp1 = BLAKE2b(initiator.chaining_key)</div><div>sending_key = temp[0:31]</div><div>receiving_key = temp[32:63]</div></div><div><br></div><div>I see no reason why this shouldn't be the construction. It brings 6 hash operations down to 1. I think the reason Trevor keeps it as prior is for simplicity:</div><div><br></div><div><a href="https://moderncrypto.org/mail-archive/noise/2015/000312.html">https://moderncrypto.org/mail-archive/noise/2015/000312.html</a><br></div><div><br></div><div>Trevor - would you be willing to reconsider this?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>Okay good to know about the speed trade-off. Right now I'm doing a sort of awkward dance of having "Curve25519 + Blake2b", which is a bit incoherent. Originally it made sense, as the 64byte output from Blake2b could be split to make two 32byte keys, and thus reduced the number of required operations. But now with HKDF, that advantage no longer remains. So, I'll have to make a decision.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Only looked at the .md docs so far, will peek at the code once I've some time.</div></div></blockquote><div><br></div><div>Great! Looking forward.<br></div></div>
</div></div>