What quantum breaks, and where your app uses it.
Shor's algorithm breaks the public-key cryptography behind key exchange, signatures and tokens. NightVision finds each place your application chooses it and names the post-quantum replacement.
A large quantum computer running Shor's algorithm breaks RSA, DSA, Diffie-Hellman and the elliptic-curve schemes ECDH, ECDSA, EdDSA and X25519. That covers most key exchange, most digital signatures and the JWT algorithms RS256, PS256, ES256 and EdDSA. AES and ChaCha20 with 128-bit keys or more, and SHA-256 and above, are not in that group. NIST has standardized ML-KEM (FIPS 203) and ML-DSA (FIPS 204) to replace the vulnerable schemes.
Two hard problems, one algorithm that solves both
Public-key cryptography rests on problems that classical computers solve slowly. RSA depends on factoring a large number. Diffie-Hellman and DSA depend on the discrete logarithm. ECDH, ECDSA, EdDSA and X25519 depend on the same problem over an elliptic curve.
Shor's algorithm solves both problems efficiently on a large enough quantum computer. Larger keys raise the cost of the attack but do not change the outcome, so the fix is a different family of algorithms, not a bigger RSA modulus.
Symmetric cryptography holds up. NIST IR 8547 judges the approved symmetric primitives with at least 128 bits of classical security, such as AES-128 and above and SHA-256 and above, to meet at least its lowest post-quantum security category. NightVision does not report them, so the quantum findings stay on public-key choices.
- RSAencryption and signatures
- DSAsignatures
- DHkey agreement
- ECDH, X25519key agreement
- ECDSA, EdDSAsignatures
- AES-128 and upblock cipher
- ChaCha20stream cipher
- SHA-256 and uphash
- HMAC-SHA-256message authentication
- ML-KEM, ML-DSApost-quantum keys
Encryption and key exchange come first
An attacker does not need a quantum computer today to profit from one later. Encrypted traffic and stored ciphertext can be recorded now and decrypted once the machine exists. NIST calls this the harvest now, decrypt later threat. Anything protected by RSA encryption or a Diffie-Hellman style key agreement today stays exposed for as long as the data stays sensitive.
Signatures run on a different clock. NIST IR 8547 notes that an authentication system stays secure as long as its algorithms and keys are secure when the authentication is performed. A forged signature needs the quantum computer at the time of the attack, so long-lived signing keys, certificates and tokens need a plan, but recorded traffic is the more urgent exposure.
NightVision's severities follow that order. A quantum-vulnerable choice used for encryption or key establishment is rated medium. One used for a signature is rated low. Choices that are already broken today, such as MD5 on a password or certificate verification turned off, are rated high and come before either. Those are covered on weak cryptography today.
Where quantum-vulnerable cryptography shows up in an app
Each row is a family Shor's algorithm breaks, the places NightVision finds it, how the finding is rated, and what NIST has standardized to replace it.
| Algorithm family | Where it shows up | Weakness and severity | Replace with |
|---|---|---|---|
| RSA encryptionkey transport, JWE key wrapping | JWE headers with RSA-OAEP or RSA1_5, RSA keys generated in code, committed RSA private and public keys |
quantum-vulnerableMedium |
ML-KEM FIPS 203 |
| Diffie-Hellman, ECDH, X25519key agreement | DH and X25519 keys generated in code, JWE headers with ECDH-ES, committed DH PARAMETERS blocks |
quantum-vulnerableMedium |
ML-KEM FIPS 203 |
| RSA signaturesRS256, RS384, RS512, PS256 | jwt.encode(..., algorithm="RS256"), SimpleJWT and Flask-JWT-Extended settings, OpenID Connect ID tokens, certificates and SSH keys |
quantum-vulnerableLow |
ML-DSA FIPS 204 |
| ECDSA and EdDSAES256, ES384, EdDSA, Ed25519 | EC and Ed25519 keys generated in code, jwcrypto EC and OKP keys, ES256 token settings, EC certificates and SSH keys |
quantum-vulnerableLow |
ML-DSA FIPS 204 |
| DSAsignatures | DSA keys generated in code, committed DSA private keys | quantum-vulnerabledeprecated |
ML-DSA FIPS 204 |
| AES, ChaCha20, SHA-256 and upsymmetric ciphers and hashes | Anywhere | Not reported | Keep them |
JWT signing algorithms count
A JWT's alg header names a signature scheme. RS256, RS384 and RS512 are RSA signatures, and PS256 and its siblings are RSA-PSS. ES256, ES384 and ES512 are ECDSA, and EdDSA is an Edwards-curve signature. All of them are public-key signatures, so all of them are quantum-vulnerable. HS256 is an HMAC with SHA-256, a symmetric construction, and is not in this group.
Tokens are easy to miss in an inventory because the algorithm is often one string in a settings file. NightVision reads it in PyJWT and python-jose calls, jwcrypto headers and keys, Django REST framework SimpleJWT's ALGORITHM, Flask-JWT-Extended's JWT_ALGORITHM and JWT_DECODE_ALGORITHMS, and django-oauth-toolkit's OpenID Connect setup, which signs ID tokens with RS256.
When the algorithm is only the default of an environment variable, as in os.getenv("JWT_ALGORITHM", "RS256"), the finding names the variable, since a deployment may set it to something else. JWE key establishment is read too: RSA-OAEP, RSA1_5 and ECDH-ES in a jwcrypto header protect the token's content key with a quantum-vulnerable scheme.
One finding, ready for an owner
Each finding says where the choice is written and what it is, then why it is weak and what to choose instead.
- Where: the rule, the file, line and column, and the function it sits in.
- What: the role it plays (signature, key agreement, encryption), the algorithm, and the key size or curve when the source fixes one.
- Why: the weakness, a severity and confidence, a plain reason, and the NIST or IETF reference.
- When: the years after which NIST deprecates and disallows it, where NIST has scheduled them.
- Tracking: a fingerprint that stays the same when code elsewhere in the file moves.
Code and framework settings are read in Python today. Committed keys, certificates and SSH keys are read in any language; see keys, certificates and TLS. A finding never holds key material, only an algorithm, a size or a curve.
fingerprint c41e7a0d92b5f318
Reason
RS256 signs with RSA, public-key cryptography that Shor's algorithm breaks. NIST IR 8547 deprecates it at 112 bits of security after 2030 and disallows it after 2035.
Remediation
Plan the move to ML-DSA (FIPS 204) for token signatures.
What to move to
NIST published both replacement standards as final on August 13, 2024. Each finding names the one that fits the use it found.
ML-KEM for key establishment
A module-lattice key-encapsulation mechanism. It takes the place of RSA encryption and key transport, Diffie-Hellman, ECDH and X25519: the uses that harvest now, decrypt later puts at risk first.
ML-DSA for signatures
A module-lattice digital signature algorithm. It takes the place of RSA, DSA, ECDSA and EdDSA signatures, including the JWS algorithms your tokens are signed with.
The practical first step is the inventory. The NIST PQC timeline covers the dates and a migration checklist.
Questions about quantum-vulnerable cryptography.
Which algorithms does Shor's algorithm break?
RSA, DSA, Diffie-Hellman, ECDH, ECDSA, EdDSA and X25519, and the protocols and token formats built on them, including the JWT signing algorithms RS256, PS256, ES256 and EdDSA.
Are AES and SHA-256 quantum-vulnerable?
Not in the way that drives a migration. NIST IR 8547 judges approved symmetric primitives with at least 128 bits of classical security, such as AES-128 and above and SHA-256 and above, to meet at least its lowest post-quantum security category. NightVision does not report them.
Why are signatures rated lower than key exchange?
Traffic protected by a quantum-vulnerable key exchange can be recorded today and decrypted later. A signature can only be forged once a quantum computer exists, so NightVision rates quantum-vulnerable encryption and key establishment medium and signatures low.
Is HS256 quantum-vulnerable?
No. HS256 is an HMAC with SHA-256, a symmetric construction. RS256, PS256, ES256 and EdDSA are public-key signatures and are quantum-vulnerable.
Which languages does NightVision cover?
Code and framework settings are analyzed in Python today. Committed private and public keys, certificates and SSH keys are read in any language, along with TLS configuration and cryptography dependencies.
Where does this run today?
It runs in the NightVision CLI today: add the --weak-crypto flag to nightvision openapi extract and the report is written beside the API spec that source intelligence generates. The --no-upload flag sends nothing to NightVision. Viewing and tracking these findings in the NightVision platform is in development.
Find the public-key cryptography in your code.
Get every quantum-vulnerable choice in your applications, rated by what it protects, with the replacement for each.