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

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.

• Scalable Scanning and Automatic Classification of TLS Padding Oracle Vulnerabilities by Merget et. al.

  They scanned the top 1M sites and conclude that CBC with MAC-than-Encrypt is hard to implement securely. They find 93 different vulnerabilities. Their

• Github page; TLS Padding Oracles

• Code page; TLS-Attacker

• Video WAC2-2019

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.

Solved by user18298 (43,162 )
Aug 07, 2019 at 08:07