Are ECB and CBC modes of operation generally insecure?

Question

In some Java code that I'm reading, I stumbled over the following encryption algorithms passed to the Cipher.getInstance(...) method:

• AES/CBC/PKCS5Padding
• DESede/ECB/PKCS5Padding
• RSA/ECB/PKCS1Padding

Note: In the Java model, the first substring represents the cipher, the second the mode of operation, and the third the padding scheme.

Now, I believe that ECB is generally insecure (independently of the used cipher / padding scheme), because it preserves the structure of the plaintext.

In addition, I also read that CBC can be insecure, depending on the implementation. More precisely, if the implementation is written in such a way that it is revealed whether some given ciphertext was correctly padded or not, then this can be exploited to decrypt encrypted messages. In the case of Java, the problem is that different platforms / Java implementations / crypto providers are available, so it's hard to tell in general whether using CBC as a mode of operation is fine.

That leads me to think that all three of the above algorithms are potentially insecure. But perhaps I'm overestimating the problems of ECB / CBC, and they can be used in a secure way?

Hence the question: Can/Should the above algorithms be considered as secure or not, and why?

Update: To provide some more context, the code I'm referring to is the OWASP Benchmark. This benchmark consists of thousands of test cases, some of which intentionally contain actual vulnerabilities, while others intentionally contain "fake" vulnerabilities (i.e., code that looks like it might be vulnerable but actually isn't). Some of the test cases labeled as "fake vulnerabilities" encrypt some text using one of the three algorithms mentioned above. Since OWASP considers these as "fake vulnerabilities", that implies that OWASP considers these algorithms as safe, which surprised me. I'm wondering whether OWASP is right in considering these algorithms as safe, or whether these test cases in the OWASP Benchmark really ought to be labeled as "actual vulnerabilities" rather than "fake vulnerabilities".

An example of such a "fake vulnerability" test case in the OWASP Benchmark is the test case 54, which encrypts some data using AES/CBC/PKCS5Padding, but is labeled as not being vulnerable to CWE 327: Use of a Broken or Risky Cryptographic Algorithm.

Answer 1

• DESede/ECB/PKCS5Padding

• DES is already broken^* and Triple DES was created to use until a new cipher is developed, Rijndael selected in 2000 and called AES.

• The block size of DES or TDES is 64-bit and this is insecure, see Sweet32.

• ECB mode for block ciphers, forget about it. It is not even a mode of operation. It reveals a pattern in your data. See the penguin on Wikipedia. In some cases you may need it like equality queries in DB, however, it still can leak information, see How can frequency analysis be applied to modern ciphers?

• PKCS5Padding See in the next section.

• AES/CBC/PKCS5Padding

• AES is a block cipher and is supposed to be a pseudorandom permutation. It can achieve IND-CPA or IND-CCA or Authenticated Encryption (AE) by using the appropriate mode of operation together with AES (CBC,CTR has Ind-CPA and GCM has AE). AES is still secure after more than 20 years

• CBC mode requires an IV and that is needed to be not only unique but also must be unpredictable

• PKCS5Padding is vulnerable to padding oracle attacks. Actually, Encrypt -than-MAC can solve this issue.

• RSA/ECB/PKCS1Padding

• RSA is not meant for encryption. It can be used for signatures with PSS padding or Key encapsulation mechanism like RSA-KEM with Data Encapsulation Mechanism. Composition of a KEM and a DEM provides the standard of IND-CCA2/NM-CCA2—ciphertext indistinguishability and non-malleability under adaptive chosen-ciphertext attack if an authenticated encryption mode is used like AES-GCM, ChaCha20-Poly1305, or crypto_secretbox_xsalsa20poly1305
• ECB has no meaning here. It doesn't implement ECB. None is better here.
• Here the PKCS1Padding indicates RSA with PKCS#1 v1.5 padding for encryption. There are at least 8-byte makes this padding probabilistic, i.e. if you encrypt the same text you will get a different ciphertext.

Using RSA PKCS#1 v1.5 encryption securely is hard and one should not be used to. There are Bleichenbacher's attack and its variants on PKCS#1 v1.5 padding. Also, there is no security proof of it, but Optimal Asymmetric Encryption Padding (OAEP) has been proven secure in the random oracle model. If you want to encrypt you should OAEP it, but better not to use it. Prefer the Hybrid Encryption.

###Short conclusion

None of the above-listed modes is preferred today. In TLS 1.3 now we have only authenticated encryption modes.

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256

CBC, gone, TDES no more, all static RSA and Diffie-Hellman suites are removed.

Stay with the recommendations. In modern Cryptography we want

• IND-CCA2/NM-CCA2—ciphertext indistinguishability and non-malleability under adaptive chosen-ciphertext attack

Therefore you need authenticated encryption modes.

---

_{^*The linear attack of Matsui is faster than brute-force with 2⁴³ known-plaintext. Matsui implemented this. This is a major attack on a cipher. In practice, the brute-force is the way to break the DES since 1997. So we can say DES is not adequate for modern hardware. Sweet32 on the other hand an attack works on any 64-bit block cipher. The 50% advantage is way too high for an adversary to wait for an attack. In practice, they can work for even 0.1% probability for their advantage, though this doesn't reveal the key. Remember that the first aim of an adversary to an encryption scheme is revealing the messages, not the key.}

Answer 2

In short: The ECB mode is very insecure, the CBC mode alone also in many cases, but it can be supplemented (MAC) and thus become secure.

About ECB mode: The plaintext is encrypted in blocks, whereby the blocks are independent of each other. As a result, identical plaintext blocks result in identical ciphertext blocks. So you can identify by the ciphertext alone, where the same blocks exist. This weakness is especially easy to see in the encryption of images (see this example).

About the CBC mode: In a server architecture, plaintexts often can be successfully decrypted using so-called padding oracle attacks. This depends on the implementation. ( see: Wikipedia).
Another attack (not in the server scenario) is a targeted manipulation of the encrypted text, if you have assumptions about the plaintext. For example, if you assume that the plaintext is "Pay Beloumi 100$", then you can change it to "Pay Beloumi 999$" without the person concerned being able to recognize the manipulation. This weakness can be eliminated by an additional MAC, but it is easier and less error-prone to use an authenticated encryption mode like EAX or CCM right away.