3

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.

Malte Skoruppa
  • 133
  • 1
  • 7
  • Both archaic use authentication modes like AES-GCM. – kelalaka Jan 10 '20 at 02: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. – Malte Skoruppa Jan 10 '20 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**.) – Future Security Jan 13 '20 at 19:28

2 Answers2

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.

kelalaka
  • 5,409
  • 4
  • 24
  • 47
  • 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. – Gilles 'SO- stop being evil' Jan 10 '20 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 '20 at 12:32
  • I'm not aware of a proof for v1.5 encryption or signature. – Gilles 'SO- stop being evil' Jan 10 '20 at 12:36
  • @Gilles'SO-stopbeingevil' There is one for signature, [On the Security of the PKCS#1 v1.5 Signature Scheme](https://eprint.iacr.org/2018/855.pdf) – kelalaka Jan 10 '20 at 12:37
  • 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'. – dave_thompson_085 Jan 11 '20 at 10:22
  • Thank you for the detailed answer and the provided links. It is pretty much what I expected: The mentioned algorithms are not secure. I have one more question concerning "RSA/ECB/PKCS1Padding" (resp. "RSA/None/PKCS1Padding", which is the same but better named) before I accept the answer. In your answer you're basically implying that "PKCS1Padding" refers to PKCS#1 v1.5, which is insecure (Bleichenbacher's attack). Yet OAEP is PKCS#1 v2, so couldn't "RSA/None/PKCS1Padding" actually refer to PKCS#1 v2, i.e., OAEP-RSA, which is secure? – Malte Skoruppa Jan 13 '20 at 18:18
  • @MalteSkoruppa There is no security proof for PKCS#1 v1.5 padding, OAEP-RSA has a security proof. As long as they are not correctly implemented, there are no attacks. As said by Gilles, RSA PKCS1v1.5 is hard to use and should not be preferred. I'll update with some links. – kelalaka Jan 13 '20 at 18:32
  • Yes I understand that there is no security proof for RSA with PKCS#1 v1.5 and that there is a security proof for OAEP-RSA (PKCS#1 v2.0) in the random oracle model. My point is: Both of these are specified in PKCS#1, only in different versions, right? See [here](https://en.wikipedia.org/wiki/PKCS_1). So what do I get when I specify "RSA/ECB/PKCS1Padding" in Java? Is it PKCS#1 v1.5, or is it PKCS#1 v2? In your post you say "the PKCS1Padding indicates RSA with PKCS#1 v1.5 padding for encryption", but are you sure of that? I would have expected modern Java to implement the current version (v2.2). – Malte Skoruppa Jan 13 '20 at 19:59
  • 1
    In Java OAEP is called like `RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING. See here [breaking down RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING](https://stackoverflow.com/q/32161720/1820553) – kelalaka Jan 13 '20 at 20:04
  • "RSA/OAEP has been proven secure ... but better not to use it." What kind of attack could be successful? – Sam Ginrich Feb 11 '22 at 18:51
  • @SamGinrich it is not about attacks it is about performance. In cryptography, we prefer Hybrid encryption in which public key cryptosystems are used for key transfer/exchange like RSA-KEM, DHKE, and the resulting transferred/exchanged key material applied to a KDF then it is used for the key for symmetric key encryption. – kelalaka Feb 11 '22 at 21:03
  • @kelalaka Thank you. That's why I don't consider this community as one, following the scientific protocol "Security is about performance" ... – Sam Ginrich Feb 12 '22 at 08:46
  • @SamGinrich It is your point of view. Public key algorithms are magnitude slower than symmetric key algorithms. You can test on OpenSSL's speed command. AES-NI can output Gigabits/s. Although, [Fast doesn't mean secure](https://crypto.stackexchange.com/q/75408/18298) these are years of experience of the Cryptographers. You can use [RSA-KEM for key encapsulation](https://crypto.stackexchange.com/a/76857/18298) then encrypt with a symmetric algorithm like AES-GCM or XChaCha20-Poly-1305 to achieve DEM. Could you tell me on a real cryptographer advises you to encrypt messages/files with RSA? – kelalaka Feb 12 '22 at 11:36
  • DES is not broken; it's merely inadequate (in terms of key strength) to resist modern hardware. In other words, there's no way without the key to decrypt the data without brute force - that's what "broken" means in cryptography - but it's possible to brute force (unlike ciphers with longer key lengths). Also, you didn't explicitly say otherwise, but "DESede" *is* TDES (triple DES, encrypt-decrypt-encrypt), although it does matter whether two or three unique keys are used. – CBHacking Feb 12 '22 at 22:03
  • @CBHacking In Cryptographic terms, it is broken, Matsui's linear attack was not envisioned by the NSA (they were aware of Differential attack) is the attack that has less time than brute-force. It is one of the successful attacks on a cipher that we have. The data was higher, so in practice, one prefers the brute-force. The Sweat32 attack on the other hand is much more devastating on the large messages for any block cipher that has a 64-bit block size. The 50% calculation is too high for an adversary, far from negligible. Well, DES has bruteforce in 1997. – kelalaka Feb 12 '22 at 22:24
  • It was designer bad choice about not producing 64-bit key size. I've used 3DES as a bundle. It was a patch before having AES, nothing more. – kelalaka Feb 12 '22 at 22:26
0

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.

BeloumiX
  • 246
  • 1
  • 5