1
$\begingroup$

The scenario

Using AES 256 with CBC mode. (Authentication is done separately. Ignored here.)

The goal (explained more later)

To avoid sending an unencrypted IV.

But since this is being done using .NET whose function forces us to use an IV, we can't just prepend 16 random bytes and then toss away the first 16 bytes after decryption.

The plan

Prepend 16 random bytes ("IV1"), and besides that use 16 bytes with value zero as the IV ("IV0"). Then send the ciphertext without its first 16 bytes.

Decryption will be done by the receiver first determining what the first block of ciphertext will be (for that AES key, for any message) by encrypting something in the aforementioned manner (which will have to be done only once per key) and taking the first 16 bytes of the resulting ciphertext.

They then prepend those bytes to the cropped-ciphertext-received to get the original uncropped ciphertext, and then decrypt it with an IV ("IV0") of 16 bytes of value zero (i.e. they use .NET's decryption function, feeding it the required IV which is those 16 zeros).

They then discard the first 16 bytes of the result (which is received from .NET after .NET discards the first-first 16 bytes which are the IV) because those are the 16 random bytes prepended ("IV1").

But why?

Communicating the IV in plaintext gives a brute-force attacker an edge - they can decrypt only one block (16 bytes) and compare it to the IV in order to check if the key is correct. (Perhaps there are more attack channels possible which I am unaware of.)

So my question is

Does this plan seem fine, or am is there some pitfall in it?

Improve this question
$\endgroup$
6
  • $\begingroup$ The question as is, seems hard to properly answer. Perhaps an improvement could be adding the fact that the key is not random but derived from what is a low entropy space as you mentioned in your comment to the first answer? $\endgroup$
    – Marc Ilunga
    Commented Nov 25, 2021 at 22:02
  • $\begingroup$ Usually the IV is prefixed to the message. However, the IV doesn't give the attacker any more advantage than any other ciphertext block as that acts as the vector for the next block. This is conveyed by the answer of Fractalice. For any cipher we assume that the attacker can know (part of) the plaintext. As such, hiding the IV doesn't make any difference, it is assumed to be public. $\endgroup$
    – Maarten Bodewes ♦
    Commented Nov 29, 2021 at 21:58
  • $\begingroup$ @MaartenBodewes Usually the IV is prefixed to the message. - The keyword here is "usually". If this were the case in CBC, and no more was done with the IV - my point in the question would be true. I.e. communicating the IV in plaintext would give the attacker an edge in brute-forcing the key. Since the IV is XORd with the plaintext before encryption - that is not the case. As Fractalice's comment implies. $\endgroup$
    – ispiro
    Commented Nov 30, 2021 at 18:23
  • $\begingroup$ You're still misunderstanding. The IV is send and it is XOR'ed with the plaintext before encryption, so it is assumed to be available to an adversary. All modern ciphers should provide protection against even chosen plaintext attacks. This is called IND-CPA: indistinguishability under chosen plaintext attack, and it is provided by most if not all modes of operation except ECB. There is no edge to be gained if the cipher is IND-CPA secure, and brute forcing for AES is completely dependent on the key size - which for AES-256 is definitely ample protection. $\endgroup$
    – Maarten Bodewes ♦
    Commented Dec 1, 2021 at 14:59
  • $\begingroup$ @MaartenBodewes Thanks for the clarification, however, I think I should further clarify what I thought at first (which I now know is wrong). I thought that an IV works like this (in CBC): a) Prepend the IV to the plaintext. b) Encrypt without XORing the first block with anything. If this were in fact the case, there would be no need to send the IV, only to make it random, and the receiver would just decrypt and throw away the first block. Thanks again. $\endgroup$
    – ispiro
    Commented Dec 1, 2021 at 17:46

1 Answer 1

Reset to default
4
$\begingroup$

I didn't fully understand the plan, but:

In CBC, each ciphertext block plays the role of IV for the next block. So, the bruteforce attacker can attack the next block, since the ciphertext block will be send in clear.

Are you really afraid that someone will bruteforce a 256-bit key? This is impossible.

Also, please consider using authenticated encryption to stop active attackers.

Improve this answer
$\endgroup$
6
  • $\begingroup$ the bruteforce attacker can attack the next block - they test a key and receive a result. How do they know that's the correct one? AFAIK AES will just transform 16 bytes into 16 bytes. Always. Never with a failure (except the last one because of padding). Am I wrong? $\endgroup$
    – ispiro
    Commented Nov 25, 2021 at 19:49
  • $\begingroup$ Are you really afraid that someone will bruteforce a 256-bit key? - Not a random key. A key based on an easy-to-remember password which a non-security-minded user chooses (think "password1" etc.). $\endgroup$
    – ispiro
    Commented Nov 25, 2021 at 19:51
  • $\begingroup$ please consider using authenticated encryption - As I mentioned in my question: Authentication is done separately. Ignored here.. $\endgroup$
    – ispiro
    Commented Nov 25, 2021 at 19:51
  • 1
    $\begingroup$ If the attacker does not know anything about plaintext, how could you test the first block with plaintext IV? Note that the first ciphertext block decrypted is IV xor message, so the attacker just gets a message candidate on each key guess. And, as you noticed - the last block often has known plaintext - padding, which allows to to such bruteforce in the end. $\endgroup$
    – Fractalice
    Commented Nov 26, 2021 at 8:33
  • $\begingroup$ Thanks. I was misled by tutorials which say that the IV is simply prepended to the plaintext. If that were the case, my worry would be founded. As it is, the IV is XORd with the first block instead (in CBC) which solves that problem. Thanks again. $\endgroup$
    – ispiro
    Commented Nov 30, 2021 at 18:25

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.