Hacker News: FiloSottile

New comment by FiloSottile in "Opaque, Interoperable Passkey Records (and a Go API)"

FiloSottile — Tue, 21 Jul 2026 08:27:22 +0000

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.

New comment by FiloSottile in "Vulnerability reports are not special anymore"

FiloSottile — Wed, 24 Jun 2026 13:26:07 +0000

> 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.

New comment by FiloSottile in "Vulnerability reports are not special anymore"

FiloSottile — Wed, 24 Jun 2026 09:40:37 +0000

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.

Securing the Nation Against Advanced Cryptographic Attacks

FiloSottile — Mon, 22 Jun 2026 21:37:11 +0000

Article URL: https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/

Comments URL: https://news.ycombinator.com/item?id=48636557

Points: 17

# Comments: 5

New comment by FiloSottile in "Why stdx is not on crates.io"

FiloSottile — Wed, 17 Jun 2026 15:35:03 +0000

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.)

New comment by FiloSottile in "Frood, an Alpine Initramfs NAS (2024)"

FiloSottile — Tue, 16 Jun 2026 21:51:02 +0000

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

New comment by FiloSottile in "Anthropic requires 30 day data retention for Fable and Mythos"

FiloSottile — Wed, 10 Jun 2026 23:58:27 +0000

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.

New comment by FiloSottile in "Anthropic requires 30 day data retention for Fable and Mythos"

FiloSottile — Wed, 10 Jun 2026 23:21:07 +0000

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!

New comment by FiloSottile in "Anthropic requires 30 day data retention for Fable and Mythos"

FiloSottile — Wed, 10 Jun 2026 22:59:25 +0000

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.)

New comment by FiloSottile in "A blueprint for formal verification of Apple corecrypto"

FiloSottile — Sat, 23 May 2026 10:34:44 +0000

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?

New comment by FiloSottile in "Jujutsu megamerges for fun and profit"

FiloSottile — Tue, 21 Apr 2026 01:30:48 +0000

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.

New comment by FiloSottile in "Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys"

FiloSottile — Mon, 20 Apr 2026 22:31:29 +0000

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.

New comment by FiloSottile in "Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys"

FiloSottile — Mon, 20 Apr 2026 22:26:46 +0000

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.

New comment by FiloSottile in "Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys"

FiloSottile — Mon, 20 Apr 2026 18:42:41 +0000

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.

New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"

FiloSottile — Tue, 07 Apr 2026 01:29:04 +0000

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.

New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"

FiloSottile — Mon, 06 Apr 2026 23:13:27 +0000

> 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.

New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"

FiloSottile — Mon, 06 Apr 2026 22:07:29 +0000

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.

New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"

FiloSottile — Mon, 06 Apr 2026 21:56:29 +0000

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.)

New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"

FiloSottile — Mon, 06 Apr 2026 21:34:06 +0000

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."

New comment by FiloSottile in "A cryptography engineer's perspective on quantum computing timelines"

FiloSottile — Mon, 06 Apr 2026 21:19:42 +0000

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.