← Back to main

Migration Guide

Step-by-step migration paths from legacy or broken algorithms to modern replacements. Ordered by priority — critical migrations first.

CRITICAL

MD5 anywhereSHA-256

Why migrate: MD5 has been collision-broken since 2004 (Xiaoyun Wang et al.). Practical chosen-prefix collisions demonstrated in 2009. Used to forge rogue CA certificates. No remaining security margin.
View SHA-256
HIGH

SHA-1 anywhereSHA-256 or BLAKE3

Why migrate: SHA-1 collision was demonstrated in 2017 (SHAttered attack, Google/CWI). Chosen-prefix collisions published in 2020 (SHA-1 is a Shambles). All major browsers and CAs have deprecated SHA-1 certificates.
View SHA-256 or BLAKE3
HIGH

PBKDF2 or bcryptArgon2id

Why migrate: PBKDF2 is not memory-hard — a GPU can run thousands of PBKDF2 instances in parallel with minimal memory. bcrypt is better (Blowfish key schedule is memory-bound) but truncates passwords at 72 bytes and has no parallelism resistance tuning. Argon2id provides memory hardness, GPU/ASIC resistance, and side-channel resistance in one algorithm.
View Argon2id
HIGH

AES-CBC + separate HMACAES-256-GCM (AEAD)

Why migrate: AES-CBC without authentication is vulnerable to padding oracle attacks (Vaudenay 2002), which recover full plaintext. Even with a separate HMAC, the encrypt-then-MAC composition must be implemented exactly right — MAC-then-encrypt (the wrong order) leaves the padding oracle open.
View AES-256-GCM (AEAD)
MEDIUM

RSA-2048 signaturesEd25519

Why migrate: RSA-2048 provides ~112 bits of classical security — adequate until ~2030 per NIST guidance, but below modern minimums for new systems. Ed25519 provides 128-bit classical security with 64-byte signatures (vs. 256-byte RSA signatures), deterministic nonce generation (eliminating a major class of ECDSA bugs), and significantly faster signing and verification.
View Ed25519
MEDIUM

X25519-only key exchangeX25519 + ML-KEM-768 hybrid

Why migrate: X25519 is classically secure but provides zero post-quantum security. Shor's algorithm on a sufficiently large quantum computer would break all elliptic curve key exchange. The harvest-now-decrypt-later threat means data encrypted today under classical-only key exchange may be retroactively compromised.
View X25519 + ML-KEM-768 hybrid
HIGH

TLS 1.0 / 1.1TLS 1.3

Why migrate: TLS 1.0 and 1.1 are deprecated by IETF (RFC 8996, March 2021) and removed from all major browsers. They support weak cipher suites, lack forward secrecy by default, and are vulnerable to BEAST, POODLE, Lucky13, and FREAK attacks. PCI-DSS prohibited TLS 1.0 since June 2018.
View TLS 1.3
HIGH

Static RSA key exchangeForward-secret (ECDHE) via TLS 1.3

Why migrate: Static RSA key exchange encrypts the pre-master secret with the server's RSA public key. If the server's private key is ever compromised — by theft, legal order, or vulnerability — every past session encrypted under that key can be decrypted retroactively. TLS 1.3 eliminates static RSA key exchange entirely, mandating ephemeral (EC)DHE.
View Forward-secret (ECDHE) via TLS 1.3

See how these algorithms fit into complete stacks.

View Stacks →