Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Block cipher mode of operation
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===={{Anchor|CTR}}Counter (CTR)==== {{Infobox |name = |bodystyle = |title = |titlestyle = |image = |imagestyle = |caption = |captionstyle = |headerstyle = background:#ccf; |labelstyle = background:#ddf; |datastyle = |header1 = CTR |label1 = |data1 = |header2 = |label2 = |data2 = Counter |header3 = |label3 = Encryption parallelizable |data3 = Yes |header4 = |label4 = Decryption parallelizable |data4 = Yes |header5 = |label5 = Random read access |data5 = Yes |belowstyle = background:#ddf; |below = }} : Note: CTR mode (CM) is also known as ''integer counter mode'' (ICM) and ''segmented integer counter'' (SIC) mode. Like OFB, counter mode turns a [[block cipher]] into a [[stream cipher]]. It generates the next [[keystream]] block by encrypting successive values of a "counter". The counter can be any function which produces a sequence which is guaranteed not to repeat for a long time, although an actual increment-by-one counter is the simplest and most popular. The usage of a simple deterministic input function used to be controversial; critics argued that "deliberately exposing a cryptosystem to a known systematic input represents an unnecessary risk".<ref>{{cite book |first=Robert R. |last=Jueneman |chapter=Analysis of certain aspects of output feedback mode |title=Advances in Cryptology, Proceedings of CRYPTO 82 |pages=99–127 |year=1983 |location=New York |publisher=Plenum Press |isbn=0306413663 }}</ref> However, today CTR mode is widely accepted, and any problems are considered a weakness of the underlying block cipher, which is expected to be secure regardless of systemic bias in its input.<ref name=commentstonist/> Along with CBC, CTR mode is one of two block cipher modes recommended by Niels Ferguson and Bruce Schneier.<ref>{{cite book |first1=Niels |last1=Ferguson |first2=Bruce |last2=Schneier |first3=Tadayoshi |last3=Kohno |title=Cryptography Engineering |page=71 |date=2010}}</ref> CTR mode was introduced by [[Whitfield Diffie]] and [[Martin Hellman]] in 1979.<ref name=commentstonist>{{cite web |last1=Lipmaa |first1=Helger |last2=Wagner |first2=David |last3=Rogaway |first3=Phillip |title=Comments to NIST concerning AES Modes of Operations: CTR-Mode Encryption |url=http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ctr/ctr-spec.pdf |url-status=live |archive-url=https://web.archive.org/web/20150226072817/http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/ctr/ctr-spec.pdf |archive-date=2015-02-26 |date=2000}}</ref> CTR mode has similar characteristics to OFB, but also allows a random-access property during decryption. CTR mode is well suited to operate on a multi-processor machine, where blocks can be encrypted in parallel. Furthermore, it does not suffer from the short-cycle problem that can affect OFB.<ref>{{cite web |url=http://www.quadibloc.com/crypto/co040601.htm |title=Basic Block Cipher Modes |website=www.quadibloc.com |access-date=28 April 2018 |url-status=live |archive-url=https://web.archive.org/web/20171024164915/http://www.quadibloc.com/crypto/co040601.htm |archive-date=24 October 2017}}</ref> If the IV/nonce is random, then they can be combined with the counter using any invertible operation (concatenation, addition, or XOR) to produce the actual unique counter block for encryption. In case of a non-random nonce (such as a packet counter), the nonce and counter should be concatenated (e.g., storing the nonce in the upper 64 bits and the counter in the lower 64 bits of a 128-bit counter block). Simply adding or XORing the nonce and counter into a single value would break the security under a [[chosen-plaintext attack]] in many cases, since the attacker may be able to manipulate the entire IV–counter pair to cause a collision. Once an attacker controls the IV–counter pair and plaintext, XOR of the ciphertext with the known plaintext would yield a value that, when XORed with the ciphertext of the other block sharing the same IV–counter pair, would decrypt that block.<ref>{{cite web |url=https://www.coursera.org/learn/crypto |title=Cryptography I |website=Coursera |access-date=28 April 2018 |url-status=live |archive-url=https://web.archive.org/web/20180323220803/https://www.coursera.org/learn/crypto |archive-date=23 March 2018}}</ref> Note that the [[cryptographic nonce|nonce]] in this diagram is equivalent to the [[initialization vector]] (IV) in the other diagrams. However, if the offset/location information is corrupt, it will be impossible to partially recover such data due to the dependence on byte offset. {{multiple image | header = Counter (CTR) | align = center | direction = vertical | image1 = CTR encryption 2.svg | caption1 = CTR mode encryption | image2 = CTR decryption 2.svg | caption2 = CTR mode decryption | width = 512 }}
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)