4
$\begingroup$

I understand that in CBC mode, the IV must be chosen randomly for every use of the same key.

But for practical purposes I would like to easily store the IV alongside the cyphertext.

So I thought of calling the encryption function with a zero IV and prepend my actual IV to the plaintext:

         IV         P1         P2
          │          │          │
          ▼          ▼          ▼
Zero ──▶ XOR   ┌──▶ XOR   ┌──▶ XOR   ┌──▶ ...
          │    │     │    │     │    │
          ▼    │     ▼    │     ▼    │
         AES   │    AES   │    AES   │
          │    │     │    │     │    │
          ├────┘     ├────┘     ├────┘
          ▼          ▼          ▼
         C1         C2         C3

The decryption function can be called with the same constant (zero) IV and then I can just discard the first block_len bytes to recover the plaintext.

Are there any security risks with this approach?

$\endgroup$

migrated from security.stackexchange.com Apr 3 '17 at 12:49

This question came from our site for information security professionals.

  • 2
    $\begingroup$ Why can't you just prepend the IV to the ciphertext? That's almost exactly what this "scheme" tries to accomplish, only it's more vulnerable to accidental misuse, involves extra unnecessary AES invocations. $\endgroup$ – Stephen Touset Mar 31 '17 at 22:22
2
$\begingroup$

I can think of one security risk, though it can be mitigated:

  1. If the attacker can guess your IV, then you are giving them an avenue to recover your key. Ie if they know the IV, then they can do a known-plaintext attack on the first block. If you use a cryptographically-secure random number for the IV, then it's probably fine.

As @AgentMe points out, this has already been discussed here:

Why is CBC with predictable IV considered insecure against chosen-plaintext attack?


More importantly, there are some efficiency losses by doing this:

  1. You do an extra encryption round. This is probably not a big deal for most applications.

  2. You inflate the size of the cyphertext by one block. This can be a big deal where the plaintext and cyphertext are required to be the same size - for example if the caller is expecting it to be encrypted in place in the same memory block.

$\endgroup$
  • $\begingroup$ It is random. And I don't care about the size. Should I just concat the IV to the cyphertext to store them together, to avoid the extra encryption round? $\endgroup$ – Tobia Mar 31 '17 at 16:48
  • $\begingroup$ Yeah, that's the normal way of doing it. Re "I don't care about the size". Are you sure that all of the crypto libraries you use also don't care about the size? the assumption len(plaintext) == len(cyphertext) is a pretty common one when dealing with CBC mode. $\endgroup$ – Mike Ounsworth Mar 31 '17 at 16:50
  • $\begingroup$ "one of the advantages of CBC mode is that it does not require a secure source of randomness at runtime"? Wait, that's new to me! Can the IV just be pseudo-random then? $\endgroup$ – Tobia Mar 31 '17 at 16:51
  • 1
    $\begingroup$ @AgentME Ah. Thanks for pointing me to that, I have learned something. I'll re-do my answer. $\endgroup$ – Mike Ounsworth Mar 31 '17 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy