3
$\begingroup$

What are the safety issues of using the the hash of plaintext as the key to encrypt it? The first that comes to mind is that if I can guess an approximation or part of the plain text, brute force attack complexity will be reduced considerably. Suppose that this is not an issue. Are there other security risks on this approach?

$\endgroup$
  • 1
    $\begingroup$ Possible duplicate of crypto.stackexchange.com/questions/729/… $\endgroup$ – Mikero Feb 13 '18 at 19:22
  • $\begingroup$ To be clear, do you mean using the hash to derive the key from the same plaintext that you intend to encrypt? It's not explicitly said in the question as of now. $\endgroup$ – Luis Casillas Feb 13 '18 at 21:59
  • $\begingroup$ @LuisCasillas Yes, the hash of the same plaintext. $\endgroup$ – user3368561 Feb 13 '18 at 23:23
  • $\begingroup$ I might be stating the obvious: this scheme implies that you need to transmit securely as many keys as you need to transmit encrypted messages. This is obviously not suitable for generic use. $\endgroup$ – Erwan Legrand Feb 14 '18 at 10:39
  • $\begingroup$ @ErwanLegrand This scheme is intended for distributed storage, not communication. $\endgroup$ – user3368561 Feb 14 '18 at 10:45
3
$\begingroup$

No, there are no security risk beyond "(with) an approximation or part of the plain text, brute force attack complexity will be reduced considerably", understood to cover the fact that an exact (or near complete) guess of the plaintext can be verified with near certainty by one not holding the key. That is under the plausible assumptions that the hash is secure in the random oracle model, and the cipher's design is independent of the hash (the later condition takes care of a cipher purposely made insecure specifically when the key is equal to the hash of the plaintext).

Decryption works just as usual: under the standard assumption that the ciphertext is public, revealing the key allows decryption. The only functionality issues that I can think of are that encryption requires more work, including two passes on the plaintext, and on-the-fly encryption is impossible.


So-called Convergent Encryption goes one step further: it uses a hash of the plaintext as key, and deterministic encryption (the hash is typically stored conventionally encrypted along the ciphertext, possibly using asymmetric cryptography). The same plaintext is therefore always enciphered to the same ciphertext (except for the conventionally encrypted hash). That is nice for de-duplicating encrypted data, but gives up a little more on security: it becomes slightly easier to recognize a known piece of data from its enciphered form.

$\endgroup$
  • $\begingroup$ Actually, it does not look good to me that the secret key is determined by the plaintext, although I do not know what can go wrong. For instance, the same plaintext will always correspond to the same key. $\endgroup$ – Shan Chen Feb 13 '18 at 18:44
  • $\begingroup$ @ShanChen Typically that is exactly the reason one would use the technique $\endgroup$ – Ella Rose Feb 13 '18 at 18:57
  • $\begingroup$ @EllaRose Thanks! I see. This technique seems to have many applications. But from the security aspect, it doesn't achieve the ind-cpa security if the underlying encryption scheme is deterministic. Anyway, maybe the question is about a weaker level of security. $\endgroup$ – Shan Chen Feb 13 '18 at 19:08
  • $\begingroup$ @ShanChen If the state space of the plaintext is so small that the probability of collisions is a concern, you always can append a random secret string to it and encrypt the result. A kind of salt to make hash (key) unique. This way, only people knowing the secret string will be able to decrypt your data, basically converting Convergent Encryption in conventional encryption. $\endgroup$ – user3368561 Feb 14 '18 at 9:32
  • $\begingroup$ @user3368561 Actually, I would not worry about collision resistance too much if the plaintext entropy is big enough. The uniqueness of the key is not the whole point. The point is you always get the same key for the same plaintext unless you choose different secret strings for different plaintexts. But if you can choose a random secret string for each plaintext, then why not choose a random key? My point is hashing plaintext as the key has to give up some security. For instance, this technique can hardly be used in secure communication because no ind-cpa security is guaranteed. $\endgroup$ – Shan Chen Feb 14 '18 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.