Talk:Block cipher mode of operation

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Archives[edit]

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)[reply]

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)[reply]
davidpech 201.175.216.173 (talk) 07:20, 29 August 2023 (UTC)[reply]

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

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)[reply]
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)[reply]
> - 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.
This is incorrect in practice. One would not use the cipher text without authenticity assurances. Period.Jeffrey Walton 19:18, 21 February 2012 (UTC)
> In a very very weak sense, you could deduce integrity in CBC by looking for "garbled" of message blocks.
No, this is not correct. "A common misconception is that encryption provides data origin authentication and data integrity, under the argument that if a message is decrypted with a key shared only with party A, and the message is meaningful, then it must have originated from A." - from Hanbook of Applied Cryptography, ISBN 0-8493-8253-7 Parameter error in {{ISBN}}: checksum, p. 364. Jeffrey Walton 19:23, 21 February 2012 (UTC)

Random IV in CBC[edit]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Is the CFB decode diagram correct?[edit]

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)[reply]

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)[reply]

I agree with Jipis in that the figure for CFB may be improved. I am looking at the encryption figure for CFB in Stallings' Cryptography and Network Security 5th Ed. (Figure 6.5) and looks different from the one in the wikipedia. In the book it is clear that we take s bits from the output of the encryption block and discard the remaining b-s bits (where b is the block size). In the book, the s bits of cyphertext are fed to a shift register. Jbarcelo (talk) 10:50, 25 October 2010 (UTC)[reply]

The text describes how the method is used when the segment size is less than the block size. However, this is so important part of this mode that a figure describing that should be included. The description how the segmenting is incorporated to the algoritm can be found in Schneier's Applied Cryptography (2nd ed. sect. 9.6), NIST SP800-38a (sect 6.3), and Manezes et al, Handbook of Applied Cryptography (sect 7.2.2 (iii) and fig. 7.1(c)).Lauri.pirttiaho (talk) 07:21, 20 February 2011 (UTC)[reply]

I sectioned the CFB article, and left the image under "CFB Simplified". The complete CFB description for the NIST CFB-1, CFB-8 etc I left under a different section. The separation is fairly significant as the IV=0 vulnerability of Zerologon attack did not make sense under the initial description and the simplified image. Perhaps the proper image from NIST SP800-38A could be painted and inserted later, to enable easier understanding of CFB modes in the future. Blaufish (talk) 13:35, 17 October 2020 (UTC)[reply]

Maybe some external references?[edit]

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)[reply]

It is worth noting that in the first paragraph of History and Standardization the article states "Other confidentiality modes exist which have not been approved by NIST. For example, CTS is ciphertext stealing mode and available in many popular cryptographic libraries." but this example is in error. NIST published an Addendum to NIST Special Publication 800-38A, October, 2010 that adds 3 variants of Ciphertext Stealing for CBC mode making these variants "approved" in the FIPS 140-2 sense of the word. I suggest changing the text and adding this document as an external reference. — Preceding unsigned comment added by 72.29.187.229 (talk) 19:51, 9 May 2017 (UTC)[reply]

OFB vulnerable to known plaintext attack[edit]

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

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

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)[reply]

CFB used with a shift register[edit]

I just added a section about using CFB with a shift register. If anyone wants to add a diagram to this that would be awesome. There is an example of one here, but it doesn't make it very clear when the shift register is being updated relative to the other operations. Wingedsubmariner (talk) 20:23, 1 March 2009 (UTC)[reply]

OFB may also refer to the Austrian Football Association?[edit]

"OFB" redirects here. OFB may also refer to the Austrian Football Association.

IMHO this is wrong. The Austrian Football Association is the ÖFB or OEFB - have a loot at their website, which is http://www.oefb.at/. On the other hand is OEFB not redirecting to the Austrian Football Association. —Preceding unsigned comment added by 217.194.34.103 (talk) 12:32, 24 November 2009 (UTC)[reply]

SVG graphics[edit]

Shouldn't all of the graphics be svg? I am not so good at making svgs, but we can put a template requesting a conversion. Should this be done? --Chrismiceli (talk) 19:33, 20 February 2010 (UTC)[reply]

Why? They look good as they are, and they are just as easy to edit as PNGs as SVGs.
Translating the text in a PNG to other languages (if wanting to reuse the images on for instance the Spanish Wikipedia) is just as easy as translating the text in an SVG.
Actually, I think editing PNGs is easier since PNGs don't come with all the rendering bugs that SVGs still have. SVGs we created some year ago look bad here on Wikipedia since Wikipedia has changed its SVG rendering engine. While PNGs we made many years ago still look fine. And images we do with today's SVG tools often render badly or don't render at all on Wikipedia, so we constantly have to work around bugs. And SVGs made with one SVG editor sometimes don't load at all in another SVG editor, so we can't even update some of the images made as SVGs.
Using bitmapped formats such as PNG is simpler and probably more future proof. It is more likely the PNG images still can be rendered and edited in the future. I think SVGs should only be used where using vector graphics is clearly the better choice. For the simple images here using SVGs simply isn't worth the trouble.
And the people doing PNG to SVG conversions often don't know cryptography, so when they remake the images they often loose or damage some details that are essential to the images. I seen it happen with lots of our crypto images. So please don't request a remake of these images.
--David Göthberg (talk) 22:05, 20 February 2010 (UTC)[reply]
I respect your opinions. SVG usage in Wikipedia is not great. Perhaps when vector graphics have better support in Wikipedia, we can reconsider this idea. --Chrismiceli (talk) 06:21, 21 February 2010 (UTC)[reply]

Article Introduction[edit]

I feel like the article's introduction is more appropriate for block ciphers rather than block cipher modes of operation. I somewhat agree with 85.1.208.213's reversion. It seems to me that the first paragraph should include (1) a definition of a 'block cipher mode of operation' (or more generically, 'mode of operation'), and (2) a list of the three modes: (a) confidentiality, (b) authenticity, and (c) authenticated encryption. I envision something similar to, "In cryptography, a block cipher mode of operation is.... There are three modes of operation...."

I don't feel the current first paragraph should be discarded due to the close relationship between a block cipher and its modes of operation. It simply should not be the first paragraph.

Would it be possible for someone with penmanship nail the first paragraph?

I'm not the right person to call for copy editing. However, there are multiple issues introduced during the last series of edits. You're pointing out one of them. Generally, the lead section is not very satisfactory at the moment (standard bodies are better mentioned in the body, the note regarding use for a asymmetric encryption primitive is more confusing than explanatory, the descriptions regarding padding and the introduction of block size, etc.). The History section should discuss that the need for integrity protection was not well understood in the beginning, and instead error propagation properties of modes were studied. Examples of MACs should not be discussed here. Padding is required for modes that do not turn the block cipher into a stream cipher. Regarding authenticated encryption, AFAIK all one-pass modes are patented. The phrase 'unfortunately, for the cryptographic community' is not very well chosen (even if true). The explanation of one-pass vs. two-pass is missing. Feel free to address these issues. Otherwise, I'll get to it when I find the time. Nageh (talk) 20:37, 8 August 2010 (UTC)[reply]
Part one done. Regarding MACs, the historical situation is much more than that it was finally realized that integrity protection was a separate goal from encryption (which happened more like in the late 80s/early 90s). CBC-MAC was defined in the early 80s. The main driver for HMAC was that CBC-MACs were slow, and ad-hoc designs based on hash functions were insecure. As HMAC is not based on a block cipher and is formally not a mode of operation (despite similarities in design of hash functions), the relevant paragraphs in the article need to be rewritten.
Regarding authenticated encryption as a reaction to people not understanding how to combine them, this is also just one side of the story. The primary driver for the myriad of recent authenticated encryption schemes in fact was the development of efficient 1-pass schemes.
Nageh (talk) 10:50, 18 September 2010 (UTC)[reply]

Suggestion for the first paragraph[edit]

Suggestion for the first paragraph:

In cryptography, a block cipher is only suitable for the secure encryption of one fixed-length group of bits called a block. To encrypt multiple blocks securely a multitude of modes of operation have been designed. The most common information security goals in designing these modes are confidentiality and authenticity.
A mode of operation describes the process of encrypting data in blocks, and generally uses randomization based on an additional input value, often called an initialization vector, to allow doing so securely. Typically, the last part of the data to be encrypted is smaller than a block. Some modes of operation require the last block to be extended to match the cipher's block length using a suitable padding scheme.

En.gravious (talk) 16:43, 11 April 2013 (UTC)[reply]

I want a simple and clear introduction.
The current version and this proposal remain too abstract and even a bit wrong. Modes don't address just encryption but also decryption. ECB is a mode, but it does not offer the same security as some other modes. Don't label the entire class with the benefits that don't exist for all members.
On my talk page, En.gravious stated, "NIST defines Mode of operation as An algorithm for the cryptographic transformation of data that features a symmetric key block cipher algorithm (NIST IR 7298 and NIST SP 800-38C)." I haven't checked the sources, but that seems a better explanation than what we have. Basic confidentiality is provided by the underlying block cipher.
To me, a mode of operation is just a description of how to use a block cipher to achieve some larger purpose (an algorithm). Say a user has an 8-byte block cipher such as DES (choke). There needs to be some agreement about how to use that cipher for messages longer than a block. A simple mode is ECB, but it has some problems (see Penguin pix). There are more involved modes that tend to alleviate some problems. They can offer more security by introducing an IV and/or chaining. Some modes can have a different purpose such as computing a MAC digest.
A block cipher always raises the issue of padding, but I don't see that as a fundamental issue of a mode. It's more an afterthought. Even if one were transmitting a message shorter than a block, padding/salting would be an issue. It is not peculiar to a mode of operation.
What is important to say in the introduction?
Glrx (talk) 18:45, 11 April 2013 (UTC)[reply]
Thanks Grlx for your comments I've tried to incorporate them and comment on them below:
New proposal for the first paragraph of Block cipher modes of operation:
In cryptography, a block cipher is only suitable for the secure cryptographic transformation (en- or decryption) of one fixed-length group of bits called a block. To transform multiple blocks securely a multitude of modes of operation have been designed. The most common information security goals in designing these modes are confidentiality and authenticity.
Second paragraph from first proposal unchanged :
A mode of operation describes the process of encrypting data in blocks, and generally uses randomization based on an additional input value, often called an initialization vector, to allow doing so securely. Typically, the last part of the data to be encrypted is smaller than a block. Some modes of operation require the last block to be extended to match the cipher's block length using a suitable padding scheme.
Benefits / design goals of ECB:
"ECB Mode is electronic codebook. ECB was originally specified by NIST in FIPS 81. The standard, issued in 1981, only offers confidentiality (Source: http://www.cryptopp.com/wiki/ECB_Mode)."
"The same input block always produces the same output block under a fixed keg in ECB mode. If this is undesirable in a particular application, the CBC, CFB or OFB modes should be used. (Source: FIPS 81)"
Even though confidentiality is compromised the intend is to provide confidentiality.
Padding:
Stream cipher modes such as OFB and CTR do not raise the issue of padding, padding is peculiar to block ciphers and modes of operation that use block ciphers.

En.gravious (talk) 21:47, 11 April 2013 (UTC)[reply]

I hit the first paragraph with a hammer. It's inspired by what you've suggested but not exactly the same. Please change it or tell me what you think. Skippydo (talk) 01:59, 12 April 2013 (UTC)[reply]
I've kept some of your hammering. Of your sentence: "A mode of operation describes the process of encrypting variable-length messages using a block cipher while achieving various performance, bandwidth, and security goals." referring to the Handbook of Applied Cryptography by Menezes, Oorschot, et al. The book mentions on page 5, 227 and 228, various evaluation criteria for block ciphers and modes of operation. These are mentioned in Block cipher under the heading Practical evaluation.

In Block cipher modes however, the security goals are now mentioned in the first line of the article. Performance applies more to the choice between block cipher primitives (AES, Serpent, Twofish, etc) than to mode of operation, and bandwidth applies more to stream cipher modes IMHO. En.gravious (talk) 14:11, 12 April 2013 (UTC)[reply]

Single bit errors and error propagation. Contradiction in text?[edit]

The section on cipher feedback mode (CFB) says that "if a whole blocksize of ciphertext is lost both CBC and CFB will synchronize, but losing only a single byte or bit will permanently throw off decryption." Later in the same section, however, it is stated that "a one-bit change in the ciphertext affects two plaintext blocks: a one-bit change in the corresponding plaintext block, and complete corruption of the following plaintext block", but that "Later plaintext blocks are decrypted normally." Likewise, the section on cipher-block chaining (CBC) states that "a one-bit change to the ciphertext causes complete corruption of the corresponding block of plaintext, and inverts the corresponding bit in the following block of plaintext, but the rest of the blocks remain intact."

How are these statements to be reconciled? Does a single-bit or byte error "permanently throw off decryption", or does it only throw off decryption for a couple of blocks? --66.50.16.13 (talk) 14:39, 21 March 2014 (UTC)[reply]

The two sections are talking about two different kinds of single-bit or single-byte damage to the ciphertext, which have two very different effects: 

   ciphertext : error-free original
   cipertext : lost one byte, and the rest of the message shifted over
   cipphertext : duplicated one byte, and the rest of the message shifted over
   cixhertext : one byte mangled, without shifting the rest of the message

Each bit-flip soft errors, including substituting one character for another character, cause the decrypted plaintext to have error(s) in one or two blocks; but -- with most block cipher modes of operation -- the rest of the decrypted "plaintext" is identical to the original plaintext.

With nearly all block cipher modes of operation, a single Bit slip error, including duplicating or losing an entire byte, generally corrupts all the rest of the decrypted plaintext, .

How could we improve this article to avoid making it seem self-contradictory? --DavidCary (talk) 16:48, 8 October 2014 (UTC)[reply]

Resolved hopefully; I removed parts of the text on error handling in CFB that did not fully make sense and/or were extremely detailed/verbose. I inserted the SP800-38A text about how well CFB-1 self synchronizes, and that other CFB modes are expected to require external synchronization. Then I inserted one of the old examples where CFB-XXX actually will self synchronize in a special case (single bit flip) and an example where it will not (single bit lost in transmission). Blaufish (talk) 14:34, 17 October 2020 (UTC)[reply]

OFB and CTR modes[edit]

Concerning the streaming nature of OFB and CTR modes, it would be good to indicate explicitly that the plaintext does not have to consist of complete blocks. For a partially filled final plaintext block, just the corresponding ciphertext symbols (an incomplete ciphertext block) are transmitted; this can still be decoded.

It might be appropriate to note the relationship between OFB and CTR mode, and the One-time pad. In OFB/CTR mode, the key and the block cipher encryption function are used to generate a (pseudo-random) one-time pad, which is then XOR-ed with the plaintext to yield the ciphertext.

Wstomv (talk) 15:01, 30 May 2014 (UTC)[reply]

Explicit IV in CBC[edit]

It would be helpful to add the concept of explicit initialization vectors. This could be done either in its own section or as a part of CBC mode. In explicit IV mode a random data block is prepended to the plain text. The encrypted random block then takes the place of communicating the IV because the first block will always be thrown out. An example of where this is currently being used can be found on page 6 of "The Design and Implementation of Datagram TLS"[1]

I could add it, but this is the first time I've edited any wikipedia article and I thought the talk page would be a better place to start. 216.45.141.162 (talk) 17:48, 2 January 2015 (UTC)[reply]

References

  1. ^ Rescorla, Eric. "The Design and Implementation of Datagram TLS" (PDF). crypto.stanford.edu. Retrieved 2 January 2015.

OFB formula incorrect[edit]

When j=1, you do not use I(0), you use I(1) and O(0). Therefore, the IV is O(0), not I(0). Alternatively you could say that I(1) is the IV. — Preceding unsigned comment added by 68.11.83.88 (talk) 02:06, 27 February 2015 (UTC)[reply]

^ O(0) is not IV, it is the output of Encrypt(IV), so the formula is correct. YoloMcSwagson (talk) 03:58, 1 May 2015 (UTC)[reply]

what about OpenSSL's "Infinite Garble Extension" ?[edit]

It is mentioned here and explained there but I didn't find anything about this mode in the Wikipedia. Who might want to add it here? --RokerHRO (talk) 12:13, 27 April 2015 (UTC)[reply]

"Block chain"[edit]

the usage and primary topic of block chain is under discussion, see talk:Block chain (transaction database) -- 65.94.43.89 (talk) 04:22, 29 May 2015 (UTC)[reply]

"Blockchain"[edit]

The usage and primary topic of Blockchain is under discussion, see talk:Blockchain -- 65.94.43.89 (talk) 08:39, 29 May 2015 (UTC)[reply]

Mention that CBC and CTR are "recommended"[edit]

I made a small edit recently removing this phrase "Along with CBC, CTR mode is one of two block cipher modes recommended by Niels Ferguson and Bruce Schneier". My edit message said:

let's not suggest to the casual reader that using CBC or CTR directly is "recommended" at all

It got reverted by intgr saying:

using none of this "directly" is "recommended" to a casual person, Should we blank the whole article then?

I'm not very familiar with wiki procedures but I guess the right thing is to take this to the talk page.

What I really meant to say there was that claiming that CBC or CTR are recommended at all is a bad idea, and doesn't contribute any useful information - it seems to make a statement that those modes are "better" than others which is, at best, meaningless, and more likely to be harmful than anything. It's probably taken out of context of the original citation, too.

I know that people should know better than to take crypto advice from wikipedia, but it was an attempt to reduce misinformation.

Dequis (talk) 22:26, 10 October 2015 (UTC)[reply]

@Dequis: Why is the statement that some modes are better than others meaningless or harmful? I believe there is widespread consensus among experts that the two recommended modes are better, compared to the others described in this article — ECB, PCBC, CFB and OFB — which are only useful in rare fringe applications.
You say "it's probably taken out of context", I don't think it is. From the source itself:

Which Mode Should I use?

We have discussed several modes, but there are really only two modes we would consider using: CBC and CTR. We've already explained that ECB is not secure enough. OFB is a good mode, but CTR is better in some respects and doesn't suffer from the short cycle problem. There is no reason to choose OFB over CTR."
If you're not convinced by this source alone, I'm sure more could be found.
There is a real problem with this article, that it puts too much emphasis on classical un-authenticated modes, without recognizing that there are multiple applications, for which different kinds of modes are applicable — authenticated encryption modes and disk encryption modes. But that's a separate issue. -- intgr [talk] 21:47, 11 October 2015 (UTC)[reply]

Including other rare cipher modes[edit]

It might be a good idea to add some of the other proposed Cipher Modes into the index of this article, and maybe they should have their own page, or just one page all-together. Reference: https://web.archive.org/web/20170904011624/http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html List:

— Preceding unsigned comment added by 202.40.137.199 (talk)

ECB/Citation needed[edit]

To explain why ECB should not be used :

Could these references be used here? Janiko (talk)

References

  1. ^ https://www.schneier.com/blog/archives/2020/04/security_and_pr_1.html

kanatronjitjung@gmail.com[edit]

kanatronjitjung@gmail.com 49.237.11.134 (talk) 16:57, 25 January 2022 (UTC)[reply]

Acronym for Output Feedback in diagram is incorrect[edit]

I noticed that the acronym to the right of "Output Feedback" in the diagram is CFB - a duplicate of the acronym for Cipher Feedback above it. This should be OFB, right? Davidfinnie (talk) 23:44, 15 April 2024 (UTC)[reply]

You are 1000% correct. Good catch. It has been fixed. Epachamo (talk) 14:10, 16 April 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Block_cipher_mode_of_operation&oldid=1219230752"