2

This is just an idea I had while looking through some threads so take it as you will.

Given a plaintext of any length and a key that a specific hash function is capable of taking as input(I mention this as I know bcrypt has issues with extremely large inputs), what would be the potential issues/attacks of hashing the key and then xoring the resulting key with a plaintext block of the same length? For the next block you would hash the previous hash created via the key and xor that with the next plaintext block. Repeat till you reach the end of the plaintext, pad it to the needed length, and commit the last xoring

I would imagine that it would make for a high speed stream cipher that is reasonably capable as long as the initial key is sufficiently strong.

Thanks.

Everlag
  • 150
  • 8

2 Answers2

3

This is essentially a (bad) stream cipher. It has multiple problems:

  1. You might hit a cycle much sooner than you'd want.

  2. It's not parallelizable - this is a large performance issue on modern CPU's compared to algorithms that parallelize well.

  3. The key is only inserted at one point of the stream, meaning if an enemy knows only one block of plaintext it can XOR it out to retrieve the internal state of the cipher compromising all further blocks.

  4. There is no nonce, meaning that every cipherstream will be the same.

(5.)  Padding plaintext is not necessary in a stream cipher - you can simply discard the unneeded bits from the cipherstream.

However, the answer to the question in your title (What prevents continued hashing of a key from being used as a cipher when xored with plaintext?), is nothing. For example the ChaCha stream cipher works by repeatably hashing the key, nonce and an increasing counter for each block. Note that the hash function ChaCha uses is very specialized - it doesn't compress or is collision resistant, and as result can be much faster than "regular" hash functions that have much more stringent requirements.

orlp
  • 4,230
  • 20
  • 29
  • 3
    Point 3 is a killer. Encrypt something that starts " \n" (with a 128-bit hash), and the message is trivial to crack. – Gordon Davisson Jul 15 '13 at 05:52
  • Thanks for the quick and concise answer. It really is helpful to know what was wrong so I can look and become educated. – Everlag Jul 15 '13 at 06:02
1

While nightcracker has correctly given the bad news, I'm adding this reply to point out that the basic idea is not unsalvageable.

Take the cryptographic hash function of your choosing. We can use it as the basic transformation** of a sponge function, which can serve as the basis for an encryption scheme, and works roughly the way you describe.

The key modification from your proposal is that we must only output part of the hash each time (the rate), while the remaining (capacity) bits are never accessible to the attacker. Further, if we are to encrypt more than one message with the same key, you also need to input a nonce along with the key. The hash function must also have sufficient output size to avoid certain attacks.

Note that using a regular cryptographic hash this way is unlikely to result in top performance compared to existing stream ciphers such as Salsa20 or AES-CTR.

** Sponge functions can be instantiated with non-invertible functions with no major loss of security; see this.

Samuel Neves
  • 12,460
  • 43
  • 52