Talk:Block cipher modes of operation

Missing image Key-crypto-sideways.png WikiProject on Cryptography

This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography in the 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.

Template:CryptographyReader

	Pending tasks for [[Template:Articlespace:Block cipher modes of operation]]: (https://academickids.com:443/encyclopedia/index.php?title=Talk:Block_cipher_modes_of_operation&action=purge)	edit (https://academickids.com:443/encyclopedia/index.php?title=Talk:Block_cipher_modes_of_operation/to_do&action=edit) - watch (https://academickids.com:443/encyclopedia/index.php?title=Talk:Block_cipher_modes_of_operation/to_do&action=watch) - purge (https://academickids.com:443/encyclopedia/index.php?title=Talk:Block_cipher_modes_of_operation&action=purge)
	Talk:Block cipher modes of operation/to do

Contents

1 some missing modes. add them? 2 some questions about modes 3 algorithm or protocol? 4 correct category tag is?? 5 Is it needed to keep the IV secret? 6 Is this right? 7 Confusing 8 Is the CFB decode diagram correct?

some missing modes. add them?

There have been some relatively recently developed block modes, some of which are patent or other intellectual property encumbered. As the article now is, there is no discussion of them, the subject matter being limited essentially to those covered in the relevant FIPS document from the 70s. As well, an NSA proposed block cipher mode was found to be problematical; this is also not covered here. Since these matters are primarily developer level stuff, it may be that some would feel that WP shouldn't cover such things. BUT, since incorrect block mode use in a crypto system design can vitiate all other good qualities in the crypto system design, this IS a user level issue. As well, it would be well to include some coverage if only to illustrate that elementary mistakes -- not obvious to anyone, perhaps including the designers / implementors -- are fatal to security. And that is a very useful bit of paranoia to get across to would be crypto users.

Comments?

ww

Absolutely. I think all manner of modes are encyclopedic. Be bold! Lunkwill 23:24, 23 Feb 2004 (UTC)

Block ciphers and hash algorithms are equivalent. Why isn't using one as the other considered a mode (a possibly insecure one, a la TEA on Xbox)? --Myria 08:46, 19 Oct 2004 (UTC)

What do you mean by equivalent? Block ciphers and hash functions are certainly distinct types of cryptographic primitive, although there exist constructions which allow block ciphers to be designed which use a hash function as a component, and vice versa. — Matt 11:07, 19 Oct 2004 (UTC)

Any block cipher can be used as a hash function and vice versa. --Myria 18:03, 19 Oct 2004 (UTC)

Not trivially, and not generally in practice. Lunkwill 02:16, 20 Oct 2004 (UTC)

Well, the block cipher → hash function case is trivial, and has happened in practice (Xbox 1.1 and TEA comes to mind). Set key = constant. For each block, do this: key = encrypt(key, block). The resulting key is then the hash. Stream ciphers can also be made into hash functions; consider what happens if you use the data to be hashed as a big RC4 key to encrypt a bunch of 00's.

some questions about modes

Greetings,

I have a question relating to this article.

I am researching CCMP "counter mode encryption(CTR), cipher block chaining (CBC), and a message authentication code (MAC) protocol" This is to be part of the new 802.11i wireless standard... (sometimes referred to as WAP2)...

The diagrams here are great! And seem to simplify the story... but I can't seem to figure out how CCM puts CTR and CBC together....? is there a discussion of this somewhere on the web I just haven't found yet?... or am I completely off track and maybe should get myself a pickup truck and a lawn mower and change careers?...

I would really appreciate and hints and/or pointers.

• Thanks to Jason for pointing me to http://www.vocal.com/CCMP.pdf
• but I'm still struggling with how to interpret the diagrams on this
• .pdf ... I may be in a bit over my head... I want to create diagrams
• Like Jason's explaining CCMP

Thanks for your time and consideration.

Chris chandler Chris@littleharbor.com

Note that the original Openoffice files for the existing diagrams are in the public domain, so feel free to use them for CCM: - Lunkwill 18:16, 4 Apr 2004 (UTC)

algorithm or protocol?

The category tag here is currently algorithm. Operating modes are, as I take it, protocols for the use of block cypher algorithms. So, the category should be protocols. Comments? ww 17:33, 22 Jun 2004 (UTC)

I don't think so here, not in the sense that it's usually used. A mode of operation tells you how to apply a block cipher to encrypt a message longer than the block size. A protocol, on the other hand, involves two or more parties exchanging messages according to a fixed procedure for some set aim etc. I would reclassify this article into general Category:Cryptography, personally, as it isn't really about one specific algorithm like DES, SHA, RSA etc. — Matt 00:04, 23 Jun 2004 (UTC)

Matt, Since a protocol is a prescribed procedure it is surely an algorithm in at least that sense. However, I observe that protocol is used to describe a usage pattern for algorithms (as in the message exchange example you give) and is therefore a sort of '2nd level' algorithm. So a ticket exchange protocol (of which there are several in Kerberos) isn't usually termed an algorithm, nor are authentication protocols, or digital signature protocols, or ... .

In this case, my sense was that a mode specifies a usage pattern for an algorithm (there being several possible for the same algorithm) and so should be a protocol, rather than an algorithm. Do you think I'm missing some usage point here in re protocol (at least in crypto)? ww 17:50, 23 Jun 2004 (UTC)

I think if you're wanting to say (e.g.) "Cipher Block Chaining is a cryptographic protocol", then that's out of step with how "protocol" gets used. Protocols are indeed algorithms, but they involve sending messages between parties. — Matt 12:45, 24 Jun 2004 (UTC)

Matt, Actually I think something like this is about right. "Cypher block chaining is a protocol for the use of block cypher algorithms which has this and that but not this other property". If you don't like this use, and you seem not to, then propose an alternative word for the concept here. It applies to your example of message exchange schemes but to other things as well, as for instance, CBC, CTR, ECB, ... No? ww 17:16, 24 Jun 2004 (UTC)

It would be misleading to describe CBC as a "cryptographic protocol" (e.g. by putting it in the category). I would use "mode of operation" or "scheme", probably the former. "Protocol" implies interaction between principals (users or agents), and that doesn't apply here. — Matt 17:34, 24 Jun 2004 (UTC)

correct category tag is??

Sorry if I didn't tag this article correctly :-) When categorizing, I used about 1-2 secs reading the article to determine which cat it should go in, so I may well be wrong. Again, I don't know much about crypto, but this article seems to discuss algorithms in general terms, thus it's in the algorithm cat. I don't think only algorithms should go in this category; this is more like algorithm theory that should go here too. ✏ Sverdrup 17:31, 24 Jun 2004 (UTC)

Sverdrup, Please don't apologize! You've done nothing wrong, and I'm grateful that you pitched in on the catergory thing. I didn't even notice it going on, mostly, until it was almost over. And then I found out about the WikiHelp page...

As you can tell from the above, those who are cryptiacs (unlike your lucky(?) self) are not quite settled on the use of the term. You're hardly to be faulted (even self faulted) for not being au courant of a usage for which the courant is in some flux. Indeed, there is even some disagreement on the use of the term algorithm in crypto, see Talk cryptography for about mid March this year. That one is still hanging!ww 19:57, 24 Jun 2004 (UTC)

---

I want a CBC penguin for comparison. I know i could use any random noise, but the efect would be great.

Yes, any randomly-generated image would suffice (the algorithm and key aren't specified, so it wouldn't be inaccurate) — Matt 05:54, 20 Jul 2004 (UTC)

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)

Is this right?

Is this right?

The cipher feedback (CFB) and output feedback (OFB) modes make the block cipher into a stream cipher: they generate keystream blocks, which are then XORed with the plaintext blocks to get the ciphertext. Just as with other stream ciphers, flipping a bit in the ciphertext produces a flipped bit in the plaintext at the same location.

It seems so, even if it's confusing, see Integrity protection and error propagation paragraph below that one. -- ClementSeveillac 14:25, 8 May 2005 (UTC)

Yes, it is true, but not the whole story for CFB. In CFB, if you flip a bit on a block, you do indeed flip a bit in the plaintext in the same location. However, you also corrupt the entire of the subsequent plaintext block. — Matt Crypto 00:11, 23 May 2005 (UTC)

Confusing

If CFB and OFB diagrams are read from top-bottom, it makes no sense; wherereas if we read them upside-down, at least there is some logic. Am I right?

Which diagrams are you referring to? I don't believe we have any diagrams (yet) of OFB or CFB in this article. — Matt Crypto 00:12, 23 May 2005 (UTC)

Sorry, I mean the OFB and CFB Mathematical Equations(Shouldn't it be read upside-down??) --Natakaasd 04:03, 23 May 2005 (UTC)

Hm, I see what you mean. I was about to switch them as you suggest, but then I realized that the way they are emphasizes the "meat" of the algorithm first, then lists the boundary conditions afterward. Recursive definitions took me a long time to get used to, and I think they can be written in any order -- the reader is just left with the job of finding the equation that fills in the value she's looking for. Perhaps you can help us find a way to explain what's going on in a more accessible way. (My original OpenOffice diagrams are floating around here somewhere in a .tgz file, so somebody could do diagrams for these modes like the others). Lunkwill 04:49, 23 May 2005 (UTC)

Thanks for adding the OFB/CFB diagrams! I've restored the formulae because I think they also help explain what's going on. — Matt Crypto 18:36, 23 May 2005 (UTC)

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)