Join Log in
Score:1
avatar Crypto

Is it okay to avoid a plaintext IV in AES?

ke flag
ispiro

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?

106
0 + 0
aes
Marc Ilunga avatar
tr flag
Marc Ilunga
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?
0
Reply
Maarten Bodewes avatar
in flag
Maarten Bodewes
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](https://crypto.stackexchange.com/a/96314/1172). 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.
0
Reply
ke flag
ispiro
@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.
0
Reply
Maarten Bodewes avatar
in flag
Maarten Bodewes
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.
0
Reply
ke flag
ispiro
@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.
0
Reply
Maarten Bodewes avatar
in flag
Maarten Bodewes
There is not much difference in the normal use of the IV, the only difference is that the actual IV is now the *encrypted* IV. It's actually used sometimes to randomize a counter value so the IV is unpredictable to an adversary. Knowing the IV or not doesn't matter, but for CBC an unpredictable (pseudo-) random IV is required. *Preferably* the IV would be encrypted with a different key though. Note that the plaintext could well be all zeros, and since the attacker knows any encrypted block in advance (which is public but unpredictable), leaking the IV would still not make a difference.
0
Reply
Score:4
Fractalice avatar Crypto
in flag
Fractalice

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.

0 + 0
ke flag
ispiro
`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?
0
Reply
ke flag
ispiro
`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.).
0
Reply
ke flag
ispiro
`please consider using authenticated encryption` - As I mentioned in my question: `Authentication is done separately. Ignored here.`.
0
Reply
Fractalice avatar
in flag
Fractalice
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.
1
Reply
ke flag
ispiro
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.
0
Reply
Fractalice avatar
in flag
Fractalice
@ispiro IV is indeed sent in clear, which is the "IV" for the first block. The "IV" for the second block is the first ciphertext block, which is also sent in clear. CBC is designed like that, and there's no problem with that. It just must be unpredictable.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.