AES-CTR.

AES-CTR (Counter Mode) is a confidentiality-only mode standardised in NIST SP 800-38A. The cipher encrypts successive counter blocks (typically a 96-bit nonce concatenated with a 32-bit block counter) and XORs the resulting keystream with the plaintext. Because each block depends only on the counter, not on the previous block, CTR allows fully parallel encryption/decryption and random access into the ciphertext — properties that make it the workhorse of disk encryption, IPsec ESP (RFC 3686), and TLS record protection when wrapped in an authenticated mode.

CTR's defining weakness is that it provides no integrity and is malleable: an attacker who flips a ciphertext bit flips exactly the same plaintext bit, with no detection. It must always be paired with a MAC or used as the engine inside an AEAD such as GCM, EAX, or CCM. The second, more dangerous trap is nonce/counter reuse: encrypting two messages under the same key and starting counter produces overlapping keystreams, so XORing the two ciphertexts cancels the keystream and yields the XOR of the plaintexts — a classic "two-time pad" that has broken real systems. The keystream is identical regardless of the data, so a repeated counter is catastrophic even across different files.

In practice, never deploy raw AES-CTR for stored or transmitted data: choose AES-GCM or ChaCha20-Poly1305, which build authentication on top of the same counter-mode core while guaranteeing unique nonces are the only operational requirement.

flowchart LR
  subgraph Keystream generation
    N[Nonce + Counter 0] --> E0[AES encrypt] --> KS0[Keystream block 0]
    N1[Nonce + Counter 1] --> E1[AES encrypt] --> KS1[Keystream block 1]
    N2[Nonce + Counter 2] --> E2[AES encrypt] --> KS2[Keystream block 2]
  end
  P0[Plaintext 0] --> X0((XOR))
  KS0 --> X0 --> C0[Ciphertext 0]
  P1[Plaintext 1] --> X1((XOR))
  KS1 --> X1 --> C1[Ciphertext 1]
  P2[Plaintext 2] --> X2((XOR))
  KS2 --> X2 --> C2[Ciphertext 2]
  C0 --> MAC[Add MAC / use GCM<br/>for integrity]