On Tue, 18 Mar 2025 23:15:13 GMT, Francisco Ferrari Bihurriet <fferr...@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
