On September 8, 2026, Cloudflare flipped the switch on post-quantum TLS origin handshakes across its edge. Two days later, on September 10, 1.1.1.1 enabled post-quantum DNSSEC powered by NIST's ML-DSA-44 algorithm. The numbers are not small: the TLS deployment alone now covers roughly 45 billion daily connections.
If you saw that headline and immediately opened your code editor to grep for md5 and sha256 — this post is for you. If you saw it and shrugged because you only use hashing for "checksumming" — this post is also for you.
If that's you — this is roughly what your terminal looks like right now:
$ rg -n "md5|sha256" src/ --color=always | head -20
src/main.c:1: fprintf(stderr, "ERROR: Unsupported hash function: %s\n", hash_type);
src/CMakeLists.txt:21: target_compile_options(${PROJECT_NAME} PRIVATE
-Werror=deprecated-declarations)
src/Rust/Cargo.toml:45: version = "0.1.1"
src/Rust/Cargo.toml:46: md5 = "0.10.0"
src/Rust/Cargo.toml:47: sha256 = "0.9.0"
src/Rust/src/lib.rs:120: let hash = md5::compute(data);
src/Rust/src/lib.rs:11: let hash = sha2::Sha256::digest(data);
src/scripts/build.sh:15: if ! command -v openssl &> /dev/null; then
src/scripts/build.sh:15: if ! command -v sha256sum &> /dev/null; then
src/scripts/build.sh:12: echo "ERROR: Neither openssl nor sha256sum found!" >&2
src/scripts/util.sh:35: md5sum "$file" | awk '{print $1}'
src/scripts/util.sh:36: sha256sum "$file" | awk '{print $1}'
(That's not a snippet from a real repo, but the panic it captures is.)
The short version: most of the tools you already use are fine. The panic comes from confusing hashes with encryption, and from using encryption when you actually needed a checksum.
Let's untangle that.
The panic that doesn't help
Here's what happened in a few Discord servers I read this week:
"Should I migrate from MD5 to SHA-256? Grover's algorithm makes SHA-256 only 128-bit secure anyway. Should I just go to SHA-3?"
"Should I rotate all my UUIDs to UUIDv7?"
"Is base64 still safe?"
These are reasonable questions if you don't know the answer. They are also three different categories of mistake.
MD5, SHA-1, and SHA-256 are hash functions. They produce a fixed-size fingerprint from any input. The reason they exist is not to keep secrets — it's to verify that data didn't change in transit. A 1GB ISO file you downloaded can be checksummed with any of them; the question is "did the bytes arrive intact", not "can someone read the bytes".
Base64 is an encoding, not encryption. It exists so that binary data can travel through channels (JSON, URL paths, email) that only support text. There is no key. There is no "secure" mode. Anyone who tells you base64 is "encrypted" is selling you snake oil.
UUID v4 is a random identifier, 122 bits of randomness. It's not a hash, not an encryption — it's a label. Whether quantum computers threaten it depends on whether you used a cryptographic random number generator (good) or Math.random() (you have bigger problems than Grover).
So when Cloudflare ships post-quantum TLS, here's what's actually happening at the protocol level:
- The TLS handshake negotiates session keys using a key exchange algorithm that a quantum computer cannot efficiently break.
- Everything inside that TLS tunnel — your HTTP traffic, your JSON, your base64-encoded blobs — is still protected by classical symmetric ciphers (AES-256-GCM, ChaCha20) and authenticated by classical hashes (SHA-256, SHA-384).
- The risk model is "harvest now, decrypt later": an adversary records encrypted traffic today, waits for a cryptographically-relevant quantum computer (CRQC), then decrypts it. That's the threat post-quantum key exchange is closing.
Your MD5 checksum tool does not enter this picture.
What each tool is actually for
Since I built AI Subtools — a no-fluff browser-side toolbox — here's the honest guide. Same tool, different intent:
| Tool | What it does | Threat model | Replace with PQC? |
|---|---|---|---|
| CRC32 Checksum Generator | Fast integrity check on small files / packets | Accidental corruption | No — error-detection, not security |
| MD5 Hash Generator | Legacy checksum, fingerprint for deduplication | Accidental corruption | No, for the same reason |
| SHA256 Hash Calculator | Strong fingerprint for file integrity / commit hashes | Accidental corruption | Optional — SHA-256 is fine for non-adversarial checks |
| Base64 Encoder/Decoder | Binary ↔ text transport | None — it's encoding | No — never was security |
| URL Encoder/Decoder | Make strings safe for URLs | None | No |
| UUID v4 Generator | Random 122-bit ID | Collision, predictability | No, if you use crypto.getRandomValues
|
| Password Strength Check | Estimate entropy of a passphrase | Dictionary attack | The length matters, not the hash |
| Random Password Generator | High-entropy secrets | Predictability | No, if CSPRNG-backed |
| Encrypt/Decrypt (AES-256) | Symmetric encryption, browser-side | Adversary steals ciphertext | No — AES-256 is post-quantum-safe |
The last row is the only one where a quantum computer would matter at all, and even then: Grover's algorithm gives a quadratic speedup, which means AES-256 effectively becomes AES-128 — still considered computationally infeasible to break. NIST standardized it for exactly that reason.
So when do you actually need post-quantum?
There are exactly three situations where PQC migration matters for the average developer:
- You run a TLS server. Migrate your server library to support hybrid Kyber/X25519 key exchange (OpenSSL 3.5+, BoringSSL, rustls 0.23+). Cloudflare already did this for you if your users connect via their edge.
- You sign software or firmware updates. Classic ECDSA signatures are quantum-broken. Migrate to ML-DSA-44 / Dilithium for new releases; consider re-signing historical binaries if your threat model includes harvest-now-decrypt-later.
- You embed long-lived secrets in firmware or code signing certificates. Anything with a 10+ year shelf life needs a PQC plan now.
Everything else — your file checksums, your base64-encoded JSON payloads, your UUIDs, your SHA-256 commit hashes — is already fine.
A simple decision tree
When you reach for one of these tools, ask one question: am I protecting against bit-flips, or against an adversary?
- Bit-flips only (corrupted download, broken pipe, accidental edit) → CRC32, MD5, SHA-256. Any of them. CRC32 is fastest; SHA-256 is most defensible.
- Adversary who can read but not modify → AES-256 encryption. Done.
- Adversary who can read and modify → authenticated encryption (AES-GCM) or HMAC over the ciphertext.
- Adversary with a quantum computer who recorded your traffic years ago → PQC key exchange at the protocol layer (already handled by Cloudflare, AWS, GCP, Fastly, Akamai in 2026).
That's it. No framework. No vendor lock-in.
FAQ
Q: Is MD5 broken?
Yes, but not for checksumming. Collision attacks against MD5 mean you can craft two different files with the same MD5 — useful for forging signatures, useless for catching accidental corruption. Use MD5 for cache keys, deduplication, and legacy file verification. Don't use it for digital signatures — that hasn't been safe since 2008.
Q: Should I switch to SHA-3 for file integrity?
No reason to. SHA-256 is fine for non-adversarial integrity. The actual quantum risk lands on digital signatures and key exchange, not on file checksums.
Q: Is base64 encryption?
No. It is an encoding. There is no key. Anyone — including this page's CSS — can decode it. If someone tells you they "encrypted it with base64", they did not.
Q: Is UUID v4 quantum-safe?
UUID v4 is 122 bits from a CSPRNG. Brute-forcing 122 bits is computationally infeasible even with Grover's algorithm — you'd need ~2^61 operations, which is more atoms than in a kilogram of lead. As long as your UUID generator uses a cryptographic random source, you're fine.
Q: What about AES-256?
Post-quantum-safe by design. Grover halves effective key length to 128 bits. NIST confirmed AES-256 is acceptable for top-secret data through the post-quantum era.
Closing thought
Cloudflare's PQC deployment this week was an infrastructure milestone, not a consumer panic trigger. The right response is to make sure your TLS library supports hybrid post-quantum key exchange — not to throw out your hash functions.
If you're picking a tool for a one-off task today, pick the one that matches the threat model, not the trend.
— Built and maintained at aisubtools.xyz — 40+ free browser-side tools for developers and creators.
Top comments (2)
The inventory should classify each use of a primitive by security property, not by function name. A checksum, password verifier, signature, and key-derivation path have different migration urgency; recording that intent beside the dependency is what turns a grep result into a defensible plan.
Couldn’t agree more. This is exactly the trap the article calls out — engineers see sha256 in the code and assume it all needs urgent replacement. Recording intent next to each crypto primitive turns a naive inventory into a prioritized migration plan.