On Mon, Mar 23, 2026 at 05:27:58PM +0000, John Mattsson wrote:
> >And as a physicist I object to saying that QKD relies on classical
> >mechanisms for detecting eavesdropping.
>
> Your initial statement was "the information exchanged is indeed
> private”. As a physicist you should maybe learn some cryptography
> before making statements on security. Just like ECDHE, the
> quantum-parts of QKD are unauthenticated key exchange and only
> protects against passive attackers. Not considering active attackers
> is an outdated attack model. It is much better than not having
> encryption but does not meet modern requirements. Especially not for
> something claiming to provide better security than current
> state-of-the art, which is TLS 1.3 with X.509 and X25519MLKEM768.
That critique looks rather ad hominem, and may presume too much.
Perhaps what Yaakov has in mind is a more complete QKD implementation
with a reliable classical channel for Wegman-Carter authentication
(information-theoritic authentication with no privacy, initially keyed
with a pool of one-time shared secrets between the two end-points) as a
companion to the QKD channel (information-theoretic privacy with no
authentication), and then all the associated protocols to ensure that Eve's
QKD MitM attempts are detected and rejected, while authenticated QKD is
used in a 2-phase commit process to grow the shared secret pool to avoid
its eventual exhaustion.
Much cleverness goes into QKD to actually make it in principle secure
and usable if the initial keying was secure, and side-channel or other
realities of concrete physical devices don't undermine the QKD
assumptions.
Scaling limitations, performance limitations, and a limited repertoire
of supported cryptographic primitives that don't ultimately involve
standard cryptographic hardness assumptions rather than physics, ...
are the reason that QKD is rarely if ever practical.
On paper, it appears to be possible to design a complete system that
does relies only on QM no-cloning, and and an initial pool of one-time
secrets shared by the two endpoints. In practice, it is unclear why
one would bother. And certainly unclear why one might not at least
hedge one's bets and use 8773(bis) with psk_dhe_ke and X25519MLKEM768
as the "dhe", and say ML-DSA for the certificate(s).
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
