Quantum-safe encryption, also called quantum-secure or quantum-resistant encryption, is cryptography that stays secure against an attacker with a large quantum computer. Symmetric algorithms such as AES-256 and hash functions such as SHA-256 already qualify; the public-key algorithms RSA, Diffie-Hellman and elliptic curves do not, and are being replaced by post-quantum algorithms, chiefly ML-KEM for key exchange and ML-DSA or SLH-DSA for signatures. In practice a quantum-safe connection uses a hybrid key exchange combining a classical and a post-quantum algorithm to agree a key, then encrypts with AES-256. Current browsers, Signal, iMessage and OpenSSH already do this for key exchange.
The three terms are marketing-friendly and appear on products of varying honesty, so it pays to know exactly what they should mean. This guide defines quantum-safe encryption, lists which algorithms qualify at each layer, walks through how a quantum-safe connection works end to end, surveys where it is already deployed, notes what is not yet migrated, and gives a short procedure for evaluating any product's quantum-safe claim.
Definitions: safe, secure, resistant
The three adjectives are interchangeable in practice. All mean that the best known attack, whether run on a classical or a quantum computer, requires infeasible effort. No cryptography is provably unbreakable in an absolute sense; quantum-safe means that the algorithm is not broken by the quantum algorithms known to break current public-key schemes, Shor's algorithm above all, and retains a large security margin against Grover's search speedup. The quantum computers guide on this site explains those algorithms.
Post-quantum cryptography is the name for the new public-key algorithms specifically; quantum-safe encryption is the broader term covering an entire system, including the symmetric parts that never needed replacing.
Which algorithms are quantum-safe at each layer
| Layer | Quantum-safe | Not quantum-safe alone |
|---|---|---|
| Key exchange | ML-KEM, HQC, hybrids including them | RSA key transport, Diffie-Hellman, ECDH, X25519 |
| Signatures | ML-DSA, SLH-DSA, FN-DSA, stateful hash-based schemes | RSA, DSA, ECDSA, Ed25519 |
| Bulk encryption | AES-256, ChaCha20-Poly1305, AES-192 | AES-128 marginal for long-term secrecy |
| Hashing | SHA-256, SHA-384, SHA-512, SHA-3 | MD5 and SHA-1, broken classically anyway |
| Key derivation | Argon2, PBKDF2 and scrypt with strong inputs | Weak passwords, regardless of algorithm |
The classical public-key algorithms in the right-hand column are not weak today. They are secure against every computer that exists, and they remain in use as one half of hybrid schemes. They are listed as not quantum-safe because a future quantum computer would break them, which matters for data that must stay secret beyond that point.
How a quantum-safe connection works end to end
Take a browser connecting to a website that supports post-quantum TLS.
- Key exchange. The browser and server perform a hybrid exchange: X25519 elliptic-curve Diffie-Hellman and ML-KEM in parallel, as the post-quantum cryptography guide on this site diagrams. Both shared secrets are combined into the session keys. An attacker recording the handshake would need to break both.
- Authentication. The server proves its identity with a certificate signed by a classical algorithm, typically ECDSA or RSA. This step is not yet quantum-safe, but it only needs to be by the time a quantum computer exists, since forging a signature after the fact does not help decrypt a past session.
- Bulk encryption. Data flows under AES-256-GCM or ChaCha20-Poly1305, both quantum-safe.
- Integrity. Message authentication uses the same authenticated encryption, and the handshake transcript is hashed with SHA-256 or SHA-384, quantum-safe.
The recorded traffic of this connection cannot be decrypted by a future quantum computer, because the session key was protected by ML-KEM. That is the property harvest-now-decrypt-later attacks target, and it is what quantum-safe key exchange denies them.
The same pattern applies elsewhere. A messaging protocol adds a post-quantum key agreement to its initial handshake and, in Signal's case, to ongoing ratcheting. An SSH connection negotiates a hybrid key exchange method. A VPN using WireGuard can pre-share a symmetric key agreed by a post-quantum mechanism, or use implementations that add a post-quantum handshake. A file encrypted with age or GPG using a passphrase is symmetric throughout and already quantum-safe; a file encrypted to a recipient's RSA or elliptic-curve public key is not.
Where quantum-safe encryption is already deployed
Web browsing. Major browsers enable hybrid X25519 plus ML-KEM key exchange by default, and large content networks, cloud providers and many popular sites support it on the server side. A substantial share of HTTPS connections from current browsers are already quantum-safe in their key exchange. You can verify with your browser's developer tools or a test site that reports the negotiated group.
Messaging. Signal introduced a post-quantum extension to its key agreement protocol and later to its ratcheting, and iMessage introduced a protocol with post-quantum key establishment and ongoing rekeying. The messaging guides on this site cover these apps.
SSH. OpenSSH added a hybrid post-quantum key exchange and made a version of it the default in recent releases, so administrators connecting to updated servers are protected without configuration.
VPNs. Several VPN providers and open-source projects offer post-quantum key exchange options, and WireGuard-based services can layer a post-quantum pre-shared key. The VPN guides on this site cover choosing a provider; asking about post-quantum support is now a reasonable question.
Operating systems and libraries. Major TLS libraries, operating system crypto frameworks and cloud key management services have added ML-KEM and ML-DSA, so applications inherit support as they update.
What is not yet migrated
Certificates and code signing remain classical, because the public key infrastructure involves many parties and post-quantum signatures are large. Post-quantum certificates are being specified and tested. Long-lived public-key encrypted data, such as PGP-encrypted archives and email, remains vulnerable to future decryption; OpenPGP post-quantum extensions are in progress. Hardware security keys and passkeys use classical elliptic-curve signatures, which is acceptable for authentication since forgery only matters at login time, and post-quantum FIDO extensions are under development. Embedded and constrained devices lag because of key sizes.
For an individual, the practical gaps are public-key encrypted archives, which can be re-encrypted symmetrically, and any service that has not updated, which is a reason to prefer actively maintained software.
Evaluating a quantum-safe claim
When a product says quantum-safe, quantum-secure or quantum-resistant, ask four things.
- Which algorithm? A real answer names a standardised post-quantum algorithm such as ML-KEM or ML-DSA, or points to AES-256 for a purely symmetric product. Vague references to quantum technology or proprietary algorithms are red flags, and a reference to quantum key distribution for a consumer product means the vendor is confused or hoping you are.
- Where in the protocol? Key exchange is the part that matters now. A product that uses AES-256 for storage but RSA for sharing keys is quantum-safe at rest and not in transit.
- Hybrid or pure? Hybrid with a classical algorithm is current best practice; pure post-quantum is acceptable for some uses but shows less caution.
- Is it on by default? An option nobody enables protects nobody.
A product that answers all four clearly is making a genuine claim. One that cannot is using the phrase as decoration.
A six-point checklist
- Use AES-256 for files and disks that must stay secret for decades.
- Keep browsers, operating systems and messengers updated; that is how post-quantum key exchange arrives.
- Prefer services that document post-quantum support, and ask VPN providers about it.
- Re-encrypt long-lived archives that were encrypted to RSA or elliptic-curve keys with a symmetric passphrase or a post-quantum tool.
- Treat quantum-safe marketing without a named algorithm as ordinary encryption.
- Do not panic about signatures and passkeys; they migrate on a longer, appropriate timeline.
What standards bodies, vendors and cryptographers say
The account above follows published standards and deployment announcements.
Standards and security agencies define quantum-resistant cryptography as algorithms secure against both classical and quantum attack, list AES-256 and the SHA-2 and SHA-3 families as remaining secure, and identify RSA, Diffie-Hellman and elliptic-curve algorithms as requiring replacement with the standardised post-quantum schemes.
Browser vendors, Signal, Apple and the OpenSSH project have each documented deployment of hybrid post-quantum key exchange in their products, describing the goal as protecting current traffic against future decryption.
Cryptographers advise hybrid deployment while confidence in new algorithms matures, describe signatures and certificates as the slower phase of the transition, and caution against products that use quantum terminology without specifying algorithms.
Most of the work is already done for you
Quantum-safe encryption sounds exotic and is, in practice, a software update. Your browser, your messenger and your SSH client have very likely already switched their key exchange; your AES-256 files were never at risk. What remains is to keep everything current, re-encrypt any old public-key archives, and hold vendors to a named algorithm when they use the phrase. The purpose guide on this site explains why this migration is worth caring about even though the machine does not yet exist.
Frequently asked questions
What is quantum-resistant encryption?
Cryptography that remains secure against attackers with a large quantum computer. It includes symmetric algorithms such as AES-256, which are already resistant, and post-quantum public-key algorithms such as ML-KEM and ML-DSA that replace RSA and elliptic curves. Quantum-safe, quantum-secure and quantum-resistant are used interchangeably.
How does quantum-safe encryption work?
The public-key step that agrees a session key uses a post-quantum algorithm, usually ML-KEM, often in hybrid with a classical elliptic-curve exchange so both must be broken. The agreed key then encrypts data with AES-256 or ChaCha20, which are already quantum-resistant. The result is a connection whose recorded traffic cannot be decrypted by a future quantum computer.
Which encryption algorithms are quantum-safe?
For key exchange, ML-KEM and other standardised post-quantum mechanisms. For signatures, ML-DSA, SLH-DSA and FN-DSA. For bulk encryption, AES-256 and ChaCha20. For hashing, SHA-256, SHA-3 and SHA-512. RSA, Diffie-Hellman, ECDH, ECDSA and Ed25519 are not quantum-safe on their own, though they remain secure today and are used in hybrids.
Do I already have quantum-safe encryption?
Probably in part. Current versions of major browsers negotiate hybrid post-quantum key exchange with servers that support it, which includes many large sites. Signal and iMessage use post-quantum key agreement. OpenSSH defaults to a hybrid post-quantum exchange in recent versions. Your files encrypted with AES-256 are already safe. Signatures and certificates are still classical.
Is AES-256 quantum-safe?
Yes, for practical purposes. A quantum computer running Grover's algorithm reduces the work to break AES-256 to about 2 to the power of 128 operations, which is still infeasible. AES-128 drops to about 2 to the power of 64 quantum operations, which is why AES-256 is recommended for data that must stay confidential for decades.
Last reviewed and updated on . Plain text version: /encryption/quantum-safe-encryption.txt.
