# Is the Java function AES/CBC/PKCS5Padding vulnerable to padding oracle?

I have an application that stores data on the devices. Currently AES/CBC/PKCS5Padding from javax.crypto.Cipher(see reference) is used to encrypt the stored data.

The padding isn't verified manually. Does that make the process vulnerable to Padding Oracle attacks?

Would the process benefit from using AES/GCM?

• In addition to what @kelalaka wrote below, one other consideration with GCM is that it has a limit to the amount of data that can be encrypted with a single key/IV pair of about 64 GB. After that you lose the ability to guarantee data integrity. That may or may not an issue in your situation. Aug 7, 2019 at 17:34
• This is just CBC mode with PKCS#7 padding. I don't get the question; if your specific system allows a padding oracle to exist then yes, it is vulnerable, otherwise no. I'm mentioning this specifically since quite often, padding oracle attacks are not possible when data is encrypted at rest. Furthermore, if the device is hacked then the attacker may also be able to get to the key (or use the key). Aug 15, 2019 at 23:41

## 2 Answers

The problem with CBC mode is the padding. When there is a padding error, the server must respond to a message back to you so that you can send the message back again or encrypt the message from the beginning.

The padding oracle attack is solely based on this idea. The attacker changes the byte and looks at the response of the server to execute the attack.

As we can see the attacker needs an oracle to execute the padding oracle attack. Data on-rest or encrypted databases has no oracle. Therefore they are not vulnerable to padding oracle attacks.

CBC mode has no integrity and authentication like all basic (archaic) block cipher mode of operations and it is usually used with HMAC. CBC is removed from TLS 1.3. We can see a good reason in a 2019 work.

AES-GCM which is in TLS 1.3 has an authenticated encryption scheme that provides both integrity and authentication. The internal GCM mode uses CTR mode for encryption that requires no padding. Therefore padding oracle is not applicable.

So in short, in GCM mode you will have

1. Integrity
2. Authentication, and
3. No padding which is vulnerable to padding oracles.

Since you are going to use AES/GCM your next issue will be the IV. Instead of random IV, you can use incremental IV so that you can mitigate IV Reuse catastrophe. For more information on IV recommendations see section 8 of NIST-800-38D

In Java, you can use AES/GCM/NoPadding from javax.crypto.Cipher package.

• In summary of kelalaka's answer: yes AES/CBC/PKCS5Padding can create a vulnerability to Padding Oracle attack. The modern, safe option is authenticated encryption, e.g. AES/GCM/NoPadding in modern javax.crypto.Cipher.
– fgrieu
May 5, 2021 at 17:47

Yes - any system that uses and mode of operation that requires unpadding could be vulnerable to padding oracle attacks.

But even if the implementation isn't vulnerable to padding oracle attacks: padding oracle attacks are only a subclass on plaintext oracle attacks. If the attacker has information on the plaintext and is able to generate some kind of response that data handling fails in a particular way after decryption, then you'd still have a problem.

This is why authenticated encryption is so important if you have some kind of service (i.e. Oracle) that performs the decryption. That way the authenticity of the message is validated (to originate from somebody who has the established key) before it is decrypted or handled.

This is all moot for data at rest or if the attacker cannot learn anything from the decryption of the message, or if the attacker can only eavesdrop. In that case there is no oracle, and thus this kind of attacks do not apply. It could still make sense to verify integrity for other reasons of course, so defaulting to authenticated encryption is generally a good idea.