Talk:Block cipher modes of operation/Archive 1

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents

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.
NIST has a gigantic collection of modes, almost all of which are unencumbered or trivially encumbered. I believe all of them should be listed here. Listing only approved, production-level modes is a bit like indexing the architectures of the world -- that met the Bay Area, California, building codes three weeks ago on thursday. In order to get a feel for the subject, it is just as important to understand the dead-ends and the speculative approaches as it is to understand the ideas that work. Otherwise, you have no basis by which to understand what works. Besides which, criteria that may hold true of a Government agency is not guaranteed to always hold true for everyone else. Where the information exists, I would certainly stipulate what modes are definitely known to work well with what ciphers. For completeness, I would also stipulate what modes definitely should not be used with specific ciphers and why. (For example, there would seem to be no advantage in using a mode like 2DEM if you are using a cipher like Rainbow, as the primary benefit is the same in each case, so the extra overheads aren't buying you a whole lot.)

Does someone knows if "Counter Feedback Mode" is the same as "Counter Mode"? [User: Miguel]18 Jan 2006

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: Image:Crypto diagrams.tgz - 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 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)

OCB vs CBC

In the introduction it claims OCB was one of the earliest modes proposed and it did not provide authentication. This is incorrect on both counts. So I guess CBC was what you really meant.

-Dan
Thanks for catching that one! — Matt Crypto 28 June 2005 14:18 (UTC)

Phantasy Star Online

Do you think we should keep the mention of this game in the article? It was me who originally put it there, but now I seem to think it shouldn't be there. Everything I said is correct, that people repeated the encrypted packet to gain levels. It just seems not really relevant at that point in the article. -- Myria 05:01, 31 October 2005 (UTC)

I like it. Lunkwill 08:53, 31 October 2005 (UTC)
I like it too, keep it. It is a very good, easy to understand and short enough example of how a replay attack works. And understanding how attacks work is very relevant in computer security. Besides, it gave me a good laugh! --David Göthberg 15:48, 31 October 2005 (UTC)

Nonce/IV + Counter

Nice doc! Nice diagrams! In this figure there is a Nonce and a Counter that seem to "come together" and crypted with the key. My question is, how do they "come together". The only explanation in the text is this one:

It generates the next keystream block by encrypting successive values of a "counter".

p@

Ok, I added this to the CTR section of the article: "The IV/nonce and the counter can either be concatenated, added or XORed together to produce the actual unique counter block to encrypt." I hope that answers your question. If you want to know more why we use IVs either scroll down to the last part of the article and read the section about IVs or why not even read the full article on initialization vectors. --David Göthberg 08:35, 2 February 2006 (UTC)

Move of IV section

Come to think about it, every one I know that has read this article has wondered about the IVs in the graphs. We should probably move the section that explains what IVs are and why they are used to the top of the article. They wondered about padding and integrity/error propagation much later so I think that should be left in the end of the article. I'll wait for any comments for some day and then I'll move the IV section to the top of the article. --David Göthberg 08:35, 2 February 2006 (UTC)

Ok, since no one protested and I have since seen even more people asking about IVs when reading (part of) this article. I now moved the IV section close to the top of the article. In the IRC chat #crypto on irc.freenode.net we usually direct people to this article when they ask what CBC/CTR mode etc means. They then always wonder what "IV" in the graphs mean. So I hope the new ordering will be more pedagogic. --David Göthberg 10:26, 31 July 2006 (UTC)