X-Wing KEM

[Wei-Jun Wang]

> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
> 
> Hi Weijun,
> 
> waiting for the final standard is understandable. The internals may still change, but the „outer hull“ of the PR is something that could already be discussed before - under these premises, would it make sense to already start a draft? Knowing that it won’t be merged yet?

Feel free to start a draft if you’d like. I'll create a JBS issue once we decide we want to include it in the JDK.

> 
> I have a working set of KeyPairGenerator, KeyFactory and KEM SPI including test vectors basically ready - just SHAKE256 currently borrowed from BC.
> 
> I know that using SHAKE256 within the JDK is not a problem. However if we want to make it public, there simply *is no* XOF API in JCA. Technically the expand step of the KDF API can be used, but semantically that would be a misuse. Adding a completely new API is nothing I currently want to work on.

I see.

> 
> Btw I am somewhat familiar with the development process as I have started contributing to the JDK in 2021 on cipher and NIO issues. [1]

Nice to know. Sorry I didn't noticed that earlier.

Thanks,
Weijun

> 
> Thank you,
> Sebastian
> 
> [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Aoverheadhunter
> 
>> On 29. May 2025, at 18:44, Wei-Jun Wang <weijun.wang at oracle.com> wrote:
>> 
>> Hi Sebastian.
>> 
>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> For the past few months I have been in contact with one of the authors of two spec drafts for future JOSE encryption standards [1] [2] with the latter of them relying on X-Wing.
>>> 
>>> As the X-Wing spec doesn’t face significant changes any more (there have been some larger shifts in regards to secret key derivation last year), I am now tasked to create a prototype implementation for these RFCs.
>> 
>> Thanks for your continued interest on enhancing OpenJDK.
>> 
>> That said, we have a policy of not implementing algorithms that haven't been standardized. So we won't be able to consider your contribution until IETF publishes draft-connolly-cfrg-xwing-kem as an RFC. I'm not sure how familiar you are with the OpenJDK developing process, but in the meantime, you might find it helpful to read the OpenJDK Developers’ Guide [1] and try working on something smaller first. 
>> 
>>> 
>>> All the primitives for X-Wing are technically already there in OpenJDK, however two of them are private API (namely SHAKE256 and ML-KEM’s `KeyGen_internal(d, z)` [3]). So the question arises whether I can contribute an X-Wing KEM implementation to the JDK at the current state of the spec?
>> 
>> It's acceptable to use private API inside OpenJDK when you are working on OpenJDK itself. After all, we created them for this very purpose. However, please keep in mind that this means you bind your X-Wing implementation to the SunJCE/SunEC implementations. Usually, as a higher-level algorithm, if its underlying algorithms could be implemented by different security providers, it will be nice to make it provider-neutral where possible.
>> 
>>> 
>>> Alternatively, can we make the two mentioned APIs public?
>> 
>> No. These methods are too specific to their respective algorithms. We prefer JCA/JCE-style API that is algorithm-neutral.
>> 
>> [1] https://openjdk.org/guide/
>> 
>> Thanks,
>> Weijun
>> 
>>> 
>>> Cheers!
>>> Sebastian
>>> 
>>> [1]: https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt/
>>> [2]: https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07
>>> [3]: https://github.com/openjdk/jdk/blob/070c84cd22485a93a562a7639439fb056e840861/src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java#L498-L536
>>> 
>> 
>