In ML-KEM, Bob derives b deterministically from m and H(ek).
If Bob tried to reuse b with a different public key, then the
re-encryption check would fail during decapsulation.
Peter
> -Original Message-
> From: Viktor Dukhovni
> Sent: 10 March 2025 00:47
> To: tls@ietf.org
> Subject: [T
17:37
To: tls@ietf.org
Subject: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt
On Mon, Nov 4, 2024 at 6:31 PM D. J. Bernstein
mailto:d...@cr.yp.to>> wrote:
Speaking for myself, not on behalf of the SPHINCS+ team (or other teams
potentially relevant here).
Peter C writes:
&g
used for both extensions, so
if you are not proposing SLH-DSA end-entity certificates then you need to be
more explicit that it is not recommended for use in signature_algorithms.
Peter
From: tirumal reddy
Sent: 04 November 2024 07:16
To: Peter C
Cc: IETF TLS
Subject: Re: [TLS] Re: New Version N
John Mattsson wrote:
> "Conversely, the fast version prioritizes speed over
> signature size, minimizing the time required to generate
> and verify signatures."
>
> This is incorrect. The "f" versions only have faster key
> generation and signing. They have slower verification.
Also:
"This docu
Tiru,
Is SLH-DSA considered a practical option for TLS end-entity certificates?
Under realistic network conditions, TLS handshakes with full SLH-DSA
certificate chains seem to be about 5-10 times slower than traditional
certificate chains and, in some cases, can take on the order of seconds. S
on't think it's obvious.
Best,
Peter
> -Original Message-
> From: Felix Günther
> Sent: 05 September 2024 09:25
> To: Peter C
> Cc: Marc Fischlin ; TLS List
> Subject: [TLS] Re: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt
>
> Hi Peter,
&g
ar enough!
Best,
Peter
> -Original Message-
> From: Felix Günther
> Sent: Tuesday, August 13, 2024 10:51 AM
> To: Peter C ; Marc Fischlin darmstadt.de>
> Cc: tls@ietf.org
> Subject: Re: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt
>
> Hi Peter,
tance from the X-Wing paper (https://ia.cr/2024/039). It is also
entirely possible that I'm missing something obvious and a different
part of the proof rules this out.
Best,
Peter
> -Original Message-
> From: Felix Günther
> Sent: Friday, August 2, 2024 2:05 PM
> To: P
Marc and Felix,
Thank you both for your replies.
I can see how this will work for NIST P-256 and X25519 - it is
straightforward to detect the equivalent public and adjust the
output of the simulator accordingly - and I also agree that it is
not a significant change to the PRF-ODH assumption.
Douglas,
> > It's not exactly due to the point formats, at least for X25519. The RFC
> > 7748
> > security considerations highlight that "for each public key, there are
> > several
> > publicly computable public keys that are equivalent to it, i.e., they
> > produce
> > the same shared secrets
re if there's anything else in
[DOWLING] that would need to be adjusted or if that would be enough by itself.
Peter
> -Original Message-
> From: Douglas Stebila
> Sent: Wednesday, July 24, 2024 9:58 PM
> To: Peter C
> Cc: TLS List
> Subject: Re: [TLS] I-D Action: dra
’, label) should give the same KDF
output.
Note that in both cases we are deviating from the idealised PRF-ODH setting so
this does not contradict the proof that StDH implies PRF-ODH
(https://ia.cr/2017/517).
Peter
From: Deirdre Connolly
Sent: Wednesday, July 24, 2024 3:34 PM
To: Peter C
Cc
Douglas,
The agenda for the TLS session is looking packed, and this is a very
in-the-weeds comment, so I hope you don't mind me posting it to the list.
Happy to take any discussion off-list, if you'd prefer.
The draft-ietf-tls-hybrid-design security considerations currently say:
The share
Mike,
X-Wing is not a profile of the generic construction. Dropping the ML-KEM
ciphertext changes the security assumptions you need to make. If X25519 is
secure then, in the generic construction, ML-KEM doesn’t need to satisfy any
security properties at all for the hybrid to be secure. In X-
Thom and Ilari,
TW> We should currently be using full HPKE, we're just wrapping it in
TW> some KEM operations. But this is something I haven't looked at
TW> too deeply either.
Can I check what you mean here? Are you using the KEM by itself, HPKE with
single-shot secret export, HPKE with singl
Sorry, the hybrid TLS draft I referenced should have been
draft-tls-westerbaan-xyber768d00. I do realise they are different drafts with
slightly different KEMs, I just can't copy and paste properly!
Peter
From: TLS On Behalf Of Peter C
Sent: Monday, November 6, 2023 4:08 PM
To: tls@iet
Thom,
If I'm understanding things correctly, the proof of multi-stage security for
AuthKEM requires that the KEM used for authentication is IND-CCA2 secure.
Unfortunately, kem_x25519kyber768 from draft-westerbaan-cfrg-hpke-xyber768d00
is not IND-CCA2 secure. It simply concatenates the shared s
17 matches
Mail list logo
