View source for Block cipher mode of operation

{{short description|Cryptography algorithm}}
{{Redirect|Mode of operation|"method of operation"|Modus operandi}}
[[File:BlockCipherModesofOperation.svg|400px|thumb|right|Six common block cipher modes of operation for encrypting]]
In cryptography, a '''block cipher mode of operation''' is an algorithm that uses a [[block cipher]] to provide [[information security]] such as [[confidentiality]] or [[authentication|authenticity]].<ref name="NIST-BLOCK-CIPHER-MODES">
{{cite web
 |author      = NIST Computer Security Division's (CSD) Security Technology Group (STG)
 |title       = Block cipher modes
 |year        = 2013
 |work        = Cryptographic Toolkit
 |publisher   = NIST
 |url         = http://csrc.nist.gov/groups/ST/toolkit/BCM/index.html
 |access-date  = April 12, 2013
 |url-status  = live
 |archive-url  = https://web.archive.org/web/20121106212417/http://csrc.nist.gov/groups/ST/toolkit/BCM/index.html
 |archive-date = November 6, 2012
}}</ref> A block cipher by itself is only suitable for the secure cryptographic transformation (encryption or decryption) of one fixed-length group of [[bit]]s called a [[Block (data storage)|block]].<ref name="FERGUSON">
{{Cite book
| author1 = Ferguson, N. 
| author2 = Schneier, B. 
| author3 = Kohno, T.
| year = 2010
| title = Cryptography Engineering: Design Principles and Practical Applications
| publisher = Wiley Publishing, Inc.
| location = Indianapolis
| isbn = 978-0-470-47424-2
| pages = 63, 64
}}</ref> A mode of operation describes how to repeatedly apply a cipher's single-block operation to securely transform amounts of data larger than a block.<ref name="NIST-PROPOSED-MODES">
{{cite web
 |author      = NIST Computer Security Division's (CSD) Security Technology Group (STG)
 |title       = Proposed modes
 |year        = 2013
 |work        = Cryptographic Toolkit
 |publisher   = NIST
 |url         = http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html
 |access-date  = April 14, 2013
 |url-status  = live
 |archive-url  = https://web.archive.org/web/20130402203904/http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html
 |archive-date = April 2, 2013
}}</ref><ref name="HAC">
{{cite book
 |author1    = Alfred J. Menezes 
 |author2    = Paul C. van Oorschot 
 |author3    = Scott A. Vanstone
 |title      = Handbook of Applied Cryptography
 |publisher  = CRC Press
 |year       = 1996
 |isbn       = 0-8493-8523-7
 |pages      = [https://archive.org/details/handbookofapplie0000mene/page/228 228–233]
 |url        = https://archive.org/details/handbookofapplie0000mene/page/228
 |url-access = registration
}}</ref><ref name="ISO-10116">
{{Cite journal
 |title       = ISO/IEC 10116:2006 – Information technology – Security techniques – Modes of operation for an ''n''-bit block cipher
 |journal     = ISO Standards Catalogue
 |url         = http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38761
 |year        = 2006
 |url-status  = live
 |archive-url  = https://web.archive.org/web/20120317153312/http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38761
 |archive-date = 2012-03-17
}}</ref>

Most modes require a unique binary sequence, often called an [[initialization vector]] (IV), for each encryption operation. The IV must be non-repeating, and for some modes must also be random. The initialization vector is used to ensure that distinct [[ciphertext]]s are produced even when the same [[plaintext]] is encrypted multiple times independently with the same [[Key (cryptography)|key]].<ref>{{Citation|last1=Conrad|first1=Eric|title=Chapter 3 - Domain 3: Security engineering|date=2017-01-01|url=http://www.sciencedirect.com/science/article/pii/B9780128112489000036|work=Eleventh Hour CISSP® (Third Edition)|pages=47–93|editor-last=Conrad|editor-first=Eric|publisher=Syngress|language=en|doi=10.1016/b978-0-12-811248-9.00003-6|isbn=978-0-12-811248-9|access-date=2020-11-01|last2=Misenar|first2=Seth|last3=Feldman|first3=Joshua|editor2-last=Misenar|editor2-first=Seth|editor3-last=Feldman|editor3-first=Joshua|url-access=subscription}}</ref> Block ciphers may be capable of operating on more than one [[Block size (cryptography)|block size]], but during transformation the block size is always fixed. Block cipher modes operate on whole blocks and require that the final data fragment be [[Padding (cryptography)|padded]] to a full block if it is smaller than the current block size.<ref name="FERGUSON"/> There are, however, modes that do not require padding because they effectively use a block cipher as a [[stream cipher]].

Historically, encryption modes have been studied extensively in regard to their error propagation properties under various scenarios of data modification. Later development regarded [[integrity protection]] as an entirely separate cryptographic goal. Some modern modes of operation combine [[confidentiality]] and [[authentication|authenticity]] in an efficient way, and are known as [[authenticated encryption]] modes.<ref name="NIST-CURRENT-MODES">
{{cite web
 |author      = NIST Computer Security Division's (CSD) Security Technology Group (STG)
 |title       = Current modes
 |year        = 2013
 |work        = Cryptographic Toolkit
 |publisher   = NIST
 |url         = http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html
 |access-date  = April 12, 2013
 |url-status  = live
 |archive-url  = https://web.archive.org/web/20130402203842/http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html
 |archive-date = April 2, 2013
}}</ref>

==History and standardization==
The earliest modes of operation, ECB, CBC, OFB, and CFB (see below for all), date back to 1981 and were specified in [http://csrc.nist.gov/publications/fips/fips81/fips81.htm FIPS 81], ''DES Modes of Operation''. In 2001, the US [[National Institute of Standards and Technology]] (NIST) revised its list of approved modes of operation by including [[Advanced Encryption Standard|AES]] as a block cipher and adding CTR mode in [http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf SP800-38A], ''Recommendation for Block Cipher Modes of Operation''. Finally, in January, 2010, NIST added [[Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS-AES]] in [http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38e.pdf SP800-38E], ''Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices''. Other confidentiality modes exist which have not been approved by NIST. For example, CTS is [[ciphertext stealing]] mode and available in many popular cryptographic libraries.

The block cipher modes ECB, CBC, OFB, CFB, CTR, and [[XTS mode|XTS]] provide confidentiality, but they do not protect against accidental modification or malicious tampering. Modification or tampering can be detected with a separate [[message authentication code]] such as [[CBC-MAC]], or a [[digital signature]]. The cryptographic community recognized the need for dedicated integrity assurances and NIST responded with HMAC, CMAC, and GMAC. [[HMAC]] was approved in 2002 as [http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf FIPS 198], ''The Keyed-Hash Message Authentication Code (HMAC)'', [[CMAC]] was released in 2005 under [http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38b.pdf SP800-38B], ''Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication'', and [[Galois/Counter Mode|GMAC]] was formalized in 2007 under [http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf SP800-38D], ''Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC''.

The cryptographic community observed that compositing (combining)  a confidentiality mode with an authenticity mode could be difficult and error prone.  They therefore began to supply modes which combined confidentiality and data integrity into a single cryptographic primitive (an encryption algorithm). These combined modes are referred to as [[authenticated encryption]], AE or "authenc". Examples of AE modes are [[CCM mode|CCM]] ([http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf SP800-38C]), [[Galois/Counter Mode|GCM]] ([http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf SP800-38D]), [[CWC mode|CWC]], [[EAX mode|EAX]], [[IAPM (mode)|IAPM]], and [[OCB mode|OCB]].

Modes of operation are defined by a number of national and internationally recognized standards bodies. Notable standards organizations include [[National Institute of Standards and Technology|NIST]], [[International Organization for Standardization|ISO]] (with ISO/IEC 10116<ref name="ISO-10116"/>), the [[International Electrotechnical Commission|IEC]], the [[Institute of Electrical and Electronics Engineers|IEEE]], [[American National Standards Institute|ANSI]], and the [[Internet Engineering Task Force|IETF]].

=={{anchor|IV}}Initialization vector (IV)==
{{Main|Initialization vector}}

An initialization vector (IV) or starting variable (SV)<ref name="ISO-10116"/> is a block of bits that is used by several modes to randomize the encryption and hence to produce distinct ciphertexts even if the same plaintext is encrypted multiple times, without the need for a slower re-keying process.{{Citation needed|date=November 2019}}

An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. For most block cipher modes it is important that an initialization vector is never reused under the same key, i.e. it must be a [[cryptographic nonce]]. Many block cipher modes have stronger requirements, such as the IV must be [[random]] or [[pseudorandom]]. Some block ciphers have particular problems with certain initialization vectors, such as all zero IV generating no encryption (for some keys).

It is recommended to review relevant IV requirements for the particular block cipher mode in relevant specification, for example [http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf SP800-38A].

For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages.

For OFB and CTR, reusing an IV causes key bitstream re-use, which breaks security.<ref>{{cite web |title=Stream Cipher Reuse: A Graphic Example |date=31 May 2008 |url=http://cryptosmith.com/2008/05/31/stream-reuse/ |publisher=Cryptosmith LLC |access-date=7 January 2015 |url-status=live |archive-url=https://web.archive.org/web/20150125035328/http://cryptosmith.com/2008/05/31/stream-reuse/ |archive-date=25 January 2015}}</ref> This can be seen because both modes effectively create a bitstream that is XORed with the plaintext, and this bitstream is dependent on the key and IV only.

In CBC mode, the IV must be unpredictable (random or pseudorandom) at encryption time; in particular, the (previously) common practice of re-using the last ciphertext block of a message as the IV for the next message is insecure (for example, this method was used by SSL 2.0). If an attacker knows the IV (or the previous block of ciphertext) before the next plaintext is specified, they can check their guess about plaintext of some block that was encrypted with the same key before (this is known as the TLS CBC IV attack).<ref>{{citation |author=B. Moeller |title=Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures |date=May 20, 2004 |url=http://www.openssl.org/~bodo/tls-cbc.txt |url-status=live |archive-url=https://web.archive.org/web/20120630143111/http://www.openssl.org/~bodo/tls-cbc.txt |archive-date=June 30, 2012}}</ref>

For some keys, an all-zero initialization vector may generate some block cipher modes (CFB-8, OFB-8) to get the internal state stuck at all-zero. For CFB-8, an all-zero IV and an all-zero plaintext, causes 1/256 of keys to generate no encryption, plaintext is returned as ciphertext.<ref>{{cite web |last1=Tervoort |first1=Tom |title=Zerologon: Unauthenticated domain controller compromise by subverting Netlogon cryptography (CVE-2020-1472) |url=https://www.secura.com/pathtoimg.php?id=2055 |website=Secura |access-date=14 October 2020}}</ref> For OFB-8, using all zero initialization vector will generate no encryption for 1/256 of keys.<ref>{{cite web |last1=Blaufish |title=Netlogon CFB8 considered harmful. OFB8 also. |website=[[GitHub]] |date=14 October 2020 |url=https://github.com/blaufish/cfb8-vulnerable |access-date=14 October 2020}}</ref> OFB-8 encryption returns the plaintext unencrypted for affected keys.

Some modes (such as AES-SIV and AES-GCM-SIV) are built to be more nonce-misuse resistant, i.e. resilient to scenarios in which the randomness generation is faulty or under the control of the attacker.  
* Synthetic initialization vectors (SIV) synthesize an internal IV by running a [[pseudo-random function]] (PRF) construction called S2V on the input (additional data and plaintext), preventing any external data from directly controlling the IV. External nonces / IV may be fed into S2V as an additional data field.
* AES-GCM-SIVs synthesize an internal IV by running POLYVAL Galois mode of authentication on input (additional data and plaintext), followed by an AES operation.

==Padding==
{{Main|Padding (cryptography)}}
A [[block cipher]] works on units of a fixed [[block size (cryptography)|size]] (known as a ''block size''), but messages come in a variety of lengths. So some modes (namely [[Block cipher modes of operation#ECB|ECB]] and [[Block cipher modes of operation#CBC|CBC]]) require that the final block be padded before encryption. Several [[padding (cryptography)|padding]] schemes exist.  The simplest is to add [[Null character|null bytes]] to the [[plaintext]] to bring its length up to a multiple of the block size, but care must be taken that the original length of the plaintext can be recovered; this is trivial, for example, if the plaintext is a [[C (programming language)|C]] style [[Literal string|string]] which contains no null bytes except at the end. Slightly more complex is the original [[Data Encryption Standard|DES]] method, which is to add a single one [[bit]], followed by enough zero [[bit]]s to fill out the block; if the message ends on a block boundary, a whole padding block will be added.  Most sophisticated are CBC-specific schemes such as [[ciphertext stealing]] or [[residual block termination]], which do not cause any extra ciphertext, at the expense of some additional complexity. [[Bruce Schneier|Schneier]] and [[Niels Ferguson|Ferguson]] suggest two possibilities<!-- Practical Crypto, sect 5.1 -->, both simple: append a byte with value 128 (hex 80), followed by as many zero bytes as needed to fill the last block, or pad the last block with ''n'' bytes all with value ''n''.

CFB, OFB and CTR modes do not require any special measures to handle messages whose lengths are not multiples of the block size, since the modes work by [[Exclusive or|XORing]] the plaintext with the output of the block cipher.  The last partial block of plaintext is XORed with the first few bytes of the last [[keystream]] block, producing a final ciphertext block that is the same size as the final partial plaintext block.  This characteristic of stream ciphers makes them suitable for applications that require the encrypted ciphertext data to be the same size as the original plaintext data, and for applications that transmit data in streaming form where it is inconvenient to add padding bytes.

==Common modes==

=== Authenticated encryption with additional data (AEAD) modes ===
{{Main|Authenticated encryption}}
A number of modes of operation have been designed to combine secrecy and authentication in a single cryptographic primitive. Examples of such modes are ,<ref>{{cite conference |author-link1=Virgil D. Gligor |first1=Virgil D. |last1=Gligor |first2=Pompiliu |last2=Donescu |title=Fast Encryption and Authentication: XCBC Encryption and XECB Authentication Modes |conference=Fast Software Encryption 2001 |date=2002 |pages=92–108 |series=Lecture Notes in Computer Science |volume=2355 |url=https://link.springer.com/content/pdf/10.1007%2F3-540-45473-X_8.pdf |doi=10.1007/3-540-45473-X_8 |isbn=978-3-540-43869-4 |publisher=Springer |location=Berlin |editor-last=Matsui |editor-first=M.|doi-access=free }}</ref> {{clarify|text=integrity-aware cipher block chaining (IACBC)|date=August 2020}}, integrity-aware parallelizable mode (IAPM),<ref>{{cite conference |first=Charanjit S. |last=Jutla |title=Encryption Modes with Almost Free Message Integrity |conference=Eurocrypt 2001 |series=Lecture Notes in Computer Science |volume=2045 |date=May 2001 |doi= 10.1007/3-540-44987-6_32 |url=https://iacr.org/archive/eurocrypt2001/20450525.pdf |publisher=Springer|doi-access=free }}</ref> [[OCB mode|OCB]], [[EAX mode|EAX]], [[CWC mode|CWC]], [[CCM mode|CCM]], and [[Galois/counter mode|GCM]]. [[Authenticated encryption]] modes are classified as single-pass modes or double-pass modes.

In addition, some modes also allow for the authentication of unencrypted associated data, and these are called [[AEAD block cipher modes of operation|AEAD]] (authenticated encryption with associated data) schemes. For example, EAX mode is a double-pass AEAD scheme while OCB mode is single-pass.

===={{Anchor|GCM}}Galois/counter (GCM)====
{{Main article|Galois/Counter Mode}}
{{Infobox
|name         = 
|bodystyle    = 
|title        = 
|titlestyle   = 
|image        = 
|imagestyle   = 
|caption      = 
|captionstyle = 
|headerstyle  = background:#ccf;
|labelstyle   = background:#ddf;
|datastyle    =
|header1 = GCM
|label1  = 
|data1   = 
|header2 = 
|label2  = 
|data2   = Galois/counter
|header3 = 
|label3  = Encryption parallelizable
|data3   = Yes
|header4 = 
|label4  = Decryption parallelizable
|data4   = Yes
|header5 = 
|label5  = Random read access
|data5   = Yes
|belowstyle = background:#ddf;
|below = 
}}

Galois/counter mode (GCM) combines the well-known counter mode of encryption with the new Galois mode of authentication. The key feature is the ease of parallel computation of the Galois field multiplication used for authentication. This feature permits higher throughput than encryption algorithms.

GCM is defined for block ciphers with a block size of 128 bits. Galois message authentication code (GMAC) is an authentication-only variant of the GCM which can form an incremental message authentication code. Both GCM and GMAC can accept initialization vectors of arbitrary length. GCM can take full advantage of parallel processing and implementing GCM can make efficient use of an [[instruction pipeline]] or a hardware pipeline. The CBC mode of operation incurs [[pipeline stall]]s that hamper its efficiency and performance.

Like in CTR, blocks are numbered sequentially, and then this block number is combined with an IV and encrypted with a block cipher {{math|E}}, usually AES. The result of this encryption is then XORed with the plaintext to produce the ciphertext. Like all counter modes, this is essentially a stream cipher, and so it is essential that a different IV is used for each stream that is encrypted.



{{multiple image
| header = Galois/Counter (GCM)
| width=512
| align = center
| direction = vertical
| image1 = GCM-Galois Counter Mode with IV.svg
| caption1 = GCM mode encryption
}}

The ciphertext blocks are considered coefficients of a [[polynomial]] which is then evaluated at a key-dependent point {{math|H}}, using [[finite field arithmetic]]. The result is then encrypted, producing an [[authentication tag]] that can be used to verify the integrity of the data. The encrypted text then contains the IV, ciphertext, and authentication tag.

==== Counter with cipher block chaining message authentication code (CCM) ====
{{main|CCM mode}}
''Counter with cipher block chaining message authentication code'' (counter with CBC-MAC; CCM) is an [[authenticated encryption]] algorithm designed to provide both authentication and confidentiality.  CCM mode is only defined for block ciphers with a block length of 128 bits.<ref name="NIST SP800-38C">{{cite tech report
| first = Morris | last = Dworkin
| title = Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality
| institution = [[National Institute of Standards and Technology|NIST]]
| series = NIST Special Publications
| number = 800-38C
| date = May 2004
| doi = 10.6028/NIST.SP.800-38C
| url = http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf
| doi-access = free
}}</ref><ref name="RFC3610">{{cite IETF
| title = Counter with CBC-MAC (CCM)
| rfc = 3610
| first1 = D. | last1 = Whiting
| first2 = R. | last2 = Housley
| first3 = N. | last3 = Ferguson
| publisher = [[Internet Engineering Task Force|IETF]]
| date=September 2003
}}</ref>

==== Synthetic initialization vector (SIV) ====

Synthetic initialization vector (SIV) is a nonce-misuse resistant block cipher mode.

SIV synthesizes an internal IV using the pseudorandom function S2V. S2V is a keyed hash based on CMAC, and the input to the function is:
* Additional authenticated data (zero, one or many AAD fields are supported)
* Plaintext
* Authentication key (K{{sub|1}}).

SIV encrypts the S2V output and the plaintext using AES-CTR, keyed with the encryption key (K{{sub|2}}).

SIV can support external nonce-based authenticated encryption, in which case one of the authenticated data fields is utilized for this purpose. RFC5297<ref>{{cite web |last1=Harkins |first1=Dan |title=Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) |date=October 2008 |url=https://tools.ietf.org/html/rfc5297 |access-date=21 October 2020}}</ref> specifies that for interoperability purposes the last authenticated data field should be used external nonce.

Owing to the use of two keys, the authentication key K{{sub|1}} and encryption key K{{sub|2}}, naming schemes for SIV AEAD-variants may lead to some confusion; for example AEAD_AES_SIV_CMAC_256 refers to AES-SIV with two AES-128 keys and '''not''' AES-256.

==== AES-GCM-SIV ====

[[AES-GCM-SIV]] is a mode of operation for the Advanced Encryption Standard which provides similar performance to Galois/counter mode as well as misuse resistance in the event of the reuse of a cryptographic nonce. The construction is defined in RFC 8452.<ref>{{cite IETF |title=AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption |rfc=8452 |last1=Gueron |first1=S. |date=April 2019 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=August 14, 2019 |doi=10.17487/RFC8452}}</ref>

AES-GCM-SIV synthesizes the internal IV. It derives a hash of the additional authenticated data and plaintext using the POLYVAL Galois hash function. The hash is then encrypted an AES-key, and used as authentication tag and AES-CTR initialization vector.

'''AES-GCM-SIV''' is an improvement over the very similarly named algorithm '''GCM-SIV''', with a few very small changes (e.g. how AES-CTR is initialized), but which yields practical benefits to its security "This addition allows for encrypting up to 2<sup>50</sup> messages with the same key, compared to the significant limitation of only 2<sup>32</sup> messages that were allowed with GCM-SIV."<ref>{{cite journal |last1=Gueron |first1=Shay |last2=Langley |first2=Adam |last3=Lindell |first3=Yehuda |title=AES-GCM-SIV: Specification and Analysis |journal=Cryptology ePrint Archive |date=14 Dec 2018 |volume=Report |issue=2017/168 |url=https://eprint.iacr.org/2017/168 |access-date=19 October 2020}}</ref>

===Confidentiality only modes===

Many modes of operation have been defined. Some of these are described below.  The purpose of cipher modes is to mask patterns which exist in encrypted data, as illustrated in the description of the [[#ECB-weakness|weakness of ECB]].

Different cipher modes mask patterns by cascading outputs from the cipher block or other globally deterministic variables into the subsequent cipher block.  The inputs of the listed modes are summarized in the following table:

<!-- Todo this table could probably be cleaner,maybe make a column for intermediates, ciphertext and cipher block function, key is always an input.  Maybe use math markup-->
{| class="wikitable"
|+ Summary of modes
! colspan="2" | Mode !! Formulas !! Ciphertext
|-
| Electronic codebook || (ECB) || Y<sub>''i''</sub> = F(PlainText<sub>''i''</sub>, Key) || Y<sub>i</sub>
|-
| Cipher block chaining || (CBC) || Y<sub>''i''</sub> = PlainText<sub>''i''</sub> XOR Ciphertext<sub>''i''−1</sub> || F(Y, Key); Ciphertext<sub>0</sub> = IV
|-
| Propagating CBC || (PCBC) || Y<sub>''i''</sub> = PlainText<sub>''i''</sub> XOR (Ciphertext<sub>''i''−1</sub> XOR PlainText<sub>''i''−1</sub>) || F(Y, Key); Ciphertext<sub>0</sub> = IV
|-
| Cipher feedback || (CFB) || Y<sub>''i''</sub> = Ciphertext<sub>''i''−1</sub> || Plaintext XOR F(Y, Key); Ciphertext<sub>0</sub> = IV
|-
| Output feedback || (OFB) || Y<sub>''i''</sub> = F(Y<sub>''i''−1</sub>, Key); Y<sub>0</sub> = F(IV, Key) || Plaintext XOR Y<sub>''i''</sub>
|-
| Counter || (CTR) || Y<sub>''i''</sub> = F(IV + ''g''(''i''), Key); IV = token() || Plaintext XOR Y<sub>''i''</sub>
|}

Note: ''g''(''i'') is any deterministic function, often the [[identity function]].

===={{Anchor|ECB}}Electronic codebook (ECB)====
{{Infobox
|headerstyle  = background:#ccf;
|labelstyle   = background:#ddf;
|header1 = ECB
|data2   = Electronic codebook
|label3  = Encryption parallelizable
|data3   = Yes
|label4  = Decryption parallelizable
|data4   = Yes
|label5  = Random read access
|data5   = Yes
|belowstyle = background:#ddf;
}}
The simplest of the encryption modes is the '''electronic codebook''' (ECB) mode (named after conventional physical [[codebook]]s<ref>{{cite web |title=Recommendation for Block Cipher Modes of Operation |url=http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf |website=NIST.gov |publisher=NIST |access-date=1 April 2017 |page=9 |url-status=live |archive-url=https://web.archive.org/web/20170329041940/http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf |archive-date=29 March 2017}}</ref>). The message is divided into blocks, and each block is encrypted separately. ECB is not recommended for use in cryptographic protocols: the disadvantage of this method is a lack of [[confusion and diffusion|diffusion]], wherein it fails to hide data patterns when it encrypts identical [[plaintext]] blocks into identical [[ciphertext]] blocks.<ref>{{cite book |last1=Menezes |first1=Alfred J. |url=https://books.google.com/books?id=YyCyDwAAQBAJ |title=Handbook of Applied Cryptography |last2=van Oorschot |first2=Paul C. |last3=Vanstone |first3=Scott A. |date=2018 |publisher=CRC Press |isbn=9780429881329 |page=228}}</ref><ref>{{cite book |last1=Dam |first1=Kenneth W. |url=https://books.google.com/books?id=H8OaAgAAQBAJ |title=Cryptography's Role in Securing the Information Society |last2=Lin |first2=Herbert S. |date=1996 |publisher=National Academies Press |isbn=9780309054751 |page=132}}</ref><ref>{{cite book |last=Schneier |first=Bruce |url=https://books.google.com/books?id=VjC9BgAAQBAJ |title=Applied Cryptography: Protocols, Algorithms and Source Code in C |date=2015 |publisher=John Wiley & Sons |isbn=9781119096726 |page=208}}</ref>



{{multiple image
| header = Electronic Codebook (ECB)
| align = center
| direction = vertical
| image1 = ECB encryption.svg
| caption1 = ECB mode encryption
| image2 = ECB decryption.svg
| caption2 = ECB mode decryption
| width = 512
}}






{{Anchor|ECB-weakness}}
A striking example of the degree to which ECB can leave plaintext data patterns in the ciphertext can be seen when ECB mode is used to encrypt a [[bitmap image]] which contains large areas of uniform color. While the color of each individual [[pixel]] has supposedly been encrypted, the overall image may still be discerned, as the pattern of identically colored pixels in the original remains visible in the encrypted version.

{{multiple image
| align             = center
| image1            = Tux.svg
| caption1          = Original image
| image2            = Tux encrypted ecb.png
| caption2          = Using ECB allows patterns to be easily discerned
| image3            = Tux encrypted ctr.png
| caption3          = Modes other than ECB result in pseudo-randomness
| width             = 196
}}

ECB mode can also make protocols without integrity protection even more susceptible to [[replay attack]]s, since each block gets decrypted in exactly the same way.{{Citation needed|date=April 2020}}
===={{Anchor|CBC}}Cipher block chaining (CBC)====
{{Infobox
|headerstyle  = background:#ccf;
|labelstyle   = background:#ddf;
|header1 = CBC
|data2   = Cipher block chaining
|label3  = Encryption parallelizable
|data3   = No
|label4  = Decryption parallelizable
|data4   = Yes
|label5  = Random read access
|data5   = Yes
|belowstyle = background:#ddf;
}}
Ehrsam, Meyer, Smith and Tuchman invented the cipher block chaining (CBC) mode of operation in 1976. In CBC mode, each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block depends on all plaintext blocks processed up to that point. To make each message unique, an initialization vector must be used in the first block.

{{multiple image
| header            = Cipher block chaining (CBC)
| align             = center
| direction         = vertical
| image1            = CBC encryption.svg
| caption1          = CBC mode encryption
| image2            = CBC decryption.svg
| caption2          = CBC mode decryption
| width             = 512
}}

If the first block has index 1, the mathematical formula for CBC encryption is
: <math>C_i = E_K(P_i \oplus C_{i-1}),</math>
: <math>C_0 = IV,</math>

while the mathematical formula for CBC decryption is
: <math>P_i = D_K(C_i) \oplus C_{i-1},</math>
: <math>C_0 = IV.</math>

===== Example =====
{{multiple image
| header = Example
| align = center
| direction = vertical
| image1 = CBC example v3.svg
| caption1 = CBC encryption example with a toy 2-bit cipher
| image2 = Rev CBC example v3.svg
| caption2 = CBC decryption example with a toy 2-bit cipher
| width = 512
}}

CBC has been the most commonly used mode of operation. Its main drawbacks are that encryption is sequential (i.e., it cannot be parallelized), and that the message must be padded to a multiple of the cipher block size. One way to handle this last issue is through the method known as ciphertext stealing. Note that a one-bit change in a plaintext or initialization vector (IV) affects all following ciphertext blocks.

Decrypting with the incorrect IV causes the first block of plaintext to be corrupt but subsequent plaintext blocks will be correct. This is because each block is XORed with the ciphertext of the previous block, not the plaintext, so one does not need to decrypt the previous block before using it as the IV for the decryption of the current one. This means that a plaintext block can be recovered from two adjacent blocks of ciphertext. As a consequence, decryption ''can'' be parallelized. Note that a one-bit change to the ciphertext causes complete corruption of the corresponding block of plaintext, and inverts the corresponding bit in the following block of plaintext, but the rest of the blocks remain intact. This peculiarity is exploited in different padding oracle attacks, such as POODLE.

''Explicit initialization vectors'' take advantage of this property by prepending a single random block to the plaintext. Encryption is done as normal, except the IV does not need to be communicated to the decryption routine. Whatever IV decryption uses, only the random block is "corrupted". It can be safely discarded and the rest of the decryption is the original plaintext.

===={{Anchor|PCBC}}Propagating cipher block chaining (PCBC)====
{{Infobox
|headerstyle  = background:#ccf;
|labelstyle   = background:#ddf;
|header1 = PCBC
|data2   = Propagating cipher block chaining
|label3  = Encryption parallelizable
|data3   = No
|label4  = Decryption parallelizable
|data4   = No
|label5  = Random read access
|data5   = No
|belowstyle = background:#ddf;
}}
The ''propagating cipher block chaining''<ref>{{cite web |url=http://www.iks-jena.de/mitarb/lutz/security/cryptfaq/q84.html |title=Kryptographie FAQ: Frage 84: What are the Counter and PCBC Modes? |website=www.iks-jena.de |access-date=28 April 2018 |url-status=live |archive-url=https://web.archive.org/web/20120716222121/http://www.iks-jena.de/mitarb/lutz/security/cryptfaq/q84.html |archive-date=16 July 2012}}</ref> or ''plaintext cipher-block chaining''<ref>{{cite book |last1=Kaufman |first1=C. |last2=Perlman |first2=R. |last3=Speciner |first3=M. |year=2002 |title=Network Security |location=Upper Saddle River, NJ |publisher=Prentice Hall |page=319 |edition=2nd |isbn=0130460192 }}</ref> mode was designed to cause small changes in the ciphertext to propagate indefinitely when decrypting, as well as when encrypting. In PCBC mode, each block of plaintext is XORed with both the previous plaintext block and the previous ciphertext block before being encrypted. Like with CBC mode, an initialization vector is used in the first block.
Unlike CBC, decrypting PCBC with the incorrect IV (initialization vector) causes all blocks of plaintext to be corrupt.

{{multiple image
| header = Propagating cipher block chaining (PCBC)
| align = center
| direction = vertical
| image1 = PCBC encryption.svg
| caption1 = PCBC mode encryption
| image2 = PCBC decryption.svg
| caption2 = PCBC mode decryption
| width = 512
}}


Encryption and decryption algorithms are as follows:
: <math>C_i = E_K(P_i \oplus P_{i-1} \oplus C_{i-1}), P_0 \oplus C_0 = IV,</math>
: <math>P_i = D_K(C_i) \oplus P_{i-1} \oplus C_{i-1}, P_0 \oplus C_0 = IV.</math>

PCBC is used in [[Kerberos (protocol)|Kerberos v4]] and [[WASTE]], most notably, but otherwise is not common. 

On a message encrypted in PCBC mode, if two adjacent ciphertext blocks are exchanged, this does not affect the decryption of subsequent blocks.<ref>{{cite book |last=Kohl |first=J. |chapter=The Use of Encryption in Kerberos for Network Authentication |title=Proceedings, Crypto '89 |year=1990 |publisher=Springer |location=Berlin |isbn=0387973176 |chapter-url=http://dsns.csie.nctu.edu.tw/research/crypto/HTML/PDF/C89/35.PDF |url-status=dead |archive-url=https://web.archive.org/web/20090612060426/http://dsns.csie.nctu.edu.tw/research/crypto/HTML/PDF/C89/35.PDF |archive-date=2009-06-12 }}</ref> For this reason, PCBC is not used in Kerberos v5.

===={{Anchor|CFB}}Cipher feedback (CFB)====

=====Full-block CFB=====
{{Infobox
|name         = 
|bodystyle    = 
|title        = 
|titlestyle   = 
|image        = 
|imagestyle   = 
|caption      = 
|captionstyle = 
|headerstyle  = background:#ccf;
|labelstyle   = background:#ddf;
|datastyle    =

|header1 = CFB
|label1  = 
|data1   = 
|header2 = 
|label2  = 
|data2   = Cipher feedback
|header3 = 
|label3  = Encryption parallelizable
|data3   = No
|header4 = 
|label4  = Decryption parallelizable
|data4   = Yes
|header5 = 
|label5  = Random read access
|data5   = Yes

|belowstyle = background:#ddf;
|below = 
}}
The ''cipher feedback'' (CFB) mode, in its simplest form uses the entire output of the block cipher. In this variation, it is very similar to CBC, turning a block cipher into a self-synchronizing [[stream cipher]]. CFB decryption in this variation is almost identical to CBC encryption performed in reverse:
: <math>\begin{align}
  C_i &= \begin{cases}
    \text{IV},                & i = 0 \\
    E_K (C_{i-1}) \oplus P_i, & \text{otherwise}
  \end{cases} \\
  P_i &= E_K (C_{i-1}) \oplus C_i,
\end{align}</math>

{{multiple image
| header = Cipher feedback (CFB)
| align = center
| direction = vertical
| image1 = CFB encryption.svg
| caption1 = Cipher feedback (CFB) encryption
| image2 = CFB decryption.svg
| caption2 = Cipher feedback (CFB) decryption
| width = 512
}}


===== CFB-1, CFB-8, CFB-64, CFB-128, etc. =====
NIST SP800-38A defines CFB with a bit-width.<ref name="AESBlockDocumentation">{{cite journal |url=http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf |title=SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques |first=Author: Morris Dworkin |last=(NIST) |website=csrc.nist.gov |year=2001 |doi=10.6028/NIST.SP.800-38A |access-date=28 April 2018 |url-status=live |archive-url=https://web.archive.org/web/20170828210645/http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf |archive-date=28 August 2017|doi-access=free }}</ref> ''The CFB mode also requires an integer parameter, denoted s, such that 1 ≤ s ≤ b.  In the specification of the CFB mode below, each plaintext segment (Pj) and ciphertext segment (Cj) consists of s bits. The value of s is sometimes incorporated into the name of the mode, e.g., the 1-bit CFB mode, the 8-bit CFB mode, the 64-bit CFB mode, or the 128-bit CFB mode.''

These modes will truncate the output of the underlying block cipher.
: <math>I_0 = \text{IV}.</math>
: <math>I_i = \big((I_{i-1} \ll s) + C_i\big) \bmod 2^b,</math>
: <math>C_i = \operatorname{MSB}_s\big(E_K(I_{i-1})\big) \oplus P_i,</math>
: <math>P_i = \operatorname{MSB}_s\big(E_K(I_{i-1})\big) \oplus C_i,</math>

CFB-1 is considered self synchronizing and resilient to loss of ciphertext; "When the 1-bit CFB mode is used, then the synchronization is automatically restored b+1 positions after the inserted or deleted bit. For other values of s in the CFB mode, and for the other confidentiality modes in this recommendation, the synchronization must be restored externally." (NIST SP800-38A). I.e. 1-bit loss in a 128-bit-wide block cipher like AES will render 129 invalid bits before emitting valid bits.

CFB may also self synchronize in some special cases other than those specified. For example, a one bit change in CFB-128 with an underlying 128 bit block cipher, will re-synchronize after two blocks. (However, CFB-128 etc. will not handle bit loss gracefully; a one-bit loss will cause the decryptor to lose alignment with the encryptor)

=====CFB compared to other modes=====
Like CBC mode, changes in the plaintext propagate forever in the ciphertext, and encryption cannot be parallelized. Also like CBC, decryption can be parallelized.

CFB, OFB and CTR share two advantages over CBC mode: the block cipher is only ever used in the encrypting direction, and the message does not need to be padded to a multiple of the cipher block size (though [[ciphertext stealing]] can also be used for CBC mode to make padding unnecessary).

===={{Anchor|OFB}}Output feedback (OFB)====
{{Infobox
|name         = 
|bodystyle    = 
|title        = 
|titlestyle   = 
|image        = 
|imagestyle   = 
|caption      = 
|captionstyle = 
|headerstyle  = background:#ccf;
|labelstyle   = background:#ddf;
|datastyle    =

|header1 = OFB
|label1  = 
|data1   = 
|header2 = 
|label2  = 
|data2   = Output feedback
|header3 = 
|label3  = Encryption parallelizable
|data3   = No
|header4 = 
|label4  = Decryption parallelizable
|data4   = No
|header5 = 
|label5  = Random read access
|data5   = No

|belowstyle = background:#ddf;
|below = 
}}
The ''output feedback'' (OFB) mode makes a block cipher into a synchronous [[stream cipher]].  It generates [[keystream]] blocks, which are then [[XOR]]ed with the plaintext blocks to get the ciphertext.  Just as with other stream ciphers, flipping a bit in the ciphertext produces a flipped bit in the plaintext at the same location.  This property allows many [[error-correcting code]]s to function normally even when applied before encryption.

Because of the symmetry of the XOR operation, encryption and decryption are exactly the same:
: <math>C_j = P_j \oplus O_j,</math>
: <math>P_j = C_j \oplus O_j,</math>
: <math>O_j = E_K(I_j),</math>
: <math>I_j = O_{j-1},</math>
: <math>I_0 = \text{IV}.</math>


{{multiple image
| header = Output feedback (OFB)
| align = center
| direction = vertical
| image1 = OFB encryption.svg
| caption1 = OFB mode encryption
| image2 = OFB decryption.svg
| caption2 = OFB mode decryption
| width = 512
}}


Each output feedback block cipher operation depends on all previous ones, and so cannot be performed in parallel.  However, because the plaintext or ciphertext is only used for the final XOR, the block cipher operations may be performed in advance, allowing the final step to be performed in parallel once the plaintext or ciphertext is available.

It is possible to obtain an OFB mode keystream by using CBC mode with a constant string of zeroes as input. This can be useful, because it allows the usage of fast hardware implementations of CBC mode for OFB mode encryption.

Using OFB mode with a partial block as feedback like CFB mode reduces the average cycle length by a factor of 2<sup>32</sup> or more. A mathematical model proposed by Davies and Parkin and substantiated by experimental results showed that only with full feedback an average cycle length near to the obtainable maximum can be achieved. For this reason, support for truncated feedback was removed from the specification of OFB.<ref>{{cite book |first1=D. W. |last1=Davies |first2=G. I. P. |last2=Parkin |chapter=The average cycle size of the key stream in output feedback encipherment |title=Advances in Cryptology, Proceedings of CRYPTO 82 |pages=263–282 |year=1983 |location=New York |publisher=Plenum Press |isbn=0306413663 }}</ref>

===={{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&nbsp;bits and the counter in the lower 64&nbsp;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
}}


==Error propagation==
"Error propagation" properties describe how a decryption behaves during bit errors, i.e. how error in one bit cascades to different decrypted bits.

Bit errors may occur intentionally in attacks or randomly due to transmission errors.

* Random bit errors occur independently in any bit position with an expected probability of ½.
* Specific bit errors occur in the same bit position(s) as the original bit error(s).

* Specific bit errors in stream cipher modes (OFB, CTR, etc.) are trivial. They affect only the specific bit intended. 
* Specific bit errors in more complex modes such (e.g. CBC): [[adaptive chosen-ciphertext attack]] may intelligently combine many different specific bit errors to break the cipher mode. In [[Padding oracle attack]], CBC can be decrypted in the attack by guessing encryption secrets based on error responses. The Padding Oracle attack variant "CBC-R" (CBC Reverse) lets the attacker construct any valid message.

For modern [[authenticated encryption]] (AEAD) or protocols with [[message authentication codes]] chained in MAC-Then-Encrypt order, any bit error should completely abort decryption and must not generate any specific bit errors to decryptor. I.e. if decryption succeeded, there should not be any bit error. As such error propagation is less important subject in modern cipher modes than in traditional confidentiality-only modes.

{| class="wikitable"
! Mode !! Effect of bit errors in C<sub>i</sub> !! Effect of bit errors in the IV or nonce
|-
| ECB || Random bit errors in P<sub>i</sub> || {{n/a}}
|-
| CBC || Random bit errors in P<sub>i</sub><br>Specific bit errors in P<sub>i+1</sub> || Specific bit errors in P<sub>1</sub>
|-
| CFB || Specific bit errors in P<sub>i</sub><br> Random bit errors in P<sub>i+1</sub>, …, until synchronization is restored || Random bit errors in P<sub>1</sub>, …, until synchronization is restored
|-
| OFB || Specific bit errors in P<sub>i</sub> || Random bit errors in P<sub>1</sub>, P<sub>2</sub>, …, P<sub>n</sub> 
|-
| CTR || Specific bit errors in P<sub>i</sub> || Random bit errors in P<sub>i</sub> for bit error in counter block T<sub>i</sub>
|}
(Source: SP800-38A Table D.2: Summary of Effect of Bit Errors on Decryption)

It might be observed, for example, that a one-block error in the transmitted ciphertext would result in a one-block error in the reconstructed plaintext for ECB mode encryption, while in CBC mode such an error would affect two blocks. Some felt that such resilience was desirable in the face of random errors (e.g., line noise), while others argued that error correcting increased the scope for attackers to maliciously tamper with a message.

However, when proper integrity protection is used, such an error will result (with high probability) in the entire message being rejected. If resistance to random error is desirable, [[error-correcting code]]s should be applied to the ciphertext before transmission.

==Other modes and other cryptographic primitives==
Many more modes of operation for block ciphers have been suggested. Some have been accepted, fully described (even standardized), and are in use. Others have been found insecure, and should never be used. Still others don't categorize as confidentiality, authenticity, or authenticated encryption – for example key feedback mode and [[one-way compression function#Davies.E2.80.93Meyer|Davies–Meyer]] hashing.

[[NIST]] maintains a list of proposed modes for block ciphers at ''Modes Development''.<ref name="AESBlockDocumentation" /><ref>{{cite web |url=http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html |title=Modes Development – Block Cipher Techniques – CSRC |date=4 January 2017 |publisher=Computer Security Division, Information Technology Laboratory, National Institute of Standards and Technology, U.S. Department of Commerce |access-date=28 April 2018 |url-status=live |archive-url=https://web.archive.org/web/20170904011624/http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html |archive-date=4 September 2017}}</ref>

Disk encryption often uses special purpose modes specifically designed for the application. Tweakable narrow-block encryption modes ([[Disk encryption theory#Liskov.2C Rivest.2C and Wagner .28LRW.29|LRW]], [[Xor–encrypt–xor|XEX]], and [[XTS mode|XTS]]) and wide-block encryption modes ([[Disk_encryption_theory#CBC–mask–CBC_(CMC)_and_ECB–mask–ECB_(EME)|CMC]] and [[Disk_encryption_theory#CBC–mask–CBC_(CMC)_and_ECB–mask–ECB_(EME)|EME]]) are designed to securely encrypt sectors of a disk (see [[disk encryption theory]]).

Many modes use an initialization vector (IV) which, depending on the mode, may have requirements such as being only used once (a nonce) or being unpredictable ahead of its publication, etc.  Reusing an IV with the same key in CTR, GCM or OFB mode results in XORing the same keystream with two or more plaintexts, a clear misuse of a stream, with a catastrophic loss of security.  Deterministic authenticated encryption modes such as the NIST [[Key Wrap]] algorithm and the SIV (RFC 5297) AEAD mode do not require an IV as an input, and return the same ciphertext and authentication tag every time for a given plaintext and key.  Other IV misuse-resistant modes such as [[AES-GCM-SIV]] benefit from an IV input, for example in the maximum amount of data that can be safely encrypted with one key, while not failing catastrophically if the same IV is used multiple times.

Block ciphers can also be used in other [[cryptographic protocol]]s. They are generally used in modes of operation similar to the block modes described here. As with all protocols, to be cryptographically secure, care must be taken to design these modes of operation correctly.

There are several schemes which use a block cipher to build a [[cryptographic hash function]]. See [[one-way compression function]] for descriptions of several such methods.

[[Cryptographically secure pseudorandom number generator]]s (CSPRNGs) can also be built using block ciphers.

[[Message authentication code]]s (MACs) are often built from block ciphers. [[CBC-MAC]], [[One-key MAC|OMAC]] and [[PMAC (cryptography)|PMAC]] are examples.

==See also==

* [[Disk encryption]]
* [[Message authentication code]]
* [[Authenticated encryption]]
* [[One-way compression function]]

==References==
{{Reflist|30em}}

{{Cryptography navbox | block | stream | hash}}

{{DEFAULTSORT:Block Cipher Modes Of Operation}}
[[Category:Block cipher modes of operation| ]]
[[Category:Cryptographic algorithms]]