Efficiency of chaining AES "groups" of blocks 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.
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.