{ "id": "ep99m6p6st", "slug": "counter-mode", "title": "Counter mode", "updated": "2026-10-21", "topic_path": [ { "id": "technology", "label": "Technology and the built world", "api_url": "https://www.edgepedia.org/api/v1/topics/technology" }, { "id": "technology.computing", "label": "Computing and digital systems", "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing" }, { "id": "technology.computing.networks", "label": "Networks and security", "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.networks" }, { "id": "technology.computing.networks.alpha-2-to-ma", "label": "Titles 2 to Ma", "api_url": "https://www.edgepedia.org/api/v1/topics/technology.computing.networks.alpha-2-to-ma" } ], "geo": [ { "id": "geo.nongeo.t1946.technology.computing.networks.alpha-2-to-ma", "label": "Non-geographic · 1946 to 2000: Titles 2 to Ma", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing.networks.alpha-2-to-ma", "path": [ { "id": "geo.nongeo", "label": "Non-geographic", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo" }, { "id": "geo.nongeo.t1946", "label": "Non-geographic · 1946 to 2000", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946" }, { "id": "geo.nongeo.t1946.technology", "label": "Technology and the built world", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology" }, { "id": "geo.nongeo.t1946.technology.computing", "label": "Computing and digital systems", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing" }, { "id": "geo.nongeo.t1946.technology.computing.networks", "label": "Networks and security", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing.networks" }, { "id": "geo.nongeo.t1946.technology.computing.networks.alpha-2-to-ma", "label": "Titles 2 to Ma", "api_url": "https://www.edgepedia.org/api/v1/geo/geo.nongeo.t1946.technology.computing.networks.alpha-2-to-ma" } ] } ], "excerpt": "Counter mode (CTR) is a block cipher mode of operation that encrypts counter blocks to produce a keystream, XORed with plaintext, effectively turning a block cipher into a stream cipher.", "snippet": "Counter mode (CTR) is a block cipher mode of operation that encrypts counter blocks to produce a keystream, XORed with plaintext, effectively turning a block cipher into a stream cipher.", "node": "technology.computing.networks.alpha-2-to-ma", "markdown": "# Counter mode\n\nCounter mode (CTR) is a confidentiality mode of operation for block ciphers that encrypts a sequence of counter blocks to produce a keystream, which is exclusive-ORed (XORed) with the plaintext to produce the ciphertext. Because the ciphertext is the plaintext masked by a pseudorandom bitstream, CTR effectively turns a block cipher into a stream cipher, and it is widely regarded as the modern mode of choice for privacy-only encryption.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) • [2](https://eprint.iacr.org/2018/159.pdf) • [3](https://www.cs.ucdavis.edu/~rogaway/papers/modes-cryptrec.pdf) In Rogaway's evaluation of standardized modes, CTR is \"usually the best and most modern way to achieve privacy-only encryption,\" a judgment attributed to its parallelizability, speed, and simple design.[3](https://www.cs.ucdavis.edu/~rogaway/papers/modes-cryptrec.pdf) • [2](https://eprint.iacr.org/2018/159.pdf)\n\n| Key fact | Detail |\n|---|---|\n| What it produces | A keystream from encrypting counter blocks, XORed with plaintext; decryption reuses the same keystream.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) |\n| Core rule | All counter blocks must be distinct across all messages encrypted under a given key.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) |\n| Padding | None: for a final partial block of u bits, the most significant u bits of the last keystream block are used and the rest discarded.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) |\n| Parallelism | All forward-cipher calls are independent and can be precomputed before data is available; CBC encryption cannot be parallelized.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) |\n| Standardization | Specified in NIST SP 800-38A; absent from NIST's first series of standardized modes and added later.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) • [2](https://eprint.iacr.org/2018/159.pdf) |\n| Authenticated variants | GCM (CTR + GHASH, SP 800-38D) and CCM (CTR + CBC-MAC, SP 800-38C).[4](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8459.pdf) |\n| Main hazard | Reusing a counter block under the same key yields a two-time pad and complete failure of privacy.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) • [5](https://cr.yp.to/bib/2002/mcgrew.pdf) |\n\n## How it works\n\nCTR is a keystream mode. For each block j, the cipher's forward direction (encryption) is applied to a counter block \\( T_{j} \\), producing an output block \\( O_{j} \\) that serves as keystream; the plaintext is then XORed with this keystream. SP 800-38A gives the equations, writing \\( \\mathrm{CIPH}_{K} \\) for the forward cipher under key \\( K \\):[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf)\n\n\\[ O_{j} = \\mathrm{CIPH}_{K}(T_{j}), \\qquad C_{j} = P_{j} \\oplus O_{j} \\]\n\nDecryption is the same computation with the roles of plaintext and ciphertext swapped:[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf)\n\n\\[ P_{j} = C_{j} \\oplus O_{j} \\]\n\nBecause both directions XOR data with the same keystream, decryption needs only the forward cipher; the block cipher's decryption direction is never invoked. This is one practical reason implementations of CTR are simple: the same hardware or software primitive serves encryption and decryption.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf)\n\nNo padding is required. If the message ends with a partial block of u bits, the most significant u bits of the final keystream block are used in the XOR and the remaining \\( b - u \\) bits are discarded.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf)\n\n## How it is done\n\nA CTR implementation fixes three things: how counter blocks are formed, how they advance, and how data is processed.\n\n**Counter generation.** SP 800-38A allows several options. In the nonce-based construction, each message carries a unique nonce \\( N \\) of \\( b/2 \\) bits, and the counter blocks are formed from the nonce together with the block index encoded in the remaining bits.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf)\n\n**Per-standard counter block formats.** Different protocols partition the counter block differently. RFC 3686 for IPsec ESP defines a 128-bit counter block as a 32-bit nonce, a 64-bit per-packet IV, and a 32-bit block counter initially set to one and incremented per block.[6](https://www.rfc-editor.org/rfc/rfc3686.txt) AES-CTR was proposed for TLS/DTLS in an Internet-Draft, which specified the leftmost 48 bits from the client_write_IV, the next 64 bits as the record sequence number, and the remaining 16 bits as a block counter initialized to one; the draft expired in 2006 without becoming an RFC, so AES-CTR is not a standardized TLS cipher suite.[7](https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctr-01.txt)\n\n**Per-block processing and access.** Because each counter block is independent, the forward-cipher calls can run in parallel and can be precomputed before plaintext or ciphertext is available.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) The keystream also supports random access: any block's keystream can be computed from its counter alone, so DTLS records can be processed out of order without depending on packet arrival order.[7](https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctr-01.txt)\n\n## Origin\n\nCTR was not among the modes in NIST's first series of standardized modes; it was added later in SP 800-38A.[2](https://eprint.iacr.org/2018/159.pdf) • [1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf)\n\n## Variants\n\nCTR's structure, a pseudorandom keystream XORed with data, makes it the confidentiality core of the two dominant authenticated-encryption modes.\n\n**GCM.** [Galois/Counter Mode](https://www.edgepedia.org/galois-counter-mode), specified in NIST SP 800-38D, combines CTR-mode encryption with a polynomial hash function called GHASH under the Encrypt-then-MAC paradigm; the authentication is a Wegman-Carter polynomial hash operating in the field \\( \\mathrm{GF}(2^{128}) \\).[4](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8459.pdf) • [8](https://eprint.iacr.org/2024/1111.pdf) GCM was standardized by NIST in SP 800-38D.[8](https://eprint.iacr.org/2024/1111.pdf) Iwata and colleagues showed that the original GCM security proof was flawed and how to repair it, with better bounds for 96-bit nonces.[4](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8459.pdf) [TLS 1.3](https://www.edgepedia.org/tls-1-3), standardized in 2018, specifies 96-bit AEAD nonces in its record interface, independently of this later analysis. NIST is revising GCM in SP 800-38D Rev. 1 and proposes to specify a wider variant, wGCM, operating on an underlying block cipher with a larger block size.[9](https://csrc.nist.gov/pubs/sp/800/38/d/r1/2prd)\n\n**CCM.** Counter with CBC-MAC combines counter mode for confidentiality with the cipher block chaining technique (CBC-MAC) for authentication.[4](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8459.pdf) It is inherently serial, limiting speed in some contexts.[3](https://www.cs.ucdavis.edu/~rogaway/papers/modes-cryptrec.pdf)\n\n## Applications\n\nCTR and its authenticated derivatives carry much of today's encrypted traffic. AES-GCM, whose encryption core is CTR, is described as the most widely used AEAD algorithm in the world, deployed in TLS, QUIC, IPsec, MACsec, and WiFi WPA3.[8](https://eprint.iacr.org/2024/1111.pdf) AES-CTR itself is specified for IPsec ESP in RFC 3686 and was drafted for TLS 1.1 and DTLS.[6](https://www.rfc-editor.org/rfc/rfc3686.txt) • [7](https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctr-01.txt)\n\nThe performance case rests on parallelism and overhead. RFC 3686 notes that AES-CTR is easy to implement, can be pipelined and parallelized, and supports keystream precomputation.[6](https://www.rfc-editor.org/rfc/rfc3686.txt) Against CBC, CTR saves space as well as time: in TLS 1.1 and DTLS, AES-CTR saves 17 to 32 bytes per record, 16 bytes from not transmitting an explicit IV and 1 to 16 bytes from the absence of a padding block.[7](https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctr-01.txt)\n\n## Limitations and alternatives\n\n**Counter reuse.** The uniqueness requirement is not restricted to a single message: across all messages encrypted under a given key, all counter blocks must be distinct.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) The reason is mechanical. A key and counter block completely specify a portion of the cipher stream, so reusing the pair generates two identical keystream segments.[7](https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctr-01.txt) • [5](https://cr.yp.to/bib/2002/mcgrew.pdf) The result is a two-time pad: if any plaintext block encrypted under a given counter is known, the forward-cipher output can be computed from the associated ciphertext, and every other plaintext encrypted under that same counter can then be recovered.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) Rogaway's evaluation states the consequence bluntly: complete failure of privacy if a nonce is reused on encryption or decryption.[3](https://www.cs.ucdavis.edu/~rogaway/papers/modes-cryptrec.pdf) For the GCM variant the stakes extend to integrity: for AEAD_AES_128_GCM and AEAD_AES_256_GCM the limit on uses of a single key-nonce pair is 1, and reuse has serious consequences for both confidentiality and integrity.[10](https://cfrg.github.io/draft-irtf-cfrg-aead-limits/draft-irtf-cfrg-aead-limits.html) A conservative implementation generates counters within the core cryptographic module to ensure uniqueness.[5](https://cr.yp.to/bib/2002/mcgrew.pdf)\n\n**Malleability.** Unauthenticated CTR is malleable: to flip a bit of the decrypted plaintext, an attacker flips the corresponding bit of the ciphertext, so the ciphertext can be manipulated to decrypt to a message of the attacker's choosing whenever the attacker knows the plaintext.[5](https://cr.yp.to/bib/2002/mcgrew.pdf) The fix is authentication: CTR should be used with a message authentication code, and the AEAD variants GCM and CCM build exactly that in, GCM via GHASH and CCM via CBC-MAC.[5](https://cr.yp.to/bib/2002/mcgrew.pdf) • [4](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8459.pdf) Where an application cannot guarantee that nonces will not repeat, a nonce-misuse resistant AEAD such as AES-GCM-SIV, which can tolerate a limited amount of nonce reuse, is likely a better choice.[10](https://cfrg.github.io/draft-irtf-cfrg-aead-limits/draft-irtf-cfrg-aead-limits.html)\n\n**Comparison with other modes.** CBC encryption cannot be parallelized because each forward-cipher input (except the first) depends on the previous operation's result.[1](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf) CTR's parallelizability often makes it faster, in some settings much faster, than other confidentiality modes.[3](https://www.cs.ucdavis.edu/~rogaway/papers/modes-cryptrec.pdf) CTR as conventionally implemented also avoids a random per-packet initialization vector, unlike CBC, avoiding failures from pseudorandom IV generation.[5](https://cr.yp.to/bib/2002/mcgrew.pdf) No published head-to-head comparison of CTR with CFB or OFB is available. CTR does not appear in published accounts of disk encryption; the storage-device mode is XTS (SP 800-38E and IEEE 1619), a tweakable-block-cipher mode restricted to block-structured storage devices, whose narrow block width and poor treatment of fractional final blocks Rogaway lists as problems.[3](https://www.cs.ucdavis.edu/~rogaway/papers/modes-cryptrec.pdf)\n\n## References\n\n1. [NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf)\n2. [Missing Difference Attack on GCM / CTR context (Leurent & Sibleyras, IACR ePrint 2018/159)](https://eprint.iacr.org/2018/159.pdf)\n3. [Evaluation of Some Blockcipher Modes of Operation (Rogaway)](https://www.cs.ucdavis.edu/~rogaway/papers/modes-cryptrec.pdf)\n4. [NIST IR 8459: Report on the Block Cipher Modes of Operation in the NIST SP 800-38 Series (2024)](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8459.pdf)\n5. [Counter Mode Security: Analysis and Recommendations (McGrew, 2002)](https://cr.yp.to/bib/2002/mcgrew.pdf)\n6. [RFC 3686: Using Advanced Encryption Standard (AES) Counter Mode With IPsec ESP](https://www.rfc-editor.org/rfc/rfc3686.txt)\n7. [draft-ietf-tls-ctr-01: AES-CTR for TLS/DTLS (Modadugu & Rescorla)](https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctr-01.txt)\n8. [Making GCM Great Again: Toward Full Security and Longer Nonces (2024)](https://eprint.iacr.org/2024/1111.pdf)\n9. [SP 800-38D Rev. 1, Second Pre-Draft Call for Comments: GCM and GMAC Block Cipher Modes of Operation](https://csrc.nist.gov/pubs/sp/800/38/d/r1/2prd)\n10. [Usage Limits on AEAD Algorithms (CFRG draft)](https://cfrg.github.io/draft-irtf-cfrg-aead-limits/draft-irtf-cfrg-aead-limits.html)\n\n---\n*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Networks and security › Titles 2 to Ma*\n\n*Initially written Sep 29, 2026 · Reviewed: Sep 30, 2026 · Edited: Oct 15, 2026; Oct 21, 2026 · Last review: Sep 30, 2026*\n\n*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*\n\nLicense: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license\n", "same_as": [ "https://www.cs.ucdavis.edu/~rogaway/papers/modes-cryptrec.pdf" ], "url": "https://www.edgepedia.org/counter-mode", "markdown_url": "https://www.edgepedia.org/counter-mode.md", "license": { "name": "Edgepedia Community License 1.0", "url": "https://www.edgepedia.org/edgepedia/license", "summary": "Free with credit, commercial use included. AI training is open to everyone. For other uses, organizations over USD 100M in revenue or 100M monthly users license separately.", "spdx": "LicenseRef-Edgepedia-Community-1.0" }, "credit": "\"Counter mode\", Edgepedia (EdgeChat), https://www.edgepedia.org/counter-mode. Edgepedia Community License 1.0.", "credit_md": "\"[Counter mode](https://www.edgepedia.org/counter-mode)\", Edgepedia (EdgeChat), [https://www.edgepedia.org/counter-mode](https://www.edgepedia.org/counter-mode). [Edgepedia Community License 1.0](https://www.edgepedia.org/edgepedia/license).", "credit_html": "\"Counter mode\", Edgepedia (EdgeChat), https://www.edgepedia.org/counter-mode. Edgepedia Community License 1.0.", "speakable": "Counter mode is a block cipher mode of operation that encrypts counter blocks to produce a keystream, XORed with plaintext, effectively turning a block cipher into a stream cipher." }