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?
Yes, but think about how you would fit it into the question I raised:
- 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".
- 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.
Pinning down where the primitive ends and the protocol is tricky and ultimately
of little value. The takeaway is that crypto algorithms have to be used with
caution. Even a perfect block cipher, if used in "the most obvious way" (ECB
mode), reveals when it has been given identical inputs. Which is why it's been
argued that any encryption primitive (at some level) has to be probabilistic,
so that identical inputs don't produce identical outputs. (Note that this
implies that output must always be larger then the input!) Still, we have
attainable models in which no semantic information about the input leaks (given
random keys). Related key attacks rely on a different model which has nothing
much to do with practical usage but are obvious from a purely theoretical point
of view: OK, we've insulated ourselves from attacks via the plaintext input,
how about the key?
More broadly there are plenty of attacks (probably including most of the
related key attacks; I haven't looked closely enough to be sure) that are based
on weaknesses in key scheduling. If you're going to make a cryptographic hash
function a fundamental part of your block cipher, why not use it to generate
round keys? The only reason I know of - and in practical terms it's not a
trivial one - is the substantial performance hit.
-- Jerry
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
