8328119: Support HKDF in SunPKCS11 (Preview) #22215

martinuy · 2024-11-18T18:05:34Z

We would like to propose an implementation of the HKDF algorithms for SunPKCS11, aligned with the KDF API proposed for JDK 24 (see JEP 478: Key Derivation Function API (Preview)).

This implementation will be under the Preview umbrella until the KDF API becomes stable in a future JDK release. The benefit of this early proposal is to gather more feedback about the KDF API for future improvements.

The P11KDF class has the core implementation and Java calls to the PKCS 11 API. Different native mechanism were used to merge key material: CKM_CONCATENATE_BASE_AND_DATA (key and data), CKM_CONCATENATE_BASE_AND_KEY (key and key) and CKM_CONCATENATE_DATA_AND_BASE (data and key). The implementation also supports merging data with data, at the Java level. List of HKDF algorithms supported: HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512.

Derivation modes supported: extract, expand, and, extract-expand.

We further advanced the consolidation of algorithm and key info in the P11SecretKeyFactory map —this effort started with the PBE support enhancement and has helped to avoid duplication—. The map has now information about HMAC (HMACKeyInfo class) and HKDF (HKDFKeyInfo class) algorithms. P11Mac is now aligned to take the information from the map.

Generic keys now supported in SecretKeyFactory. Derived keys could be Generic.

Testing

TestHKDF.java test added
- All non-SHA1 & non-SHA224 RFC 5869 test vectors checked
- Cross-checking against SunJCE's HKDF implementation for every algorithm possible
  - Static assertion data for resilience if SunJCE were not available
- Use of derived key for encryption check
- Concatenation of input key material and salt checked (multiple combinations)
- Multiple derivation types checked (extract only, expand only, and, extract-expand)
- Derive key and derive data checked
- All supported HKDF algorithms tested (HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512)
- DH and ECDH key derivation for TLS checked
- Informative output for debugging purposes (shown automatically if there is a test failure)
  - Note: test failures do not prevent all tests for running
- Test integrated to the SunPKCS11 tests framework
No regressions observed in jdk/sun/security/pkcs11 (114 tests passed, 0 failed)

A CSR will be proposed.

This proposal is a contribution of @martinuy and @franferrax .

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue
Change requires CSR request JDK-8344464 to be approved

Issues

JDK-8328119: Support HKDF in SunPKCS11 (Preview) (Enhancement - P4)
JDK-8346720: Support Generic keys in SunPKCS11 SecretKeyFactory (Enhancement - P4)
JDK-8344464: Support HKDF in SunPKCS11 (Preview) (CSR)
JDK-8346721: Support Generic keys in SunPKCS11 SecretKeyFactory (CSR) (Withdrawn)

Reviewers

Valerie Peng (@valeriepeng - Reviewer)
Kevin Driver (@driverkt - Committer)
Weijun Wang (@wangweij - Reviewer) Review applies to a7c82ee3

Contributors

Francisco Ferrari Bihurriet <[email protected]>
Martin Balao <[email protected]>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22215/head:pull/22215
$ git checkout pull/22215

Update a local copy of the PR:
$ git checkout pull/22215
$ git pull https://git.openjdk.org/jdk.git pull/22215/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 22215

View PR using the GUI difftool:
$ git pr show -t 22215

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22215.diff

Using Webrev

Link to Webrev Comment

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

bridgekeeper · 2024-11-18T18:06:20Z

👋 Welcome back mbalao! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2024-11-18T18:07:05Z

@martinuy This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8328119: Support HKDF in SunPKCS11 (Preview)
8346720: Support Generic keys in SunPKCS11 SecretKeyFactory

Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>
Co-authored-by: Martin Balao <[email protected]>
Reviewed-by: valeriep, kdriver, weijun

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 83 new commits pushed to the master branch:

55097dd: 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni
b8576eb: 6562489: Font-Renderer should ignore invisible characters \u2062 and \u2063
7a0832f: 8349934: Wrong file regex for copyright header format check in .jcheck/conf
2a5d1da: 8349571: Remove JavaThreadFactory interface from SA
74e458b: 8349684: Remove SA core file tests from problem list for macosx-x64
ba28119: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition
c5ac3c4: 8249831: Test sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java is marked with @ignore
336d0d8: 8349926: [BACKOUT] Support static JDK in libfontmanager/freetypeScaler.c
4b463ee: 8342103: C2 compiler support for Float16 type and associated scalar operations
332d87c: 8349859: Support static JDK in libfontmanager/freetypeScaler.c
... and 73 more: https://git.openjdk.org/jdk/compare/b499c827a512fb209a806d95b97df0f5932a29c0...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2024-11-18T18:07:45Z

@martinuy The following labels will be automatically applied to this pull request:

core-libs
security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2024-11-18T18:11:36Z

Webrevs

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

wangweij · 2024-12-06T18:03:40Z

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KDF.java

+        }
+
+        SecretKey getKeyMaterial() {
+            return null;


If the ikms list is empty, this would return a null key and convertKey does not like it. You might say this should not happen, but it seems the RFC has not forbidden this and the one in SunJCE does support it.

You're right, good catch!

wangweij · 2024-12-06T18:34:00Z

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KDF.java

+                    token.p11.C_DestroyObject(session.id(), derivedObjectID);
+                }
+            } else {
+                ret = P11Key.secretKey(session, derivedObjectID, alg, outLen,


Is the key length in bytes or bits here?

Good question. Should be converted to bits. The same issue repeats one more time.

wangweij · 2024-12-06T18:40:04Z

I set CKA_EXTRACTABLE = false and generate an AES key and its getEncoded is null. Then I use it as an IKM for HKDF and the deriveKey output is still unextractable. So far so good, but if I call deriveData on the same input spec, a byte array is returned. Doesn't this mean the derive output is actually extractable? Is this intended?

Update: I read https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/csd01/pkcs11-spec-v3.1-csd01.html#_Toc98177685 and https://docs.oasis-open.org/pkcs11/pkcs11-profiles/v3.1/os/pkcs11-profiles-v3.1-os.html#_Toc142307348 and it shows that some pInfo are allowed to derive CKO_DATA. Maybe the PKCS #11 library I am playing with (NSS 3.101 on macosx_aarch64) is tolerant.

martinuy · 2024-12-11T21:12:18Z

I set CKA_EXTRACTABLE = false and generate an AES key and its getEncoded is null. Then I use it as an IKM for HKDF and the deriveKey output is still unextractable. So far so good, but if I call deriveData on the same input spec, a byte array is returned. Doesn't this mean the derive output is actually extractable? Is this intended?

Update: I read https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/csd01/pkcs11-spec-v3.1-csd01.html#_Toc98177685 and https://docs.oasis-open.org/pkcs11/pkcs11-profiles/v3.1/os/pkcs11-profiles-v3.1-os.html#_Toc142307348 and it shows that some pInfo are allowed to derive CKO_DATA. Maybe the PKCS #11 library I am playing with (NSS 3.101 on macosx_aarch64) is tolerant.

Yes, my interpretation is that data (the derivation output in this case) is fine. What shouldn't happen is to have a non-extractable key derived extracted.

Conversion of bytes to bits when calling P11Key::secretKey. Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

wangweij · 2024-12-12T01:10:04Z

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KDF.java

+
+        long saltType = CKF_HKDF_SALT_NULL;
+        byte[] saltBytes = null;
+        P11Key p11SaltKey = null;


For Expand, salt is null.

Did you test with assertion on?

For Expand, salt should be null. Do you mean adding or hitting an assertion?

Assertion on line 162 will throw an NPE.

Ah, you're right, the assertion throws an NPE. Fixed.

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

wangweij · 2024-12-17T21:55:17Z

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java

+        d(KDF, "HKDF-SHA384", P11KDF, m(CKM_SHA384_HMAC),
+                m(CKM_HKDF_DERIVE, CKM_HKDF_DATA));
+        d(KDF, "HKDF-SHA512", P11KDF, m(CKM_SHA512_HMAC),
+                m(CKM_HKDF_DERIVE, CKM_HKDF_DATA));


We only defined HKDF-SHA256 and later in the Java Security Standard Names doc.

We included SHA1 because there could be a legacy use case to support and it's part of the test vectors for RFC 5869 (HMAC-based Extract-and-Expand Key Derivation Function (HKDF)). We don't recommend using it, and will probably filter it out once we have the Filter integrated, but would you be okay with keeping it?

Do you have any data on how many legacy use cases use it? I think for new mechanisms we should be forward looking and refrain from adding support for weak or not recommended algorithms unless there is a very good reason. It is often harder to remove something than to add it.

Yes, I see your point. We don't have data to back it up. If someone comes up with a strong case, we can reconsider it in the future. We removed it.

wangweij · 2024-12-18T16:38:39Z

I have never been a PKCS11 expert, but the code looks fine to me. The import line at the beginning of CK_HKDF_PARAMS.java is useless.

seanjmullan · 2024-12-18T19:24:02Z

@driverkt should review this too.

driverkt · 2024-12-18T19:47:17Z

It's on my list, thanks.

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

martinuy · 2024-12-18T19:52:42Z

I have never been a PKCS11 expert, but the code looks fine to me. The import line at the beginning of CK_HKDF_PARAMS.java is useless.

Thanks for your review. Unused import removed.

wangweij · 2024-12-18T22:48:04Z

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java

        d(SKF, "ChaCha20",      P11SecretKeyFactory,
                m(CKM_CHACHA20_POLY1305));
+        d(SKF, "Generic",       P11SecretKeyFactory,
+                m(CKM_GENERIC_SECRET_KEY_GEN));


How useful is this? Is it only used to import a "Generic" SecretKeySpec into a token? I see it's used in the test when adding a key. Can you simply add the SecretKeySpec key there?

Generic is a native PKCS11 key type (CKK_GENERIC_SECRET) that could have been added to SunPKCS11 before, irrespective of HKDF. It's convenient for the test to have key material in the token and test consolidation (IKM or salt).

Do you think we can add it to the Java Security Standard Names document?

Yes, sure. I added a comment to the Solution section of the CSR and the name to the table in Specification.

BTW, what else can this key be used? I tried in HmacSHA256 and there is a CKR_KEY_TYPE_INCONSISTENT error.

Hi @wangweij,

What test have you executed? I'm able to use "Generic" keys for HmacSHA256, in a local slowdebug build of this branch.

cat >providersList.properties <<'EOF' security.provider.1=SunPKCS11 --\\n\ name = NSS\\n\ nssLibraryDirectory = /usr/lib64\\n\ nssDbMode = noDb security.provider.2=SUN security.provider.3=SunRsaSign security.provider.4=SunEC security.provider.5=SunJSSE security.provider.6=SunJCE security.provider.7=SunJGSS security.provider.8=SunSASL security.provider.9=XMLDSig security.provider.10=SunPCSC security.provider.11=JdkLDAP security.provider.12=JdkSASL EOF

cat >Main.java <<'EOF' import java.util.HexFormat; import javax.crypto.Mac; import javax.crypto.SecretKey; import javax.crypto.SecretKeyFactory; import javax.crypto.spec.SecretKeySpec; public final class Main { public static void main(String[] args) throws Exception { byte [] keyMaterial = "Secret-Bytes".getBytes(); SecretKeySpec spec = new SecretKeySpec(keyMaterial, "Generic"); SecretKeyFactory skf = SecretKeyFactory.getInstance("Generic"); SecretKey sk = skf.generateSecret(spec); System.out.println(sk); Mac mac = Mac.getInstance("HmacSHA256"); mac.init(sk); mac.update("test".getBytes()); System.out.println(HexFormat.of().formatHex(mac.doFinal())); } } EOF

./build/linux-x86_64-server-slowdebug/images/jdk/bin/java \ -Djava.security.properties=providersList.properties Main.java rm providersList.properties Main.java

Output:

SunPKCS11-NSS Generic secret key, 96 bits session object, not sensitive, extractable) c5dca603b87a1a1fe264f3cab2f851d513afdd2a7dd5ed3ee337356e2d7a001a

I tried on my machine and see the same result. However, at least on my machine, Mac.getInstance actually chose the SunJCE implementation. If I explicitly getInstance from SunPKCS11-NSS I see the error.

The key has to have CKA_SIGN = true in order to be used for a HMAC operation in NSS. For example, you can modify the code snippet shared by @franferrax to include the line Mac mac = Mac.getInstance("HmacSHA256", "SunPKCS11-NSS"); in Main.java (instead of Mac mac = Mac.getInstance("HmacSHA256");) and the line attributes = compatibility in providersList.properties. With these changes, I get the following output:

./bin/java -Djava.security.properties=providersList.properties Main.java SunPKCS11-NSS Generic secret key, 96 bits session object, not sensitive, extractable) c5dca603b87a1a1fe264f3cab2f851d513afdd2a7dd5ed3ee337356e2d7a001a

Yes, it works now with the attributes = compatibility line. Told you I am not an expert. Thanks.

Hi, sorry for the confusion. Even when SunPKCS11 was the first provider in the list, I should have checked what provider was implementing the Mac.

In my previous example, due to delayed provider selection, the provider is chosen during the mac.init(sk) call. SunPKCS11 throws the InvalidKeyException you were reproducing (caused by PKCS11Exception: CKR_KEY_TYPE_INCONSISTENT), but this exception is ignored and SunJCE is finally selected. This doesn't happen if attributes = compatibility or attributes(*,CKO_SECRET_KEY,CKK_GENERIC_SECRET)={ CKA_SIGN=true } is used.

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

wangweij · 2024-12-19T02:29:07Z

Just curious, if I disable the CKM_CONCATENATE_DATA_AND_BASE mechanism in the config file, then addIKM(data).addIKM(key) still works. I guess that's because the config only applies to JCA/JCE algorithms but not internal implementations. This is designed so, right?

martinuy · 2024-12-19T03:52:31Z

Just curious, if I disable the CKM_CONCATENATE_DATA_AND_BASE mechanism in the config file, then addIKM(data).addIKM(key) still works. I guess that's because the config only applies to JCA/JCE algorithms but not internal implementations. This is designed so, right?

Yes, you're right. The mechanism, by design, can be used to avoid registering services for which there is no support in the token or has been disabled in the configuration. However, we decided not to make CKM_CONCATENATE_DATA_AND_BASE a requirement for HKDF services in SunPKCS11. The reason is that there might be a token that does not implement CKM_CONCATENATE_DATA_AND_BASE but still be usable for HKDF. By being less strict we can support more tokens and use cases that don't require concatenation. There will still be an error if the token does not support it and it's used.

AlanBateman · 2024-12-19T08:51:55Z

/label remove core-libs

wangweij

@martinuy I’m not a PKCS #11 expert, but I also haven’t identified any issues with it, and I’ve used it in several places without any problems. Thank you.

valeriepeng

Updates look fine.

seanjmullan · 2025-01-22T13:58:52Z

@seanjmullan , should I move CSR JDK-8344464 to finalized?

Yes.

Can we have CSR JDK-8346721 reviewed?

@valeriepeng @driverkt @wangweij - can you please review this CSR?

Make a PKCS openjdk#11 library supporting only CKM_HKDF_DERIVE or CKM_HKDF_DATA to also register the HKDF algorithms. Notice that the corresponding HMAC mechanism is still required. In case only one of the mechanisms is available, KDF::deriveKey or KDF::deriveData will fail at run time. If the user disables one of CKM_HKDF_DERIVE or CKM_HKDF_DATA through sun.security.pkcs11.Config, also refrain from using it. Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

Fix trivial copyright conflict in: src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java

franferrax · 2025-02-05T23:15:20Z

Hi @valeriepeng, @driverkt, @wangweij,

We needed to make more changes to align the behavior with the CSR description, see 87f4820. Would you mind giving it a look? Please note that the CSR has also been updated.

martinuy · 2025-02-12T14:03:13Z

CSR and PR were re-approved since our last changes. We intend to integrate this PR soon, if no one has any other concern.

martinuy · 2025-02-12T23:36:52Z

/author set @franferrax

martinuy · 2025-02-12T23:37:31Z

/author @martinuy

openjdk · 2025-02-12T23:37:39Z

@martinuy
Setting overriding author to Francisco Ferrari Bihurriet <[email protected]>. When this pull request is integrated, the overriding author will be used in the commit.

openjdk · 2025-02-12T23:37:45Z

@martinuy
Setting overriding author to Martin Balao <[email protected]>. When this pull request is integrated, the overriding author will be used in the commit.

martinuy · 2025-02-12T23:41:17Z

/contributor add fferrari

martinuy · 2025-02-12T23:41:23Z

/contributor add mbalao

openjdk · 2025-02-12T23:42:22Z

@martinuy
Contributor Francisco Ferrari Bihurriet <[email protected]> successfully added.

openjdk · 2025-02-12T23:43:13Z

@martinuy
Contributor Martin Balao <[email protected]> successfully added.

martinuy · 2025-02-13T16:54:50Z

/integrate

openjdk · 2025-02-13T16:55:34Z

Going to push as commit 6ddbcc3.
Since your change was applied there have been 94 commits pushed to the master branch:

28e744d: 8348092: Shenandoah: assert(nk >= _lowest_valid_narrow_klass_id && nk <= _highest_valid_narrow_klass_id) failed: narrowKlass ID out of range (3131947710)
0b50e47: 8349753: Incorrect use of CodeBlob::is_buffer_blob() in few places
18958c6: 8349925: [REDO] Support static JDK in libfontmanager/freetypeScaler.c
c2fc947: 8349378: Build splashscreen lib with SIZE optimization
5b75ff7: 8349907: jdk.tools.jlink.internal.plugins.ZipPlugin does not close the Deflater in exceptional cases
add3cd1: 8348600: Update PipeWire to 1.3.81
efc597b: 8349564: Clean warnings found in jpackage tests when building them with -Xlint:all
29202d1: 8349648: Test tools/jpackage/share/JLinkOptionsTest.java fails with --enable-linkable-runtime set after JDK-8346434
24b7f81: 8349783: g1RemSetSummary.cpp:344:68: runtime error: member call on null pointer of type 'struct G1HeapRegion'
a637ccf: 8349851: RISC-V: Call VM leaf can use movptr2
... and 84 more: https://git.openjdk.org/jdk/compare/b499c827a512fb209a806d95b97df0f5932a29c0...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-02-13T16:55:44Z

@martinuy Pushed as commit 6ddbcc3.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8328119: SunPKCS#11 implementation of HKDF

e87ec99

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

openjdk bot added the rfr Pull request is ready for review label Nov 18, 2024

openjdk bot added security [email protected] core-libs [email protected] labels Nov 18, 2024

Algorithms renamed for alignment with SunJCE.

0c13f2c

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

openjdk bot added the csr Pull request needs approved CSR before integration label Nov 18, 2024

martinuy changed the title ~~8328119: SunPKCS#11 implementation of HKDF~~ 8328119: Support HKDF in SunPKCS11 (Preview) Nov 19, 2024

wangweij reviewed Dec 6, 2024

View reviewed changes

martinuy and others added 2 commits December 11, 2024 18:15

Derivation of empty base keys.

453aa24

Conversion of bytes to bits when calling P11Key::secretKey. Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

Make EMPTY_KEY static.

aab90aa

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

wangweij reviewed Dec 12, 2024

View reviewed changes

Fix NPE in assertion.

bfe052f

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

wangweij reviewed Dec 17, 2024

View reviewed changes

Unused import removed.

c5750f0

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

wangweij reviewed Dec 18, 2024

View reviewed changes

Support for HKDF-SHA1 and HKDF-SHA224 removed.

52eb82f

Co-authored-by: Martin Balao Alonso <[email protected]> Co-authored-by: Francisco Ferrari Bihurriet <[email protected]>

wangweij approved these changes Jan 21, 2025

View reviewed changes

valeriepeng approved these changes Jan 22, 2025

View reviewed changes

openjdk bot added ready Pull request is ready to be integrated and removed csr Pull request needs approved CSR before integration labels Feb 5, 2025

franferrax and others added 2 commits February 5, 2025 19:43

Merge openjdk/master into JDK-8328119

d018b4a

Fix trivial copyright conflict in: src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java

openjdk bot removed the ready Pull request is ready to be integrated label Feb 5, 2025

openjdk bot added the csr Pull request needs approved CSR before integration label Feb 6, 2025

driverkt approved these changes Feb 6, 2025

View reviewed changes

valeriepeng approved these changes Feb 7, 2025

View reviewed changes

openjdk bot added ready Pull request is ready to be integrated and removed csr Pull request needs approved CSR before integration labels Feb 12, 2025

openjdk bot added the integrated Pull request has been integrated label Feb 13, 2025

openjdk bot closed this Feb 13, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Feb 13, 2025

8328119: Support HKDF in SunPKCS11 (Preview) #22215

8328119: Support HKDF in SunPKCS11 (Preview) #22215

Uh oh!

Conversation

martinuy commented Nov 18, 2024 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issues

Reviewers

Contributors

Reviewing

Uh oh!

bridgekeeper bot commented Nov 18, 2024

Uh oh!

openjdk bot commented Nov 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Nov 18, 2024

Uh oh!

mlbridge bot commented Nov 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

wangweij Dec 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wangweij commented Dec 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinuy commented Dec 11, 2024

Uh oh!

wangweij Dec 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seanjmullan Dec 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wangweij commented Dec 18, 2024

Uh oh!

seanjmullan commented Dec 18, 2024

Uh oh!

driverkt commented Dec 18, 2024

Uh oh!

martinuy commented Dec 18, 2024

Uh oh!

wangweij Dec 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wangweij Dec 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

martinuy commented Nov 18, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Nov 18, 2024 •

edited

Loading

mlbridge bot commented Nov 18, 2024 •

edited

Loading

wangweij Dec 6, 2024 •

edited

Loading

wangweij commented Dec 6, 2024 •

edited

Loading

wangweij Dec 12, 2024 •

edited

Loading

seanjmullan Dec 18, 2024 •

edited

Loading

wangweij Dec 18, 2024 •

edited

Loading

wangweij Dec 19, 2024 •

edited

Loading

franferrax Dec 19, 2024 •

edited

Loading

martinuy Dec 20, 2024 •

edited

Loading