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. – Swashbuckler Aug 7 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). – Maarten Bodewes Aug 15 at 23:41

The problem with CBC mode is the padding. When there is a padding error, the server must response a message back to you so that you can send the message back again or encryption 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.

CBC mode has no integrity and authentication and removed from TLS 1.3.

AES-GCM which is in TLS 1.3 has an authenticated encryption scheme which provides both integrity and authentication. In 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