Skip to content

Proton Mail Adds Post-Quantum Encryption for New Emails to Counter Harvest-Now-Decrypt-Later Attacks

Proton Mail has added optional post-quantum encryption for new emails sent between Proton Mail accounts, protecting against harvest-now-decrypt-later (HNDL) attacks in which adversaries collect encrypted communications today with the intention of decrypting them when sufficiently powerful quantum computers become available. The feature uses the CRYSTALS-Kyber (ML-KEM) algorithm standardised by NIST in 2024. Existing encrypted emails are not retroactively re-encrypted.

Article security-architecture

Proton Mail has announced the availability of post-quantum encryption for emails sent between Proton Mail accounts, using the CRYSTALS-Kyber (formally standardised as ML-KEM under NIST FIPS 203 in 2024) algorithm for key encapsulation. The feature is available as an opt-in beta for Proton Mail users and is enabled on a per-account or per-conversation basis.

The implementation uses a hybrid approach: messages are encrypted with both a classical RSA or Elliptic Curve key exchange and a Kyber (ML-KEM) key encapsulation, providing protection against quantum-capable adversaries while maintaining compatibility with current infrastructure. An attacker would need to break both the classical and post-quantum encryption independently β€” with the classical algorithm maintaining current security and Kyber providing quantum resistance.

Why Post-Quantum Email Encryption Matters Now

The common misconception about post-quantum cryptography is that it only matters when quantum computers that can break current encryption actually exist. This is incorrect for communications that need long-term confidentiality.

The harvest-now-decrypt-later (HNDL) threat model describes adversaries β€” primarily nation-state intelligence agencies β€” that collect and store encrypted communications today with the intention of decrypting them when cryptographically relevant quantum computers (CRQCs) become available. If a sufficiently powerful quantum computer capable of breaking RSA-2048 or ECC-256 keys is available in 10–20 years, any communications encrypted today with these algorithms that were archived by an adversary become retroactively decryptable.

For communications requiring confidentiality over a multi-decade horizon β€” classified government information, sensitive business negotiations, health records, legal proceedings β€” HNDL is an active threat, not a theoretical future concern. Intelligence agencies known to operate large-scale communications interception programmes are assumed to be archiving encrypted traffic today.

Proton Mail’s primary user base includes individuals and organisations with higher-than-average HNDL risk: journalists with confidential sources, whistleblowers, human rights advocates, legal professionals, and businesses with sensitive long-term commercial communications.

Technical Implementation

Proton Mail’s implementation follows the hybrid encryption approach recommended by NIST and NSA:

  1. Classical key exchange: RSA-4096 or X25519 (depending on account key type) for the key exchange component β€” maintaining current protection against classical cryptographic attacks
  2. ML-KEM-768 key encapsulation: NIST FIPS 203 ML-KEM (formerly Kyber-768) for the post-quantum key encapsulation, providing quantum resistance
  3. Combined session key: The classical and ML-KEM-derived key material is combined using HKDF to produce the AES-256 session key used to encrypt the message body
  4. AES-256-GCM: Message content encrypted with AES-256 in GCM mode β€” unchanged from Proton’s existing encryption

The hybrid approach means that breaking the encryption requires breaking both the classical RSA/ECC component (infeasible with current computers) AND the ML-KEM component (infeasible with a quantum computer) β€” providing security against both current classical and future quantum attackers simultaneously.

Limitations

Opt-in: Post-quantum encryption is not enabled by default in the initial rollout. Users must enable it in account settings.

Proton-to-Proton only: The feature applies to emails between Proton Mail accounts. Emails sent to or received from non-Proton email addresses (Gmail, Outlook, etc.) use Proton’s standard encryption for inbound and standard SMTP for outbound, without post-quantum protection β€” reflecting the technical reality that non-Proton servers cannot participate in the ML-KEM key exchange.

No retroactive re-encryption: Existing encrypted emails stored in Proton accounts are not retroactively re-encrypted with post-quantum protection. Only new messages created after enabling the feature receive PQC protection.

Context: Industry Momentum

Proton’s announcement follows similar moves by other providers. Signal enabled post-quantum key agreement (PQXDH) in 2023. Apple added PQ3 post-quantum encryption to iMessage in 2024. Google Cloud’s internal infrastructure began migrating to hybrid post-quantum key exchange in 2023. The NSA has mandated PQC algorithm migration for national security systems by 2030.

The NIST PQC standardisation process β€” which finalised ML-KEM, ML-DSA, and SLH-DSA in August 2024 β€” provides the stable algorithmic foundation that deployment now requires. Organisations with data confidentiality requirements measured in decades should assess whether their current encryption posture accounts for the HNDL threat.

Share this article

Related Intelligence

πŸ›οΈ Architecture

NSA's January 2027 PQC Deadline Is Nine Months Away β€” Enterprise Migration Is Now Mandatory

With NIST's post-quantum cryptography standards finalised and the NSA's CNSA 2.0 deadline requiring all new National Security System acquisitions to be quantum-resistant by January 2027, the migration window for enterprise and federal contractor environments is closing fast. Most organisations have yet to inventory their cryptographic assets, let alone begin migration.

#post-quantum +7
πŸ›οΈ Architecture

OpenSSH CVE-2026-35414 β€” Certificate Authentication Bypass via Comma Bug Grants Root Access

A single-character defect in OpenSSH's certificate Subject Alternative Name parsing allows an attacker with a maliciously crafted certificate to bypass host-based and user certificate authentication entirely, potentially gaining unauthorised access to systems relying on certificate-based SSH for privileged access. Researchers have named the vulnerability SplitSSHell. Operators using OpenSSH certificate authentication for root or privileged user access should review their CA trust chains immediately.

#openssh +6
πŸ›οΈ Architecture

CVE-2026-5194: Critical wolfSSL Flaw Enables Certificate Forgery Across 5 Billion Devices

A critical cryptographic validation flaw in wolfSSL, a lightweight TLS library embedded in billions of IoT devices, routers, industrial control systems, and automotive components, allows attackers to present forged X.509 certificates that pass signature verification without a legitimate private key. The vulnerability enables man-in-the-middle attacks and authentication bypass across an enormous installed base. wolfSSL version 5.9.1, released 8 April 2026, provides the fix.

#cve-2026-5194 +5