Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
This technique is responsible for the famous BEAST attack against TLS. – CodesInChaos May 25 '14 at 9:25
@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. – Artjom B. May 25 '14 at 10:25
up vote 3 down vote accepted

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.

share|improve this answer
+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. – Maarten Bodewes May 24 '14 at 22:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.