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.
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
