0

Usually the IV for the crypto operations is chosen randomly and is sent together with the encrypted data [at the first block]. For decryption, the IV is first extracted from data and set separately in the crypto components (functions or HW peripherals) and then feed the crypto operation with data.

enter image description here

The other case is to set the IV always to fixed value but the first block of data is chosen randomly. In this case after decryption the first block will be just ignored!

enter image description here

In terms of result, I understand that the encrypted text are different but in terms of security does anybody know if it matters or not?

HmT
  • 101
  • Relevant but not duplicate: https://crypto.stackexchange.com/q/47328 – Squeamish Ossifrage Mar 12 '19 at 18:09
  • Not an answer to your question, but: Please consider using an authenticated cipher that works on messages of arbitrary byte lengths, like NaCl crypto_secretbox_xsalsa20poly1305, or AES-GCM, or AES-CCM. The concept of ‘CBC mode’ is not useful for application development; the security goal of unauthenticated encryption (IND-CPA, indistinguishability under chosen-plaintext attack) often fails to models what applications really need -- very few applications need no authentication; and you also have to worry about padding which is a notorious vector for attacks like POODLE. – Squeamish Ossifrage Mar 12 '19 at 18:18

1 Answers1

0

Actually, that turns out that it's sometimes a useful way of implementing CBC mode (at least, with the understanding that you don't send the value you have labeled 'Initialization Vector', but instead the first cipherblock you generate will be sent to the decryptor as the CBC mode IV, and the rest of the cipherblocks will be sent to the ciphertext.

It is easy to see that if the decryptor uses the standard CBC decryption process with the provided IV and ciphertext, he'll get the plaintext.

So, why is this useful? Well, one requirement for CBC mode is that the IV be unpredictable (specifically, unpredictable to someone who doesn't know the key; if they know the key, they don't need to predict IVs to verify potential plaintext blocks). With the standard CBC mode implementation, you are given the responsibility of generating unpredictable values, which is not especially cheap.

However, with your construction, it turns out that we no longer require that the first block (that is, the one you labeled 'Initialization Vector') be unpredictable; it is sufficient that it just be unique - after it passes through the AES function, it'll become unpredictable. Hence, it is sufficient that it can be a counter, which is a lot cheaper than an unpredictable value.

However, you'll say, you perform another CBC mode block (which involves another AES block operation); doesn't that increase the cost? Well, sometimes, it doesn't - specifically, if you have some encryption hardware that performs a CBC mode encryption as a primitive, then the cost for encryption one additional block is usually fairly minimal (and certainly a lot cheaper than a side operation to generate an unpredictable value).

So, if you are in this specific scenario, yes, it can be a nice optimization.

poncho
  • 147,019
  • 11
  • 229
  • 360