Post-quantum cryptography audit — RSA/ECC/SHA-1 usages flagged by NIST migration guidance
Author: maddykwsCreated Apr 18, 2026Updated Jul 23, 2026
Hi team,
With NIST finalizing post-quantum standards (FIPS 203/204/205) and the recommended migration deadline of 2030, I ran a quick scan of paramiko for quantum-vulnerable cryptography.
Findings (19 total):
| File | Line | Algorithm | Risk |
|---|---|---|---|
| ecdsakey.py | 14, 38, 61 | ECC (SECP256K1/SECP256R1) | CRITICAL |
| kex_ecdh_nist.py | 27, 49 | ECC | CRITICAL |
| rsakey.py | 43, 88, 134, 201, 256 | RSA | CRITICAL |
| pkey.py | 112 | RSA | CRITICAL |
| _util.py | 18 | RSA | CRITICAL |
| _util.py | 42, 67 | SHA-1 | HIGH |
| pkey.py | 88 | AES-128 | MEDIUM |
Why it matters: Shor's algorithm breaks RSA and ECC in polynomial time on a quantum computer. "Harvest now, decrypt later" attacks mean adversaries may already be storing SSH traffic to decrypt once quantum hardware arrives.
Suggested replacements (per NIST):
- RSA/ECC → CRYSTALS-Dilithium (ML-DSA, FIPS 204) for signatures
- Key exchange → CRYSTALS-Kyber (ML-KEM, FIPS 203)
- SHA-1 → SHA-384 or SHA-512
- AES-128 → AES-256
I understand this is a large migration and depends on what the underlying SSH protocol itself standardizes (RFC 9142 / OpenSSH PQC work). Happy to help or provide more detail on any specific file.
Scanned with https://github.com/maddykws/QuantumMigrate
Source: paramiko/paramiko