What is the difference between encrypting something and hashing something? in what situations would I want one or the other?

  • 2
    $\begingroup$ @moderation: please, make this question a sugested similar question to every new question that asks about encryption or hashing. We're full of "how to encrypt with MD5" and so on. $\endgroup$ – woliveirajr Jun 15 '12 at 13:53

(I am new to cryptography, so hopefully I wouldn't say anything wrong. The following I hope should help give an idea of differences).

In general you always have a plaintext or something that you want to keep secret. This might be a message or a file or a password.

Encrypting: encryption transforms the plaintext into something that cannot be understood - something that doesn't have any meaning. Something unintelligible. You encrypt the message/plaintext by using an algorithm and a key. The output (the ciphertext) always depends on the key. The essential thing about encryption is that you can always recover the plaintext (if you know the key/password), and given a key/password you have only one plaintext. So you can think of encryption/decryption as a way to move back and forward between you plaintext and your cipher text (using a key).
Uses: Encryption is good if you say have a message to send to someone. You encrypt the message with a key and the recipient decrypts with the same (or maybe even a different) key to get back the original message.

Hashing: hashing turns something (usually a key or a password) into a (usually fixed length) string of characters. For example your hashing algorithm might always produce a string that is 8 bytes long. As with encryption you transform something intelligible into something unintelligible. One might call the product of the hashing the hash codes of the hash sums. One difference is that hashing two different messages might produce the same hash values. So you cannot decrypt something that you have hashed. But even though you can't decrypt a hashed value, it is (or it should) in general hard to make two messages that have the same hash value. Another difference is that hashing doesn't require a key.
Uses: One use of hashing is if you want to send someone a file. But you are afraid that someone else might intercept the file and change it. So a way that the recipient can make sure that it is the right file is if you post the hash value publicly. That way the recipient can compute the hash value of the file received and check that it matches the hash value.

  • 2
    $\begingroup$ Be aware that providing a hash value alongside a download does not prevent file interception: The third party might simply intercept your communication again and replace the hash with the one for the modified file. Hashes help against accidental modifications like transfer errors. $\endgroup$ – Nils Werner Jan 15 '16 at 11:55
  • $\begingroup$ The expression "key / password" gives the impression, they are equivalent. But passwords usually are considered to be random values with low entropy, while keys are usually required to have high entropy. Getting a key from a password involves using a proper key derivation function. $\endgroup$ – tylo Sep 27 '16 at 12:00
  • $\begingroup$ I would highlight that encryption isn't required to be bidirectional. As such hashing is a specific form of encryption $\endgroup$ – UKMonkey Mar 6 at 15:21

I wanted to note a couple of KEY (no pund intended).

Encryption doesnt collide because you are essentially generated a "messed" up copy of the same length of your original message. A collide is the name for what Thomas describes in his hash description. What this means is essentially:

Encrypt input to output is n bits in, n bits out, and data is reversible given the key.

Hashing (if we exemplify SHA 512 for example) takes in 1024 bit chunks at a time (but can generate a HASH for multiple blocks of 1024, but for simplicity we will only talk about a single block). Since the output is ALWAYS 512 bits (in this case), there could be as many as 2^(1024 - 512) repeated input values that result in the exact same output hash value (digest). Hashing can be keyed or not keyed.

  • $\begingroup$ More formally, encryption is a random permutation by virtue of being invertible, so two distinct plaintexts cannot result in the same ciphertext under a given key (obviously) $\endgroup$ – Thomas Jun 14 '12 at 10:25
  • $\begingroup$ Actually, it is not a random permutation, it is a VERY DETERMINISTIC permutation (normally) based on a random input (i.e. the key). By definition, if it were truly a "random" permutation, it would not be reversible. $\endgroup$ – trumpetlicks Jun 14 '12 at 13:14
  • $\begingroup$ Oh yes, indeed, that was a horrible abuse of terminology! Pseudorandom, low-entropy permutation it is, of course. $\endgroup$ – Thomas Jun 14 '12 at 18:54
  • $\begingroup$ Actually, it's a pseudorandom permutation, based on a high entropy key (that's the basic assumption about the key). And the statement "truly random permutations are not reversible" is wrong, because permutations are always bijective and therefore invertible. $\endgroup$ – tylo Sep 27 '16 at 11:54

An encrypted document can be decrypted by those, who know the secret.

A cryptographic hash is a checksum that allows someone to proof that he knows the original input (e. g. a password) and that the input (e. g. a document) has not been modified. A cryptographic secure hash does not allow to recover the original input or any other matching input.


An encryption scheme $E$ is a triple of algorithms $E=(\mathsf{KGen},\mathsf{Enc},\mathsf{Dec})$.

The key generation algorithm $\mathsf{KGen}$ is a probabilistic algorithm that on input a so called security parameter $\kappa$ (usually the length of the key) outputs a random key $k$.

The encryption algorithm $\mathsf{Enc}$ is a (possibly probabilistic) algorithm that on input a key $k$, and a message $m$ outputs a ciphertext $c$.

The decryption algorithm $\mathsf{Dec}$ is a deterministic algorithm that on input a key $k$ and a ciphertext $c$ outputs the message $m$.

The correctness property of an encryption scheme is that for all security parameters $\kappa$, all keys $k \gets \mathsf{KGen}(\kappa)$, all messages $m$ (that are in the schemes message space), and all ciphertexts $c \gets \mathsf{Enc}(k,m)$ it holds that $\mathsf{Dec}(k,c)=m$.

The minimal security notion we usually want the encryption scheme to fulfill, is called ciphertext indistinguishability under adaptively chosen message attacks (IND-CPA). The security notion basically means that we have an attacker, he can ask arbitrary messages and we will encrypt them and give the ciphertext to the attacker. At some point the attacker will give us two messages $m_0,m_1$, we flip a coin and encrypt only one of them (depending on the coin toss) and give that ciphertext back to the attacker. Now even though the attacker can ask us to encrypt arbitrary messages, he should not be able to decide which of his messages was encrypted.

A cryptographic hash function $H$ (actually to define security we need to speak about families of hash functions, but that might get a bit complicated) is a function that maps bitstrings of arbitrary length into some finite set. The most common case is a mapping to fixed length bit-strings. That is we have a function $H: \{0,1\}^* \rightarrow \{0,1\}^n$ for some length $n$.

The only correctness condition is that $H$ must be deterministic, that is, the same input is always mapped to the same output.

The security property of a cryptographic hash function is called collision resistance. Collision resistance means, that an attacker given access to the hash function should be unable to produce two messages $m_0,m_1$ such that $H(m_0)=H(m_1)$. (This also implies a few other properties often defined separately, such as first and second preimage resistance.)

Note, however, that hash functions do have collisions. A large set is mapped onto a smaller set, so collisions are bound to happen. However, an attacker should not be able to find such collisions. (which is also why we actually need hash function families to define security)

So in summary: An encryption scheme enables you to encrypt a message, so that anybody who knows the key can decrypt it and therefore recover the message. You can use this to send or store messages while hiding their content from others.

Contrary to that, with a hash function, it is impossible recover the message, given only the hash-value. And not only that but you cannot even find a different message, that will produce the same hash value. This can be used for example to check the integrity of files (given that the hash is from a trusted source) as an attacker will not be able to produce a different file with the same hash. They are further used as a building block of most signature schemes and in password based authentication schemes.

  • $\begingroup$ @tylo A hash function definitely needs to be surjective, however that is indeed a useless detail, since it is already implied by the fact that it is a function. Collision resistance in standard frameworks requires a function family. For any single fixed hash function, a trivial attacker exists that simply outputs a hardcoded collision. $\endgroup$ – Maeher Sep 27 '16 at 13:54
  • $\begingroup$ Surjectivity is not the property you described. And surjectivity has nothing to do with collision resistance and preimage resistance. Neither property is broken if some value in $\{0,1\}^n$ can't be reached by the hash function. But you're right about the families, although I think mentioning them along the "simplified versions" of the security definitions might be confusing (since it's basically a new and different approach, starting with defining $H: \mathcal{K} \times \mathcal{M} \rightarrow \{0,1\}^n$) $\endgroup$ – tylo Sep 27 '16 at 14:50
  • $\begingroup$ Yes, surjectivity was indeed incorrect, what I meant to say was that the algorithm needs to define a function (obviously). That had never anything to do with collision resistance though. $\endgroup$ – Maeher Sep 27 '16 at 15:05

Encryption & Decryption: It increases the messages secrecy. Sender encrypts the plain text using a secret Key and sends it(cipher text) to receiver. Then the receiver receives the cipher text and decrypt it using the same secret key.

The secret key should be shared between the sender and receiver.

Hashing: It ensures the integrity of a message (which means the message is being same as the sender sent).

Sender will compute the hash using hashing algorithm and sends it with the actual message. Hashes are always fixed length (Hash size depends on hashing algorithm). The receiver will receive the message and compute the hash for message using the same algorithm and checks that the computed hash is same as the hash with the message. If both the hashes are same, the message is being same as the sender sent.

  • 1
    $\begingroup$ Hashing can be used as a tool to achieve integrity. On its own it doesn't do that, however. If you just send a hash along the message the attacker just changes the hash. For integrity, you actually need something like an HMAC or a digital signature. $\endgroup$ – tylo Sep 27 '16 at 11:49

In short Encryption help protect the data confidentiality, while hashing protect the data intigrity

  • 1
    $\begingroup$ a hash, by itself, does not cryptographically protect data integrity. $\endgroup$ – mikeazo Feb 4 '15 at 15:45
  • $\begingroup$ How to ensure the data integrity ? By verifying hashes ! $\endgroup$ – SaDHacK Feb 11 '15 at 5:20
  • 2
    $\begingroup$ An attacker who can modify the message can surely also modify the hash. Therefore, it will verify successfully. What you need for cryptographically strong data integrity is something like a MAC or a digital signature $\endgroup$ – mikeazo Feb 11 '15 at 12:20

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.