# Is it safe to use the hash of the data as the key to encrypt them? [duplicate]

Is it safe to use the hash of the data as the key to encrypt them?

That is, if I give one some encrypted data and tell them that the key that was used to encrypt them was the hash digest of the data before encrypting, will it be easier for them to decrypt them?

Edit as I can not reply to comments: The recipient will have the keys, that is no problem.

• How is the recipient supposed to decrypt the ciphertext? – hunter Sep 26 '17 at 7:13
• So the party that will decrypt knows the key, which is the hash of the message, right? – Hilder Vitor Lima Pereira Sep 26 '17 at 8:18
• You can reply to comments, but you need to use the original account. You've got now two accounts with the same name. Otherwise ask a mod to merge them. – Maarten Bodewes Sep 26 '17 at 8:25
• @MaartenBodewes Actually, it's not really something we mods can or should do. SE expects users to contact SE directly via the contact form, selecting I need to merge user profiles. I've send the user an according message with a short how-to (incl. the two profile links the user needs to mention so that SE knows what to merge) . – e-sushi Sep 27 '17 at 9:24
• I know this is an old question but one point that has not been mentioned is that this prevents you from verifying the sender. – JoeS Jan 29 at 17:42

It's kind of pointless to use the hash over the data even if you only hand over the key to the receiver of the ciphertext.

First of all, it's insecure. Consider an empty or very simple message. In that case an attacker can guess the message, create the hash, and verify correctness by decrypting.

Second, it binds the key to the data of the message. You will have to refresh the key each time you change the message. The idea of symmetric ciphers is that you can reuse the key for different messages. This scheme is not as bad as a one-time pad where the key has to have the size of the message as well, but it is still very inefficient.

Creating a secure key for most symmetric ciphers isn't hard; you just take 128 to 256 bits of secure random data and use that as key. There is no need to make the key dependent on the plaintext message. If you communicate with another party then often key agreement (DH or ECDH) is performed to agree on a key instead. There are of course countless other methods of key establishment.

In case the key is reused then you would have to use a different IV for each message. This IV can however be included with the ciphertext; it doesn't need to remain secret.

Note that this answer assumes a cryptographically secure hash such as SHA-2 or SHA-3. It doesn't consider a keyed hash or PRF such as HMAC-SHA-2 or KMAC-SHA-3.

Giving an adversary $E_{H(m)}(m)$ for uniform random $H$ doesn't help them to guess $m$ any better than giving someone $E_k(m)$ for uniform random $k$: their only way to guess the key $H(m)$ is to guess $m$ in the first place!

Why might you want to do this? It provides a deterministic way to pick an encryption key for a content-addressed encrypted storage scheme, such as Tahoe-LAFS.

This doesn't work if $H$ is known to the attacker, e.g. $H = \operatorname{SHA-256}$. But you could use $H(m) = \operatorname{HMAC-SHA256}_k(m)$ for some long-term deduplication key $k$. Revealing $k$ to the attacker lets them distinguish between two possible messages $m_0$ and $m_1$, but doesn't help to decrypt unknown messages better than guessing them.

• This is ridiculous. Say the message $m$ simply consists of a $ABABABAB$ or $BABABABA$. Then a CPA secure encryption won't let the attacker know if the message is $ABABABABAB$ or $BABABABABA$ unless he somehow cracks the key. However, this will be very simple if the key can only consists of a hash over only 8 specific bytes, and verification will be easy as well: the decrypted plaintext needs to be just $ABABABAB$ or $BABABABA$. So although the guessing will be as easy, the verification of the guess should be impossible for CPA secure cipher, but very easy with a hash over the plaintext as key. – Maarten Bodewes Sep 27 '17 at 21:04
• How does the attacker compute $E_{H(m_i)}(m_i)$ to distinguish the ciphertexts for $m_0$ versus $m_1$ when $H$ is secret, e.g. $H = \operatorname{HMAC-SHA256}_k$ for a secret key $k$? – Squeamish Ossifrage Sep 27 '17 at 21:06
• No, if you introduce a key then the scheme will be secure again. But 1. that's not the question, and using a hash is not excluded in your answer and 2. you fail to provide a reason to choose HMAC here; just using $k$ for SIV mode encryption would probably work better. – Maarten Bodewes Sep 27 '17 at 21:09
• I edited to clarify that $H$ must be secret in order for this to provide ciphertext indistinguishability. – Squeamish Ossifrage Sep 27 '17 at 21:09
• The question just says ‘hash’. It doesn't say ‘hash with a single fixed public function of no secret inputs other than the message’. I picked HMAC because it's an easy standard PRF that everyone's familiar with. Any other PRF with the same domain and codomain would work just as well. – Squeamish Ossifrage Sep 27 '17 at 21:11

In addition to Maarten Bodewes's answer, this scheme also invalidates the whole point of using a hash.

Hash values are meant to be public. You can safely show the hash of a message to an attacker and be confident that they gain no information about the plaintext message. In your scheme you are giving the attacker a copy of the message encrypted with the hash of the message. Now the main premise of a hash is no longer true because the attacker learning the hash is equivalent to the attacker learning the plaintext.

Moreover, it's not clear what you even gain from this scheme. You plan to hash the message, use that as a a key to encrypt the message. Then send the ciphertext over an insecure channel, and deliver the hash of the message to the decryptor by some out-of-band method? Why not just create a random encryption key? What do you gain by using the hash?

• Random keys prevent deduplication. Convergent encryption is useful for encrypted shared storage and file sharing. Also hashes aren't necessarily public. The information leak of convergent encryption is equivalent to telling the attacker the hash of the plaintext. – CodesInChaos Sep 28 '17 at 0:07
• @CodesInChaos Neat. I didn't know that Convergent Encryption existed. Thanks! – Mike Ounsworth Sep 28 '17 at 0:13