Editing Block cipher mode of operation (section)

=={{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.