4
$\begingroup$

Theoretically, when using a symmetric block cipher in CBC mode, the current block is dependent on the previous block. Suppose one plaintext is encrypted using CBC, and then one bit of it is changed, let's say somewhere in the middle. Then the new ciphertext will change from the middle onward. Would it be better if I used CBC like this?

  1. encrypt plaintext
  2. reverse the ciphertext
  3. continue encrypting (now from finish to start)

That would ensure that one modification to the plain text will change the entire new ciphertext. Right?

Improve this question
$\endgroup$
5
  • $\begingroup$ Yes, but using an IV you are already making sure two similar messages that start the same don't encrypt to the same ciphertext. And using a MAC (which I am confident you are doing) will let you catch any integrity (and/or authentication) failure, if you were thinking of using this as some kind of safeguard against transmission errors. Basically, my question is, why do you need this property? $\endgroup$
    – Thomas
    Commented Apr 9, 2013 at 7:35
  • $\begingroup$ I'm not thinking of transmitting this data... It's about stored data. But that data might be sent to another device to sync with it. So you are saying I need a new IV for every encryption ? $\endgroup$
    – Clau
    Commented Apr 9, 2013 at 7:37
  • 2
    $\begingroup$ Absolutely, every distinct message encrypted with CBC should (almost always) use a fresh new IV. Using the same IV for multiple messages is the number one cryptographic failure and while it isn't as devastating for CBC as for some other modes, it's still a major weakness. Still wondering, though, why is it important that the whole ciphertext changes if any one bit is changed? $\endgroup$
    – Thomas
    Commented Apr 9, 2013 at 7:41
  • $\begingroup$ @Thomas, care to write your comments up as an answer? $\endgroup$
    – mikeazo
    Commented Apr 9, 2013 at 14:35
  • $\begingroup$ @mikeazo Done.. $\endgroup$
    – Thomas
    Commented Apr 9, 2013 at 14:58

3 Answers 3

Reset to default
4
$\begingroup$

Your problem is that if you encrypt two messages which start the same (and change at some point later on) the beginning of the ciphertext will be the same in CBC mode when using the same IV.

Normally you should change the IV every time you encrypt a new message. This is precisely what the IV is meant for - achieving IND-CPA (semantic) security which prevents an attacker from detecting where the the message was changed. Once you do this, your concerns go away, since even two similar messages (say, an old document, and a newer, slightly revised one) will be encrypted with completely different IV's, and hence their ciphertext will be unrelated. And you don't need a two-pass scheme anymore!

Improve this answer
$\endgroup$
1
$\begingroup$

It looks like what you are describing is comparable to IGE (Infinite Garble Extension) and especially biIGE mode of encryption.

So I guess my question and the answer on my question here is of relevance.

Improve this answer
$\endgroup$
1
  • $\begingroup$ April? Sheesh, I'm kicking old cows :) $\endgroup$
    – Maarten Bodewes ♦
    Commented Nov 25, 2013 at 20:21
1
$\begingroup$

You need to use different IV for every message you encrypt. Thus rather than the process:

  1. encrypt plaintext
  2. reverse the ciphertext
  3. continue encrypting (now from finish to start)

You need to generate IV each time. I.e.:

  1. generate IV
  2. encrypt the plaintext using the IV
  3. store/send the ciphertext and the materials required to recreate IV

The easiest way choice is to generate random IVs. This will of course require more storage space (ciphertext + 16 bytes).

Some other schemes which deterministically generate IV are allowed. See NIST SP800-38A for recommendations on how CBC mode IV can be generated.

How to use CBC without expanding block

Linux's dm-crypt uses CBC-ESSIV mode, which generates IV on the fly without need for expansion and thus allows to use CBC mode, without requiring more space than the size of plaintext (assuming plaintext size is multiple of AES block size). However, this mode requires significant amount of processing to calculate IV.

(There are also some other ways to use CBC or build mode based on CBC, which does not need to store IV). Common for all such modes and mode variants is: you need to be very careful with such mode to avoid IV reuse does not happen unexpectedly.

For example, one notable situation where IV reuse occurs is when CBC-ESSIV stores the same value to the same block. In some security models this is considered acceptable.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ CBC-ESSIV does not solve the problem of IV-reuse leaking information about where a plaintext has changed; it's simply a fix on the even worse problem of IVs changing in predictable ways from sector to sector that affected earlier versions of dm-crypt (and still affects CBC-plain). While you're probably aware of this, I worry that your answer does not make it clear. $\endgroup$
    – Seth
    Commented Nov 25, 2013 at 19:58
  • $\begingroup$ @Seth: Thanks. Yes, I specifically wrote: "you need to be very careful with such mode to avoid IV reuse does not happen unexpectedly." This is indeed one of situations where I would say IV reuse is expected event. But, I'll clarify the response anyway. $\endgroup$
    – user4982
    Commented Nov 26, 2013 at 21:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.