Hash based stream cipher where the input is a constant, key, nonce and counter
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 &amp; 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.