RFR: 8348732: SunJCE and SunPKCS11 have different PBE key encodings

[Valerie Peng]

On Tue, 18 Mar 2025 23:15:13 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:

>> As part of [https://bugs.openjdk.org/browse/JDK-8301553](JDK-8301553), SunPKCS11 provider added support for PBE SecretKeyFactories for `HmacPBESHAxxx` and `PBEWithHmacSHAxxxAndAES_yyy`. These impls produce keys whose encoding contains the PBKDF2 derived bytes. Given that SunJCE provider have supported `PBEWithHmacSHAxxxAndAES_yyy` SecretKeyFactories whose key encoding is the password bytes for long time. Such difference may be very confusing, e.g. using the same KeySpec and same-name SecretKeyFactory (from different providers), the resulting keys have same algorithm and format but different encodings.
>> 
>> Given that the `P11Mac` and `P11PBECipher` classes already do key derivation internally, these PKCS11 SecretKeyFactories aren't a must-have and are proposed to be removed. I've also aligned the com.sun.crypto.provider.PBEKey class with com.sun.crypto.provider.PPBKDF2KeyImpl class to switch to "UTF-8" when converting the char[] to byte[]. This is to accomodate unicode passwords and given that "UTF-8" encoding is same for ASCII characters, this change should not affect backward compatibility.
>
> test/jdk/sun/security/pkcs11/Cipher/PBECipher.java line 1:
> 
>> 1: /*
> 
> I suggest changing this test's password to contain non-ASCII characters, so we have a better coverage in both _SunJCE_ (when checking the assertion data) and _SunPKCS11_ (when doing the actual test):
> 
> diff --git a/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java b/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
> index b12cb5c2687..93ef097933f 100644
> --- a/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
> +++ b/test/jdk/sun/security/pkcs11/Cipher/PBECipher.java
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2023, Red Hat, Inc.
> + * Copyright (c) 2023, 2025, Red Hat, Inc.
>   *
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
> @@ -47,7 +47,7 @@
>   */
>  
>  public final class PBECipher extends PKCS11Test {
> -    private static final char[] password = "123456".toCharArray();
> +    private static final char[] password = "123456\uA4F7".toCharArray();
>      private static final byte[] salt = "abcdefgh".getBytes(
>              StandardCharsets.UTF_8);
>      private static final int iterations = 1000;
> @@ -112,35 +112,35 @@ private static void checkAssertionValues(BigInteger expectedValue,
>      // Generated with SunJCE.
>      private static final AssertionData[] assertionData = new AssertionData[]{
>              cipherAssertionData("PBEWithHmacSHA1AndAES_128",
> -                    "AES/CBC/PKCS5Padding", "ba1c9614d550912925d99e0bc8969032" +
> -                    "7ac6258b72117dcf750c19ee6ca73dd4"),
> +                    "AES/CBC/PKCS5Padding", "9e097796e8d8224f2a7f5c950677d879" +
> +                    "c0c578340147c7ae357550e2f4d4c6ce"),
>              cipherAssertionData("PBEWithHmacSHA224AndAES_128",
> -                    "AES/CBC/PKCS5Padding", "41960c43ca99cf2184511aaf2f0508a9" +
> -                    "7da3762ee6c2b7e2027c8076811f2e52"),
> +                    "AES/CBC/PKCS5Padding", "7b915941d8e3a87c00e2fbd8ad67a578" +
> +                    "9a25648933b737706de4e4d48bdb61b6"),
>              cipherAssertionData("PBEWithHmacSHA256AndAES_128",
> -                    "AES/CBC/PKCS5Padding", "6bb6a3dc3834e81e5ca6b5e70073ff46" +
> -                    "903b188940a269ed26db2ffe622b8e16"),
> +                    "AES/CBC/PKCS5Padding", "c23912d15599908f47cc32c9da56b37f" +
> +                    "e41e958e9c3a6c6e4e631a2a9e6cd20f"),
>              cipherAssertionData("PBEWithHmacSHA384AndAES_128",
> -                    "AES/CBC/PKCS5Padding", "22aabf7a6a059415dc4ca7d985f3de06" +
> -                    "8f8300ca48d8de585d8026...

Sure, I can do this. Thanks for the suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24068#discussion_r2011057913