🚨 Active Threat — Now

Harvest Now, Decrypt Later (HNDL)

The most immediate quantum security threat. Nation-state adversaries are capturing your encrypted traffic today, storing it, and will decrypt it when quantum computers arrive. This threat is active right now — regardless of when quantum computers mature.

⚠️ This threat is active today. You do not need a quantum computer to be a victim of HNDL. The capturing is happening now. Adversaries collect encrypted traffic that is valuable but currently undecryptable, with the expectation that sufficiently powerful quantum computers will arrive within the decade. Data that must remain confidential for 5+ years is already at risk. Defence, government, critical infrastructure, financial services, and telecom organisations in India should treat this as an active threat, not a future concern.

📡 How HNDL Works

Adversary intercepts and stores encrypted traffic

Nation-state intelligence agencies tap undersea cables, intercept satellite links, compromise ISP infrastructure, or conduct passive monitoring of public internet exchange points. They capture and store large volumes of encrypted traffic — TLS sessions, VPN tunnels, encrypted email. The traffic is encrypted and currently unreadable, but they store it anyway. Storage is cheap. Decryption patience is infinite.

Traffic is stored in bulk data archives

The captured data is tagged with metadata (source IP, destination, timestamp, approximate data volume) and stored in cold storage archives. The adversary does not need to analyse it now — they just need to retain it until decryption becomes possible. At current storage costs, petabytes of intercepted traffic can be retained for years at modest cost for a nation-state actor.

Cryptographically Relevant Quantum Computer (CRQC) arrives

Estimates for a CRQC capable of breaking RSA-2048 or ECDH P-256 range from 2030 to 2040+. A CRQC uses Shor's algorithm to factor large numbers exponentially faster than classical computers. The first CRQC will likely be a classified national asset — the adversary will use it quietly, targeting the highest-value archived traffic first.

Archived traffic is decrypted retroactively

The adversary runs the CRQC against their archive. Diplomatic communications from 2025, defence procurement documents from 2026, financial market intelligence from 2027 — all become readable. By this point, the data has been breached for years without your knowledge. The only protection is ensuring traffic captured today cannot be decrypted even with a future quantum computer — which means migrating to PQC key exchange now.

🔐 Why Current Encryption Doesn't Protect Against HNDL

AES-256 symmetric encryption is quantum-safe (Grover's algorithm only provides a quadratic speedup). The vulnerability is in the key exchange — how two parties agree on the AES key over an insecure channel.

Component	Quantum vulnerability	HNDL implication
RSA key exchange	Broken by Shor's algorithm	Captured TLS session key → decrypts session content
ECDH key exchange	Broken by Shor's algorithm	Captured ECDHE parameters → reconstructs session key
AES-256 session encryption	Grover halves effective key size — AES-256 → 128-bit security	Remains secure — content protection is OK
TLS 1.3 with ECDHE	Key exchange vulnerable, content cipher OK	Session keys recoverable — full session decryptable
ML-KEM-768 (hybrid)	Resistant to known quantum attacks	HNDL protection — captured traffic remains encrypted

The fix is specifically in the key exchange step. Deploying hybrid ML-KEM-768 for TLS key exchange today means that any traffic captured after deployment cannot be retroactively decrypted — even if a CRQC becomes available in the future. This is why TLS key exchange migration is the highest-priority PQC action.

🧮 HNDL Data Risk Calculator

Assess which of your data categories are at risk from HNDL attacks today.

Data Category

Required Confidentiality Period

Likely Adversary Interest (India Context)

🎯 India-Specific HNDL Target Profiles

Critical Risk

Defence & MoD

Procurement plans, capability assessments, operational communications, weapons system specs. Strategic value persists for decades. Primary nation-state target. DRDO's QKD research acknowledges this threat directly.

Critical Risk

Intelligence Agencies / RAW / IB

Source identities, collection methods, ongoing operations. Information that is sensitive today will be catastrophically sensitive in 10 years if a source is still active. Highest-priority HNDL target in India.

Critical Risk

MEA / Diplomatic Missions

Negotiating positions, back-channel communications, foreign policy intelligence. Diplomatic communications captured today may inform adversary strategy for years. Treaty negotiations especially vulnerable.

Critical Risk

Critical Infrastructure (Power, Water, Nuclear)

OT/SCADA communications, vulnerability data, contingency plans. Information about infrastructure weaknesses remains relevant as long as the infrastructure operates. Nuclear facilities represent maximum-priority targets.

High Risk

SEBI-Regulated Financial Institutions

M&A intelligence, trading strategies, market position data. Financial strategy captured today may be exploitable within the 5-10 year confidentiality window. RBI's SWIFT-connected systems are priority targets.

High Risk

Telecom Backbone Operators (BSNL, Jio, Airtel)

Subscriber communications metadata, lawful intercept capabilities, network topology. Telecom infrastructure data is strategically valuable — understanding India's surveillance capabilities is of high interest to adversaries.

High Risk

DRDO / ISRO / Space Sector

R&D roadmaps, mission parameters, technology specifications. India's space and defence R&D represents decades of investment — competitor nations have strong incentive to capture this via HNDL today for use in future programmes.

Moderate Risk

Large Indian Enterprises (Manufacturing, Pharma)

Drug formulations, manufacturing IP, trade secrets. Pharma patents expire in 20 years — HNDL-captured R&D data could be used to prepare competing products. Strategic M&A targets are of particular interest.

🔍 Indicators of HNDL Activity

HNDL is inherently passive — capturing encrypted traffic leaves few traces. These indicators suggest your traffic is being positioned for HNDL collection.

Network — Passive Tap Indicators

Unexplained latency increases on specific international routes. Asymmetric packet loss (traffic going out behaves differently from traffic coming in). RSPAN or port mirroring configurations on upstream provider equipment that you didn't request.

BGP / Routing Anomalies

BGP hijacking of your IP space — traffic briefly rerouted through unexpected ASes (particularly in China, Russia, Iran). BGP Monitor alerts for unexpected prefix announcements involving your address space. Use BGPmon or RIPE NCC RIS for monitoring.

TLS Downgrade Attempts

SSL/TLS client hello packets attempting to negotiate TLS 1.2 or weak cipher suites against servers configured for TLS 1.3. Adversaries may attempt to force use of weaker key exchange to make HNDL easier. Log cipher negotiation failures.

Upstream Provider Anomalies

Unusual maintenance windows at internet exchange points. Requests from ISPs to install new hardware in co-location facilities. MPLS traffic engineering changes that alter expected traffic paths. These may indicate lawful intercept equipment installation.

DNS over HTTPS / DNS Leakage

Even if traffic is encrypted, DNS queries reveal destinations. HNDL collectors use DNS metadata to prioritise which encrypted sessions to retain. Monitor for DNS queries leaving your network in cleartext — adversaries correlate DNS with TLS sessions.

Nation-State Interest Signals

APT group reconnaissance activity against your organisation (spear phishing, credential stuffing on VPN endpoints). Nation-state actors conduct active reconnaissance of targets they are also passively collecting against via HNDL to correlate data.

Practical detection approach

True HNDL is nearly undetectable in real-time. The most effective detection is forensic — monitoring BGP routing tables for hijacks, certificate transparency logs for unauthorised certificate issuance, and TLS downgrade attempts in your firewall logs. The better investment is prevention — deploying hybrid PQC key exchange makes HNDL irrelevant for protected traffic.

🛡️ Protection Priority — Where to Start

You cannot protect everything at once. Prioritise based on data sensitivity lifetime and adversary interest. Start with the traffic that is most valuable and longest-lived.

Priority	Traffic / Data Type	Action	Tool / Standard	Effort
1 — Now	Classified / sensitive government traffic	Enable hybrid PQC TLS (ML-KEM-768 + X25519)	OpenSSL 3.5+, nginx with X25519MLKEM768	Medium
2 — Now	VPN tunnels for remote access to sensitive systems	Deploy hybrid PQC IKEv2 or WireGuard with PQC extension	StrongSwan with ML-KEM, WireGuard PQC fork	Medium
3 — Now	SSH to critical servers	Enable sntrup761x25519-sha512 hybrid KEX in OpenSSH	OpenSSH 9.0+ — already installed on Ubuntu 22.04	Low
4 — Q3 2025	Email encryption (S/MIME, PGP)	Begin evaluation — standards not yet finalised for email	OpenPGP PQC draft RFC, S/MIME PQC IETF draft	Medium
5 — 2026	Code signing / software supply chain	Add ML-DSA parallel signature to existing signing pipeline	Sigstore PQC, ML-DSA-65 in signing tool	Medium
6 — 2026-27	Internal PKI / CA certificates	Plan hybrid PQC CA — issue dual classical+PQC certificates	EJBCA PQC mode, Bouncy Castle FIPS	High
7 — 2027+	Application-level encryption (databases, file systems)	Migrate from RSA wrapping to ML-KEM key wrapping	Depends on application crypto library	High

Immediate action — enable hybrid SSH (5 minutes)

# Ubuntu 22.04 / Debian — OpenSSH 9.0+ already installed
# Enable hybrid PQC key exchange — edit /etc/ssh/sshd_config

grep -q "sntrup761x25519" /etc/ssh/sshd_config || \
echo "KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,ecdh-sha2-nistp256" \
>> /etc/ssh/sshd_config

systemctl reload sshd

# Verify hybrid KEX is active
ssh -vvv your-server 2>&1 | grep "kex: algorithm"
# Expected output: kex: algorithm: sntrup761x25519-sha512@openssh.com

This single change protects all SSH sessions established after the change against HNDL — even if a CRQC decrypts the session key exchange parameters, the sntrup761x25519 hybrid ensures the session remains encrypted.