[Cryptography] AES-256- More NIST-y? paranoia

[Jerry Leichter]

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