No, AES is a block cipher. It encrypts data in fixed chunks of 128 bits at a time, using keys of 128, 192, or 256 bits. However, AES can behave like a stream cipher when you run it in certain modes of operation, which is likely the source of the confusion behind this question.
Block Ciphers vs. Stream Ciphers
A block cipher takes a fixed-size block of data and transforms it into encrypted output of the same size. AES always works on 128-bit blocks. If your data doesn’t fit neatly into 128-bit pieces, the leftover bits need to be padded to fill the final block.
A stream cipher works differently. It generates a continuous stream of random-looking bytes (called a keystream) and combines them with your data one bit or byte at a time using a simple XOR operation. There’s no need for padding, and you can encrypt data of any length as it arrives. This makes stream ciphers a natural fit for things like video streaming, real-time communications, and network traffic where data flows continuously rather than arriving in neat packages.
How AES Becomes a Stream Cipher
AES itself is always a block cipher. But the “mode of operation” you wrap around it changes how it processes data. Several standard modes effectively turn AES into a stream cipher by using the block cipher engine to generate a keystream rather than to directly encrypt the data.
CTR (Counter) mode is the most straightforward example. Instead of feeding your actual data into the AES block cipher, CTR mode feeds in a counter value. It starts with a number (called a nonce), encrypts that number with AES, then increments the counter by one and encrypts again, and so on. This produces a long stream of random-looking output. Your plaintext data is then XORed with this stream to produce ciphertext. The original data never passes through the AES block cipher at all.
OFB (Output Feedback) mode works similarly, using the output of one AES encryption as the input for the next, creating a synchronous stream cipher. CFB (Cipher Feedback) mode feeds previous ciphertext back into AES to generate the next chunk of keystream. Both eliminate the need for padding and allow encryption of arbitrary-length messages.
By contrast, modes like ECB and CBC use AES as a traditional block cipher, requiring data to be split into exact 128-bit blocks with padding added to the last one.
Why This Matters in Practice
The stream cipher modes of AES are dominant in modern internet security. When you connect to a website over HTTPS, the encryption is most likely handled by AES-GCM, which is built on CTR mode with an added authentication layer. GCM doesn’t just encrypt your data as a stream; it also generates a tag that verifies nothing was tampered with in transit. This combination of encryption and authentication in one pass is called authenticated encryption, and it’s the current standard for secure communications.
Plain CTR mode is fast and parallelizable but provides no authentication on its own. AES-GCM solves this, which is why protocols like TLS 1.3 use it as a default. If you’re choosing a mode for a new application, GCM (or another authenticated mode) is almost always the right call over raw CTR, OFB, or CFB.
The Nonce Reuse Problem
When AES operates as a stream cipher, one critical rule applies: never reuse the same nonce (or initialization vector) with the same key. In CTR or GCM mode, reusing a nonce produces the exact same keystream twice. An attacker who captures two messages encrypted with the same keystream can XOR the ciphertexts together and cancel out the encryption entirely, exposing the relationship between the two plaintexts. NIST describes nonce reuse in AES-GCM as a “catastrophic failure” of security.
This isn’t a theoretical concern. Real-world systems have been broken because of nonce management mistakes. CTR mode typically uses a 64-bit nonce paired with a 64-bit counter, giving you room for many unique encryptions under one key, but the system generating those nonces needs to guarantee they never repeat. If nonces are chosen randomly rather than sequentially, the probability of an accidental collision grows faster than you might expect.
Performance of AES in Stream Modes
Stream-like modes are also the fastest way to use AES on modern hardware. Most desktop and server CPUs include dedicated AES instructions (Intel calls theirs AES-NI) that accelerate AES operations at the hardware level. For parallelizable modes like CTR, these instructions can deliver roughly 10 times the throughput of a pure software implementation. That translates to speeds around 1.3 CPU cycles per byte for AES-128 in parallel modes, which is fast enough to encrypt gigabits per second on a single core.
Sequential modes like CBC encryption, where each block depends on the previous one, can’t take full advantage of this parallelism and typically see only a 2 to 3 times speedup from hardware acceleration. This performance gap is another reason CTR-based modes have become the default for high-throughput applications like disk encryption and network protocols.
NIST’s Evolving Guidance
NIST, the U.S. agency that standardized AES and its approved modes, announced plans to revise its block cipher mode recommendations (SP 800-38A). The key changes include restricting ECB mode to very specific use cases, clarifying requirements for initialization vectors and counters, and emphasizing the importance of authentication. NIST has noted that confidentiality-only modes (those without built-in authentication, including plain CTR, OFB, and CFB) have known security vulnerabilities. The agency is exploring whether to eventually deprecate these unauthenticated modes in favor of authenticated alternatives like GCM.
The practical takeaway: AES is a block cipher by design, but most of the time you’ll encounter it functioning as a stream cipher through CTR or GCM mode. Understanding the difference matters mainly when you’re choosing a mode or evaluating a system’s security, because the rules for safe usage change significantly depending on whether AES is operating block by block or generating a keystream.