What is the advantage of using a symmetric cipher like AES to generate a keystream?

Question

I see examples of AES (with a shared secret key) being used to encrypt shared secrets (e.g. nonce + counter) to produce a keystream against which the plaintext is XOR'ed to produce the ciphertext.

What is the advantage of using this method over simply using AES to encrypt the plaintext?

What is the advantage of using a symmetric cipher like AES to generate the keystream in this algorithm where it functions as a one-way hash?

Answer 1

AES, by itself, is a block cipher: it accepts as input a "block" of 16 bytes, and produces a block of 16 bytes. But we want to use it to encrypt "data", usually long sequences of bytes, much longer than 16 bytes, so something else is needed; this is the mode of operation. The mode of operation defines how the input data is processed, and, in particular, what exactly goes into the block cipher proper.

The simplest method is to split the data into 16-byte blocks and process them independently of each other. This is called ECB. The usual penguin picture (see @drjimbob's answer) is a clear demonstration that there is something wrong with ECB, when processing "normal data". A better encryption mode is needed. Historically, OFB, CFB and CBC first gained popularity, then later on CTR was defined. All these modes make different things with the data and invoke the block cipher on different blocks. In CBC and CFB, AES is invoked of blocks which are a XOR of a data block with some produce of past processing; with OFB and CTR, AES is invoked on something which depends on the IV, key and block position, but not on the data itself.

With a lot of hand-waving, we can claim that in a good mode of operation, the raw data should not enter the block cipher "as is". The reason is the following: normal data has redundancy, so you can expect the source blocks to have repetitions (e.g. think of XML). However, the block cipher itself is deterministic, so if you call it twice on the same output, you will get twice the same output. This is the kind of information leak that a good encryption system should hide. In a mode of operation, the "hiding power" lies in the block cipher; the rest is mere data routing; therefore, in order to hide repetitions and other structural elements of the source data, the mode should be such that no two invocations of the block cipher shall send the same block to the block cipher. And this implies at the very least some pre-cipher processing.

Now CFB and CBC still "combine" the data block with the block cipher input, while OFB and CTR do this combination on the output only. We might argue that the latter method is superior because it allows precomputations: with OFB and CTR, one can "prepare" the pseudo-random string before having access to the actual data. However, this is rarely done, because buffering has its own costs. A much more important characteristic of CTR, that CFB, OFB and CBC do not have, is parallelization: given, say, a 160-byte message to encrypt, the 10 underlying AES invocations can be done simultaneously, provided that you have enough circuitry for that. You cannot do that with CBC, because you have to wait for the result of the encryption of one block to begin processing the next block (you can have parallel CBC decryption, though). High-bandwidth circuit makers love CTR mode (it maps well onto unrolled, pipe-lined AES implementations).

---

To sum up:

• There is a need for a mode of operation more complex than ECB.
• The mode should include some data pre-processing so that the raw data does not enter "as is" the block cipher. If the mode "directly encrypts the plaintext" (i.e. applies the block cipher on unmodified source data blocks) then it will have trouble hiding repetitions, and that's a problem with normal structured data.
• There is no formal need that the source data enters the block cipher at all; the source data may enter the mix as a post-processing step. This gives some minor advantages, e.g. the possibility to precompute the bulk of the operations; if the post-processing is a simple XOR, it also makes decryption identical to encryption, which is nice when a system must do both (it saves code space and/or silicon area).
• An important feature of good modes is the possibility to speed up things with parallelization. It so happens that the one popular mode which is amenable to parallelization for both encryption and decryption (that's CTR) also is a "post-processing only" mode. That's a coincidence; to my knowledge, there is no strong reason why it should be so. But it is nice nonetheless (as said above) so we will not complain.

Answer 2

That operation you described is just CTR mode, one of the standard block cipher modes. You have to choose a block cipher mode; not choosing one amounts to ECB (Electronic code book) mode when you have to encrypt more than one block of data. It is well known you should avoid ECB mode as it is quite common to be able to detect patterns in the encrypted data. See for example wikipedia's example of encrypting an image of a penguin with ECB mode:

CBC (Cipher Block Chaining) is a good mode security wise; granted you can't parallelize encryption -- you can't encrypt block 2 until you've encrypted block 1. This is because the N-th block of the ciphertext (C_N) is generated by encrypting XOR of the N-th block of plaintext and the (N-1)-th block of ciphertext: C_N = Encrypt(P_N XOR C_N-1).

CTR mode is another good mode security wise. The main benefit over CBC is you can parallelize both encryption and decryption.

There's also another minor benefit of CTR mode over modes like CBC if you are encrypting massive amounts of data. For a AES-128, where every block is 128-bits with CTR mode, you don't run into a cycle until you encrypt more than 2¹²⁸ blocks (and every block is 128 bits = 16 bytes - this 5070602400912917605986812821504 GB of data before you should reset CTR mode to be safe). For CBC mode, you have the birthday paradox in action so you'll generate a collision every 2^128/2 blocks encrypted - every 274877906944 GB of data, before you have to worry about that you should be changing your key.

See also Thomas Pornin's great answer on this minor benefit.