I was thinking about this today and thought I should ask. I think I understand IV's enough to say that they are basically the same thing as Salts when talking about hashes. They are there to improve randomness between messages. If the IV is simple appended, or prepended to the plain text, why does AES need to know the IV to decrypt it? Can't it just decrypt it, drop the first x amount of bytes and then it has the original plaintext or does AES do some special jizz-jazz with the first bytes in the stream?
$\begingroup$
$\endgroup$
8
-
2$\begingroup$ This can pretty much be answered trivially by reading the relevant Wikipedia article. Note that attempting decryption without the IV is the logical equivalent of trying to compare a password against a salted hash, without having access to the salt. $\endgroup$– Stephen TousetApr 8, 2013 at 5:50
-
$\begingroup$ I never understood exactly what CBC was doing tho. Did it take the unencrypted previous block as the IV for the next, or the encrypted previous block as the IV for the next? $\endgroup$– jduncanatorApr 8, 2013 at 5:52
-
$\begingroup$ In fact that Wikipedia article confirms what I said. If the IV is the same length, and is prepended or appended to the plaintext, then you could simply strip those bytes off the end or from the front after decryption. The only reason the decryptor needs the IV (by the looks of that article) is to know what bytes to strip! $\endgroup$– jduncanatorApr 8, 2013 at 5:54
-
1$\begingroup$ Look at the images. The previous ciphertext block is always used as the "IV" for the next block, both during encryption and decryption. The initialization vector acts as the first "previous block" when none would otherwise be there. $\endgroup$– Stephen TousetApr 8, 2013 at 5:54
-
4$\begingroup$ The IV is not prepended to the plaintext. It is XORed against the plaintext block, as the second sentence in that section clearly states. When you decrypt the first ciphertext block, you now have a message that was XORed against the IV; good luck retrieving the original message if the IV is unknown. $\endgroup$– Stephen TousetApr 8, 2013 at 5:55
|
Show 3 more comments
2 Answers
$\begingroup$
$\endgroup$
3
The initialization vector is XORed against the first plaintext block before encryption in CBC mode, as shown in the Wikipedia article on block cipher modes. After the first block is decrypted, you still have an intermediate value which has been XORed with the plaintext — without this, you have little hope of recovering the plaintext. However, you do not need the IV to decrypt subsequent blocks.
You could perform CBC in a way that would remove the need to know the initialization vector (note: this is not recommended or encouraged, just pointing it out for the novelty). If you use a null IV and use a random value for the first block of plaintext, you can discard this value and only transmit the ciphertext. Note that this actually gains you nothing, because now the ciphertext is one whole block longer!
answered Apr 8, 2013 at 6:02
-
$\begingroup$ The only problem with using a null IV and and random value for the first block of plain text, if done consistently, is that you get one extra unnecessary block cipher operation. The end result is indistinguishable from using a random block as the first cipher text block. $\endgroup$ Apr 8, 2013 at 7:11
-
$\begingroup$ In effect the XOR of the first random block with null (ie the first random block) becomes your IV. $\endgroup$– AronAug 12, 2015 at 3:01
-
$\begingroup$ The ciphertext is 1 block longer, but the transmitted message is the same length (assuming you're appending/prepending the IV to the message such that the recipient can decrypt it). In this mode (junk first block) the IV becomes irrelevant during decryption, but still ensures encrypting the same plaintext with the same key will result in different ciphertext. $\endgroup$– mkstJul 23, 2020 at 8:06
$\begingroup$
$\endgroup$
1
I agree. For my purposes I've been prepending the plaintext with a block of random data so that when the receiver decrypts they simply discard the first block as it was only there to ensure the ciphertext always changes even if the plaintext payload was the same (not counting the first random block). This seems to achieve what the initialization vector was doing from the beginning without the need to send the initialization vector with the ciphertext. IE it can be ignored.
It is recommended that an Initialization vector be random and used only once meaning it will some how need to be send to the receiver which seems identical to the proposal of generating a random first block of plaintext and discarding it after decryption.
-
$\begingroup$ You are sending the IV with the ciphertext — you've simply made the ciphertext longer by the size of the IV and conducted an extra block cipher operation in the process. $\endgroup$ Nov 15, 2017 at 21:05