David McGrew wrote:
Hi Hugo and Pasi,
[snip]
The conspicuous unmeet need, in crypto standards at least, is for a computational extractor, since "extraction" is an important goal, and there is an efficiency gap for statistical extractors. On the other hand, there are many definitions and implementations of PRFs that implement the "expand" stage perfectly well. One option we have is to define an extractor function, rather than a general-purpose KDF (or inaddition to it).
[snip]
Regards, David
[snip]NIST SP 800-90, which is actually about random number generation, specifies two extractors, which it calls Derivation Functions, in Section 10.4.1 and 10.4.2. These are hash based and block cipher based, respectively. Both can deal with generating internal key material wider than a single block. (I write "internal key material" because the data so generated is used to as input to the expansion function.)
The hash-based generation function is basically just a hash in counter mode: block_i = Hash(i || N || input), where i is a 32-bit counter and N is the number of bits to be generated as a 32-bit value.
The block cipher based extractor similarly generates block_i = last_block(XXX_CBC(fixed_key, i, L || N || input || 0x80 | 0-padding)) where XXX is the block cipher (e.g. AES_128), i (the IV) is the block count as a 32 bit value 0-padded to the block size, L is the input size as a 32 bit value, and N is the number of bits to to be returned by the derivation function as a 32 bit value. The fixed_key is just octets of 0, 1, ... out to the key length. (They don't actually say CBC mode; but that is what it looks like to me.)
(I've ignored endian issues, and omitted some special cases, such as when the internal key is not a multiple of the block size, etc.)
Only 2 requirements on the entropy are stated that are relevant to us:1. "The entropy input shall have entropy that is equal to or greater than the security strength of the instantiation." (Section 8.6.3)
2. "The entropy input and the resulting seed shall be handled in a manner that is consistent with the security required for the data protected by the consuming application. For example, if the DRBG is used to generate keys, then the entropy inputs and seeds used to generate the keys shall (at a minimum) be protected as well as the keys." (Section 8.6.6)
One difference between this and HKDF regarding input is that HKDF explicitly allows the adversary to know some of the input. But it is not obvious how allowing the adversary to know some of the input would be harmful to security of the SP 800-90 functions, as long as the portions known to the adversary were not counted as entropy.
Intuition tells me to worry a bit about using a block cipher with a fixed key, since the key is known to the adversary and a block cipher is invertible, But maybe it is okay since their expansion functions protect the internal key material.
-- David Jacobson