> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.sten...@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.w...@oracle.com> wrote: >> >> Hi Sebastian. >> >>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.sten...@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 >>> >> >
