hashing some data and encrypting data share some similar attributes. Surely this is why "Difference between encrypting something and hashing something" has been asked.

The point of this question is hence not repeating the different purposes. Instead I would like to ask.

Since hashing does not, by intention provide a way back I was wondering if there would be a possibility enhance a hashing scheme as to allow a way to revert the data.

To keep this a concrete and less abstract question assume this case.

  1. Let there be data and a key provided initially (which I agree is already some derivation to hashing in which there is only data)
  2. Then let the key serve as the initial input to a perform a hashing operation. For instance this could be a SHA256(key)
  3. Let step 2 be continuously repeated using the result of the previous step as new input. (So essentially this would be a SHA256(SHA256(key)) as the result of the second round). The results of each round are collected until it reaches the length of data.
  4. Finally let the data be XOR'ed with this "hash-generated one-time-pad"

Now to reverse the steps 1 to 3 can also be used to reverse again from the ciphertext to the plaintext data.

In this concrete example it seems that somehow hashing has essentially become encryption. The question therefore is this: Can this be?, is the scheme presented above an encryption scheme mainly consisting of a hashing function?


would the hash be a cryptographic safe pseudo-random-number-generator (CSPRNG) and hence this hash be part of a stream cipher setup?
Can a hash become a CSPRNG (and this would be then a stream cipher)?


With happiness I have read all and even accepted one answer with thanks. Yet I want to stress that the questions focus was less "Is this suggested algorithm a safe encryption scheme" (it is not in particular the question of safety), Instead it was about logical connectedness/links between what can be understood as encryption and which is understood as hashing

Given that for instance both hashing and encryption often attempt to produce a pseudo-random deterministic outcome. I think the question hence "can hashing become encryption?" is answered well, as it seems in some respects there is chance to use mainly a hash and end up at least with a weak encryption. Maybe the only think yet still missing (because much of some answer's efforts focus on the safety of the example algorithm) is maybe. (1) If all encryption can be seen as hashing? and be (2) all encryption bases on hashing? (which I do not think)

Yet the question is already answered very nicely so any addition focusing on that aspects (instead of the safety of the algorithm - which was simple to be more concrete) would be nice.


You can in principle encrypt using a hash function, in the manner you describe (although what you have described is not necessarily a secure construction). What you are trying to do is generate a keystream from a hash function and a key.

You can use counter mode to turn any strong pseudorandom function (PRF) into a stream cipher. CTR mode produces a keystream that is XORed onto the plaintext to produce the ciphertext (or vice versa). Some Message Authentication Code (MAC) functions are PRFs; in particular HMAC has been proven (Bellare 2006) to be a PRF if the compression function of the underlying hash is a PRF (as is the case with SHA-2). So HMAC-SHA256 in CTR mode would be a secure construction that supports encryption and decryption using a hash function.

While you can do this, you probably shouldn't. The security of block ciphers for this purpose has received more attention, and block ciphers are substantially faster than hash functions. NIST SP800-108 "Recommendation for Key Derivation Using Pseudorandom Functions" permits HMAC-SHA256 in CTR mode as a key derivation function, but cautions against using the output as a keystream for a stream cipher as "The level of security provided ... has not been investigated".

See also Is SHA-256 secure as a CTR block cipher?.


Yes, it is possible to turn a hash into a secure cipher, though not in the manner described.

The encryption scheme described is extremely poor: if someone can guess the first 32 bytes of the message (e.g. because that's a standard file header), it is trivial to recover SHA256(key): that's the XOR of the 32-byte guess and the first 32 bytes of ciphertext. It then allows to decipher the rest of the message, which allows confirming the guess.

An example of a secure cipher that can be constructed with SHA256 is to build HMAC-SHA256 and use that to produce a keystream. To encipher a message, one

  • draws a random IV of (say) 32 bytes
  • builds a keystream as
  • sends IV followed by the XOR of message and keystream.

The construction is about twice less efficient than the one proposed, but its security can be derived from that of HMAC-SHA256, which can be derived from that of SHA256 even without relying on the collision-resistance of SHA256.

If efficiency matters more than security proof, the keystream SHA256(key||IV||0)||SHA256(key||IV||1)||SHA256(key||IV||2)||SHA256(key||IV||3).. will do.


Another way to encrypt with a hash function is chaffing and winnowing.


According to this primitives like AES and SHA generate proper pseudo random numbers that pass relevant tests. Hence, your scheme should be sufficient for generating a stream of random bytes as encryption key for stream cipher.

Although, it should be noted again (as you already did): You do not generate a real one-time pad, but just a stream that might look like one according to some tests.

  • $\begingroup$ And terminology wise would the scheme suggested be (a) a hashing stil or did it (b) became an encryption or else (c)? $\endgroup$ – humanityANDpeace Nov 11 '14 at 10:12
  • $\begingroup$ Security concerns left aside: This scheme is an ordinary stream cipher. $\endgroup$ – Thekwasti Nov 11 '14 at 10:16

Yes, a hash function can become an encryption function this way. I posted something similar a while back: Hash Based Encryption.

One thing that is sub-optimal in your approach, is that it isn't a stream cipher. If you encrypt 500 GB of data using this method, and then at some point in the future you only need to decrypt the last 3 KB of the data, you still have to process the entire 500 GB of hashing rounds to reproduce the pseudo-random bits for that last 3 KB. Also, it doesn't allow for parallel processing.


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.