What Is Harvest Now, Decrypt Later?
What is a harvest now, decrypt later attack?
“Harvest Now, Decrypt Later” is a simple strategy: steal encrypted information today, store it, and wait for future quantum computers to defeat the cryptography protecting it.
It is not a hypothetical. In their joint guidance on quantum readiness, CISA, NSA, and NIST warn that cyber threat actors could be targeting data today that would still require protection in the future, using a “catch now, break later” or “harvest now, decrypt later” operation. The UK’s National Cyber Security Centre describes the same risk: an attacker collecting and storing data today and decrypting it at some point in the future.
The attack does not need a quantum computer to begin. It only needs one to finish. Every encrypted file stolen today is a bet on what cryptography will be able to withstand tomorrow.
The quantum clock is already running. The harvest is happening now.
Key Takeaways
- Harvest now, decrypt later means stealing encrypted data today, storing it, and waiting for future quantum computers to defeat the cryptography protecting it.
- The highest-risk data is information that must stay confidential for decades: intellectual property, financial records, legal agreements, government information, and personal data.
- The risk is not limited to the encryption algorithm. Wrapped keys, certificates, recovery information, and other metadata carried inside a file can give an attacker a future path to decrypt it offline.
- Shor’s algorithm threatens RSA and elliptic-curve public-key cryptography. Grover’s algorithm only reduces AES-256 from 2²⁵⁶ to roughly 2¹²⁸, which known quantum methods cannot practically reach.
- DocuID® encrypts locally with AES-256, keeps the key separate from the document, and releases it only after fresh proof of the authorized human, so a stolen file stays encrypted data.
Which Data Is Most at Risk from Harvest Now, Decrypt Later?
Harvest now, decrypt later is especially dangerous for documents that must remain confidential for decades. If a file will still matter in ten or twenty years, it is worth stealing today. That includes:
- Intellectual property
- Financial records
- Legal agreements
- Government information
- Personal data
For this kind of information, the question is not whether the encryption holds this year. It is whether the protection holds for as long as the information stays sensitive.
The Risk Is Not Limited to the Encryption Algorithm
Most discussions of quantum risk focus on the algorithm. But the algorithm is only part of the picture.
Many encrypted files carry cryptographic artifacts with them. Those artifacts can include:
- Wrapped keys
- Certificates
- Recovery information
- Other cryptographic metadata
Any of these could eventually help an attacker decrypt the document offline. When the file travels, its path to decryption travels with it.
What if the document did not carry its own path to decryption?
How DocuID® Protects Documents Against Harvest Now, Decrypt Later
That is the approach we take with DocuID®. The document and the ability to decrypt it are separated by design:
- 1The document is encrypted locally using AES-256.
- 2The decryption key is maintained separately from the document.
- 3No usable key or key-recovery path travels with the file.
- 4The key is released only after fresh proof of the authorized human.
- 5Access can be revoked or restricted even after the document has been distributed.
A stolen file therefore remains encrypted data, not a self-contained cryptographic puzzle an attacker can archive and solve later.
The release of the key is tied to Provable Human Authority™: fresh proof that the authorized human is present and is the one asking. Possessing the file is not the same as having the authority to open it.
What an Attacker Actually Harvests
Compare a file that carries its own key material with a DocuID® protected document.
| Dimension | File carrying its own key material | DocuID® protected document |
|---|---|---|
| What the stolen file contains | Ciphertext plus wrapped keys, certificates, recovery information, or metadata | AES-256 ciphertext only |
| Path to the decryption key | Travels with the file, often protected by public-key cryptography | Held separately; no usable key or key-recovery path travels with the file |
| Exposure to future quantum attacks | Public-key artifacts may be attacked later with Shor’s algorithm | No embedded public-key artifacts to attack |
| What it takes to decrypt | Solving the cryptographic puzzle, offline, at any time | Fresh proof of the authorized human before the key is released |
| Control after distribution | Whoever holds the file holds the puzzle | Access can be revoked or restricted after the document is shared |
Does Quantum Computing Break AES-256 Encryption?
Quantum computing does not change this equation as much as many assume. Two quantum algorithms drive most of the concern, and they affect cryptography very differently.
| Dimension | Shor’s algorithm | Grover’s algorithm |
|---|---|---|
| What it targets | Widely used public-key cryptography, including RSA and elliptic-curve systems | Brute-force key search against symmetric encryption such as AES |
| Effect on security | Threatens to break the underlying math | Theoretically reduces AES-256 search complexity from 2²⁵⁶ to about 2¹²⁸ |
| Practical meaning | Key exchange and signatures need post-quantum replacements | AES-256 remains out of practical reach for known quantum methods |
Shor’s algorithm threatens widely used public-key cryptography, including RSA and elliptic-curve systems. That is why NIST finalized its first post-quantum cryptography standards (FIPS 203, 204, and 205) and why agencies are urging organizations to plan their migration now.
Grover’s algorithm can theoretically accelerate brute-force attacks against symmetric encryption such as AES. But it would only reduce the theoretical search complexity of AES-256 from 2²⁵⁶ to approximately 2¹²⁸.
That remains an extraordinarily large computational challenge before accounting for the immense practical requirements of quantum error correction, circuit depth, processing time, and hardware. NIST’s own post-quantum cryptography FAQ states that AES 192 and AES 256 will still be safe for a very long time.
In practical terms, known quantum methods do not make AES-256 reachable.
An Architectural Defense, Not Just a Stronger Algorithm
Strong symmetric encryption is necessary. DocuID® adds an important architectural defense on top of it: the attacker gets neither the AES-256 key nor embedded public-key artifacts that could provide a future path to it.
Shor’s algorithm has nothing in the file to attack. Grover’s algorithm leaves AES-256 out of practical reach. And the key itself is never part of what gets stolen.
For Security & Risk Leaders
Find the documents that must stay secret for decades.
Walk through your long-lived sensitive data and where DocuID® fits with the iVALT team.
The Larger Lesson: Make the Harvest Not Enough
The larger lesson is simple:
Do not give an attacker both the encrypted document and the cryptographic artifacts needed to attack its access path.
Separate the document from the key.
Separate possession from authority.
Require fresh proof of the right human before releasing the ability to decrypt.
The best defense against “Harvest Now, Decrypt Later” may be ensuring that what gets harvested is simply not enough.
Separate the document from the key. Prove the right human before it opens.
Harvest Now, Decrypt Later: Frequently Asked Questions
What is a harvest now, decrypt later attack?
Harvest now, decrypt later is a strategy in which an attacker steals encrypted information today, stores it, and waits for future quantum computers to defeat the cryptography protecting it. CISA, NSA, and NIST also describe it as “catch now, break later.” It is sometimes called “store now, decrypt later.”
What data is most at risk from harvest now, decrypt later?
Data that must remain confidential for decades is most at risk, because it may still be valuable when quantum computers mature. That includes intellectual property, financial records, legal agreements, government information, and personal data.
Is AES-256 quantum safe?
Based on known quantum methods, yes. Grover’s algorithm could theoretically reduce the search complexity of AES-256 from 2²⁵⁶ to approximately 2¹²⁸, which remains an extraordinarily large computational challenge before accounting for quantum error correction, circuit depth, processing time, and hardware. NIST states that AES 192 and AES 256 will still be safe for a very long time.
What does Shor’s algorithm threaten?
Shor’s algorithm threatens widely used public-key cryptography, including RSA and elliptic-curve systems. That matters for encrypted files because keys are often wrapped or exchanged with public-key cryptography. If those artifacts travel with the file, they could give an attacker a future path to the key.
Why is encryption alone not enough to stop harvest now, decrypt later?
The risk is not limited to the encryption algorithm. Many encrypted files carry cryptographic artifacts with them, such as wrapped keys, certificates, recovery information, or other metadata, that could eventually help an attacker decrypt the document offline.
How does DocuID® protect documents against harvest now, decrypt later?
DocuID® encrypts the document locally using AES-256 and maintains the decryption key separately from the document. No usable key or key-recovery path travels with the file, and the key is released only after fresh proof of the authorized human. A stolen file therefore remains encrypted data, not a self-contained cryptographic puzzle an attacker can archive and solve later.
Can access to a DocuID® protected document be revoked after it is shared?
Yes. With DocuID®, access can be revoked or restricted even after the document has been distributed, because the key is never carried inside the file.
When should organizations prepare for quantum threats to encrypted data?
Now. CISA, NSA, and NIST encourage organizations to begin preparing by creating quantum-readiness roadmaps, conducting cryptographic inventories, and engaging vendors, because threat actors could be targeting data today that will still require protection in the future.