2
$\begingroup$

From ISO/IEC 23001-7:2012/Amd 1:2012 10.2.2 Creation of Initialization Vector (Informative)

Decryption efficiency may be improved if subsequent initialization vectors use the value of the last cipher block at the end of the previous sample so that multiple samples may be decrypted as continuous chain.

The algorithm is AES-128-CBC.

My question is: Can this really be true?

My understanding of efficiency is decryption time. For each group of blocks where a new IV would be needed the only reduction in time would be the read time of the IV (assuming the last block is kept in memory to be used as IV). But this reduction would so small in comparison to the read+decryption time of the actual blocks that I wouldn't even mention it.

The size on the other hand would be reduced as many IVs are not needed. But this depends on how many blocks are in each sample.

Improve this question
$\endgroup$
2
  • $\begingroup$ This technique is responsible for the famous BEAST attack against TLS. $\endgroup$
    – CodesInChaos
    Commented May 25, 2014 at 9:25
  • $\begingroup$ @CodesInChaos Good point, but wouldn't this be infeasible for such high payloads as AVC video streams? I've seen the video of the BEAST attack demonstration. It doesn't look that fast for one byte at a time, but it might be parallelizable. $\endgroup$
    – Artjom B.
    Commented May 25, 2014 at 10:25

1 Answer 1

Reset to default
3
$\begingroup$

Well, if you have hardware which you can give it a long ciphertext block, and say "decrypt this block in one shot", well, one could argue that reusing the last ciphertext block as the next IV might give some minimal amount of gain; you would concatinate all the ciphertexts in order, and ask for the hardware to decrypt the entire thing -- the result will be the plaintexts all concatinated. On the other hand, even if you used independent IVs, you could concatinate the blocks as series of [IV, ciphertext blocks] vectors, and so you could still use your fancy hardware to decrypt it all in one shot.

However, arguing about minor efficiency gains misses a larger point -- it is known that generating IVs this way (or in any way where the next IV can be predicted by someone in the middle) can cause cryptographical weakness; that is, someone who can insert their own text can game the system to decrypt low entropy (that is, mostly guessable) texts. In case you think this is an entirely theoretical attack, well, this is precisely how the Beast attack worked in SSL.

Now, I don't know where an attacker can plausibly inject chosen plaintext into the encryption stream; however it strikes me as likely enough to reject this rather minimal performance gain.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ +1 I was already guessing while reading the question if that there may be an issue with using the IV in such a way. Even if the RNG is slow, you could always supplant that with a good PRNG, so there is not much of a performance enhancement in that regard either. $\endgroup$
    – Maarten Bodewes ♦
    Commented May 24, 2014 at 22:31

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.