Talk:Block cipher modes of operation

From Wikipedia, the free encyclopedia

This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks.

It is intended that this article be included in WikiReader Cryptography, a WikiReader on the topic of cryptography. Help and comments for improving this article would be especially welcome. A tool for coordinating the editing and review of these articles is the daily article box.

To-do list for Block cipher modes of operation:	edit · history · watch · refresh
None listed.

Archives

February 2004 – July 2006 (Move more sections to this archive page later.)

Contents 1 Archives 2 Is it needed to keep the IV secret? 3 Random IV in CBC 4 Is the CFB decode diagram correct? 5 Maybe some external references? 6 OFB vulnerable to known plaintext attack

[edit] Archives

The talk page was getting cluttered and I was afraid that some important comments would get overlooked. Creating: /Archive 1 Lunkwill 20:43, 7 October 2006 (UTC)

Yeah, it was starting to get cluttered. Thanks. I added the archive boxes to the top of the pages. --David Göthberg 00:03, 8 October 2006 (UTC)

[edit] Is it needed to keep the IV secret?

This article states directly that there is no need to keep the IV secret. There is a well known argument for keeping it secret though. See: http://www.ciphersbyritter.com/NEWS6/CBCIV.HTM for a discussion about this. The book Network Security Essentials 2nd ed by Stallings, also states on page 45 that the IV should be kept secret.

The risk created by not keeping the IV secret is quite small I think, but these are the possible problems as I see it:

- A man-in-the-middle (MITM) can, by changing the IV, alter bits in the first block of the plaintext received. The MITM knows exactly which bits in the plaintext received that will be altered. This will compromise integrity, but not make the plaintext available for the MITM.

- The case described over can be used as a tool for making a cryptanalyze of the ciphered text easier (it would be related to being able to select the plaintext when doing the cryptanalze). I'm not totally sure if this point is valid though.

My opinion is that the statement about it there not being any need for keeping the IV secret should be removed/altered.

Any thoughts?

• The discussion you reference includes several well known and respected researchers pointing out what I also consider to be the best answer (which is stated in the article): CBC only provides secrecy in a strong sense, not integrity. In a very very weak sense, you could deduce integrity in CBC by looking for "garbled" of message blocks. That could suggest that tampering has occurred, but as a trivial example, if I'm sending you encryptions of output from my random number generator (maybe so you can run some statistical tests on it), how are you going to distinguish "garbled" random bits from "ungarbled" bits? Since MACs, by contrast, provide very strong integrity protection, why quibble about the slightly weaker integrity of the already uselessly weak integrity offered by CBC? Just use the right tool for the job. As to aiding cryptanalysts, the standard we use for security already includes chosen plaintext attacks; if CBC wasn't CPA secure, we wouldn't consider it secure at all. That's the great thing about strong security -- we make sure that constructs work securely under such stringent constraints that you never have to worry about detecting "garbledness" or preventing attackers from choosing plaintexts. Lunkwill 02:22, 20 Jan 2005 (UTC)

I think its vaguely relevent here:

In Linux, users who have been using dm-crypt/cryptoloop in plain CBC mode are using a public IV. This lead to issues of watermark attacks, to get around that a ESSIV mode which keeps the IV's used for secret was written. Look at page 59 of http://clemens.endorphin.org/nmihde/nmihde-A4-os.pdf for mention of ESSIV/CBC - "CHAPTER 4. CBC ATTACKS"

I think your "content leak" attack is rather well known (doesn't AC talk about it?) and not especially worrying; For a 128-bit IV, you have about 2^64 expected blocks before a collision, just as with MD5. If 2^64 isn't enough, go to AES-256 and get 2^128 security. But that's not what you asked about; as to watermarking, it seems to only work because the attacker can modify the ciphertext, and that suggests that people are expecting integrity from a secrecy mode. IOW, you should be using a MAC. But I guess the attack does have something to do with secrecy; has this attack been considered in the literature? Lunkwill 20:19, 12 August 2005 (UTC)

You guys seem to talk about the same weekness as is discussed in the question below (Random IV in CBC). I took the liberty of moving that question up to right below here. The answer seems to be that the IV does not have to be secret, but for several of the modes the IV has to be unpredictable. That is, the attacker must not be able to predict what IV will be used for future messages being encrypted. See next section for more details about this. (The "ESSIV" link that some one gave above is relevant in this case and also does describe this. But note that this problem is relevant also for other systems than disk encryption.) Oh, and note that MACs doesn't solve this IV problem. What solves it is to use a CSPRNG fed with a secret seed for creating the IVs. Or kind of make a CSPRNG using the block cipher itself like this: If a counter is used as IV then simply encrypt the IV with the block cipher (you can use the same secret key as the message key) to create a unpredictable IV that then is the IV used in the block mode. --David Göthberg 14:09, 6 October 2006 (UTC)

[edit] Random IV in CBC

We really should include the caveat that in CBC mode, the IV must not be predicable to the attacker but must be randomly generated once plaintext is known. If this condition is is not met the proofs of security are broken and there is an effective distinguishing attack. — ciphergoth 10:27, 28 May 2006 (UTC)

Can you give a citation for that, please? I can't see why (who?) knowing the plaintext should affect the operation of my random number generator. Lunkwill 18:44, 28 May 2006 (UTC)

Ah, I see what ciphergoth means. It seems to me the problem is that an attacker under some circumstances can test if he guessed right about the content of a previous message. (Which I guess is what a "distinguishing attack" means.) That is if he can trick the sender to encrypt messages designed by the attacker but the sender still using the same key and a predictable IV such as a message counter used as an IV. Then if the attacker has guesses of a previous message he can design new messages with the same content but with the first block changed so that when xored with the new IV will cause the same input to the first encryption. If the attacker guessed right then the new encrypted ciphertext will look exactly as the ciphertext of the old message. If the attacker can design several messages and have the sender encrypt all of them then the attacker can even try several different guesses! And he can guess and check one message block at a time thus incrementally guess the whole message. Scary stuff.

But if the IV is not a counter but a random value (a CSPRNG can be used) and created/published by the sender AFTER the message to send is chosen/created then the attacker can not design the first block properly and thus can not do such tests. Oh, there seems to be a simple solution to this. If you use a message counter as IV simply encrypt the IV before using it for the XORing of the first block. This is the same thing as making the IV with a CSPRNG. Note that the IV need not be secret, it can be sent in cleartext. As long as both sender and receiver "mess up" the IV enough by doing the encryption on it so each new IV gets unpredictable before it is used for XORing. It can also be sent in the encrypted form. It doesn't matter if the attacker can see what is used to XOR with, as long as he can not predict what will be used for XORing in future messages.

This might be the reason that in some old books I have seen the IV is encrypted before use in CBC mode. But in the new books I have they don't do that. Seems the cryptographers have forgotten about this attack since then?

Anyway, yet another good reason to avoid using CBC mode. Simply put, this means CBC mode as presented here and in modern books is not secure.

--David Göthberg 05:25, 6 October 2006 (UTC)

Cryptographers have not forgotten about these attacks. Rather they have found new ones. What you describe is just a special case of a blockwise adaptive chosen plaintext attack. That is, an attacker can learn the ciphertext of block i and then choose the plaintext block i+1. In this case a distinguishing attack is possible (as you describe above). For example it is a bad idea to use the last block of an encrypted packet as an IV for the encryption of the next packet. Thus as you describe the IV just has to be unpredictable, but not necessarily secret and it must not be known to the attacker to avoid chosen plaintext attacks. Exactly the same must be true for every ciphertext block: the attacker must not learn it before chosing plaintext blocks. So the IV should simply be treated the same way any ciphertext block is treated. CBC is very tricky to use and should never be used without MAC. But it is not insecure. 67.84.116.166 15:33, 6 October 2006 (UTC)

So why would it not be secure to use an encrypted CTR as the IV? Just curious... 83.64.176.129 19:19, 30 August 2007 (UTC)

83.64.176.129: You misunderstood us. What both I and 67.84.116.166 are saying is that using an encrypted counter as IV is secure. That is, the counter has to be encrypted to make it random and unpredictable (for the attacker) before it is used to XOR onto the first plaintext. But it seems it doesn't matter if is transferred in plaintext or in its encrypted form. --David Göthberg 00:36, 31 August 2007 (UTC)

I realised there is a similar problem with CTR mode. If for instance a message counter is used as IV for CTR mode and we use the normal aproach to have an IV the size of the block cipher's block size and we simply add the mode internal counter (CTR) to the IV then the message counter and the CTR will interact in a bad way. So we need that the IV changes in a more unpredictable way between each message. That is, in a way that does not interact with the CTR. The solution seems to be the same as to the IV problem in CBC mode: Either use a CSPRNG to create the IVs or build a kind of CSPRNG by using the block cipher itself letting it encrypt the simple IV before it is actually used. (You can use the same key as for the message). To me it seems that for all modes the IV should be encrypted to "mess it up" in an unpredictable way before first use/combination with any other data. The CFB and OFB modes seems ok as described in this article since they do exactly that. Note that for none of the modes the IV need to be secret, just see to that it is random/unpredictable enough. (If you worry about the secresy of the IV then you are thinking of message authentication and not secresy and for that you should use MACs.) --David Göthberg 14:27, 6 October 2006 (UTC)

[edit] Is the CFB decode diagram correct?

I've just been looking at the decode diagram for CFB, this has the plaintext being fed back into the cipher encode block. I think it should the encrypted text that is fed back?

Right you are. Fixed. Lunkwill 18:37, 30 May 2005 (UTC)

Also, it seems to me that something's still off. From what I've learned, only the high t bits of the output from the encryption algorithm are used as the input to the XOR. That produces the next t bits of the ciphertext. Those t bits of ciphertext are then used as the low-order bits of the input to the next encryption algorithm round (with the high-order bits being simply shifted t bits to the left). Typical values for t are 1 and 8. Jipis 02:51, 6 October 2006 (UTC)

[edit] Maybe some external references?

Does anyone think this is worth adding to the references?

Recommendation for Block Cipher Modes of Operation; Methods and Techniques http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

It's a bit more verbose than the descriptions here (covers CBC, CFB, OFB, CTR, ECB) and clarified many things for me. Other things it covers are:

- test vectors for AES in the 5 modes
- generation of IVs
- Error propagation
- Message padding
- Counters

That sounds like an excellent reference. I've gone ahead and added it as an external link. Zetawoof^(ζ) 22:21, 17 September 2006 (UTC)

[edit] OFB vulnerable to known plaintext attack

Is it worth mentioning? I'd like to think so.

83.147.140.156 (talk) 11:59, 27 February 2008 (UTC)

The article already notes in the section IV that reusing the same IV makes OFB insecure. If you know another "known plaintext attack" then please provide a reference. 85.2.23.131 (talk) 21:04, 27 February 2008 (UTC)