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 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >
smime.p7s
Description: S/MIME cryptographic signature
