Is SHA-256 secure as a CTR block cipher?

Question

Generate a 256-bit random nonce. XOR it with a 256-bit reusable symmetric key. This is x.

We represent numbers in simple binary instead of a counting function. 0 in dec = [256 zeros] in binary, 1 = [255 zeros]1, 23092348 = [241 zeros]1011000000101110001111100, etc.

For each nth block needed for the length of the plaintext, XOR x with n and hash it with SHA-256 to form b[n].

Let p[n] be the nth 256-bit block in the plaintext and c[n] be the nth block in the ciphertext. Then c[n] := b[n] XOR p[n].

Send the unencrypted nonce along with the ciphertext.

To decrypt c[n], XOR it with b[n] to retrieve p[n].

Is this secure? If so, then why do we need AES-256?

If this is not secure, then is there any mode of operation for which SHA-256 is secure as a block cipher? Specifically, it would need to be used in cipher feedback, output feedback, or any other mode that only uses the cipher in the encryption direction.

Answer 1

Well, as far as we know, the mode you suggest should be secure. Now, to be honest, AES256 versus your mode isn't quite a fair comparison; your mode gives somewhat less theoretical security; if you encrypt a known $2^n$ block message, the key can be recovered with $2^{256-n}$ effort; however, this observation doesn't really affect the practical security.

However, as for why AES might be preferable:

• AES is faster. Performance, of course, varies wildly between platforms and implementations; but taking as an example the CryptoC++ benchmarks, we see AES256 listed as 18.2 cycles per output, while SHA256 takes about 31 cycles per output. Note: SHA256 is listed as 15.8 cycles per byte; however, that is bytes of input; a single SHA256 compression evaluation takes 64 bytes of input, and hence takes 1011 cycles; in your use, you use a single SHA256 compression evaluation to generate 32 bytes of keystream; hence 1011/32 = 31.6 cycles per byte of output.

• AES can be used on contexts other than counter mode. That is, AES is invertable (if you know the key); that sometimes comes in handy.

• However, the most important point is: AES has been far more extensively analyzed in this context. SHA256 has been analyzed fairly heavily for collision resistance; however, I don't know if anyone has really looked at the question "if we have a large number of hashes of related but unknown images, can we gdeduce what the image is?". With AES, we known that people have been attacking it with this question in mind.

Answer 2

The CTR mode of encryption is defined in general for any cryptographically strong pseudo-random function (PRF). You can build such a PRF from a hash function.

For CTR, you produce a key stream by concatenating:

$$F(k,0) || F(k,1) || ... || F(k,m)$$

where $F$ is your secure PRF, $k$ is your key, and $m$ is the the length of your plaintext divided by the output size of $F$. To rewrite it in your mode's notation:

b[n] = F(k,n)

But $F$ can be any secure PRF. It can be AES but it doesn't have to be, AES is just the popular choice.

Since you want to use SHA-256, you can use a hash-based PRF. You have effectively tried to build one, but a commonly accepted PRF, like HMAC, would be better. If you use HMAC with SHA-256 as your hash function, you have effectively built CTR mode using SHA-256. To do so, your b[n] would change from your function:

b[n] = SHA-256(SHA-256(nonce XOR key) XOR n)

to the HMAC function:

b[n] = SHA-256(key XOR opad || SHA-256(key XOR IPAD || (nonce || n)))

The HMAC scheme will require two hashes every block, whereas your scheme allowed you to only calculate the first hash once, so the HMAC scheme will be roughly twice as slow.

It's worth noting that HMAC is not proven to be a perfect PRF, but it's widely regraded as a PRF. It's definitely a safer PRF choice than a home-made construction. I can't speak as to how secure your scheme is -- it certainly looks plausible, but that doesn't really mean anything -- but it's none better than HMAC.

And since you're so close to HMAC already, if you need to use SHA-256 to build CTR-style encryption, I would recommend you use that (or some other hash-based PRF) instead.

Also, on a side note regarding your closing comment: CTR produces a stream cipher. We commonly use a block cipher to build it, but CTR mode is actually a stream cipher. So we can build a stream cipher from SHA-256, but that's distinct from being able to build a block cipher from it. I think what you meant is that you have a set of schemes you're thinking about (OFB, CFB, CTR, and maybe others) and want to know which of them a hash can be used to fulfill. Given the ability to turn a hash into a PRF, the answer would include CTR.

Answer 3

Check out "Analysis of SHA-1 in Encryption Mode", Handschuh, Knudsen, and Robshaw (2001), and some of the papers that cite it. They give some evidence that the answer to your question might be "yes".

Answer 4

What you explain in the question resembles SHACAL-2 cipher's forward cipher function, see http://en.wikipedia.org/wiki/SHACAL#Security_of_SHACAL-2. SHACAL-2 is NESSIE accepted way of using SHA-256 as cipher, therefore it has appeared somewhat secure.