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

John Kelsey <kelsey.j@ix.netcom.com> Sat, 29 October 2005 15:08 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsKD-0006Cc-U4; Sat, 29 Oct 2005 11:08:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVsKC-0006Be-5a for cfrg@megatron.ietf.org; Sat, 29 Oct 2005 11:08:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05798 for <cfrg@ietf.org>; Sat, 29 Oct 2005 11:08:32 -0400 (EDT)
Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVsXy-0005my-5i for cfrg@ietf.org; Sat, 29 Oct 2005 11:23:07 -0400
Received: from elwamui-karabash.atl.sa.earthlink.net ([209.86.224.37]) by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EVsJy-00033D-00 for cfrg@ietf.org; Sat, 29 Oct 2005 11:08:38 -0400
Message-ID: <21357237.1130598518366.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>
Date: Sat, 29 Oct 2005 08:08:38 -0700
From: John Kelsey <kelsey.j@ix.netcom.com>
To: cfrg@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Subject: [Cfrg] Re: Cfrg Digest, Vol 16, Issue 43
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: John Kelsey <kelsey.j@ix.netcom.com>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>
Sender: cfrg-bounces@ietf.org
Errors-To: cfrg-bounces@ietf.org

>Date: 28 Oct 2005 22:15:39 -0000
>From: "D. J. Bernstein" <djb@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@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg