One of the key elements to detecting cyberattacks is the concept of observability. We can literally see the packets of data being thrown towards a website when a DoS attack is taking place. The “boom” of the attack is visible and observable. But when a cryptographically relevant quantum computer is utilized to break into encrypted traffic flows, the attacker “snoops” the traffic and stores a copy somewhere else where it can be processed later with impunity, which makes the act both not observed and not observable.
This is what I call the “silent boom,” and it will most definitely be a plate tectonic shift in the world of secrets and privacy, disrupting the balance of power for every nation, every industry and every individual.
The evidence isn’t theoretical. According to network security firm Qrator Labs, there were approximately 13,626 BGP hijack attacks in the second quarter of 2024 and 13,438 in the third quarter. Not all are malicious, but enough create that “scenic route” through Chinese-owned or Russian-owned IP addresses that makes security professionals nervous about store-now-decrypt-later attacks.
At Marvel, we had secrets that, if disclosed ahead of the planned time, would cause significant damage to the brand and potentially also to projected revenues. The actors who attend the red carpet premiere have no idea what they’re going to see on screen. The scripts they were given had false scenes in them as a means of forensic watermarking that helps identify leaks. When you’re protecting 10-year story arcs and plans for what comes after phase 6 of the Multiverse Saga, you develop an appreciation for what needs long-term protection.
This is a developer problem, not a CISO shopping problem
CISOs are directing attention to have quantum security risks added to the corporate risk register. It belongs there. But the problem to be solved is not a quick fix, despite what some snake oil salesmen might be pushing. There is no simple configuration checkbox on AWS or Azure or GCP where you “turn on” post-quantum cryptography (PQC) and then you’re good to go. This is a shared responsibility problem. Just as migrating to the cloud doesn’t magically make your infrastructure more secure, quantum vendors cannot solve this without significant developer engagement.
Here’s why this lands on developers: The majority of all internet traffic is not human-generated traffic from laptops to servers and back. It’s API traffic. Your company most likely delivers services using a host of third-party solutions, all accessed via APIs. So your API client needs to learn how to speak PQC algorithms just as much as that remote API endpoint needs to learn how to speak PQC algorithms. Otherwise, the connection will negotiate down to a common protocol that both can speak and it won’t be TLSv1.3 with PQC algorithms.
Without significant engagement from developers, QA teams and product owners, the quantum decryption risk will remain in play. You cannot transfer this risk by adding more cyber insurance policy coverage. The entire cyber insurance industry itself is in a bit of an existential doubt situation regarding whether cybersecurity can reasonably be insured against, given the systemic impacts of supply chain attacks that cascade across entire industries.
What can developers actually do? Three concrete steps this quarter:
Step one: Inventory your algorithms and data with a view towards which sensitive data ought to be protected with PQC. This is a data classification exercise where you need to add a column to track whether the datastore or application qualifies for PQC.
Step two: Check your internet-facing assets to see which, if any, are already capable of supporting TLSv1.3 with PQC algorithms.
Step three: Create internal capability to test new ciphers so that once NIST is able to “bless” another set of candidates (two of the first set of four algorithms have already been broken), you’ll be positioned to implement them without a five- to 10-year lag time.
The fearmongering critics are missing the point
Critics say this is fearmongering and that we’ll have warning signs before quantum becomes a real threat. They’re wrong on the timeline. In my discussions with colleagues on the quantum security working group for the World Economic Forum, we see that financial services, healthcare and manufacturing are making plans now because they understand something crucial: It took us at least 10 years to get financial services to move to SHA-256 for encryption and for PCI compliance requirements to deprecate SSLv3 after TLS came into play in 1999. The insecure protocols weren’t formally deprecated until PCI DSS version 3.1 in 2015. That’s the current speed of “crypto agility” in financial services.
The cryptographically relevant quantum computer risk, being about five to 10 years away, is essentially a now risk, given the rate of adoption of new cryptography standards. The most dangerous myth seems to be that it can be put off to tomorrow and that nothing needs to be done today.
We’ve seen recent kerfuffles over factoring 22-bit RSA keys in research papers published in China, which is just a trivial academic milestone that doesn’t purport the demise of RSA-2048 encryption. But we will continue to see advancements in hybrid classical-quantum approaches to factoring integers. The writing is on the wall.
Meanwhile, I’ve seen some pretty insane LinkedIn assertions from organizations making statements about computers with 4,000 qubits. For RSA-2048 to be broken, according to Shor’s algorithm, we would need around 20 million qubit quantum computers. So we are still orders of magnitude away. (The marketing teams will make sweeping generalizations about achievements and write them off as “good enough,” often comparing physical qubits and logical qubits as if they’re the same thing, but that is a classic apples-and-oranges fallacy.)
Monday morning action items
The moment when a cryptographically relevant quantum computer comes into existence won’t arrive with fanfare or bombast. Hence, the idea of the silent boom. But by then, it will be too late for incident response.
What you should do Monday morning: Start that data classification exercise. Figure out what needs protecting for the long term versus what has a shorter shelf life. In the world of DNS, we have Time To Live (TTL) that declares how long a resolver can cache a response. Think of a “PQC TTL” for your sensitive data, because not everything needs 30-year protection.
Just as the HTTPS-everywhere movement took time to gain traction, so too will the PQC-everywhere efforts. The difference is we can’t wait for the attack to happen before we start preparing. There’s no such thing as quantum incident response — only quantum readiness.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
No Responses