Just push all changes to the PR and you can remove mine later. I cannot guarantee when my PR can be integrated. Those I-Ds are still in Ed Queue.
--Weijun > On Aug 4, 2025, at 08:55, Sebastian Stenzel <sebastian.sten...@gmail.com> > wrote: > > I believe I got it working. Since my PR now relies on [1] your key encoding > changes, shall I push the changes or rather wait until your’s is merged into > master? > > [1]: https://github.com/openjdk/jdk/pull/24969 > >> On 3. Aug 2025, at 21:56, Wei-Jun Wang <weijun.w...@oracle.com> wrote: >> >> The ML-KEM key does not need to be serialized anywhere so I think its >> encoding does not matter. If you already have the expanded key you can >> directly create a NamedPKCS8Key whose expander is an identity function, i.e. >> both its encoding and expanded key are the expanded key itself. The encoding >> does not necessarily be the seed. >> >> Thanks, >> Weijun >> >>> On Aug 2, 2025, at 13:42, Sebastian Stenzel <sebastian.sten...@gmail.com> >>> wrote: >>> >>> Hi, >>> >>> I merged your NamedPKCS8Key branch into the X-Wing branch and tried to >>> adjust to the new API. I encountered one problem: >>> >>> With your changes, `NamedKEM#implDecapsulate` will now receive the expanded >>> key (no longer the raw seed). So far, so good. However, in X-Wing I need to >>> split this into an ML-KEM key and the X25519 key. Now here is the problem: >>> If I only have expanded bytes, how can I construct an ML-KEM key? >>> NamedPKCS8Key requires „raw key bytes, not null“ (i.e. the seed) and only >>> optionally the expanded bytes. >>> >>> Is there any internal API I can use to run ML-KEM’s decapsulate with a >>> byte[] key? >>> >>> Otherwise, I would suggest that you widen the signature of >>> `NamedKEM#implDecapsulate` to receive both parameters, the seed and the >>> expanded key. >>> >>> Cheers, >>> Sebastian >>> >>>> On 23. Jul 2025, at 17:52, Wei-Jun Wang <weijun.w...@oracle.com> wrote: >>>> >>>> >>>> >>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> >
