Block cipher vs stream cipher: differences and examples
AES vs ChaCha20 in practice: how block and stream ciphers process data, why CTR and GCM modes blur the line, which is faster on phones, and the nonce-reuse trap.
On this page 8 sections
A block cipher encrypts data in fixed-size chunks, such as the 128-bit blocks of AES, while a stream cipher generates a stream of pseudo-random bytes (a keystream) from the key and a nonce and combines it with the data byte by byte, as ChaCha20 does. In practice the line is blurry: AES usually runs in a mode such as CTR or GCM that makes it behave like a stream cipher, so the real choice today is between AES-GCM and ChaCha20-Poly1305. Both are secure when used correctly, and the right one depends mostly on the hardware.
Block ciphers
A block cipher takes a fixed-size block of plaintext and a key and produces a block of ciphertext of the same size. AES works on 16-byte (128-bit) blocks; older ciphers such as DES, 3DES and Blowfish use 8-byte (64-bit) blocks. On its own, a block cipher can encrypt exactly one block, so it is always used in a mode of operation that says how to handle longer data. NIST's standard modes include ECB, CBC, CFB, OFB and CTR (NIST SP 800-38A). For what happens inside AES itself, see AES-256 explained.
Two practical consequences follow from working in blocks:
- Padding. Modes such as ECB and CBC need the input to fill whole blocks, so the last block is padded. Standard HLS video encryption, for example, uses AES-128 in CBC mode with PKCS#7 padding.
- Block size limits. With 64-bit blocks, repeated ciphertext blocks become likely after about 2 to the power 32 blocks, which is only 32 GB of data. The 2016 "Sweet32" attack used this to recover plaintext from long HTTPS sessions encrypted with 3DES. AES's 128-bit blocks push that limit so far away that it doesn't matter in practice.
Stream ciphers
A stream cipher turns a key and a nonce into a long keystream and XORs it with the plaintext. Decryption XORs the same keystream again. The ciphertext is exactly as long as the plaintext, no padding is needed, and a corrupted bit in transit damages only the matching bit of the output, which suits real-time audio and video.
ChaCha20, standardised in RFC 8439, is the modern stream cipher. It takes a 256-bit key, a 96-bit nonce and a 32-bit block counter, and produces keystream in 64-byte chunks, up to about 256 GB for a single key and nonce (RFC 8439). Because the counter tells it which chunk to produce, a player can jump to any point in the stream without processing everything before it. The older RC4 stream cipher had biases in its keystream and has been banned from TLS since 2015.
The weakness of any stream cipher is malleability: flipping a bit of the ciphertext flips exactly the same bit of the plaintext, and nothing notices. That is why ChaCha20 is paired with the Poly1305 authenticator, which detects any change.
Modes that turn a block cipher into a stream
Counter (CTR) mode is the bridge between the two families. Instead of encrypting the data, AES encrypts a sequence of counter blocks, each made of a nonce and a number that goes up by one per block, and the output becomes a keystream that is XORed with the data. The result behaves exactly like a stream cipher: no padding, ciphertext the same length as the plaintext, blocks that can be processed in parallel, and random access to any position.
GCM is CTR mode plus an authentication tag, which is why AES-GCM is described as a block cipher running in a stream-like mode. Other stream-like modes exist (OFB and CFB), but CTR and GCM are the ones you will meet. The chaining modes, CBC above all, are the ones that keep AES behaving like a block cipher, with padding and sequential encryption. Our comparison of AES-GCM vs AES-CBC goes deeper into that choice.
Side by side
| Aspect | Block cipher in a chaining mode (e.g. AES-CBC) | Stream cipher or counter mode (ChaCha20, AES-CTR, AES-GCM) |
|---|---|---|
| How data is processed | Fixed blocks, each mixed with the previous ciphertext block | A keystream XORed with the data |
| Padding | Needed | Not needed |
| A corrupted ciphertext bit | Garbles its block and flips a bit in the next | Flips only the same bit of the plaintext; authenticated modes such as GCM reject the whole message |
| Parallel processing | Decryption yes, encryption no | Both |
| Jumping to a position | Possible for decryption | Yes, using the counter |
| Speed | Encryption limited by chaining | Fast; AES variants need AES hardware to shine |
| Classic pitfall | Padding-oracle attacks; patterns if ECB is used | Reusing a nonce with the same key |
AES vs ChaCha20 on phones
AES is fast when the processor has dedicated AES instructions, which most laptops, servers and recent phones do (ARMv8 Cryptography Extensions on phone chips). Without them, AES in software is slow, and RFC 8439 notes that many software AES implementations are vulnerable to cache-timing attacks. ChaCha20 uses only additions, rotations and XORs, so it runs fast and in constant time on almost any chip. RFC 8439 puts it at around three times the speed of AES on platforms that lack AES hardware.
This has shaped real products. In 2014 Google deployed ChaCha20-Poly1305 in Chrome for devices without AES acceleration, which then included most Android phones. In 2019 it introduced Adiantum, a storage-encryption mode built mainly on ChaCha, for entry-level Android phones: on an ARM Cortex-A7 processor, which has no AES instructions, Google measured it at around five times faster than AES-256-XTS (Google Security Blog). Where AES hardware exists, Android still uses AES.
On hardware with AES instructions the picture flips. On one Apple M3 Max laptop running OpenSSL 3.6, a single core encrypted 16 KB buffers at these rates (September 2026; figures are for comparison only and will differ on other machines):
| Cipher | Throughput on one core |
|---|---|
| AES-128-GCM | about 9.5 GB/s |
| AES-256-GCM | about 8.2 GB/s |
| ChaCha20-Poly1305 | about 2.1 GB/s |
Both are standard TLS 1.3 cipher suites, so HTTPS can use either. Video formats are less flexible: standard HLS segments use AES-128 in CBC mode, and the Common Encryption schemes used with DRM use AES in counter mode ("cenc") or a CBC pattern ("cbcs"). Whatever the transport, the segment decryption inside the player is AES, and its security depends far more on how the key is delivered than on the cipher, as our guide to HLS encryption explains.
Security pitfalls: nonce reuse
A stream cipher's keystream depends only on the key and the nonce. Encrypt two messages with the same pair and they share a keystream, so XORing the two ciphertexts cancels it out and leaves the XOR of the two plaintexts. RFC 8439 states this consequence plainly. If an attacker knows or can guess any part of one message, such as a file header or a JSON field name, the matching part of the other is revealed. In AES-GCM a repeated nonce is worse still: NIST warns it can let an attacker forge messages, and calls nonce uniqueness almost as important as keeping the key secret.
This is not theoretical. The 2017 KRACK attacks on Wi-Fi tricked devices into reinstalling a key already in use, which reset its nonce, so WPA2 reused keystream and packets could be decrypted, replayed or forged (KRACK).
How to stay safe:
- Let a well-maintained library generate nonces; never hard-code one or derive it from the time.
- With random 96-bit nonces in AES-GCM, stay below about four billion (2 to the power 32) messages per key, as NIST requires.
- Where nonces are hard to manage, choose a design that tolerates it: XChaCha20-Poly1305 has a 192-bit nonce that is safe to pick at random, and AES-GCM-SIV (RFC 8452) reveals only whether two messages were identical if a nonce repeats.
- Rotate keys well before the limits, as described in our guide to key rotation.
Block ciphers have their own pitfalls: ECB mode leaks patterns, CBC is exposed to padding-oracle attacks when errors are observable, and 64-bit blocks run out of room in long sessions. For the bigger picture of which algorithms to use where, see types of encryption.
Key takeaways
- Block ciphers encrypt fixed-size blocks and need a mode; stream ciphers XOR data with a keystream.
- AES is a block cipher, but in CTR or GCM mode it behaves like a stream cipher.
- With AES hardware, AES-GCM is fastest; without it, ChaCha20-Poly1305 is faster and safer against timing attacks.
- Stream ciphers and counter modes must never reuse a nonce with the same key.
- Always add authentication: Poly1305 with ChaCha20, GCM with AES.
Frequently asked questions
Is AES a block or stream cipher?
AES is a block cipher: it encrypts one 128-bit block at a time with a 128, 192 or 256-bit key. It becomes practical for real data only when run in a mode of operation. In CBC mode it behaves like a classic block cipher with padding; in CTR or GCM mode it generates a keystream and behaves like a stream cipher, which is how most modern systems, including HTTPS, use it.
Is DES a stream or block cipher?
DES is a block cipher. It encrypts 64-bit blocks with an effective key of 56 bits, which is short enough to search exhaustively, so NIST withdrew the standard in 2005. Triple DES applies DES three times to lengthen the key, but it keeps the small 64-bit block, which the Sweet32 attack exploited. NIST disallowed 3DES for new encryption after 2023. Use AES instead.
Is AES-GCM a stream cipher?
Not strictly, but it behaves like one. AES-GCM uses the AES block cipher in counter mode to produce a keystream, XORs it with the data, and adds a 16-byte authentication tag. So the ciphertext is the same length as the plaintext, no padding is needed, and it inherits the stream-cipher rule that a nonce must never repeat under the same key. Formally, it is an authenticated encryption mode of a block cipher.
Which is more secure, a block cipher or a stream cipher?
Neither is inherently more secure. AES-GCM and ChaCha20-Poly1305 both give strong, authenticated encryption and are both standard in TLS 1.3. Security depends on correct use: a unique nonce for every message, authentication on every ciphertext, and keys that are generated, stored and rotated properly. Failures usually come from those details rather than from choosing the wrong family.