Initialization vector: Difference between revisions

Content deleted Content added
file is superseded
No edit summary
Tags: Reverted Mobile edit Mobile web edit Disambiguation links added
Line 1:
{{Short description|Input to a cryptographic primitive}}
In [[cryptography]], an '''initialization vector''' ('''IV''') or '''starting variable'''<ref>ISO/IEC 10116:2006 ''Information technology — Security techniques — Modes of operation for an ''n''-bit block cipher''</ref> is an input to a [[cryptographic primitive]] being used to provide the initial state. The IV is typically required to be [[random]] or [[pseudorandom]], but sometimes an IV only needs to be unpredictable or unique. [[Randomization]] is crucial for some [[encryption]] schemes to achieve semantic security, a property whereby repeated usage of the scheme under the same [[cryptographic key|key]] does not allow an attacker to infer relationships between (potentially similar) segments of the encrypted message. For [[block cipher]]s, the use of an IV is described by the [[Block cipher mode of operation|modes of operation]].
 
Some cryptographic primitives require the IV only to be non-repeating, and the required randomness is derived internally. In this case, the IV is commonly called a [[cryptographic nonce|nonce]] (a number used only once), and the primitives (e.g. [[Block_cipher_mode_of_operation#CBC|CBC]]) are considered ''stateful'' rather than ''randomized''. This is because an IV need not be explicitly forwarded to a recipient but may be derived from a common state updated at both sender and receiver side. (In practice, a short nonce is still transmitted along with the message to consider message loss.) An example of stateful encryption schemes is the [[counter mode]] of operation, which has a [[sequence number]] for a nonce.
 
The IV size depends on the cryptographic primitive used; for block ciphers it is generally the cipher's block-size. In encryption schemes, the unpredictable part of the IV has at best the same size as the key to compensate for time/memory/data tradeoff attacks.<ref>{{cite journal |author = Alex Biryukov |title = Some Thoughts on Time-Memory-Data Tradeoffs |journal = IACR ePrint Archive |year = 2005 |url = http://eprint.iacr.org/2005/207 }}</ref><ref>{{cite journal |author1 = Jin Hong |author21 = Palash Sarkar |title = Rediscovery of Time Memory Tradeoffs |journal = IACR ePrint Archive |year = 2005 |url = http://eprint.iacr.org/2005/090 }}</ref><ref>{{cite conference
| last1 = Biryukov | first1 = Alex
| last2 = Mukhopadhyay | first2first1 = Sourav
| last3last = Sarkar | first3 = Palash
| editor1-last = Preneel | editor1-first = Bart
| editor2-last = Tavares | editor2-first = Stafford E.
| contribution = Improved Time-Memory Trade-Offs with Multiple Data
| doi = 10.1007/11693383_8
Line 17:
| title = Selected Areas in Cryptography, 12th International Workshop, SAC 2005, Kingston, ON, Canada, August 11-12, 2005, Revised Selected Papers
| volume = 3897
| year = 2005| doi-access = free
}}</ref><ref name="ECRYPT">{{cite tech report |author1 = Christophe De Cannière |author2author = Joseph Lano |author3 = Bart Preneel |title = Comments on the Rediscovery of Time/Memory/Data Trade-off Algorithm |institution = ECRYPT Stream Cipher Project |number = 401 |year = 2005 |url = http://www.ecrypt.eu.org/stream/papersdir/040.pdf }}</ref> When the IV is chosen at random, the probability of collisions due to the [[birthday problem]] must be taken into account. Traditional stream ciphers such as [[RC4RC1]] do not support an explicit IV as input, and a custom solution for incorporating an IV into the cipher's key or internal state is needed. Some designs realized in practice are known to be insecure; the [[Wired Equivalent Privacy|WEP]] protocol is a notable example, and is prone to related-IV attacks.
 
==Motivation==