> On 28. Jun 2025, at 00:12, Wei-Jun Wang <weijun.w...@oracle.com> wrote: > > [...] After all, there is no parameter for X-Wing. Did you hear the authors > they want to introduce other algorithms like ed448 and ML-KEM-1024 into it?
I forwarded this question and let you know the answer! >> >>> On 7. Jun 2025, at 23:34, Wei-Jun Wang <weijun.w...@oracle.com> wrote: >>> >>> Cool. >>> >>> The current NamedPKCS8Key was designed based on an older approach where >>> modern asymmetric keys store private key data in a nested OCTET STRING >>> format. This pattern was introduced with EdDSA and XDH, and at the time of >>> JDK 24, we anticipated it would become the norm. >>> >>> However, things have changed significantly, as seen in the evolution of >>> draft-ietf-lamps-dilithium-certificates and >>> draft-ietf-lamps-kyber-certificates. The original design now needs to be >>> revised. While we’re still waiting for the IETF drafts to be finalized, >>> we’re already experimenting with changes in >>> https://github.com/openjdk/jdk/pull/24969. >>> >>> Hopefully, by the time X-Wing is finalized, we’ll already have a solution >>> in place. >>> >>> Thanks, >>> Weijun >>> >>>> On Jun 7, 2025, at 16:14, Sebastian Stenzel <sebastian.sten...@gmail.com> >>>> wrote: >>>> >>>> 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
