[noise] What noise/blake2b is being used for

[Jason A. Donenfeld]

On Wed, Nov 4, 2015 at 10:03 AM, Jean-Philippe Aumasson <
jeanphilippe.aumasson at gmail.com> wrote:

> Hi Jason,
>
> had a look at the WG protocol (sorry for the delay).
>

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.



> Was wondering about the data keys derivation:
>
> temp1 = PRF(initiator.chaining_key, [empty])
> temp2 = PRF(temp1, 0x1)
> temp3 = PRF(temp1, temp2 || 0x2)
>
> 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.
>

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.

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:

temp1 = Keyed-BLAKE2b(initiator.chaining_key, [empty])
sending_key = temp[0:31]
receiving_key = temp[32:63]

Or even easier:

temp1 = BLAKE2b(initiator.chaining_key)
sending_key = temp[0:31]
receiving_key = temp[32:63]

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:

https://moderncrypto.org/mail-archive/noise/2015/000312.html

Trevor - would you be willing to reconsider this?


>
> 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).
>

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.


>
> Only looked at the .md docs so far, will peek at the code once I've some
> time.
>

Great! Looking forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20151104/9e899c1c/attachment.html>