[noise] What noise/blake2b is being used for

[Trevor Perrin]

On Wed, Nov 4, 2015 at 1:41 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Wed, Nov 4, 2015 at 10:03 AM, Jean-Philippe Aumasson
>>
>> 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.
[...]
>
> 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?


I like the simplicity of using a single HKDF function for all key
derivation.  Currently the rest of the protocol doesn't know anything
about HMAC or keyed hashes, it just calls HKDF(), and I'd like to keep
it that way.

The performance difference between these choices is tiny, against the
background of ECDH ops.

The "extra" hashing of HMAC and HKDF is probably overkill, but the
extra work isn't thrown away:  it adds even more cryptographic mixing
for the transport keys.

If there turns out to be a weakness in the hash functions it's
remotely possible we'd be happy we used hashes in such a conservative
way.

So I'm fine with this as-is.


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

The larger hash is more conservative.  It's even more overkill, but
there's nothing wrong with that, if it doesn't cost you anything.


Trevor