Comment 23 for bug 1175367

In response to Simo Sorce:

A few notes about this:

We do need to obscure the key as well as the value here. The cache key is usable as an authentication token in other parts of the stack. Because we are doing this, it is inappropriate to talk about salting it, since if we did that we would be unable to look up any values. Furthermore, because this is a caching layer, we don't want to be doing extra work if we can avoid it, which is why I didn't use more than one round of hashing in the KDF.

I do not believe HKDF is appropriate here. Unlike many other uses of KDFs, the input keying material is expected to be of good quality to begin with. People should not be using a password or similar for generating this secret key, and this key is not derived from some other source an attacker may know something about. Furthermore, we do not need 10 blocks of key material, we need exactly 3. Additionally, it is inappropriate to salt these values because that would make it impossible to look up cached material. If you read the SP800-108 document closely, you'll notice that we're basically using one round of the approved KDF (we could prepend a 1 to the hashed value if you want to be pedantic).

However, as you've observed, if the secret material doesn't have enough entropy, this construction breaks down. I've conservatively added a requirement that the secret be at least 48 bytes long, which should reinforce the security of the construct.