Talk:Initialization vector

I was just wondering this. What if IV=0, does it threaten the security in general? —Preceding unsigned comment added by 98.230.18.172 (talk) 18:36, 03:30, 3 December 2008 (UTC)

Interesting Question. I would say no. 0 is a valid IV. IV have to be non repeating. So an adversary gets no additional information. —Preceding unsigned comment added by 87.185.76.112 (talk) 17:50, 4 February 2011 (UTC)

"Block ciphers" Paragraph seem wired

ECB usually do not use IV. —Preceding unsigned comment added by 87.185.76.112 (talk) 18:01, 4 February 2011 (UTC)

'Stream ciphers' Paragraph seem wired

IV are separate from 'rounds' and 'keys'. IVs work on the stream. Rounds and Keys on a Block. —Preceding unsigned comment added by 87.185.76.112 (talk) 18:08, 4 February 2011 (UTC)

question

What does: "distinction between the encrypted message and the message parts" mean? — Preceding unsigned comment added by 71.132.201.193 (talk) 20:10, 21 June 2011 (UTC)

Size of IV = size of key

Nowhere did I imply that the size of the IV must be that of the block cipher's block size. In fact, I clarified in the next sentence that the size of the IV in block cipher modes is generally the block size. However, there is no concept of a block size for stream ciphers (in the sense of that of block ciphers). Yet, there are several stream cipher designs whose IV size is smaller than that of the key they take. Whenever the size of the IV is smaller than the key size time-memory-tradeoff attacks are possible, reducing the expected time to break the cipher compared to a brute-force attack on the key space. This also applies to block cipher modes of operation, e.g., when AES (which has a 128-block size) is used with a 256-bit key (e.g., in CBC or CTR mode). Sure this paragraph needs additional explanation, but this should be carried out in the article body, for which I didn't find time and energy yet. Guys, if you don't understand post on the talk page rather than insisting on an improper inline comment! Nageh (talk) 15:43, 28 September 2011 (UTC)

Nageh, this is lame. Instead of simply pretending that we don't understand your post, you should support your claims with references. In fact, it seems that you are making incorrect generalizations. Let's see: NIST describes the proper generation of initialization vectors in [1]. Section B.2 describes the generation of IV's for CTR mode. There are two methods described in this section: One is a continous counter whose size is the same as the block size of the cipher. The other one assigns a unique nonce to each message whose size is half of the block size of the cipher. If we used, say CTR mode with AES, then the key size could be 256-bit but the nonce would only be 64 bit. This method for generating IVs of course means that you can't encrypt more than 2^64 messages of size 2^64. Appart from this limitation I'm not aware of any attacks. If you do think that there exist time-memory-tradeoff attacks, then I'm pretty sure NIST would like to know. Until you can support your claim with a citation, I'm going to remove the claim in question. 81.62.190.164 (talk) 20:17, 28 September 2011 (UTC)

(edit conflict)You are an idiot. NIST never provides any rationale for their specifications, and some of their decision have been criticized (for good reason). In terms of time-memory-data tradeoff attacks, NIST certainly knows about their existence. In fact, with the CTR mode you mention they can be carried out very easily. Consider the counter to predictably start with some value, e.g., zero. Assume that keys are frequently created anew, e.g., for different users, connections, etc. Assume further that there is known fixed plaintext in the data encrypted or you can carry out chosen plaintext attacks. No you can follow the following strategy: Select 2^64 different keys (from the AES 128-bit key space), for each key encrypt the chosen plaintext block using the start counter in CTR mode, store the ciphertext block along with the key in a lookup table. Now eavesdrop on the data from the legitimate sender. Read the first plaintext block and look it up in your table. There is a chance of about 2^-64 that there is a match, and the key from the entry is the right one. Thus, both the time and the memory complexity is 2^64, which is much lower than the brute-force work factor of 2^128, given by the key size. This is a very simple example of a TMD attack, there are much better strategies. This simple attack may not be an issue in practice, or it may: in this case, one strategy is to reserve some space of the IV, e.g., 64 bits, for a random nonce or salt. In this case the attack complexity of the TMD attack is 2^96, which clearly is impractical.

If you want to learn more about TMD attacks, read up sources by Babbage and Golic, Biryukov and Shamir, Hong and Sarkar, and most recently a nice paper by Biryukov, Mukhopadhyay and Sarkar. You should probably start with time-memory tradeoff attacks first before studying TMD attacks, if you have never heard of them before. You should be able to find sources when you google these names. If you insist I can look them up them for you. HTH. Nageh (talk) 21:06, 28 September 2011 (UTC)

Yes, I'd appreciate that. Because none of what you say explains your claim "its unpredictable part is ideally of the same size as the key to compensate ...". The reason why this is important is that some parts of what you say is OK, and other stuff is just a little sloppy. If there are references then it is possible to verify those claims. I'd also appreciate I you wouldn't call me an idiot or clueless.81.62.190.164 (talk) 21:21, 28 September 2011 (UTC)

If you are deleting stuff just because you don't understand/agree with it? So, would you expand on what you think is sloppy? In the mean time I am looking up sources. Nageh (talk) 21:26, 28 September 2011 (UTC)

A few more comments. The section starting with "Predictable IVs can result in a predictable plaintext with a chosen plaintext attack..." looks like an incomplete generalization of a block-wise adaptive chosen plaintext attack against the CBC mode. That is just a guess, because the text is incomprehensible. Instead of trying to explain an attack with too few words, it seems better to me to simply refer to a paper: e.g. this one: "Blockwise-Adaptive Attackers Revisiting the (In)Security of Some Provably Secure Encryption Modes: CBC, GEM, IACBC" by Joux, Martinet and Valette, CRYPTO 2002. This would allow that a reader can check the conditions under which the attack applies. This paper for example implies that the IVs for CBC mode must be chosen unpredictably. It does not imply that the IVs have to be indistinguishable from random as the wikipedia page currently claims. 81.62.190.164 (talk) 20:41, 28 September 2011 (UTC)

I did not write any of the article's body text, which is horrible; I only replaced the lead section with something better than was there before. The paper you cite, which I know, is on BCPA attacks, which is something completely different than this discussion is about. That CBC mode requires unpredictable IVs is long known. Nageh (talk) 21:09, 28 September 2011 (UTC)

Just for reference, I rewrote most of the article from 30 Sept. to 1 Oct. 2011. Nageh (talk) 10:20, 5 October 2012 (UTC)

Initialization vector vs Seed

Is an "initialization vector" the same thing as a "seed"? (Or: maybe a seed is a kind of initialization vector?) —Sburke (talk) 00:03, 18 March 2013 (UTC)

No, it is not. The concept of a seed is that a short random element gets extended to an (almost) arbitrarily long string. The concept of an initialization vector is to allow the secure operation of a cryptographic scheme under a single invocation before a new IV needs to be provided. (Also, an IV need not be random.) A seed can be better compared to a key. Nageh (talk) 10:43, 19 March 2013 (UTC)

CBC mode does not use a nonce

From the article: "In this case, the IV is commonly called a nonce (a number used only once), and the primitives (e.g. CBC) are considered stateful rather than randomized."

This implies CBC mode uses a nonce. However it is my understanding that CBC mode requires an unpredictable IV. So a nonce (which could be 0, 1, 2, etc) is unacceptable.

Does anyone disagree? LordSamanon (talk) 00:25, 2 December 2023 (UTC)