Preface
RSA Conference just wrapped up, and while phrases like “We are an Agentic AI solution for XYZ,” “AI in Cybersecurity,” and “Risks of AI Adoption” echoed across the expo halls, panels, and keynotes, you probably caught a few sessions on quantum threats and Post-Quantum Cryptography (PQC) too.
Beyond RSA, the noise about quantum is everywhere!! Articles, LinkedIn rants, webinars, fireside chats, even happy hour small talk – all swirling around a common narrative: quantum computers will soon break all encryption, and attackers will “harvest now, decrypt later.”
On one end, pundits (many without any background in cryptography) are proclaiming that “the sky is falling,” insisting some nations have already built quantum machines capable of breaking encryption. On the other hand, vendors are pushing “quantum-safe” solutions or offering tools to make you “crypto-agile.”
So, the natural reaction? “Why bother encrypting anything if it’s all going to be broken anyway?” Some even ask, “Is protecting customer data with current encryption still relevant?” Or “Should I just buy whatever that shiny PQC product was at the RSA booth with the fancy swag and wine webinar?”
Here’s my take: It’s all BOOP (Blown Out Of Proportion)!!
Not because it’s baseless, but because it’s rarely explained accurately, fully, and in context.
So before we enter “hair-on-fire” mode, take a breath. Let’s unpack this in smaller, digestible pieces, clearly and pragmatically.
But first, a quick detour: Quantum computers aren’t your most immediate threat. It’s not some teenager with a quantum laptop breaking your encryption next year.
The real threat? Your current security postures.
The next data breach your company suffers likely won’t come from quantum. It’ll come from a misconfigured bucket, a compromised credential, a 3rd party security gap, an unsecure code, a vulnerability you didn’t patch, an exposed API, or lack of visibility of where your data is or moving.
As the saying goes: “There are two types of companies – those who’ve been breached, and those who don’t know it yet.”
What Can Quantum Computers Actually Break?
Let’s be clear: quantum computers, once scaled to a large, fault-tolerant state (~4,000+ logical qubits), will completely break many of today’s most widely used asymmetric encryption algorithms. These include:
Algorithm | Vulnerability | Why It Breaks | Impact |
RSA | Broken | Integer factorization | TLS, email, digital signatures |
Diffie-Hellman (DH) | Broken | Discrete log problem | VPNs, SSH, key exchange |
ECC / ECDSA | Broken | Elliptic curve discrete log | Blockchain, TLS, certificates |
DSA | Broken | Discrete log variant | Code signing, auth, crypto wallets |
Once those machines arrive, these algorithms will fall, much like how short passwords do today.
Now, when that will happen is still debated. Some experts estimate we’re 5–15 years out from a truly “cryptographically relevant” quantum computer. Others argue it’s closer than we think. Regardless, one thing is clear: data encrypted today using RSA or ECC can be recorded now and decrypted later, the infamous “Harvest Now, Decrypt Later” threat.
A Real-World Example: TLS Under Quantum Attack
TLS (Transport Layer Security) secures most internet traffic, from HTTPS websites to API calls. But it heavily relies on asymmetric cryptography during the handshake phase.
TLS Workflow (Simplified):
- Handshake Phase
- Uses RSA or ECDHE to exchange keys
- Verifies identity with a digital certificate (RSA or ECDSA)
- Data Phase
- Uses symmetric encryption (AES) with the shared session key
Quantum Breaks TLS Here:
TLS Function | Crypto Used | Quantum Threat | Impact |
Key Exchange | RSA / ECDHE | Shor’s algorithm | Session keys exposed |
Certificate Signature | RSA / ECDSA | Shor’s algorithm | Server impersonation possible |
So, When Will Data Be Exposed in a Post-Quantum World?
Let’s walk through a familiar example: a TLS connection using RSA or ECDHE for key exchange.
Here’s how an attacker with a quantum computer compromises it:
- Record the TLS handshake and encrypted session now
- Wait until quantum computers mature
- Break RSA/ECDHE using Shor’s algorithm
- Recover the AES session key
- Decrypt the payload (your data)
Even AES-256 encryption (used in the data phase) remains secure, but if the session key is exposed, the encryption is worthless.
Even TLS 1.3 with ephemeral key exchange and AES-256 can be retrospectively broken, if the handshake uses quantum-vulnerable algorithms.
The Bottom Line
Quantum computers will compromise:
- Session keys via broken key exchange
- Identities via forged signatures
- Data, if it’s been captured and encrypted using today’s public-key algorithms
And it’s not just about data in transit. Even data at rest (like archives and backups) may be exposed if:
- AES keys are wrapped with RSA/ECC
- Or the payload itself was encrypted using public-key crypto
So, the threat isn’t always direct. It can be indirect, cascading through broken authentication, confidentiality, or integrity guarantees.
What’s Being Done About It
To get ahead of this, NIST has standardized four core Post-Quantum Cryptography (PQC) algorithms, forming the foundation for future-proofing security systems.
Algorithm | Type | Purpose | Typical Use Cases |
Kyber | Lattice-based (KEM) | Key exchange (fast, efficient) | TLS, VPNs, messaging, encrypted storage |
Dilithium | Lattice-based (Signature) | General-purpose signatures | TLS certs, code signing, digital documents, auth |
Falcon | Lattice-based (Signature) | Compact signatures for constrained devices | Smart cards, mobile apps, hardware modules |
SPHINCS+ | Hash-based (Signature) | Stateless, conservative option | Archival signing, compliance systems, backup PKI |
Are Symmetric Algorithms at Risk?
Not broken but weakened.
Quantum computers don’t break AES or ChaCha20 with Shor’s algorithm (they’re not based on factorization or discrete logs). But Grover’s algorithm can reduce the effort needed to brute-force them.
Algorithm | Classical Attack Complexity | Quantum Attack Complexity (Grover’s) |
AES-128 | 2¹²⁸ guesses | 2⁶⁴ guesses (quantum weakened) |
AES-256 | 2²⁵⁶ guesses | 2¹²⁸ guesses (still strong) |
Grover’s algorithm gives a quadratic speed-up, not exponential, so doubling key sizes is an effective defense. Symmetric Encryption Is Still Safe (If You Use Strong Keys).
These are the algorithms, and their quantum impacts and mitigations:
|
AES-256 remains secure even under quantum attack, as 2¹²⁸ operations is still practically infeasible.
Not All Data Is Worth “Harvest Now, Decrypt Later”
Let’s be clear, the “Harvest Now, Decrypt Later” risk primarily applies to data that will still matter years or decades from now, such as personal health records, national identifiers, legal contracts, or intellectual property.
But a lot of data doesn’t fall into that category. Much of it is:
- Ephemeral (chat messages, alerts)
- Time-limited (access tokens, session IDs)
- Low value (performance logs, anonymized metrics)
- Rotated or short-lived (credit card numbers, transactional data, temp keys)
In these cases, quantum attacks later won’t matter because the data will no longer be useful or sensitive.
Are Hackers Really Banking on “Harvesting Now, Decrypting Later?”
While quantum fear fuels urgency, let’s be real: Data Depreciates, Fast. The idea that attackers will store encrypted data for a decade hoping it becomes useful later is economically unrealistic. Most hackers are after instant payoff, not for a future payday. They target what’s monetizable now, such as credentials, financials, sensitive PII; not data that could be worthless in five years. Quantum may be real but immediate profit still drives the motivation and breach.
You Don’t Necessarily Need PQC to Prevent a Data Breach
What if I told you that you can still protect your data effectively using today’s tools, and you don’t necessarily need to adopt PQC right now?
Don’t believe me? Fair. Keep reading.
Let’s revisit that TLS scenario we walked through earlier. Now imagine that, instead of relying solely on the TLS session key to protect sensitive data, the payload itself had already been desensitized – meaning the sensitive fields were:
- Encrypted using AES-256, or
- Tokenized with Format-Preserving Encryption (FPE-FFX using AES-256)
- All done using a separate symmetric key
Now consider what happens when an attacker:
- Records the full TLS handshake and encrypted session
- Obtains (or waits to obtain) a quantum computer
- Breaks RSA/ECDHE/ECDSA using Shor’s algorithm
- Derives the session key
- Decrypts the TLS payload
- Discovers sensitive fields that are still encrypted or tokenized with AES-256/FPE-FFX
- Can’t decrypt the sensitive data because Grover’s algorithm isn’t enough to break AES-256
Same Applies to Data at Rest, Backups, and Archives
If sensitive fields in stored or archived data were pre-desensitized with AES-256 or FPE-FFX, then even if the outer AES key (wrapped with RSA/ECC) is compromised via quantum methods, the core sensitive fields remain protected.
In both cases, quantum attacks are neutralized by a single smart move: desensitizing sensitive data before it travels, gets stored, or is shared.
Why “Harvest Now, Decrypt Later” Doesn’t Always Apply
The HNDL threat can be rendered irrelevant if enterprises:
- Desensitize sensitive data upfront
- Use strong symmetric encryption (AES-256) or format-preserving tokenization (FPE-FFX)
- Avoid relying solely on TLS
This approach keeps data persistently protected – at rest, in transit, and even in use. So even if an attacker (or insider) compromises access credentials and exfiltrates data, what they get is garbage. The data exfiltration incident doesn’t escalate into a data breach.
Quantum Isn’t What Will Breach You Today
The real risk isn’t quantum. It’s poor security hygiene!! Most enterprises still rely on outdated, compliance-driven playbooks: encrypt at rest, use TLS, and apply access and perimeter controls. But common missteps like hardcoded secrets, keys stored with data, and quantum-vulnerable key wrapping (like RSA/ECC) still leave you wide open, even with AES-256.
Migration to PQC Is Important — But Not Your Only Defense
Yes, post-quantum cryptography will be vital for long-lived systems, especially those tied to trust (e.g., TLS, PKI, digital signatures). But let’s not mistake it as a silver bullet. You don’t need PQC to protect all data, or PQC won’t protect your data, if your current practices are already flawed.Your Current Path Towards Being Quantum Safe
The most practical path to becoming quantum-safe isn’t waiting for standards or overhauling your infrastructure, but by protecting data at the field level using quantum-resilient techniques like AES-256 or FPE-FFX. This keeps sensitive data persistently protected not just at rest or in transit, but even during use. By decoupling security from platforms and perimeters, this approach future-proofs enterprises for a world of AI agents, APIs, and decentralized workflows, ensuring that even if systems are breached, the data itself stays secure.
The Better Way: Frictionless, Persistent Data Protection
While legacy data security tools exist, they’re invasive, developer-heavy, and costly to integrate — often requiring:
- Deep cryptographic knowledge
- App rewrites or instrumentation
- Lengthy development and deployment cycles
You need solutions that enable automated, non-invasive/non-disruptive encryption & tokenization of sensitive data at the individual data element level, without breaking your applications, workflows, or budgets. What you get are:
- Persistent protection of sensitive data
- Defense against today’s threats and tomorrow’s quantum risks
- Accelerated Risk Remediation
- All with a fraction of the effort, cost, and time required by incumbent tools
The Future is Runtime Data Security
As enterprises embrace AI-driven workflows and autonomous agents, we’re entering the age of Runtime Data Security, where data is constantly in motion, accessed, transformed, and acted upon in real time, and in a lot of cases, autonomously without any human supervision. In this new paradigm, traditional security models that rely on static controls, perimeter walls, and post-facto scanning simply don’t apply, with or without PQC.
It’s the age of Runtime Data Insights & Protection (RDIP), enabling enterprises to see, secure, and control sensitive data as it moves, in real time, across AI agents, APIs, legacy systems, and modern stacks. With automated and real-time visibility, and persistent desensitization, RDIP solutions make the journey from risk detection to protection frictionless, and future ready.
Because in the era of quantum uncertainty and AI autonomy, only runtime security is effective security.
About the Author
Sid Dutta is a Data Protection and Cybersecurity Executive, a Security Advisor, an entrepreneur, with multiple patents and industry certifications. With 23 years of industry experience, Sid has been driving Data Protection and Privacy programs for the last 10 years across multiple large enterprises and has worked on/with various data security solutions including Data Discovery & Classification/DSPM, Data Subjects Rights Management, PKI/Certificate Management, Encryption, Tokenization, Key Management, P2PE, Payments and General Purpose HSMs, CASB, and various Cloud Security services.
He has also served on several vendor and Cybersecurity advisory boards and provides security advisory services to startups. Sid has multiple issued patents to his name and majority of them are within the domain of cryptography, blockchain, and tokenization.
He holds a master’s degree in business administration, and a bachelor’s degree in Electronics & Telecommunications Engineering. He is currently the Founder & CEO of Privaclave™, but prior to that he has held several Cybersecurity Leadership Roles, such as, Vice President – Data Protection & Privacy Engineering, at Activision Blizzard (Microsoft Gaming); Product Head – Voltage SecureData, OpenText (formerly Micro Focus); Vice President – Global Head of Data Protection & Applied Cryptography, Worldpay; and Director – Cryptographic Utilities & Services, American Express.
Sid can be reached online at [email protected] , https://www.linkedin.com/in/sid-dutta/ and at the company website https://www.privaclave.com/.