Hi,
When using X25519MLKEM768, I would like to know that the other peer is not
reusing its key share (as long as it is compliant). As a server reusing a key
share can have catastrophic security consequences for the client, I think this
is a _very_ reasonable request.
https://emanjon.github.io/N
On Sun, Mar 09, 2025 at 02:02:55PM +, John Mattsson wrote:
> Viktor Dukhivni wrote:
> >However, you'll be thrilled to learn that it is not possible for a TLS
> >server to reuse its ML-KEM keyshare when a client uses a fresh ephemeral
> >ML-KEM keyshare.
>
> Yes, that solves half the problem,
On Sun, Mar 09, 2025 at 03:16:46PM +, John Mattsson wrote:
> I don't think time is the important factor. The important thing is
> that encapsulation keys used with different servers are independent.
> If you have a timing side channel in KEM.Decaps(dk, c) that leaks the
> encapsulation key, th
So your concern would be resolved by an IETF RFC? To me, that says that you
are concerned about mistakes from well-meaning people, not true adversaries.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
(Note for TLS WG only: announcing with approval of chairs [0])
Hi all,
*TL;DR*: There will be a couple of /public side meetings/ on attested
TLS. For organizational purposes (e.g., to ask for a bigger room
[current room capacity: 20]), if you are interested in presenting or
attending /in-pers
On Sun, Mar 09, 2025 at 12:33:38PM +, John Mattsson wrote:
> I find the current situation of key shares being reused without the
> other peer knowing inacceptable and frankly the worst possible option.
In general terms, your expectations are unrealistic, the best you can
do, if you think you'
Salz, Rich wrote:
>I am curious why this is worse than, say, knowing that the server reports
>SSLKEYLOGFILE into a public
>S3 bucket or similar? And do you think a real adversary would self-report that
>they are using
>ephemeral keys?
I was comparing these three options:
A. Key shares being reu
I find the current situation of key shares being reused without the other peer
knowing inacceptable and frankly the worst possible option.
I am curious why this is worse than, say, knowing that the server reports
SSLKEYLOGFILE into a public S3 bucket or similar? And do you think a real
adversar
Viktor Dukhivni wrote:
>Guidance to encourage fresh keys every ~5 minutes and every ~10 users is not
>unreasonable.
I don't think time is the important factor. The important thing is that
encapsulation keys used with different servers are independent. If you have a
timing side channel in KEM.De
On Sun, Mar 09, 2025 at 11:17:10PM -, D. J. Bernstein wrote:
> Viktor Dukhovni writes:
> > However, you'll be thrilled to learn that it is not possible for a TLS
> > server to reuse its ML-KEM keyshare when a client uses a fresh ephemeral
> > ML-KEM keyshare.
>
> "Not possible"?
>
> In ECDH,
Viktor Dukhovni writes:
> However, you'll be thrilled to learn that it is not possible for a TLS
> server to reuse its ML-KEM keyshare when a client uses a fresh ephemeral
> ML-KEM keyshare.
"Not possible"?
In ECDH, or more precisely ElGamal encrypton: Alice sends A = aG; Bob
sends B = bG and C =
11 matches
Mail list logo
