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
