The issue with QKD authentication is more complicated than you make out. For one, there do exist "information theoretical" authentication methods, analogous to OTP being informational theoretical encryption. This does require a fresh set of keys to authenticate each message (just like OTP requires a fresh set of keys to encrypt each message), but since QKD generates keys, they could use some of those generated keys for that. And, unlike OTP, the key bits needed for this authentication can be much smaller than the message being authenticated.
Now, I don't believe that they use these methods in practice (possibly because if something goes wrong, and you can't authenticate a message, the QKD can't generate more keying data, and so you end up stuck), but they could (especially with 'backup keys' that could be used if a single message fails). For another, there also exist signature methods that have equivalent security to symmetric systems (and since, in practice, you use QKD to generate symmetric keys, that's good enough). Again, I don't know if they use these methods, but they could. For a third, the argument that is often made is about "harvest and decrypt later" attacks. For those attacks, using, say, RSA to authenticate is not an issue, because later breaking the authentication key doesn't break the privacy of previously encrypted message. Now, don't get me wrong - I'm not a QKD proponent by any means. I believe that the reliance on "trusted nodes" is a showstopper in most scenarios, and until they develop a workable "untrusted repeater", QKD security shouldn't be taken seriously. Side channel attacks are also bothersome. However, the ideal is not completely dead. ________________________________ From: Nico Williams <[email protected]> Sent: Monday, March 23, 2026 1:59 PM To: John Mattsson <[email protected]> Cc: Yaakov Stein <[email protected]>; Sophie Schmieg <[email protected]>; Andrei Popov <[email protected]>; [email protected] <[email protected]> Subject: [TLS] Re: [EXTERNAL] Re: Re: LS on the work item related to QKD and TLS integration framework in SG13 On Mon, Mar 23, 2026 at 05:27:58PM +0000, John Mattsson wrote: > >You need a QKD transmitter at one end and a receiver at the other end > >of every link. This means the scaling is O(N^2). > > The main problem is not the N^2 new hardware tied to the physical > layer, the main problem is that you need a full mesh N^2 > point-to-point links between all the N parties. Trusted parties breaks > e2ee. N^2 is the reason that the Internet has routers: so it can scale. But what kills QKD is the lack of "quantum authentication". You have to use classical cryptography to authenticate QKD when the whole point of QKD is to have something that is physically provably secure w/o reference to any potentially-weak classical (non-quantum) cryptography. I.e., there's just no point to QKD full stop. Even if quantum authentication existed, presumably we'd need physical contact to exchange set it up, which is another thing that won't scale, so even if there was a fully-quantum point-to-point solution, it wouldn't scale even if we built quantum-hop-by-quantum-hop authentication protocols. QKD is a dead end. Nothing can save it. Any attempt to sell QKD must inherently be snake-oil-like because of this. And they generally are. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
