[147565] in cryptography@c2.net mail archive
Re: [Cryptography] AES-256- More NIST-y? paranoia
daemon@ATHENA.MIT.EDU (Bill Stewart)
Tue Oct 8 10:14:31 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 06 Oct 2013 21:01:38 -0700
To: Jerry Leichter <leichter@lrw.com>,Ray Dillinger <bear@sonic.net>
From: Bill Stewart <bill.stewart@pobox.com>
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
>On Oct 4, 2013, at 12:20 PM, Ray Dillinger wrote:
> > So, it seems that instead of AES256(key) the cipher in practice should be
> > AES256(SHA256(key)).
> > Is it not the case that (assuming SHA256 is not broken) this
> defines a cipher
> > effectively immune to the related-key attack?
So you're essentially saying that AES would be stronger if it had a
different key schedule?
At 08:59 AM 10/5/2013, Jerry Leichter wrote:
> - If this is the primitive black box that does a single block
> encryption, you've about doubled the cost and you've got this
> messy combined thing you probably won't want to call a "primitive".
You've doubled the cost of key scheduling, but usually that's more like
one-time than per-packet. If the hash is complex, you might have
also doubled the cost of silicon for embedded apps, which is more of a problem.
> - If you say "well, I'll take the overall key and replace it by
> its hash", you're defining a (probably good) protocol. But
> once you're defining a protocol, you might as well just specify
> random keys and forget about the hash.
I'd expect that the point of related-key attacks is to find weaknesses
in key scheduling that are exposed by deliberately NOT using random keys
when the protocol's authors wanted you to use them.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
