Re: [Cfrg] soliciting feedback on HKDF

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

There are two issues. One - whether a hash function as-designed is a good
source of randomness. The other one - which is the most relevant here - is
whether HMAC adds anything useful to randomization property.

Because neither hashes like SHA nor HMAC were designed as randomizers.

I'll certainly look up the reference, thanks!

On 10/20/09  13:32 , "Dan Harkins" <dharkins at lounge.org> wrote:

> 
>   Hi Uri,
> 
>   Check out "Random Oracles are Practical" by Bellare and Rogaway.
> Section 6 discusses how to use a standard hash function, which by
> itself has too much structure, to make a random oracle.
> 
>   In fact, they provide an example to extend the range and domain of
> the mapping for an example random oracle and end up with something that
> looks remarkably like a KDF. It even includes a random "salt" to
> instantiate multiple independent random oracles.
> 
>   Dan.
> 
> On Tue, October 20, 2009 7:04 am, Blumenthal, Uri wrote:
>> I'd like to bring up my old question that hasn't been answered.
>> 
>> Design of hash functions had  producing unique digests (collision
>> avoidance) as its primary goal. Any randomization properties - if they
>> existed - were just a by-product.
>> 
>> Engineers noticed that hash output looked random to them, and started
>> using hash functions as randomizers.
>> 
>> HMAC construct was designed to foil certain attacks against keyed hash
>> functions. What are the reasons to believe that HMAC adds anything to the
>> randomization property of the underlying hash functions?
>> 
>> (I'm not asking for a proof - just give me something that wouldn't be
>> foolish to believe :-)
>> 
>> 
>> ----- Original Message -----
>> From: cfrg-bounces at irtf.org <cfrg-bounces at irtf.org>
>> To: Dan Harkins <dharkins at lounge.org>
>> Cc: Tim Polk <tim.polk at nist.gov>; David McGrew <mcgrew at cisco.com>;
>> cfrg at irtf.org <cfrg at irtf.org>; Hugo Krawczyk <hugo at ee.technion.ac.il>
>> Sent: Mon Oct 19 23:36:24 2009
>> Subject: Re: [Cfrg] soliciting feedback on HKDF
>> 
>> On Monday,2009-10-19, at 17:36 , Dan Harkins wrote:
>> 
>>>   A very nice I-D and I think HKDF will be a valuable building
>>> block for protocol designers.
>> 
>> I would like to echo this sentiment: in attempting to stringently
>> evaluate "Everything that could possibly go wrong" with Tahoe-LAFS's
>> crypto design [1], I keep thinking that the KDF is a linchpin
>> component in several places.  (The recent revelation of related-key
>> issues in AES-256 is one of the reasons to think this.)  Thank you
>> for working on the design and standardization of HKDF!
>> 
>> For what it is worth -- I really don't want to start an argument
>> about this somewhat tangential issue -- I don't like HMAC-SHA256
>> nearly as well as I like Poly1305-AES or Poly1305-Salsa20.  This is
>> an unfortunate period in cryptography when there isn't a really good
>> secure hash function that we can rely on, and the strong security
>> proofs and superior performance of the Carter-Wegman MACs like
>> Poly1305 look better to me than the security proofs of HMAC.
>> 
>> Regards,
>> 
>> Zooko Wilcox-O'Hearn
>> 
>> [1] http://allmydata.org/trac/tahoe/wiki/NewCaps/WhatCouldGoWrong
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg at irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>> 
> 
> 

-- 
Regards,
Uri         uri at ll.mit.edu
<Disclaimer>