3
$\begingroup$

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?

$\endgroup$
1
  • $\begingroup$ Perhaps a bit late, but this question re. stream ciphers may be of use, if only for the nomenclature. $\endgroup$
    – Paul Uszak
    Sep 11 at 15:32

3 Answers 3

9
$\begingroup$

"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.

$\endgroup$
6
$\begingroup$

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.

$\endgroup$
4
  • $\begingroup$ If for each byte to be encrypted one took two bytes from an AES "stream of ecrypted ocounter values" and used them to select one of 65,536 mappings of source to encrypted data, chosen in such a way that for any combination of cryptotext byte and replacement, any of 256 bytes of source text would have been possible, woudl that mitigate reaction attacks? $\endgroup$
    – supercat
    Sep 11 at 17:50
  • 1
    $\begingroup$ @supercat, you are inventing your own scheme. Inventing your own scheme is rarely a good idea in cryptography. See, e.g., security.stackexchange.com/a/2210/971, security.stackexchange.com/q/18197/971. $\endgroup$
    – D.W.
    Sep 11 at 22:20
  • $\begingroup$ @D.W.: Many schemes require transmission of an IV or nonce in addition to the data payload. While is is usually not a problem, there are some situations such as low-power radio communications where playload sizes are insufficient to support normal cryptographic methods. $\endgroup$
    – supercat
    Sep 11 at 22:55
  • 1
    $\begingroup$ @supercat, If you have a specific situation that has special constraints, I recommend asking a new question where identify your security goals and the constraints you are under and ask how best to achieve those goals within those constraints. This is beyond the scope of what comments on this site are intended for. $\endgroup$
    – D.W.
    Sep 11 at 23:36
4
$\begingroup$

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).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.