3

I was thinking of doing symmetric encryption using just hashing and simple XOR encryption. It would work as:

  1. Alice and Bob share a symmetric key
  2. Alice manages to send an (authenticated) IV to Bob
  3. Bob and Alice both combine the IV with the symmetric key and use it to seed a PRNG
  4. the output of the PRNG is hashed (SHA256)
  5. whenever a message needs to be sent, the data is XORed with the hashed PRNG output

Are there any serious issues with this approach? If indeed there aren't any, why would one use a SHA256/AES combo with 2 points of failure instead of just relying on the existence of one way functions like SHA256? Why use AES at all?

cHiMp
  • 389
  • 3
  • 11

1 Answers1

9

It is possible to turn a hash function into a stream cipher; there are several methods for that, and the simplest is to compute $h(K||IV||x)$ for hash function $h$, initialization vector $IV$, and successive values of a counter $x$. This yields an arbitrarily long sequence of pseudo-random blocks (32 bytes per invocation if $h$ is SHA-256). Then XOR that stream with the data to encrypt or decrypt.

We don't usually do that for two main reasons:

  • Security of the scheme is not that easy to characterize. A "secure" hash function (resistant to collisions and preimages) will not necessarily imply a secure stream cipher that way. (Very) roughly speaking, the stream cipher is secure if the hash function behaves like a random oracle.

  • Performance sucks. Hash function are efficient at processing a lot of input data, not at generating a lot of output data.

It is of course quite tempting to have a unique primitive diversified into multiple usages; it would save space in code. However, in embedded systems where ROM size is at a premium (in particular smart cards), CPU power and RAM are even more scarce, and AES performs better than SHA-256 along these metrics.

Sponge hash functions, like the upcoming SHA-3 (Keccak), have an internal structure which is kind-of "reversible", meaning that they are good at input and at output. A Keccak core should allow both secure hashing and efficient pseudo-random generation (i.e. encryption, with a XOR).

Conversely, authenticated encryption modes like GCM use a block cipher for both encryption and integrity, the latter replacing what would have been classically done with a hash function (with HMAC).

Thomas Pornin
  • 88,324
  • 16
  • 246
  • 315