[Cfrg] Re: Cfrg Digest, Vol 16, Issue 43

[John Kelsey <kelsey.j at ix.netcom.com>]

>Date: 28 Oct 2005 22:15:39 -0000
>From: "D. J. Bernstein" <djb at cr.yp.to>
>Subject: Re: [Cfrg] Fwd: Hash-Based Key Derivation (fwd)

...
>In other words, there's no justification for the religious notion
>that ``encryption functions'' are safe while ``hash functions'' are
>to be avoided. Sure, MD5 is a disaster, but 4-round AES is a disaster
>for the same reasons. If you want to know whether a primitive is
>safe, you have to look at the details of the primitive; the
>high-level packaging is almost irrelevant.

I think the thing you're both missing here is the ways these
primitives can be attacked.  Hash functions are easier to attack,
because in general, you can't assume any secrets from the attacker,
and because the maximum number of queries an attacker may make to the
hash function is limited by his computing power, where in the block
cipher case, the maximum practical number of queries is limited by how
much work the attacker can get his victim to do.  (A 2^{64} adaptive
chosen plaintext attack on AES requiring 2^{64} work would make a nice
publication, but it would have no practical impact.  The same
parameters on a hash function attack are potentially devastating--as
witness the reactions to the most recent Wang results on SHA1.)

This is a potential problem with shifting over to an AES-based hash
construction as a response to Wang's breaks on MD5, RIPEMD, SHA0, and
SHA1.  I don't think there's been much attention paid to attacks in
which the attacker gets to choose key bits, and gets to know
everything going on inside AES when planning his next set of inputs.
This is a really different attack model.  

Interestingly, the problem works the other direction--you can
apparently have a pretty good hash function (at least in the
collision-resistant sense) that gets broken when someone tries to use
the underlying block cipher component for encryption.  Different
attack models, different defenses applied.  (For the SHA256 underlying
block cipher, you normally can't choose plaintext blocks except by
brute-force search, and you never run it in the decryption direction,
so attacks that could work if you had that kind of access can
more-or-less be ignored.)  

And in the KDF case, the situation is a bit different, because in this
application, there are secret values.  (If there aren't some secrets
from the attacker, the KDF won't give us secure keys, though it may
still give us random-looking keys.)  

>---D. J. Bernstein, Professor, Mathematics, Statistics,
>and Computer Science, University of Illinois at Chicago

--John Kelsey 
(I'm new to this conversation, so forgive me if I'm restating
something that's already been said.)  

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg