> On Jul 23, 2025, at 11:41, Sebastian Stenzel <sebastian.sten...@gmail.com> > wrote: > > Welcome back, I hope you enjoyed the time! :-) > > If you find time, can you give me an update on the ASN.1 key encoding topic? > This is the only remaining issue to fulfill the spec. Afterwards we simply > need to wait for the final test vectors and publication of the RFC.
https://github.com/openjdk/jdk/pull/24969 updated NamedPKCS8Key which contains both the encoding format (as in PKCS #8) and the expanded format (used in calculation). For X-Wing, I think the encoding will be the seed, but you are free to choose the expanded format, or, you can "expand" it to an arbitrary object at NamdKEM::implCheckPrivateKey. The KeyPairGenerator interface does not have a deterministic generateKey method so you will have to call internal methods for both ML-KEM and x25519. Thanks, Weijun > > Thank you! > Sebastian > >> Am 23.07.2025 um 14:33 schrieb Wei-Jun Wang <weijun.w...@oracle.com>: >> >> Hi Sebastian, >> >> I'm back from my vacation. Thanks for the update. >> >> I agree, using NamedKey is probably a better choice anyway. It's nice that >> getParams() always return a name and we don't need to call getAlgorithm() as >> a fallback. >> >> Thanks, >> Weijun >> >>> On Jun 30, 2025, at 06:06, Sebastian Stenzel <sebastian.sten...@gmail.com> >>> wrote: >>> >>> Quoting Bas Westerbaan (in CC) again, we will most likely see further PQ/T >>> hybrids from the IETF crypto forum research group (CFRG for short): >>> >>>> It seems likely that the CFRG will at some point produce a >>>> P-384+ML-KEM-1024 hybrid. See >>>> https://mailarchive.ietf.org/arch/msg/cfrg/CwrVvm-J7o85TEWkG9RJxZwfXDY/ . >>>> That might take some time. >>>> >>>> Very few (but notably Ericsson) have asked for X448 hybrids, so I don't >>>> expect them soon. >>> >>> That said, the construction does not necessarily be compatible to X-Wing. >>> Just to be sure, I asked whether they see any value in parameterizing >>> X-Wing to swap out algorithms. This is what Bas replied: >>> >>>> Even if the other hybrids will also use an X-Wing style combiner, it >>>> doesn't hurt not to parametrize initially. :) >>> >>> So I would suggest to follow this advice for now and only refactor the >>> implementation eventually, when further pairs of algorithms are combined in >>> the same way. >>> >>> Best, >>> Sebastian >>> >>> >>>>> On 29. Jun 2025, at 12:02, Sebastian Stenzel >>>>> <sebastian.sten...@gmail.com> wrote: >>>> >>>> >>>>> 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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
