Bug in HKDF?

[wilko77]

I think the computation of max_length in src/cryptography/hazmat/primitives/kdf/hkdf.py is wrong.

RFC5869 states on page 3 that the input L of the HKDF-Expand function describes the "length of output keying material in octets (<= 255*HashLen)". An octet consists of 8 bit.

Currently, max_length is computed as:

max_length = 255 * (algorithm.digest_size // 8)

The problem is, that algorithm.digest_size returns the size of the digest in bytes. (There are 8 bits per byte). Therefore, the division by 8 is wrong, and thus, max_length is unnecessarily small.

(same applies for the computation of salt as well (line 33), in the case where salt is None)

[reaperhulk]

Thanks for the report. This is indeed a bug. We should allow longer output lengths. As for salt, that is a bug as well, but (fortuitously) is benign. An explanation:

• We test against a set of vectors that includes tests for the None salt case so we knew it was generating proper answers -- how could it be wrong?
• The HMAC RFC (2104) defines what to do when a key is too short (pad with null bytes)
• OpenSSL implements this behavior (https://github.com/openssl/openssl/blob/master/crypto/hmac/hmac.c#L50-L59)

So we passed too few null bytes and OpenSSL obligingly (and in accordance with the spec) padded it out to the correct number of null bytes, thus making the call return the correct value despite the wrong input. (We will still fix it though!)

A PR will be forthcoming.