Hi Weijun, I got a mostly working implementation based on NamedKEM [0], however to fulfil the spec I need your advice:
The (current) X-Wing spec wants this PKCS#8 encoding: [1] However, the NamedPKCS8Key implementation always puts a nested OctetString into the private key part. [2] Note the difference here: * https://lapo.it/asn1js/#MDQCAQAwDQYLKwYBBAGD5i2ByHoEIAABAgMEBQYHCAkKCwwNDg8QERITFBUWFxgZGhscHR4f * https://lapo.it/asn1js/#MDYCAQAwDQYLKwYBBAGD5i2ByHoEIgQg9IFQEyQtdLJL8j-hRm6Yzx3CzFiDyNk4yCADl6ZiXWo I believe we need some more flexibility, as the ASN.1 standard leaves it open to the algorithms how a private key is formatted. What do you think how to approach this? Or should I ask the authors whether they have a specific encoding in mind? The ASN.1 definitions in the spec don’t seem to be complete yet. Best regards, Sebastian [0]: https://github.com/openjdk/jdk/compare/master...overheadhunter:jdk:x-wing [1]: https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-07.html#appendix-D [2]: https://github.com/openjdk/jdk/blob/d7352559195b9e052c3eb24d773c0d6c10dc23ad/src/java.base/share/classes/sun/security/pkcs/NamedPKCS8Key.java#L76-L81 > On 30. May 2025, at 15:03, Wei-Jun Wang <weijun.w...@oracle.com> wrote: > > > >> 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 >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
