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