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.

  • Both archaic use authentication modes like AES-GCM.
    – kelalaka
    Jan 10, 2020 at 2:36
  • @kelalaka Many thanks for the comment. Perhaps I should have been clearer in formulating my question, so I have now added some context, please see the updated post. I am not asking which algorithms are the best ones to use nowadays, but I am asking specifically whether the algorithms mentioned in my question can still be considered as secure from today's perspective. Jan 10, 2020 at 10:21
  • 1
    It's a red flag, but there might be a legitimate reason to see one of those modes in a project's source. There might be some protocol involved which mandates the use of dangerous algorithms and/or modes. (I want to stress that just because that might be the case, it doesn't mean code that uses these modes isn't broken most of the time. Safe use of ECB or CBC should be considered exceptional, especially since they're unauthenticated. Legacy support of weak algorithms when it's optional is also a really bad idea because it may enable downgrade attacks.) Jan 13, 2020 at 19:28

2 Answers 2

  • 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 243 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.

  • RSA PKCS1v1.5 encryption is inherently hard to use securely and should not be used (see: Bleichenbacher and Manger attacks coming out again and again). But RSA PKCS1v1.5 signature and RSA OAEP encryption are fine. You can use PSS and KEM instead, but you don't have to. Jan 10, 2020 at 12:28
  • @Gilles'SO-stopbeingevil' I didn't want to go so deep. But you wrote I'll. Thanks for the comment. Do you know a security proof of PKCS1v1.5 encryption?
    – kelalaka
    Jan 10, 2020 at 12:32
  • I'm not aware of a proof for v1.5 encryption or signature. Jan 10, 2020 at 12:36
  • 1
    RSA doesn't actually use any mode, but the Java crypto API uses the 3-part algorithm/mode/padding in all cases, so they use 'ECB' as a dummy place-filler 'mode' for RSA. 'None' would indeed be bettter semantically, but the 'standard' (at least default) Java provider doesn't support it. If you install and use BouncyCastle instead, bcprov does accept 'None'. Jan 11, 2020 at 10:22
  • 1
    – kelalaka
    Jan 13, 2020 at 20:04

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .