# Why are block ciphers mostly used as stream ciphers?

Using a block cipher with using either CTR or GCM mode gives us a stream cipher, the only difference being that CTR does not include a MAC tag or AAD but GCM does. I think these are the most commonly used modes of operations for block ciphers because ECB is insecure and CBC is not parallelizable.

Does this not reduce the effective algorithm block size to 1 bit as one bit gets mapped to another bit depending on the keystream bits? Would it not be preferable to keep the block size of a cipher?

Why are block ciphers mostly used as stream ciphers?

CTR mode doesn't need padding like the CBC mode that caused many attacks over the years knowns as the padding oracle attack [1] [2]. Finally, CBC is removed from the TLS, TLS 1.3 has only CTR mode ciphers (rfc 8446).

          +------------------------------+-------------+
| Description                  | Value       |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
|                              |             |
| TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
|                              |             |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
|                              |             |
| TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
|                              |             |
| TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
+------------------------------+-------------+


The attacks and TLS' decision increased the usage of the CTR mode. Remember almost all internet security is based on the TLS. According to SSLlabs's survey %46.6 of the sites accepts TLS 1.3 ( Protocol Support )

Neither CTR mode nor CBC nor CFB (all archive mode of operations) doesn't have a MAC by design. To have a mac either use HMAC or use GCM, CCM, Poly1305, etc.

If we talk about mode theoretically CBC and CTR can only provide Ind-CPA. Beyond this one needs integrity for Ind-CCAx. On the other hand authenticated encryption (GCM,CCM,Poly1305) provides greater security than Ind-CCAx,

Does this not reduce the effective algorithm block size to 1 bit as one bit gets mapped to another bit depending on the key stream bits?

Well, if you use CBC and apply a padding, then you execute more stuff than discarding the unnecessary bits of the block. In both case, the number of the encrypted blocks are almost the same (except if the block is full, then for PKCS#7 one needs an additional block). Then, applying the padding and unpadding are additional functions to apply. CTR mode has need to x-or the stream.

As noted in the comments, CTR mode is highly parallelizable, even enables random access or pre-chaching the stream. The below OpenSLL performances on my machine

openssl speed -evp aes-128-cbc aes-128-ctr

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 818912.47k 1365115.22k 1404590.75k 1409671.85k 1410523.14k 1411497.98k
aes-128-ctr 561928.57k 1899517.87k 3908505.17k 5220669.78k 5835377.32k 5876869.80k

As we can see, except the very short messages CTR beat CBC in AES-NI.

Would it not be preferable to keep the block size of a cipher?

No

• We have to deal with the padding and its insecurity problems, why not remove it at all when we have CTR mode.

• It also increases the size of the data by a maximum of 16-byte for AES.

• CTR mode by design uses PRF instead of PRP (block ciphers are PRP's), this provides a wider range of functions to use - in the same was as we use ChaCha20. In CBC mode we have to use a PRP.

Of course, nothing is perfect! Each mode has its pros and cons. Depending on the context one can prefer one to another. In common sense, in modern cryptography, we prefer the authenticated encryption modes like AES-GCM (probably with SIV) and ChaCha20-Poly1305 (better xChaCha20-1305 for 192 bit nonces).

• Additionally, the parallelizability of stream ciphers (especially for AES-based ones) is also useful in single-threaded processing as modern processors love independent instructions. This can easily net you 4-8x better AES performance from a serial mode like CBC encryption to a parallel mode like CTR. A similar argument holds when you don't have AES instructions but instead have a bitsliced AES implementation.
– SEJPM
Jul 7 at 14:33
• Yes, exactly, since the OP was included that CBC is not parallelizable (though the decryption is not the case), I did not write on this. AFAIK, the parenthesis that you use is due to the fact that the block size of the ChaCha20, right? Jul 7 at 14:46