Is there a security risk to use AES-CBC as stream cipher?

Question

I am building a chat application where I want to encrypt each character while they are typing. I would require a stream cipher for that. I am planning to use AES-CBC mode with HMAC. Are there any security risks if I use AES-CBC mode to encrypt `0's to generate blocks of the one-time pad and then use that one-time pad stream to encrypt plain text through XOR?

Is there any other recommended stream cipher for my application? Does any stream cipher have built-in authentication such that I don't have to append HMAC or authentication tags?

Answer 1

"AES-CBC mode to encrypt `0's to generate blocks of the one-time pad and then use that one-time pad stream to encrypt plain text through XOR" is effectively AES-OFB.

It's fine for confidentiality, and fine if we disregard implementation issues and that it provides even less insurance on integrity than AES-CBC. I second the recommendation of AES-GCM (without HMAC), which solves the integrity issue, and has fair availability in modern dev environments.

Update: a good point is made there that AES-GCM-SIV is less prone to catastrophic failure of the RNG generating the necessary IV. When AES-GCM-SIV is available and the need to process the message twice is tolerable, that's an excellent choice.

Answer 2

You are describing AES-OFB: AES OFB mode. AES-OFB is a fine building block. But it alone isn't enough. It only provides confidentiality, and does not provide integrity.

Some textbooks will tell you that AES-OFB is fine if you only need confidentiality, but they're taking too narrow a view. In practice, we have learned that it's not fine. In practice, you essentially always need both confidentiality and integrity, even if you think you only need confidentiality.

If you try to use something that only provides confidentiality but not integrity (such as AES-OFB alone), often you'll end up with something that is vulnerable to subtle chosen-ciphertext attacks: e.g., reaction attacks, padding oracle attacks (typically not a risk for AES-OFB, but who knows), gzip format oracle attacks, or any of a number of other failure modes. As Moxie Marlinspike explains in his Cryptographic Doom Principle, "if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom". It's too hard to anticipate all of the possible subtle chosen-ciphertext attacks that might be possible. You're not smart enough to build a system using only encryption with integrity. It's not worth the risk.

Instead, good cryptographic engineering practice is to always pick something that provides both confidentiality and integrity. For instance, you can combine AES-CBC (or AES-CTR, or AES-OFB) with message authentication (e.g., SHA256-HMAC) using Encrypt-then-MAC. Or, you can use authenticated encryption, i.e., a dedicated mode that provides both, e.g., AES-GCM-SIV or XChaCha20-Poly1305.

Lastly, let me warn that AES-OFB mode has some implementation hazards. If you ever repeat an IV, then it fails catastrophically. In other words, it is a little bit "brittle" to certain kinds of implementation errors. For this reason, some practitioners recommend using modes that are less brittle, such as nonce-misuse resistant modes like AES-GCM-SIV.

To learn more about this broad subject, see https://security.stackexchange.com/a/2206/971.

Answer 3

AES-CTR, also known as counter mode, is kind of the default stream cipher mode for AES. It as an advantage in the sense that each encryption doesn't rely on previous ciphertext, that it specifies a nonce / counter block. As such it is also easy to calculate how fast it encounters a previously created plaintext block, and thus how much data can be securely processed.

If you want authentication with that then commonly AES-GCM is used. AES-GCM uses AES-CTR and adds an authentication tag calculated using GMAC (again using AES for the final calculations). The advantage of GCM is that many processors have specific instructions to make that operation faster than a run of e.g. HMAC. It makes sure that you don't make common mistakes such as forgetting to include the IV in the calculation. Finally, it allows you to authenticate plaintext as well (additional authenticated data, GCM is known as an AEAD mode).