8360939: Support X-Wing KEM

[overheadhunter]

This PR adds to SunJCE:

• X-Wing KEM
• X-Wing KeyPairGenerator
• X-Wing KeyFactory

The variable names in the X-Wing implementation corresponds with those in the RFC draft, section 5. The tests are taken from appendix C.

This PR depends on #24969.

Warning

Don't merge yet. The RFC is still a draft. While the authors confirmed it is final, it is not yet published.

The PR is intended for early testing and review.

---

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

Issue

• JDK-8360939: Support X-Wing KEM (Enhancement - P4)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26032

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

Using diff file

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

[bridgekeeper]

👋 Welcome back overheadhunter! 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]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@overheadhunter The following label will be automatically applied to this pull request:

• security

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

[overheadhunter]

@wangweij note that I use different unchecked exception types when catching NoSuchAlgorithmException:

If the algorithm exists in the same provider (SunJCE), I assert it exists, throwing an AssertionError. For algorithms defined in other providers, I can not make this assertion, as they might not be present at runtime. In these cases I use an UnsupportedOperationException.

However, I'm not too happy with this. What is the best practice to deal with algorithm dependencies? Can we somehow check whether all dependencies exist a priori?

[overheadhunter]

@wangweij Shall I hardcode the SUN provider or leave it open for the implementation to find a suitable provider?

[overheadhunter]

to be updated before merging

[openjdk]

⚠️ @overheadhunter This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

[wangweij]

X-Wing's private key is the seed. Since KeyPairGenerator lacks a deterministic generateKeyPair method, we must invoke internal methods for ML-KEM and X25519 key pair generations anyway. The same applies to KeyFactory::translateKey. Due to this restriction, I'd prefer to avoid any attempt at a provider-neutral implementation. Instead, it can directly call internal ML_KEM and XECOperations methods for all operations.

[wangweij]

Have you thought about generalizing this as QSF as described in https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems and https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-concrete-hybrid-kems?

[overheadhunter]

I'd prefer to avoid any attempt at a provider-neutral implementation. Instead, it can directly call internal ML_KEM and XECOperations methods for all operations

Done, this did remove some extra hoops I jumped through before.

Have you thought about generalizing this as QSF as described in https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems and https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-concrete-hybrid-kems?

I still need to take a closer look, but might be worth it. The question is, whether I should broaden the scope of this PR or keep it focussed on X-Wing, retrofitting a general API afterwards?

[wangweij]

I still need to take a closer look, but might be worth it. The question is, whether I should broaden the scope of this PR or keep it focussed on X-Wing, retrofitting a general API afterwards?

I'm not sure. There are quite some competing composite or hybrid schemes proposed. Maybe we can wait and see.

[openjdk]

@overheadhunter this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8360939
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[overheadhunter]

I'm not sure. There are quite some competing composite or hybrid schemes proposed. Maybe we can wait and see.

I took some time to think about the QSF framework. I do believe it is possible to add this as an intermediary class/interface layer between NamedKEM and X-Wing. However, as you already noted, it is currently unclear whether other hybrid KEMs will implement this framework and become relevant.

I still think that retrofitting X-Wing with an QSF interface wouldn't be a great deal, so unless you want it today, I would suggest to postpone it and keep the scope of this issue focused just on X-Wing.

[bridgekeeper]

@overheadhunter This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[overheadhunter]

Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@wangweij this mostly depends on #24969. When do you expect this change to be integrated?

[wangweij]

Sorry but I really cannot predict it. The ML-DSA part (RFC 9881) has been published but the ML-KEM part is still an I-D. It is our policy that we do not support I-Ds in a JDK release.