Hash based stream cipher where the input is a constant, key, nonce and counter

Question

This is a question out of curiosity !

A hash function produces an output that is considered computationally infeasible to reverse.

Let's consider, for the sake of illustration purposes a tried and tested hash function like SHA 256, belonging to any of the families ( 2 or 3). Since the block size for SHA 256 is 512 bits or 64 bytes, we could fill it in the following way, inspired by the ChaCha20 stream cipher.

cccc cccc cccc cccc kkkk kkkk kkkk kkkk kkkk kkkk kkkk kkkk bbbb nnnn nnnn nnnn

c - some fixed constants k - key n - nonce b - counter (32 bits)

Each letter strings corresponds to a byte.

NOTE : The constants could be sacrificed for nonce bytes, hence facilitating a random IV, of bit length >= 128 bits. The counter could also be made to support 64 bits the same way.

We could generate $2^{n} . (blocksize/2)$ bytes of pseudo random key stream, that could be XORed with the plaintext to get ciphertext, where $n$ is the bit length of the counter, $blocksize$ is the block size (in bytes) of the hash function, used. In this case $blocksize$ is 64 for SHA 256...

Let the counter used be $n$ bits. There are $2^{n}$ possible values for the counter. Since output of the hash function is $blocksize / 2 $ bytes for any individual value of the counter, the scheme can generate a maximum of $2^{n} . (blocksize/2)$ bytes.

Here $n = 32$ so we get, $(2^{32}) . (64/2)$ bytes.

I realize that, giving $x$ bytes of input (where $x$ = len(constants) + len(key) + len(nonce) + len(counter) ) and getting $x/2$ bytes as output from the hash function is a kind of inefficiency (SHA - 256), given the fact that the hash function has to run once more (for every input block of size $x$, (additional data of size $x$)) with MD complaint padding information (byte 0x80 followed by $55$ null bytes, and $8$ byte length encoding) . That could cost double CPU clock cycles, for every call to a stream generating function.

In the case of SHA 256 $x = 64$ bytes.

Also, This scheme, is extremely inefficient compared to other stream ciphers available like Chacha20 / Salsa20 !

But,

• Is this a good scheme ?

• What are the possible security flaws, (theoretical/implementation) in this protocol?

• If this is secure, can this scheme offer $256$ bit security ?

• What are the possible Quantum attacks on this scheme ?

• Since SHA-256 family of hash functions is immune to side channel attacks, will that be an added advantage?

Every advice and guidance, will be greatly appreciated! :)

Answer 1

Sure, you can do this. Officially the output of a hash function is not directly designed for this, but the output of SHA-256 is no doubt randomized enough to be used as a base for a stream cipher. And actually, ChaCha & Salsa use what is basically the same approach, but with a different PRF (compared with a PRP when a block cipher is used).

Of course, the devil is in the details. The nonce (96 bits) and counter (32 bits) are rather on the short side. Besides that, they don't follow the convention of having the more static nonce first and the counter next. Having a nonce for domain separation is nice, but as the key should be fully randomized, I guess it is not strictly required for this scheme.

As for the applicability: you haven't specified any padding scheme, and you do seem to be using the full 512 bit block size. That means you should have access to the low level block-based SHA-256 functionality to implement the scheme. Otherwise you would have two full blocks of SHA-256 to perform for one 256 bit output and one block with the padding and length encoding. The output is then the output of the last block operation (which also depends on the first one as the state is maintained). So in that case you would have a 4 x drawback compared with using a normal stream cipher at the minimum when using the full SHA-256.

If you are using the block size then you could define separate SHA-256 constants for the starting state instead of trying to shoe-horn them into the input block.

Generally the hash functions don't use table lookups and should be relatively safe against side channel attacks. Of course, side channel attacks are implementation dependent, so this detail is not a final verdict for any system.

---

A minor note: although logical, the output is not entirely related to the input block size for generic hash functions. So specifying $n / 2$ as output size feels a bit strange to me.