>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. >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. FYI, for good reasons, the physical layer is typically not used for security and communication security has in the last decades moved up in the network stack to enable flexibility, crypto agility, and end-to-end encryption. Cheers, John Preuß Mattsson From: Yaakov Stein <[email protected]> Date: Monday, 23 March 2026 at 17:58 To: Sophie Schmieg <[email protected]>, John Mattsson <[email protected]> Cc: Salz, Rich <[email protected]>, Andrei Popov <[email protected]>, [email protected] <[email protected]> Subject: RE: [EXTERNAL] Re: [TLS] Re: LS on the work item related to QKD and TLS integration framework in SG13 You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> There is a lot in the Google page with which I completely agree. The range limitations, the low throughput, and especially - For a global network at Google's scale, replacing existing hardware with specialized QKD equipment in our data centers is not a practical or scalable solution. The main problem with QKD is scaling. 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). This is a perfectly legitimate statement, but does not rule out its use for p2p usage or small networks. And there are people who believe in conspiracy theories regarding the disparaging of QKD by NSA and GCHQ. I am not a great fan of QKD; I was just objecting to calling a 50-year old technology “premature”. And as a physicist I object to saying that QKD relies on classical mechanisms for detecting eavesdropping. And as someone who participated in SG13 meetings for 2 decades, I would really like a polite and accurate response to be sent. Y(J)S From: Sophie Schmieg <[email protected]> Sent: Monday, March 23, 2026 6:37 PM To: John Mattsson <[email protected]> Cc: Yaakov Stein <[email protected]>; Salz, Rich <[email protected]>; Andrei Popov <[email protected]>; [email protected] Subject: [EXTERNAL] Re: [TLS] Re: LS on the work item related to QKD and TLS integration framework in SG13 In case you also want an industry perspective, on top of the perspective of NSA, GCHQ, BSI, every other European cybersecurity agency, and probably many others I'm forgetting saying that QKD is not a deployable solution, and does not appear to be a deployable solution any time soon, here is Google's blog post on this topic: https://bughunters.google.com/blog/googles-commitment-to-a-quantum-safe-future-why-pqc-is-googles-path-forward-and-not-qkd On Mon, Mar 23, 2026 at 9:21 AM John Mattsson <[email protected]<mailto:[email protected]>> wrote: Code-based and hash-based cryptography are from the 70-ties. QKD might have deployments, but it is not at all mature as a practical security technology, marketing is mostly snake-oil, current deployment are practically insecure, and both vendors and users of QKD have very little understanding of security. Many statements from QKD vendors and users are truly horrendous. Any company claiming that QKD is practical is a major red flag, indicating either a lack of understanding of security or a disregard for it. Anybody that have invested in QKD should see it as a sunk cost. >It also, unlike PQC algorithms, has a (physical) proof that if it succeeds >then the information exchanged is indeed private. No, protection against MITMs is based purely on classical (non-quantum) cryptography. Cheers, John Preuß Mattson From: Yaakov Stein <[email protected]<mailto:[email protected]>> Date: Monday, 23 March 2026 at 17:06 To: Salz, Rich <[email protected]<mailto:[email protected]>>, Andrei Popov <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [TLS] Re: LS on the work item related to QKD and TLS integration framework in SG13 From: Salz, Rich <[email protected]<mailto:[email protected]>> Sent: Monday, March 23, 2026 2:31 PM To: Andrei Popov <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [TLS] Re: LS on the work item related to QKD and TLS integration framework in SG13 It can be as simple as The TLS working group feels that QKD is still too premature to be a secure solution to any problem. We note that other organizations also feel this way [refs to UKNCSC, NSA if needed]. We are unlikely to do any work in this area now. We suggest that you look at the QCRG, in our related organization the IRTF, which has active QKD discussions. WHAT???? QKD is a much more mature technology than PQC, dating back to 1984. (I used QKD in the 1990s). There are multiple vendors with significant sales – the market size exceeded $600M in 2025 with a CAGR of 30%. It also, unlike PQC algorithms, has a (physical) proof that if it succeeds then the information exchanged is indeed private. Sure, QKD can be expensive, may be limited in range, doesn’t presently do DSA, and (despite the proof) there are implementation and timing attacks, but saying that it is “premature” may be “simple”, but is certainly incorrect. Y(J)S This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]<mailto:[email protected]> This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
