# Security of AES after key expansion 4-MB with ECB and CBC

My question is,

• how does the security depend or change if I encrypt with AES-128 in total 4-MB of Data?

1. With Electronic Code Book Mode and
2. Cipher Block Chaining Mode ?
3. Does an adversary still need $$2^{126}$$ tries (like Wikipedia suggests) to guess the key or is it less (which in my opinion it should)?

The encrypted data would be a videostream.

A videostream should probably not be encrypted with either ECB or CBC.

ECB is insecure for almost anything and it should not / can not be used to turn a block cipher in a secure cipher. This is clearly shown even in the Wikipedia description of the mode: find the penguin.

CBC is secure to keep data confidential. It is, however, susceptible to padding oracle attacks when not used correctly - especially in real time communication. It also doesn't allow e.g. caching of the key stream or parallel encryption, so the performance may be subpar as well. And although it does support seeking, it does require the user to retrieve the ciphertext block before the one that needs decryption.

This is why commonly CTR mode is used instead. Sometimes CTR mode is used in combination with a MAC to offer fast authentication and integrity of the ciphertext. , e.g. GCM mode. GCM mode, however, does undo some of the benefits of CTR mode.

However, probably the most common methods of wrapping a stream is to perform TLS. It does have some overhead, but at least well reviewed implementations exists. It depends if it fits your need.

The amount of tries to get to the key will always be in the neighborhood of $$2^{127}$$ tries for a (largely) unbroken cipher such as AES. The key is protected by the block cipher itself, rather than the mode of operation.

However, the security of the key only is only part of the security of the cipher. It is perfectly possible for a mode of operation to leak information on the plaintext even if the key is kept perfectly secure. The ECB penguin is a prime example of that. Another is CTR mode with a repeated IV, which turns the cipher into a "many-time pad".

• If a new key generated for every video stream (file), does ECB still problematic? – kelalaka Nov 27 '18 at 14:13
• @kelalaka Yes. Unless you have one key per 16 byte block ECB is always problematic. (Of course if you have one key per 16 byte block you just doubled your data size.) – DRF Nov 27 '18 at 14:25
• @kelalaka Have you looked at the penguin? That Maarten linked to? – Martin Bonner Nov 27 '18 at 15:05
• @MartinBonner I know the problem years ago. My point, in a video almost all of the data will be different. It will not reveal a pattern. Then, the passive attacker can perform, if knows the video file, only a known-plaintext attack. Since we know that AES secure against KPA, and if I change the AES key for every file, what is the problem? – kelalaka Nov 27 '18 at 15:17
• @kelaka: "My point, in a video almost all of the data will be different. It will not reveal a pattern" I'm not in the slightest bit convinced that is true. I would suggest that using CBC, CTR, or GCM is no more complicated than using ECB, and it saves having to have a long discussion with your reviewer about why it is safe it this case. – Martin Bonner Nov 27 '18 at 15:22