Re: [Cfrg] comments and questions on draft-krawczyk-hkdf and related work

["Blumenthal, Uri" <uri at ll.mit.edu>]

My question stands: how does HMAC add anything to randomness, compared to plain hash in e.g. CBC-like mode? HMAC was designed for a different purpose. And I'd rather accept AES as an ideal cipher (which it isn't) than SHA as a random oracle.


----- Original Message -----
From: cfrg-bounces at irtf.org <cfrg-bounces at irtf.org>
To: David McGrew <mcgrew at cisco.com>
Cc: cfrg at irtf.org <cfrg at irtf.org>; Pasi.Eronen at nokia.com Eronen <Pasi.Eronen at nokia.com>; Hugo Krawczyk <hugo at ee.technion.ac.il>
Sent: Tue Oct 20 23:24:32 2009
Subject: Re: [Cfrg] comments and questions on draft-krawczyk-hkdf and related work

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 in
> addition 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
_______________________________________________
Cfrg mailing list
Cfrg at irtf.org
http://www.irtf.org/mailman/listinfo/cfrg