Subject: Re: [Cfrg] AES-based PRF - comment please

From: Ran Canetti <[email-masked]>
Date: Thu, 10 Apr 2003 01:19:19 -0400

> From [email-masked] Thu Apr 10 01:11:40 2003
> 
> On Thursday, April 10, 2003, at 12:49  AM, Ran Canetti wrote:
> 
> > There were three main topics:
> > 1. How to deal with the case where the "rough keying material" we 
> > start with
> >    is not guaranteed to be "pseudorandom" - ie, not completely secret 
> > or
> >    not uniformly distributed.
> > 2. How to deal with the case where the "rough keying material" we 
> > start with
> >    is of variable length.
> > 3. How to obtain a variable-length output.
> > [...]
> > Topic 1 is much more of an unstable ground [...]
> 
> I disagree.  We know how to do 1 quite well.  David McGrew and I were 
> recently talking about this thread.  A simple PRF that takes a variable 
> length input and produces a variable length output is to hash the input 
> (if necessary), then produce as much output as necessary by using a 
> keyed counter mode operation.
> 
> When using SHA1 as a primitive, you could simply use the keying 
> material as-is, and HMAC-SHA1 a counter for however much output you 
> need.  Or, if the keying material is large, you can hash it down and 
> use the result to key HMAC-SHA1 in counter mode.
> 
> If using AES as a primitive, one can first hash the input down to the 
> size of an AES key by using one of the many constructions that turn a 
> block cipher into a hash function.  Then, one simply uses the result to 
> key counter mode.
> 
> The real issue we couldn't get past is how to create a PRF based from a 
> single primitive that is easy to pipeline in hardware.  The AES-based 
> solution looks particularly unappealing from that point of view.
> 
> Nonetheless, either of those PRFs should be fine for fairly 
> general-purpose use, unless you care about protecting against password 
> computation attacks, in which case there's no reason not to use 
> PKCS#5's PBKDF2.
> 
> John

John, I think you missed my point. Ofcourse you can do it. The question 
is which security guarantees you'll get...  

Ran

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Alex Alten <[email-masked]>
Date: Sat, 12 Apr 2003 12:21:01 -0700

At 03:31 PM 3/27/2003 -0500, Don Davis wrote:
>David Wagner wrote:
> >>> No, there's no proof [that SHA-1 behaves like a random oracle]
> > After years of scrutiny, noone has found any troubling anomalies
> > in SHA.  ... SHA1 would fit the bill, because cryptanalysts have
> > tried really hard to find any anomaly that indicates it is not
> > behaving like a random function, and they've all failed.
>
>unfortunately, SHA1 probably hasn't gotten all of the
>scrutiny its predecessors got, but for an interesting
>reason.
>
>in '96, Bart Preneel mentioned an interesting tidbit about
>SHA1's prospects for survival.  Even though SHA is closely
>related to MD5, Dobbertin was not _allowed_ to extend his
>MD5 attack to SHA, because Dobbertin works for the German
>government's Security Service, and so is forbidden by law
>to undermine US federal crypto standards.  Since Dobbertin
>is by far the strongest worker in the field of hash-function
>inversions (RIPE-MD, MD4, MD5), SHA1 probably won't suffer
>MD5's fate, even if SHA1 deserves to die.
>
>has someone else has come along to fill dobbertin's shoes?
>
>finally, i'll mention that before SHA1 came along, a hash
>function's lifetime (spec to crack) was about 6 years.
>
>                                         - don davis, boston

This is interesting.  What about SHA2?  I assume it's just
the SHA1 design extended to longer digests?

BTW, IMHO I think that designing a good & fast 1-way hash
is harder than a good & fast block cipher, especially with
all the micro-instruction pipelining that occurs inside
microprocessors.

- Alex

>-

--

Alex Alten
[email-masked]