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
