Terminology: Is a block cipher in counter mode still considered a block cipher or is it classified as a stream cipher?

Question

I'm confused about what terminology to use. I see people referring to such a cipher-MOO combination using both terms.

Answer 1

A block cipher is a block cipher. But if it is used within counter mode it becomes a block cipher within a streaming mode of operation. The resulting cipher has the external properties of a stream cipher. The block cipher now acts as a stream cipher. But I would not call it a stream cipher, because that would probably fool readers that the cipher has the internal design properties of a stream cipher.

In other words, streaming modes such as CTR simulate a stream cipher, but it doesn't emulate it. Externally it does show it to have certain properties, but it is does not try to be one internally. For instance, the key remains protected by the block cipher, rather than by properties of CTR which defines how to perform the streaming.

For these reasons I would prefer a sentence like "using CTR mode lets you use a block cipher as a stream cipher" rather than "using CTR mode turns the block cipher into a stream cipher". You could use the term "stream cipher" after such a clarification, I suppose, in case you don't want to get stuck with "block cipher in stream mode of operation" which may be too large / descriptive in texts.

Answer 2

Terminology varies, but when talking to users of cryptography, I lean towards calling CTR a “stream cipher mode built from a block cipher”, AES a “block cipher” and AES-CTR a “stream cipher”. I've been writing some cryptography API documentation lately, looking for a reasonable compromise between what is technically correct and what is comprehensible to developers, and this felt like the most natural choice.

My reason for calling AES-CTR a stream cipher is that has the same functional interface as “pure” stream ciphers like RC4 or ChaCha20. Since it xors a bitstream with the message, it's a stream cipher. The fact that a block permutation is involved under the hood is a detail.

Historically, presentations of cryptography have tended to focus on the “core” algorithm such as DES or AES. But in fact that's the wrong focus. Out there, a lot more systems are broken because they're using the wrong mode than because they're using the wrong block permutation. Choosing a block permutation is easy: go to your relevant authority (NIST, GOST, …) and pick one. Ok, NIST does still allow 3DES without deprecating it, but people don't tend to gravitate to 3DES so much as to unsuited modes. Picking a mode is not easy. Many people use an encryption mode when they should be using an unauthenticated encryption mode. Even when authentication is not needed, people tend to pick ECB because it's simpler (no IV), or to pick CBC because it gets a lot of use so it can't be wrong (and sometimes because it looks non-malleable and that feels nice to people who don't think about active attacks).

So, really, people shouldn't ever be told to “use AES”. They should always be told to “use AES-CTR” or “use AES-CCM” or “use AES-SIV” or “use ChaCha20” or “use ChaCha-Poly” or whatever is right for their use case. AES-CTR and ChaCha20 are stream ciphers, the other three are authenticated ciphers. The fact that the first three are based on an explicitly defined block cipher, while the last two only work with blocks under the hood, is an implementation detail.

Answer 3

The way that a lot of practice-oriented, introductory materials use the terminology is at odds with the more rigorous, academic treatments. For example, it's very common to find problematic statements like this: "A block cipher is an encryption algorithm that encrypts messages one block at a time."

In the more precise literature, a block cipher is a practical implementation of a pseudorandom permutation family (PRP), something that isn't really meant to be a practical message encryption algorithm but rather a core building block (a.k.a. a "primitive") out of which such algorithms can be built.

An analogy: saying that that you encrypt messages with a block cipher is the same type of category mistake like saying that you commute to work with an internal combustion engine. That'd be an odd thing to say in most contexts; what you'd actually say is you commute on a bus, or car, or train, or bicycle, etc. Likewise, you encrypt messages with algorithms like AES-CBC, AES-CTR, ChaCha20, etc. What these have in common that makes them broadly interchangeable is that they're variable length message encryption algorithms. Two of them are stream ciphers as well (AES-CTR and ChaCha20), and two of them are built out of a block cipher (AES-CBC and AES-CTR) by use of a block cipher mode (CBC and CTR), but those statements involve peeking under the hoods, so to speak. If we're foregrounding what they offer to their users, those details are of secondary relevance.

(Also note, all three algorithms could loosely be said to encrypt messages one block at a time, but only two of them use a block cipher. 🤷‍♂️)