Talk:Block cipher mode of operation/Archive 1

message: 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)
thread_title:  Some questions about modes 

message: 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)
replies: text:  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)
thread_title:  Is this right? 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Confusing 

message: 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)
replies: text: I like it. Lunkwill 08:53, 31 October 2005 (UTC)

text: 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)
thread_title:  Phantasy Star Online 

message: 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)
thread_title:  Nonce/IV + Counter 

message: 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)
replies: text: 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)
thread_title:  Move of IV section