1
$\begingroup$

I've always understood the bit security of hash functions to be related to their output size (eg. collision resistance). However, I recently came across a table from a Wickr blog post that lists HKDF-SHA256 as having 256 bits of security. Here's the table:

enter image description here

  1. How does this work when HMAC-SHA256 offers 128-bit security? Is this due to the input keying material size being used?
  2. What would the security of keyed BLAKE2b be - do the same rules as HMAC apply?
  3. What would the security of BLAKE2b as a KDF be (eg. the libsodium implementation with a salt and personalisation)?

For example, does a 256-bit key provide 256 bits of security even if the tag is only 256-bit (typically 128-bit collision resistance)?

I can't find any mention of these details for keyed BLAKE2, but an unkeyed 256-bit output has 128-bit collision resistance according to the RFC:

        Algorithm     | Target | Collision | Hash | Hash ASN.1 |
           Identifier |  Arch  |  Security |  nn  | OID Suffix |
       ---------------+--------+-----------+------+------------+
        id-blake2b160 | 64-bit |   2**80   |  20  |   x.1.5    |
        id-blake2b256 | 64-bit |   2**128  |  32  |   x.1.8    |
        id-blake2b384 | 64-bit |   2**192  |  48  |   x.1.12   |
        id-blake2b512 | 64-bit |   2**256  |  64  |   x.1.16   |

Please don't answer with a bunch of math. I'm not good at math. I'm a developer, not a mathematician.

$\endgroup$
2
0
$\begingroup$

For collision resistance, the bit security of a hash function is half the length of its output. This is because one can find a collision in any hash function of output length $n$ in time $2^{n/2}$. That is why the bit security of SHA256 with respect to its primary security property of collision resistance is 128. However, this doesn't mean that SHA256 cannot be used for other purposes and achieve higher bit security. In particular, for HKDF, the bit security of the output is essentially that of the input (up to a maximum of 256 bits, which is the output length). So, if you use HKDF on an input key of size 128 bits (or a string of entropy 128) then you receive an output key with 128 bits of security. If you use HKDF on an input key of size 256 bits (or a string of entropy 256) then you receive an output key with 256 bits of security. Note that in all cases the output of SHA256 is 256 bits, so if you need a shorter result (e.g., when using a 128-bit key) then the result needs to be truncated as specified in HKDF.

$\endgroup$
3
  • $\begingroup$ Thank you that explains the situation with HKDF. I would upvote but this is a guest account as I'm not a regular. Do you know what the situation would be for BLAKE2b as a KDF? $\endgroup$ – guest Feb 15 at 12:08
  • $\begingroup$ I don't know if one uses BLAKE2b in HMAC since it can be keyed directly. To be honest, I don't know what's recommended in its use as a KDF. $\endgroup$ – Yehuda Lindell Feb 15 at 12:33
  • $\begingroup$ I know you can use BLAKE2 in HMAC because that's what the Noise Protocol Framework does, but it doesn't make much sense when there's a keyed mode. As for the KDF aspect, it really isn't well documented to be honest. For example, libsodium says you can use a counter salt, but I've never seen that written anywhere else. What I'm wondering is whether the security of the BLAKE2 output is equivalent to the standard hash function output - e.g. 256-bit output = 128-bit security, meaning it's worse as a KDF than HKDF. $\endgroup$ – guest Feb 15 at 12:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.