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)[reply]

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)[reply]

"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)[reply]

'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)[reply]

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)[reply]

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)[reply]

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)[reply]

(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)[reply]

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)[reply]