FiloSottile

This is some serious severity inflation.

Skipping CRL checks is not a Critical. A Critical is "whoops we were not checking the signature on the certificates" or "I guess all zeroes is a fine session ticket key" (both happened, the former in wolfSSL, the latter in GnuTLS).

Bypassing chain length limits is... barely a Low? It's definitely not a High.

The DHE one is fun. It'd have been valuable if they spent some tokens figuring out if any open source library would accept those broken parameters. If not, it doesn't really matter. (Another good reason not to negotiate DH parameters ever!)

This sort of breathless outrage rhetoric would be a lot easier to take seriously if it spent even a minute acknowledging the very real risk to users that this is meant to mitigate: tech support scams where people are walked through installing an app that takes over their phone and steals their money, private data, and identity.

You can disagree with the tradeoff, but if you don't acknowledge it you're just doing propaganda.

Personally, I think the 24h cooldown is an excellent compromise to allow user freedom while slowing down attackers sufficiently to mitigate the harm.

Tech is cool, but it's not an end in itself. Serving people should be. And if people are getting hurt, it's not working well, even if those people are not the ones that read Hacker News.

> If we follow this line of thought it would be more secure to only serve sites to consumers through a few "trusted" third parties right?

No.

I did not discover the issue. I just wished to have a rapid and definitive way to test the patch(es).

As far as I know 30 minutes validity is no one's goal, even long term.

The most aggressive plans (not Let's Encrypt's specifically) target 7 day validities.

Given how expensive this computation would have been in 1997, it makes perfect sense they'd taken months, but even if we assume they tried all timestamps of 1997 and selected arbitrarily among the first 16 viable candidate of any timestamp, that's just ~30 bits of freedom.

Finding out there is a class of weak 256-bit elliptic curves so large that they can be hit randomly with 2^30 tries would be a cryptanalytic breakthrough analogous to discovering all elliptic curve cryptography is broken.

Read section 3.1 of the Koblitz and Menezes paper. It was already implausible with 160 bits of freedom. https://eprint.iacr.org/2015/1018

If you want to believe the NSA knows ECC is broken and chose to risk moving the US government to it and somehow no one figured out the same break in 30 years, you're free to do so. But pretending the seed choice plays any role in that theory is over.

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.