Skip to content
uencoder
TASK

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. 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. 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. 3
    AES Decryptor →

    Decrypt by XORing the same keystream. CTR decryption is identical to encryption (the same AES-CTR operation), which simplifies implementation.

  4. 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?

Related tools