Quantum Computers Are Not a Threat to 128-bit Symmetric Keys There is no need to update symmetric key sizes as part of the post-quantum transition, due to the details of how Grover's algorithm scales. Most authorities agree.

There are no technical or compliance reasons to double the size of symmetric keys in response to the threat of quantum computers.

This common misunderstanding of Grover's algorithm risks wasting limited resources that should go towards deploying actually urgent post-quantum algorithms.

If you want to learn a lot more (and way more than necessary as a user), this is an excellent resource: www.imperialviolet.org/tourofwebaut...

They're not device-bound, and they sync like your passwords across iCloud or Chrome or 1Password devices.

(One exception: if you store the passkey on a physical security key like a YubiKey.)

If you need to log in from a not-synced device, select this option and scan the QR from a synced phone.

Would you like answers or just pointing out what is not clear? (I don't want to mansplain!)

It's April 2026, 1 year 8 months since FIPS 204.

The IETF TLS WG is busy debating the concept of ML-DSA hybrids, and whether they should be composite, concatenated, or separate. The complexity of hybrid auth is, however, firmly denied.

In the distance, sounds of a pure ML-DSA PKI being built.

👀

Not that I know of, no, sorry.

This is awesome! Great to see more full-time positions for open source maintainers funded by commercial retainers framed around sustainability.

And uh... looks like Geomys might be undercharging!

YES! No more made up severity scores for most CVEs!

Every OSS maintainer I know hated those. (It's basically impossible to give a score to the severity of a vulnerability in a widely used library. They can ~all be low or critical, depending on how they are used.)

This happens all the time btw: engineers do reverse-malicious compliance to argue that teeeechnically something is not compliant, the labs have no idea what it's about, and then someone asks NIST and NIST says "what?? nah that's obviously fine."

Each cycle takes a 2-5 years and many souls.

How it works is that FIPS 140-3 is basically an empty pointer that references paywalled ISO/IEC 19790:2012(E). SP 800-140A/B/C/D/E/F modify/replace Annex A/B/C/D/E/F of that standard, because changing an ISO or FIPS standard is too painful. Annex D, replaced by SP 800-140D, are the Approved Generation and Establishment Methods. SP 800-140D Rev. 2, the latest, is an empty pointer to https://csrc.nist.gov/projects/cmvp/sp800-140d, because changing an SP is too painful. This was all supposed to make FIPS 140 easier by making it a modular ISO standard or something. In practice, none of that matters and the actual standard is the Implementation Guidance, because changing the web page is too painful.

If you feel like that deprives you of FIPS 140-3 madness, you might appreciate this new footnote.

words.filippo.io/fips-hkdf/#f...

[April 2026 Update] RFC 5869 is now listed in SP 800-140D, the top-level list of official Approved SSP Generation and Establishment Methods for FIPS 140-3 purposes.1 This makes it as a whole just as Approved as SP 800-108 or SP 800-56C. The CMVP announced its addition with the comment “even though it is technically compliant to SP 800-56C which is already listed” proving it had always been FIPS 140-3 compliant. The rest of the post is retained for historical purposes (and because if you want to be precise, you still need to figure out how to list it on your certificate), but most of you can stop reading now.

I had a whole post on "yes, HKDF is FIPS 140-3 compliant, actually" but now NIST just went and added it by name to the list of Approved algorithms with a change comment saying "it was always compliant, yo" (paraphrased), so yay.

words.filippo.io/fips-hkdf/

(1) said with love

1. yes you are

2. the TLS layer heartbeat extension with custom echo buffers of variable lengths was unnecessary complexity

There are only two bug classes left: complexity and memory safety.

CurveBall (CVE-2020-0601)? Complexity.
BigSig (CVE-2021-43527)? Memory safety.
Log4Shell (CVE-2021-44228)? Complexity.
BlueKeep (CVE-2019-0708)? Memory safety.

Heartbleed looks like memory safety, but it's actually complexity.

Yes, I expect LE will be issuing Merkle Tree Certs with ML-DSA next year. There was no strong reason to migrate to ECDSA. It’s not just “latest is better.”

What is cryptographic code? Was the WolfSSL vulnerability in cryptographic code? (Not being coy, I don't think there's a standard for what counts as cryptographic code.)

I wrote up in the TLS mailing list why I think composite signatures (ML-DSA + ECDSA/RSA) are a net negative, will hurt the ecosystem, and should not be implemented.

Hybrid key exchange was simple and self-contained. Hybrid signatures would be a mountain of complexity in delicate, critical code.

this is so sick????

github.com/astral-sh/uv/blob/8ae8cc3/crates/uv-pep440/src/version.rs#L1064-L1137

Ah interesting. @tangled.org does need it in the DID, which I think is the right behavior.

I typed the post wrong, @filippo.io is the second, to be clear!

We now have $16,000 riding on CRQCs, and $8,000 riding on lattice cryptanalysis!

Yes, @filippo.abyssdomain.expert is the first in the DID.

I just swapped them in the post. But also @filippo.io does resolve for me in the web app!

Looks like not even @bsky.app implements it like that, so yeah arguably worth a spec change!

This is useful to verify control of multiple domains. This way you know I am indeed the owner of filippo.io.

@tangled.org's preference picker means I can use my "professional" domain in Tangled URLs, while still using my "funny" handle on @bsky.app.

More atproto apps should support picking!

ProTip: you can have multiple handles in your DID document!

For example, you can see I am both @filippo.io and @filippo.abyssdomain.expert. pdsls.dev/at://did:plc...

@bsky.app uses the first, but also loads profile links for the others. bsky.app/profile/fili...

@tangled.org lets you pick now!

Yeah I mean, we've been joking that this is several orders of magnitude less money than any other way to measure our professional and personal exposure 😅

Alright, it's official! 💰

@matthewdgreen.bsky.social and I bet on what will break first, ML-KEM-768 or X25519. The loser donates to a 501(c)(3) picked by the winner.

If you have an opinion on quantum computers or lattices, you can join with a side bet. Just submit a PR!

github.com/FiloSottile/...