# Does the SHA-256 sum of a 256-bit key help you crack it?

If I have the SHA-256 sum of a 256-bit AES key, can I determine the key any faster than if I merely had a ciphertext and the corresponding plaintext?

The practical answer is "not really". With that said, here's a more nuanced answer:

If you only have a single AES-256 plaintext/ciphertext pair (one block, that is), it's not actually possible to bruteforce the key. AES has a block size of 128 bits, so the probability of any given key having that plaintext/ciphertext pair should be $2^{-128}$. That number is quite small, except for the fact that there are $2^{256}$ possible AES-256 keys, so there should be about $2^{128}$ keys with this plaintext/ciphertext pair. In other words, even a bruteforce search would still leave us with about $2^{128}$ possible keys. With access to a SHA-256 hash of the key, we can instead search for a preimage of the hash, which should leave at most a few possible keys (those keys can then be checked against the AES plaintext/ciphertext pair).

So, in theory, the hash should help an attacker in the above situation. Of course, in practice, it's impossible to search a key space of $2^{128}$, let alone $2^{256}$, so the above has no practical implications.

A more interesting question is whether an attacker who knows both $\text{SHA-256}(k)$ and $(m,E_\text{AES-256}(k, m))$ can combine that knowledge in order to use some more efficient method.

Here's an example of how this kind of problem could happen. Suppose we have two secure cryptographic hash functions $f$ and $g$, each operating on 256-bit inputs and producing a 256-bit output. Let $f(m) = \text{SHA-256}(m)$ and $g(m) = f(m) \oplus m$ (where $\oplus$ is XOR). I haven't checked this example carefully, but $g$ should still be preimage resistant. If an attacker is given either $f(k)$ or $g(k)$, then they should be unable to determine $k$ without a brute force search. However, if the attacker is given both $f(k)$ and $g(k)$, then they can compute $f(k) \oplus g(k) = f(k) \oplus f(k) \oplus k = k$ to recover the original input.

As far as we know, there aren't any interactions like this between SHA-256 and AES-256. This kind of situation definitely deserves caution, since as far as I know, the algorithms were not explicitly designed to avoid interaction between the two. That said, there does seem to be a fair amount of confidence that there will not be any surprising relationships discovered between AES-256 and SHA-256.

In most cases, it's better to derive separate keys for separate uses. Instead of using $k$ directly, use $k$ to compute two subkeys $k_1$ (for AES-256) and $k_2$ (for SHA-256). There are a variety of ways to do this. My favourite is to use HKDF (that RFC is surprisingly readable), which might look like this:

$k_1 = \text{HKDF-Expand}(k, \text{0x01}, 32) \\ k_2 = \text{HKDF-Expand}(k, \text{0x02}, 32)$

• Excellent answer! For context, I've written a system for sharing bits of sensitive data, where each piece of data is encrypted with 256-bit AES and then stored, with a randomly-generated identifier pointing to it. Thus, to share the secret, you must send the identifier and the key to the recipient. Somebody suggested I use the SHA-256 sum of the key as the identifier instead, reducing the amount of data that needs to be pasted to/from a chat window. I was concerned that there could be an interaction between the two algorithms like you described. – waucka Apr 9 '16 at 18:44
• @waucka If your still worried about too much info leaking, you can use just the first 4 or so bytes of the hash as your identifier, which will increase the number of possible keys matching by quite a large amount. – matsjoyce Apr 9 '16 at 19:29
• That is an excellent idea. Since the data is deleted from the server after 24 hours (and the server won't get tremendously heavy use), I really don't need the full 256 bit space for uniqueness. – waucka Apr 9 '16 at 20:43