# ECB vs. CBC, I've seen the pictures, but what's the actual strength difference?

I hope that this is not a duplicate because I'm looking for nuance. I understand the difference between ECB and CBC for a block cipher, and I understand that ECB is susceptible to replay attacks, but my question is just from the standpoint of strength. If I have cipher that has 256-bit key and 128-bit data that is used to encrypt a file on a disk, the mathematical complexity does not increase between CBC and ECB for cracking the cipher? I read a lot of answers saying "ECB is insecure", but there's a difference in theory and practice. I expect to only have 1k 128-bit blocks.

I have an extremely power constrained system, and I'm trying to determine if the 10% overhead required for CBC over a ECB architecture matters from the standpoint of security. The reason is that if I do have a significant gain using CBC over ECB, perhaps I should just use a smaller cipher size because I'd basically be trading up circuits.

Any suggestions from the engineering perspective would be appreciated.

• If you use ECB there are a few issues: a) An attacker can find duplicate blocks, b) an attacker can re-arrange blocks (if no other means of authentication is used), c) because of a) you'd have to guarantee there won't ever be duplicate 128-bit blocks.
– SEJPM
Dec 28 '16 at 14:42
• @SEJPM I just never got a good feel for if they are just academic concerns. I can image the issues for a small block size and leaking information. If I have many duplicate blocks at 128-bits, does it really matter? It's still a large space to brute force. Has anyone actually succeeded in an attack? Dec 28 '16 at 16:02
• You may have to clarify your use case before actual security differences can be qualified. For example, suppose you were encrypting 128-bit long serial numbers that are guaranteed to be unique - does the fact that duplicate blocks encrypt identically matter in such a situation? In the general case, CBC is clearly more secure then ECB as it will tend to leak less information - whether or not this information leak is relevant could be a matter of use case, and whether or not it is worth paying for is also a matter of use case. Usually it's worth paying for, but there could be edge cases. Dec 28 '16 at 17:33
• If you have seen the famous Tux picture, you see how ECB can leak information by just looking at the encrypted data, without the security of the underlying cipher ever coming into play. If that doesn't convince you, I don't know what will... Apr 8 '17 at 22:16
• @fkraiem that is a fine example, but terrible in the context of my problem. They are different comparisons. I could use any matrix kernel and get the same results from the perspective of image processing. If I had 1k entries of uniform data, you could not guess the key or original data. In the Tux case, you know the picture. If I give you 1k entries of 128-bits, that's a very small search space. I you take a 100x10 pixels down Tux, it is unlikely you'd know that it is a penguin. The challenge that I have is space constraint, and it's actually a $100M question. Apr 8 '17 at 22:33 ## 1 Answer There is no good way to calculate a strength difference between ECB and CBC. ECB is broken as a generic cipher - it is not indistinguishable under chosen plaintext attack - as repeating blocks will confer information to an attacker. That particular piece of information doesn't let itself be quantified compared to the amount of bits within the key. It's even completely separate from the key size by definition (AES-256-ECB will be as broken as AES-128-ECB). CBC with a static IV is vulnerable for the first blocks that could be identical. CBC with a predictable IV is vulnerable as well. However CBC - when used correctly - is secure for confidentiality of data at rest. The key stays protected by the block cipher itself. If that's "cracking the cipher" then any mode is OK. However, the key only exists to protect the confidentiality of the plaintext. And if that is compromised the security of the system is compromised. So the security of the cipher is inconsequential. Side note: replay attacks can happen in transport security. They can happen even if the ciphertext is authenticated. Replay attacks have little to do with ECB or CBC mode as neither is a good fit - on its own - for transport mode security. ECB mode is simply susceptible to repetition of plaintext blocks; that's different from replay attacks. • Your comment on "cracking the cipher" was basically what I was looking for and you cleared up where I was sloppy between repetition and replay attacks. The practicalities of the problem that I am wrestling with is that "does it make sense to require more than$10 of computing power to protect a \$10 t-shirt" in the sense of inventory. Most of what field of cryptography would suggest does not actually work in the realties of companies due financial constraints. Apr 9 '17 at 14:48
• How much information is leaked by ECB depends on how the cipher is used. But with regards to the cost of attacks just finding a duplicate ciphertext can be pretty cheap and should be considered within range to anybody with just a grain of cryptoanalytic knowledge. In the absolute worst case scenario you could say that it provides zero bits of security if you look at it that way. Apr 9 '17 at 15:18
• E.g. imagine two blocks of ciphertext, both the encryption of "Yes" or "No" (plus deterministic PKCS#7 padding). You know that the first one encrypts "Yes", but you don't know the second one. However, the other ciphertext is identical to the first one. They you can say with absolute certainty that the second plaintext message is also "Yes", so ECB or CBC without an IV provides no confidentiality whatsoever in that situation. Feb 2 '19 at 17:16
• Considering the constraints, I decided that it does not matter. 1k of data is so small, and it doesn't matter what the message is in this case because I know that my data stream will never repeat. If a cipher with 128-bit blocks can reveal after 8 transfers, it is effectively broken. Feb 3 '19 at 0:44
• That's of course fine for specific circumstances. But beware, I've seen e.g. RSA private keys encrypted with ECB. As RSA keys are however embedded in a structure, it is still easy to leak at least parts of keys. Anyway, I just saw that some info was missing after forest changed the question. Old stuff :) Feb 3 '19 at 0:47