ffang commented on code in PR #1645:
URL: https://github.com/apache/cxf/pull/1645#discussion_r1453523233
##########
rt/rs/security/jose-parent/jose/src/main/java/org/apache/cxf/rs/security/jose/jwa/AlgorithmUtils.java:
##########
@@ -65,7 +65,7 @@ public final class AlgorithmUtils {
public static final String A256GCM_ALGO = "A256GCM";
// Java
public static final String AES_GCM_ALGO_JAVA = AES + "/GCM/NoPadding";
- public static final String AES_CBC_ALGO_JAVA = AES + "/CBC/PKCS7Padding";
+ public static final String AES_CBC_ALGO_JAVA = AES + "/CBC/PKCS5Padding";
Review Comment:
IIUC, "PKCS7Padding" is only available from BouncyCastle provider, in JDK
default security provider, we need to use the name "PKCS5Padding" instead, but
this doesn't mean that JDK default provider doesn't support "PKCS7Padding"
since AES which is supported by JDK default provider actually requires
"PKCS7Padding". So in JDK default security provider, "PKCS5Padding" is a
legacy name convention which also covers "PKCS7Padding" if I read a few related
discussions correctly.
For example, this one here
https://crypto.stackexchange.com/questions/9043/what-is-the-difference-between-pkcs5-padding-and-pkcs7-padding
```
Many cryptographic libraries use an identifier indicating PKCS#5 or PKCS#7
to define the same padding
mechanism. The identifier should indicate PKCS#7 if block sizes other than 8
are used within the calculation.
Some cryptographic libraries such as the [SUN provider in
Java](http://docs.oracle.com/javase/7/docs
/technotes/guides/security/StandardNames.html#Cipher) indicate PKCS#5 where
PKCS#7 should be used -
"PKCS5Padding" should have been "PKCS7Padding". This is - with high
probability - a legacy from the time
that only 8 byte block ciphers such as (triple) DES symmetric cipher were
available.
```
And this one here
https://copyprogramming.com/howto/java-security-nosuchalgorithmexception-cannot-find-any-provider-supporting-aes-ecb-pkcs7padding
```
The Sun JCE provider, which is Java's implementation, required a padding
method for block size of 16 bytes.
To fulfill this requirement, PKCS#7 specifies a padding method that is
similar to PKCS#5 padding. The only
difference is that PKCS#7 padding is defined for block sizes ranging from 2
to 255 bytes, which is the
maximum value of a byte if it encodes a zero-based unsigned integer.
However, the padding method was
already available with the name "PKCS5Padding" . Instead of introducing a
new name, the existing name
"PKCS5Padding" was utilized.
At this point, it is crucial that the Sun provider offers support for
"PKCS7Padding" since PKCS#5 padding is
not appropriate. This is not only a problem for Java Naming issue , but it
affects all developers who are
attempting to implement cryptographic protocols or transfer other software
to Java. While waiting for the Sun
provider to offer support, it is recommended to use "PKCS5Padding" instead
of "PKCS7Padding" .
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
