Just push all changes to the PR and you can remove mine later. I cannot
guarantee when my PR can be integrated. Those I-Ds are still in Ed Queue.
--Weijun
> On Aug 4, 2025, at 08:55, Sebastian Stenzel
> wrote:
>
> I believe I got it working. Since my PR now relies on [1] your key encoding
>
I believe I got it working. Since my PR now relies on [1] your key encoding
changes, shall I push the changes or rather wait until your’s is merged into
master?
[1]: https://github.com/openjdk/jdk/pull/24969
> On 3. Aug 2025, at 21:56, Wei-Jun Wang wrote:
>
> The ML-KEM key does not need to be
> Am 03.08.2025 um 21:56 schrieb Wei-Jun Wang :
>
> The encoding does not necessarily be the seed.
I see, thanks for the clarification. In this case consider this a request to
improve the docs 😉
smime.p7s
Description: S/MIME cryptographic signature
The ML-KEM key does not need to be serialized anywhere so I think its encoding
does not matter. If you already have the expanded key you can directly create a
NamedPKCS8Key whose expander is an identity function, i.e. both its encoding
and expanded key are the expanded key itself. The encoding d
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 a
FYI - The IETF is still mucking around with this. I *think* the
consensus in the LAMPS session in Madrid has happened, but you may want
to wait a small amount of time before going too much further.
Mike
On 7/23/2025 11:52, Wei-Jun Wang wrote:
On Jul 23, 2025, at 11:41, Sebastian Stenzel
> On Jul 23, 2025, at 11:41, Sebastian Stenzel
> 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 fin
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 2
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
>
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-J7o85TE
> On 28. Jun 2025, at 00:12, Wei-Jun Wang 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
> On Jun 27, 2025, at 15:51, Sebastian Stenzel
> wrote:
>
> Short update on the state of the X-Wing RFC:
>
> Two weeks ago I contacted the authors, asking if they expect further changes.
> Which they don’t:
>
>> "X-Wing is final and being shipped by Google and Apple presumably in
>> hardwa
Short update on the state of the X-Wing RFC:
Two weeks ago I contacted the authors, asking if they expect further changes.
Which they don’t:
> "X-Wing is final and being shipped by Google and Apple presumably in
> hardware."
> - Bas Westerbaan
and
> "No significant changes, no changes planned
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 d
> On May 30, 2025, at 08:40, Sebastian Stenzel
> 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
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?
I have a wo
Hi Sebastian.
> On May 24, 2025, at 05:40, Sebastian Stenzel
> 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
17 matches
Mail list logo
