FiloSottile

Sort of.

I like to insist that the PLC Directory collects and distributes updates to highlight how it's different from a database. The latest state of the account is signed by the key that created it, or by a key that succeeded it. The directory can't inject any values, it's just a low-complexity solution for data availability: the "how do I learn about updates" part.

It could decide to hide/reject updates, but then it could just as well be forked and replaced if it did that. If downstream applications decide to get their account updates somewhere else, that's the directory now, without any loss of continuity for the accounts.

You don't get that from a simple database.

One could argue domain registrations, and so did:web, are more of a database controlled by a (large, international) organization than PLC. Plenty of tradeoffs of course.

Oooof, thank you for catching this. This is what I get for writing spec and API before the implementation (which, to be fair, is usually the right order not to lose sight of the broader picture).

Sorry for the confusion, it's indeed the §6.1 binary format. I corrected the spec and post not to claim it's CBOR.

> I understand people are getting slammed and it sucks, but the main result of rejecting them is going to be an increase in full disclosure.

Right, what I'm saying is that letting those bugs go to full disclosure (aka being filed as public issues, like every other bug) would have been a significant damage to user safety a year ago, and it's not anymore.

Thanks for the comment, I was actually hoping to get your take on this! I linked to it from the article.

> Still on Hacker News, Juho Forsén, one of the most prolific reporters of Go security issues, wrote a long interesting comment that makes the argument that instead we should lean harder into trust relationships with individual researchers. It'd certainly be worth it with Juho, in retrospect, but it's unclear if it would pay off often enough, in the same way that training new contributors who might leave the project in a month or two is not always worth it.

Uh, yeah, this is not the writing of someone with the experience to maintain a cryptography toolkit: https://kerkour.com/nist-cryptography-backdoor

(I’m more worried about judgement calls than implementation correctness, it’s not about AI.)

TIL about ZFSBootMenu! Still, the whole frood system is significantly less complex than ZFSBootMenu alone.

I’m pretty sure (even just based on the revenue of various SaaS products) that’s not typical, hence “most NDAs”. I’m also sure some require a SCIF, but that’s not most of them.

Your NDAs prohibit emailing a colleague about the e.g. project, or discussing it in a Slack DM with the client, or tracking progress on it in JIRA? You have to do NDA’d work exclusively with local tools or end-to-end encryption? Those are some difficult NDAs!

In the same way that using Gmail and Dropbox and iCloud and Notion violates it. (Which IANAL but for most NDAs would be not at all.)

I would really like to look at the bug and whether we could have caught it with conventional testing, but it doesn't look like Apple actually disclosed it?

I just use the VS Code git integration with the jj colocated git repo. HEAD is @- and the changes in @ are considered working copy changes. It works for all I was using the VS Code integration for.

This will probably not help enough for asymmetric keys, and is unnecessary for symmetric keys. https://arxiv.org/abs/2603.28846 claims an attack runtime of a few minutes.

There are enough order-of-magnitude breakthroughs between today and scalable quantum error correction, that it makes no sense to try to to guess exactly the order of magnitude of the attacks that will be feasible.

Either you believe they won't happen, in which case you can keep using long-term ECDSA keys, or you believe they will happen, in which case they are likely to overshoot your rotation period.

The calculated DW cost of the quantum attack is 2^104 (with conservative/optimistic assumptions and ignoring the physical cost of a single logical gate), which is "much more realistic than a brute force attack" in the same sense that a 128-bit brute force attack is much more realistic than a 256-bit brute force attack.

None of those are remotely practical, even imagining quantum computers that become as fast (and small! and long-term coherent!) as classical computers.

Hashes are symmetric cryptography primitives, and it's even proper to talk about key sizes for e.g. HMAC and HKDF hash-based constructions, to which Grover's algorithm applies analogously to how it applies to cipher keys.

The world just doesn’t work in such a binary way. Forming a mental model of an entity’s incentives, goals, capabilities, and dysfunctions will serve you much better than making two buckets for trusted parties and adversaries.

> KyberSlash

That's a timing side-channel, irrelevant to ephemeral key exchanges, and tbh if that's the worst that went wrong in a year and a half, I am very hopeful indeed.

I mean "your OS and have a CRQC" because they will need to compromise the software PQ key by compromising the OS, and derive the hardware YubiKey private key using the CRQC.

Thus succeeding at making the telecommunications vendors used for Top Secret US national security data less secure, the obvious goal of the US National Security Agency, and the only reason they wouldn't use the better cryptography designed by Dr. Bernstein. /s

Truly, truly can't understand why anyone finds this line of reasoning plausible. (Before anyone yells Dual_EC_DRBG, that was a NOBUS backdoor, which is an argument against the NSA promoting mathematically broken cryptography, if anything.)

Timing side channels don't matter to ephemeral ML-KEM key exchanges, by the way. It's really hard to implement ML-KEM wrong. It's way easier to implement ECDH wrong, and remember that in this hypothetical you need to compare to P-256, not X25519, because US regulation compliance is the premise.

(I also think these days P-256 is fine, but that is a different argument.)

TIL about the Chicago Pile! (I don't know enough about the physics to tell if it could have indeed exploded.)

> On 2 December 1942

https://en.wikipedia.org/wiki/Chicago_Pile-1

> on July 16, 1945

https://en.wikipedia.org/wiki/Trinity_(nuclear_test)

Two years and a half. This is still a good metaphor for "once you can make a small one, the large one is not far at all."

If you are doing authentication with those hardware keys, you will probably be fine, if we do our job fast enough. Apple's Secure Enclave already supports some PQ signatures (although annoyingly not ML-DSA-44 apparently?) and I trust Yubico is working on it.

If you are doing encryption, then you do have reason to worry, and there aren't great options right now. For example if you are using age you should switch to hybrid software ML-KEM-768 + hardware P-256 keys as soon as they are available (https://github.com/str4d/age-plugin-yubikey/pull/215). This might be a scenario in which hybrids provide some protection, so that an attacker will need to compromise both your OS and have a CRQC. In the meantime, depending on your threat model and the longevity of your secrets (and how easily they can rotated in 1-2 years), it might make sense to switch to software PQ keys.

> The industry standard and general recommendation for quantum resistant symmetric encryption is using 256 bit keys

It simply is not. NIST and BSI specifically recommend all of AES-128, AES-196, and AES-256 in their post-quantum guidance. All of my industry peers I have discussed this with agree that AES-128 is fine for post-quantum security. It's a LinkedIn meme at best, and a harmful one at that.

My opinion changed on the timeline of CRQC. There is no timeline in which CRQC are theorized to become a threat to symmetric encryption.

DES is the algorithms that was secretly modified by the NSA to protect it against differential cryptanalysis. Capping a key size is hardly a "backdoor."

Also, that was the time of export ciphers and Suite A vs Suite B, which were very explicit about there being different algorithms for US NatSec vs. everything else. This time there's only CNSA 2.0, which is pure ML-KEM and ML-DSA.

So no, there is no history of the NSA pushing non-NOBUS backdoors into NatSec algorithms.

> from a classical security point of view PQC cannot be trusted

[citation needed]

https://words.filippo.io/crqc-timeline/#fn:lattices

We can disagree on the tradeoff, but if you see no upside, you are missing the velocity cost of the specification work, the API design, and the implementation complexity. Plus the annoying but real social cost of all the bikeshedding and bickering.

We are stretching the metaphor thin, but surely the progress towards an atomic bomb was not measured only in uranium production, in the same way that the progress towards a QC is not measured only in construction time of the machine.

At the theory level, there were only theories, then a few breakthroughs, then some linear production time, then a big boom.

> Something doesn't add up here.

Please consider it might be your (and my) lack of expertise in the specific sub-field. (I do realize I am saying this on Hacker News.)

Yeah, that's an audience mismatch, this article is for "us." End users of cryptography, including website operators and passkey users (https://news.ycombinator.com/item?id=47664744) can't do much right now, because "we" still need to finish our side.

See https://bas.westerbaan.name/notes/2026/04/02/factoring.html and https://scottaaronson.blog/?p=9665#comment-2029013 which are linked to in the first section of the article.

> Sure, papers about an abacus and a dog are funny and can make you look smart and contrarian on forums. But that’s not the job, and those arguments betray a lack of expertise. As Scott Aaronson said:

> Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”

To summarize, the hard part of scalable quantum computation is error correction. Without it, you can't factorize essentially anything. Once you get any practical error correction, the distance between 32-bit RSA and 2048-bit RSA is small. Similarly to how the hard part is to cause a self-sustaining fissile chain reaction, and once you do making the bomb bigger is not the hard part.

This is what the experts know, and why they tell us of the timelines they do. We'd do better not to dismiss them by being smug about our layperson's understanding of their progress curve.

Remember that the entities most likely to heed those governments recommendations are those providing services to said government and its military.

I feel like the NSA pushing a (definitely misguided and obviously later exploited by adversaries) NOBUS backdoor has poorly percolated into the collective consciousness, missing the NOBUS part entirely.

See https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ for whether the current standards can hide NOBUS backdoors. It talks about ML-KEM, but all recent standards I read look like this.

Indeed, in an open system like the WebPKI it's fine in theory to only make the central authority PQ, but then you have the ecosystem adoption issue. In a closed system, you don't have the adoption issue, but the benefit to making only the central authority PQ is likely to be a lot smaller, because it might actually be the only authority. In both cases, you need to start moving now and gain little from trying to time the switchover.

This article is more aimed at those specifying and implementing WebAuthN and SSH, than at those using them.

They/we need to migrate those protocols to PQ now, so that you all can start migrating to PQ keys in time, including the long tail of users that will not rotate their keys and hardware the moment the new algorithms are supported.

For example, it might be too late to get anything into Debian for it to be in oldstable when the CRQCs come!