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]

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]