Mike
On 7/23/2025 11:52, Wei-Jun Wang 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, WeijunThank you! SebastianAm 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, WeijunOn 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, SebastianOn 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, WeijunOn 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-L81On 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, WeijunThank you, Sebastian [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3AoverheadhunterOn 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, WeijunCheers! 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
