# What are the major flaws and limitations of this hash-based stream cipher design?

• K is a 224-bit key.
• C is a 32-bit counter; it is publicly known. the same value is never used twice.
• plaintext has arbitrary length (up to 64kB).
• H is a cryptographic hash function that returns len(plaintext) bits.
• ^ is the bitwise XOR.
• + is the concatenation.

Encryption:

ciphertext = plaintext ^ H(K + C)

Decryption:

plaintext = ciphertext ^ H(K + C)

• Are there any fundamental flaws?
• Would it make sense to use a longer key?
• Under what circumstances would doing H(C + K + C) instead of H(K + C) make the algorithm more secure?
• I intend to use Skein, which comes in three flavors of internal state sizes: 256, 512 and 1024 bits. How does the internal state size limit the strength of the whole system? Would it make any sense to use the 512/1024 bit variants, even though len(K+C) = 256?
• Is there anything particular about Skein that would make it unsuitable for the job?

edit: Thinking about it, len(K) > internal state size seems pointless. To break the encryption, an attacker would just need to find a K that produces the same internal state as the real K.

-
To turn your question on its head, what are the advantages? In what way do existing, well-cryptanalyzed ciphers fall short of your needs, and in what way does this improve upon those shortcomings? – Stephen Touset May 24 '14 at 5:16
More to the point, why should anyone bother to examine this cipher in the first place? – Stephen Touset May 24 '14 at 5:48
It's mostly out of scientific interest: I was searching for a cipher to encrypt a UDP stream, and found AES CTR. Then I thought, well certainly hashing before XORing would only increase security. Then I thought, maybe hashing alone will suffice?. Then I noticed that this would allow me to encrypt variable-length messages easily. – mic_e May 24 '14 at 12:34
Why would hashing before XORing necessarily increase security? Using your gut intuition when dealing with cryptography is usually a bad idea — unless you can prove an assertion, you should not assume it. – Stephen Touset May 25 '14 at 0:02

Are there any fundamental flaws?

The construction itself is secure for a good H. It's close to what many stream ciphers use internally. E.g. chacha has an H that hashes a 256-bit key, a 64-bit nonce and a 64-bit counter to get 512 bits of output.

Would it make sense to use a longer key?

Yes, if you want more brute force resistance, since finding a preimage is not enough to find the key, if it leads to different values for other counter values.

Under what circumstances would doing H(C + K + C) instead of H(K + C) make the algorithm more secure?

If your H was vulnerable to length extension attack (e.g. SHA-256) and the counter was variable length, H(K + C) would not be secure, but H(C + K + C) might. However, with a constant sized C, I can't think of a reason to use H(C + K + C).

I intend to use Skein, [...]

Then shouldn't you use the stream cipher construction from the Skein paper (pdf, section 4.10)?

-
Excellent hint; thanks! I didn't know that Skein supports efficient partial result determination. – mic_e May 24 '14 at 14:54

…limitations of this hash-based stream cipher design?

One of the limitations of this hash-based stream cipher design would be that it does not offer any kind of “authentication”, nor any kind of “integrity-protection”.

Maybe you just forgot to describe how you will be handling authentication and integrity-protection, but it’s important not to forget about it.

I intend to use Skein…

That raises the question why you aren’t simply using Threefish as a well-vetted block cipher. After all, the design of Skein is based on the Threefish tweakable block cipher!

In the unlikely case you really need a stream-cipher because something prevents you from using a block-cipher, you could create one based on Threefish, which is bound to provide a bit more speed (when implemented correctly) than building a cipher based upon the Skein Hash Function Family.

Nota Bene:

As it’s not clear to me why someone would try to create a hash-based stream cipher while well-analyzed stream ciphers are available, I have skipped cryptanalysis – which means that your design may (or may not) have security issues I did not check on. In the end, I guess I somewhat chime in with Stephens comment and simply don’t seem to have that “scientific interest” you mentioned in your comment.

-
The peers authenticate to a trusted third party, and receive K from that third party, via TLS. The plaintext contains a CRC-32 checksum to detect ciphertext manipulation. – mic_e May 24 '14 at 22:59
@mic_e That process does not authenticate the ciphertext. Just because a plaintext cannot be easily recovered from a ciphertext does not imply that it can't be manipulated in a way to have predictable effects on the ciphertext. Particularly with a XOR-based cipher, where flipping a bit in the ciphertext flips the exact same bit in the plaintext. – Stephen Touset May 24 '14 at 23:59