# AES-CBC with zero IV and a unique first block [duplicate]

Is it safe to generate the IV for AES-CBC as the following?

1. It's like the real IV is all zeros.
2. The first block of data will be a low-entropy but unique data.
3. Once the first block is encrypted, the ciphertext will look like a random sequence of bytes that will automatically serve as IV of the second block

This would allow to save space since we don't have to store a "real" IV in addition to the low-entropy data of the first block that we need to store anyway.

Is it safe to to this thing?

## marked as duplicate by Gilles 'SO- stop being evil', AleksanderRas, Squeamish Ossifrage, Maeher, Maarten Bodewes♦ aes StackExchange.ready(function() { if (StackExchange.options.isMobile) return; $('.dupe-hammer-message-hover:not(.hover-bound)').each(function() { var$hover = $(this).addClass('hover-bound'),$msg = $hover.siblings('.dupe-hammer-message');$hover.hover( function() { $hover.showInfoMessage('', { messageElement:$msg.clone().show(), transient: false, position: { my: 'bottom left', at: 'top center', offsetTop: -7 }, dismissable: false, relativeToBody: true }); }, function() { StackExchange.helpers.removeMessages(); } ); }); }); Oct 25 at 11:08

If the IV is all zeroes, then you basically have ECB for the first block. Basically you're proposing to use this first block's encryption as the IV for the second block. You're implying that the first block will always be unique, but low entropy, which sounds like a counter or time stamp. There are attacks when the IV is predictable, and while this is a step away from that, it may still be useful information for an attacker.

This essentially amounts to an encrypted nonce, which NIST says (pdf, Appendix C) is an acceptable way to generate an IV for CBC:

There are two recommended methods for generating unpredictable IVs. The first method is to apply the forward cipher function, under the same key that is used for the encryption of the plaintext, to a nonce. The nonce must be a data block that is unique to each execution of the encryption operation.

The nonce must not be controllable by the attacker (or they could make it depend on previous ciphertext, even if IV collisions were prevented), but other than that it should be fine.

No. ​ An adversary who knows a ciphertext and one of its plaintext blocks p can trivially find the corresponding xored-plaintext x. ​ Since block ciphers with fixed keys are bijections, if there is
a previous plaintext block then x has at least as much entropy as that previous plaintext block.
(In particular, x can very easily be different from your other first blocks of data.)
However, the adversary would have seen the raw-block-cipher encryption of x
(it's the ciphertext block corresponding to p), and so can tell whether or not a
given ciphertext has x as its first block of data. ​ Furthermore, if they can get x to
be one of your first blocks of data, then they can proceed as in the BEAST attack.

On the other hand, your approach would work if your first blocks of data are
each chosen in a way that does not use any of previously-produced ciphertexts.
(Sketch: ​ By induction, each ciphertext block will be computationally unpredictable,
so the probability of the xored-plaintexts repeating will be negligible.)