Use AES in CTR mode as a stream cipher
AES-CTR turns the block cipher into a keystream generator, eliminating padding. Learn correct counter management and why you must add authentication separately.
- 1
CTR mode encrypts a counter value with AES to produce keystream blocks, then XORs with plaintext. The ciphertext length equals the plaintext length (no padding). The counter must never repeat for the same key — otherwise nonce-reuse catastrophe applies.
- 2 AES Encryptor →
Encrypt data with AES in CTR mode. The output length matches the input length exactly — no padding. Provide a nonce/counter that must be unique per encryption under the same key.
- 3 AES Decryptor →
Decrypt by XORing the same keystream. CTR decryption is identical to encryption (the same AES-CTR operation), which simplifies implementation.
- 4
Warning: CTR mode provides no integrity. An attacker can flip bits in the ciphertext and the corresponding bits change in the decrypted plaintext. Always combine CTR with HMAC (encrypt-then-MAC) or use GCM instead, which is CTR + built-in authentication.
Frequently asked questions
- CTR vs GCM — which to use?
- Use GCM. It is CTR mode with built-in authentication (GHASH). Using raw CTR without authentication is a common vulnerability — an attacker can modify ciphertext undetected.
- How do I manage the counter?
- Split the 128-bit block into a nonce (e.g., 96 bits) and a counter (32 bits). The counter increments per block. For multiple messages, use a new random nonce. Never let the counter wrap around.
Workflows that solve this
Learn more
Want to understand why?