NIST's draft transition report lists the quantum-vulnerable public-key schemes: finite-field Diffie-Hellman and MQV, elliptic curve Diffie-Hellman and MQV, RSA key establishment, and the RSA, ECDSA and EdDSA signature algorithms. Symmetric ciphers and hashes at adequate strength are not on that list.
The NIST list
In IR 8547 (initial public draft), Table 4 covers key establishment and Table 2 covers signatures.
Key establishment:
- Finite-field DH and MQV
- Elliptic curve DH and MQV
- RSA key establishment
Digital signatures:
- ECDSA
- EdDSA
- RSA signatures
Each is listed at 112 bits of security strength (deprecated after 2030, disallowed after 2035) and at 128 bits or more (disallowed after 2035).
Where they hide in your stack
You rarely choose these directly. They sit inside other things:
- TLS handshakes: key exchange (ECDHE or RSA) and the server certificate signature.
- SSH: host keys, user keys and key exchange.
- Code signing, package signing and container image signing.
- JWTs and API tokens signed with RS256 or ES256.
- Certificate authorities and internal PKI.
- VPNs, IPsec and WireGuard-style tunnels (check the key exchange used).
- Secure boot chains and firmware signing.
- Email and document signing.
- Database and storage encryption where data keys are wrapped by RSA keys in a key manager.
- Hardware tokens and smart cards.
Not on the list
AES, SHA-2 and SHA-3, HMAC and symmetric KDFs, at 128 bits of classical strength or more, are described by NIST as much less vulnerable. Password hashing is a separate topic and is not changed by this.
How to build your own list
- Search code for crypto library calls and configuration: algorithm names such as RSA, ECDSA, ECDH, X25519, DH, Ed25519.
- Check TLS and SSH configs for allowed key exchanges and signature algorithms.
- List certificates and their key types from your PKI and inventory.
- Pull dependency data to see which crypto libraries you ship and their versions.
- For each item, record data lifetime, owner and who else depends on it.
X25519 and Ed25519 are curve-based, so they belong in this group even though they are modern and fast. Modern does not mean quantum-safe.
When the list is done, sort it by two columns: how long the protected data must stay secret, and who can change the item. Items you control and that protect long-lived data go first. Items controlled by vendors become questions on your next vendor call. Items on hardware you cannot update go to a separate replacement list. That sort turns a long inventory into a short plan, and it keeps the effort proportional to the actual risk.
Quick check
Is X25519 quantum-safe because it is a modern curve?
No. It is an elliptic curve scheme, and elliptic curve key agreement is in the quantum-vulnerable class.
Does a 4096 bit RSA key fix the problem?
Longer keys do not change the category. RSA is listed as quantum-vulnerable regardless of size, so the fix is a different algorithm.
Sources
Last reviewed: 19 October 2026.
