X-Wing KEM

Mon Jun 30 10:06:40 UTC 2025

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.stenzel at gmail.com> wrote:
> 
> 
>> On 28. Jun 2025, at 00:12, Wei-Jun Wang <weijun.wang at 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.wang at 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.stenzel at 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.wang at oracle.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On May 30, 2025, at 08:40, Sebastian Stenzel <sebastian.stenzel at 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.wang at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> Hi Sebastian.
>>>>>>>> 
>>>>>>>>> On May 24, 2025, at 05:40, Sebastian Stenzel <sebastian.stenzel at 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
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4407 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250630/3f347367/smime-0001.p7s>