Harvest now, decrypt later means the attack starts the day your messages are recorded, not the day the quantum computer is switched on — so the protection has to be in place before the harvest.
Harvest now, decrypt later is the practice of recording encrypted traffic today and waiting for a future quantum computer to decrypt it. Your messages are safe from today's attackers — but if they are captured and stored, traffic sealed only with classical key agreement could be opened years from now by an attacker with a large enough quantum computer. Hybrid post-quantum encryption is the countermeasure: it combines a classical key exchange with a quantum-safe one, so a captured ciphertext remains unreadable even after quantum computers arrive.
Key takeaways
- Harvest now, decrypt later (HNDL) means an attacker records your encrypted traffic today and decrypts it later with a quantum computer; the harm happens years in advance of the machine itself.
- Anything with a long shelf life — private correspondence, medical and legal details, business plans — is exposed to HNDL even if it is properly encrypted today.
- A key-encapsulation mechanism (KEM) is a set of algorithms two parties use to establish a shared secret over a public channel, which symmetric algorithms then use for encryption and authentication, as NIST defines in FIPS 203.
- ML-KEM-768, standardized by NIST in FIPS 203, is the quantum-safe KEM used alongside classical ECDH P-256 in Livara's LVR1 direct-message protocol.
- Hybrid design is belt-and-braces: if either the classical or the quantum-safe half fails, the other still protects the key, so every message key is derived from both.
What is harvest now decrypt later, exactly?
Harvest now, decrypt later (HNDL) is a passive attack: the attacker captures ciphertexts in transit today, stores them, and decrypts them later once a cryptographically relevant quantum computer exists. Imperva's analysis of harvest now, decrypt later attacks describes the bet plainly — store ciphertext today, wait for quantum computers to mature, decrypt at leisure. No messages need to be broken now; the theft is the recording itself.
The attack matters because quantum computers running Shor's algorithm are expected to break the public-key problems that classical key exchange relies on, while symmetric encryption with sufficiently long keys is not expected to fall the same way. So the weak link in HNDL is not the AES protecting each message — it is the key agreement that put the key there in the first place.
Who should care about data with a long shelf life
If your messages lose their value within months, HNDL may mostly cost you tomorrow's embarrassing screenshots. If your conversations carry anything durable — legal, medical, financial, journalistic or personal matters you would not want read a decade on — the exposure starts the moment a quantum-capable attacker begins recording. That mismatch between "encrypted today" and "private forever" is the core problem.
Will quantum computers break encrypted messages that are end-to-end encrypted?
End-to-end encryption stops everyone on the path from reading your messages today, including the server — but it does not immunize captured ciphertext against a future quantum attacker if the key agreement behind it is only classical. The message content is still sealed after delivery; the risk is that the recorded transcript could be opened later if the key exchange falls. In short: end-to-end encryption answers "who can read this now," not "who can read this years from now if it was captured today."
This is why the question "will quantum computers break encrypted messages" has a two-part answer. Symmetric ciphers like AES-256 are considered resistant to even quantum attack at that key size. The classical key-agreement step — for example, elliptic-curve Diffie–Hellman on NIST's P-256 curve — is the part a cryptographically relevant quantum computer is expected to defeat, and it is precisely the step HNDL attackers are waiting to replay.
If you want the fine detail on what Livara's encryption does and does not cover, its security page spells out the boundaries, and for the timing signals that leak alongside message content, read privacy for last seen, read receipts and typing indicators.
Hybrid post-quantum encryption explained: ECDH P-256 plus ML-KEM-768
Hybrid post-quantum key exchange runs two independent key-agreement schemes side by side and derives one shared secret from both. Concretely, in Livara's LVR1 direct-message protocol, a P-256 ECDH ratchet and an ML-KEM-768 epoch ratchet run in parallel, and every message key is derived from both, so the transcript stays sealed unless an attacker breaks both halves at once.
Step by step:
- Classical half. Both parties perform ECDH on the P-256 curve, producing a shared secret no eavesdropper today can compute.
- Quantum-safe half. In the same session, one party encapsulates key material under ML-KEM-768, the lattice-based KEM NIST standardized in FIPS 203, and the other decapsulates it.
- Combine. Both secrets feed a hash-based key derivation function (HKDF-SHA-256 in Livara's case), which outputs the actual message key.
- Encrypt. The message is sealed with AES-256-GCM under that combined key.
The security property is simple: to recover the key, an attacker must defeat both the classical problem and the lattice problem. If someone someday breaks P-256 with a quantum computer, the ML-KEM half still holds; if a future cryptanalytic surprise hits ML-KEM, the P-256 half still holds.
Classical vs hybrid vs post-quantum-only key agreement
| Property | Classical only (ECDH P-256) | Hybrid (P-256 + ML-KEM-768) | Post-quantum only (ML-KEM-768) |
|---|---|---|---|
| Safe from today's classical attackers | Yes | Yes | Yes |
| Safe from a future quantum attacker | No — this is what HNDL exploits | Yes, if ML-KEM holds | Yes, if ML-KEM holds |
| Survives a future break of P-256 | No | Yes | — (no classical half to fall back on) |
| Survives a future cryptanalytic break of the new scheme | — | Yes | No |
| Maturity in the field | Decades of deployment | Increasingly standard | Newer, less operational history |
The hybrid column is the only one with no single point of total failure, which is why major protocol designers treat it as the prudent migration path rather than a hard swap.
What is ML-KEM-768 and why did NIST standardize it?
ML-KEM-768 is the middle parameter set of ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism standardized by NIST in FIPS 203; the shared-secret role of a KEM was sketched in the takeaways above. The "module lattice" refers to the mathematical structure — problems on module lattices — for which no efficient quantum algorithm is known, unlike factoring or discrete logarithms, which Shor's algorithm breaks.
The "768" is a security level, not a key length in the AES sense: ML-KEM comes in 512, 768 and 1024 parameter sets, and 768 is the middle tier NIST's own guidance treats as a reasonable general-purpose choice. Livara uses precisely this parameter set — named ML-KEM-768, per FIPS 203 — in its ratchet, rather than an ad-hoc or similar-sounding variant.
What should a post-quantum private messaging app actually do?
A post-quantum private messaging app should do more than name-drop a quantum-safe algorithm; it should specify where the algorithm sits, what it protects, and what it does not. The checklist worth applying:
- Protects the live conversation, not a marketing claim: the KEM must be inside the key agreement that produces each message key, so harvested ciphertext gains the attacker nothing later.
- Covers all message types: attachments (photos, video, files, captions) and group messages too, not only one-to-one text. In Livara, private groups use the LGS1 protocol with sender keys sealed in pairwise LVR1 envelopes, so group traffic gets the same hybrid post-quantum treatment.
- States its boundaries honestly: call media in Livara rides WebRTC DTLS-SRTP — strong, but not the same ratchet and not post-quantum, and metadata for routing and synchronization remains server-visible.
- Offers verifiability: published specifications and test vectors, so the claim can be checked rather than trusted. Livara's Proof Lab lets you verify release integrity yourself, and its published threat model says plainly who sees what.
How forward secrecy interacts with HNDL
Forward secrecy means past message keys are destroyed as the conversation advances, so a compromised current key does not unlock history. HNDL sidesteps this by recording the ciphertexts themselves — so forward secrecy helps only if the long-term key agreement is quantum-safe. Livara's LVR1 pairs the two: the hybrid ratchet delivers forward secrecy and post-compromise security on top of a quantum-safe key agreement, so an attacker who harvests today still has to break both halves tomorrow to get anything.
When should you start using hybrid post-quantum encryption?
Start now for anything with a long confidentiality shelf life, because the protection has to be in place before the harvest, not after the decryption. Switching later protects future messages; it cannot retroactively seal messages that were already recorded under classical-only key exchange. The asymmetry is the whole argument: you pay a small performance cost today for insurance against a decryption event that may be years away.
Honest caveat — and it applies to every vendor, including Livara: no protocol specification or test-vector suite is independent proof of security; Livara publishes open specifications, machine-checkable vectors and verifiable release checksums, but that is evidence to check, not an audit certificate. If you are comparing messengers rather than evaluating one in depth, weigh how trust boundaries differ between web and Android clients. And once you have picked a tool, compare safety numbers out of band: Livara's security page explains how its v3 safety numbers let two people check that the key fingerprints they see match.
Frequently asked questions
What is harvest now decrypt later in one sentence?
It is a passive attack in which an adversary records encrypted traffic today and waits for a future quantum computer to decrypt it, so the damage starts at capture time, not when the machine exists.
Will quantum computers break AES-256?
Grover's algorithm gives a quadratic speedup against symmetric ciphers, so AES-256 is broadly regarded as remaining secure against quantum attack at that key size. The quantum-vulnerable pieces are the classical public-key steps — key exchange and signatures — not the symmetric encryption itself.
Why use both classical and quantum-safe encryption together?
Hybrid design means the session key depends on both schemes, so an attacker must break both to read anything. If a quantum computer breaks the classical half someday, the quantum-safe half still holds; if a flaw is later found in the newer scheme, the well-studied classical half still holds.
Does hybrid post-quantum encryption slow messaging down?
Lattice KEMs add larger public keys and ciphertexts than classical elliptic-curve exchange, which costs some bandwidth and CPU, but the bulk data of a chat is still protected by fast symmetric encryption, so ordinary messaging remains responsive on modern hardware.
Is anything not covered by post-quantum protection in Livara?
Yes. Call media is protected by WebRTC DTLS-SRTP rather than the message ratchet and is not described as post-quantum, routing metadata such as sender, destination and timestamps is stored for device synchronization, and public broadcast channels are deliberately unencrypted so reported content can be reviewed.
