FiloSottile

>:)

I am a CT log operator and I hands down support short-lived certificates. Automation and short lifetimes solve a lot of the pain points of the WebPKI.

We can solve the storage requirements, it’s fine.

Ignoring the damaging and self-serving behavior of Bernstein for a moment, and focusing only on the technical claim at the core of the conspiracy theory: it makes absolutely no sense.

The assertion is that the NSA is subverting standards processes to push pure ML-KEM key exchanges, the same algorithm they are requiring for their own TS//SCI information in CNSA 2.0.

There is mathematically no place for a NOBUS backdoor in ML-KEM (see https://keymaterial.net/2025/11/27/ml-kem-mythbusting/), so the assertion is that the NSA wants the US Government to use broken cryptography for its most sensitive information. Broken in the sense that an adversary or academic could discover how to break it tomorrow (or yesterday), throwing the government signals handling in disarray, or silently causing a counter-intelligence catastrophe.

That's... ridiculous? Bernstein wraps this in a lot of words and emotionally charged gish gallop, but the core technical point doesn't hold. And it's getting tiresome, and getting in the way of actually important PQ rollout work.

Before anyone claims there's precedent: there isn't. Dual_EC_DRBG was a NOBUS backdoor (and anyway was not authorized for TS//SCI as part of Suite B, the predecessor of CNSA 2.0), and export ciphers were for everyone else not for USG data.

There are definitely better cryptographers than me working at Zcash, for example.

A cloud service that lets users upload their certificates and private keys, to be served by the service's CDN. Here the attacker is attacking the system's availability, not the key.

(But also, it's easy to see how this is a problem for public keys and ciphertexts, and it would be weird to have an inconsistent API for private keys.)

I'm not sure what you are referring to, but we were talking about keys, not IVs.

Also, "an unambiguous key type that can be constructed from a []byte or responsibly generated on your behalf" is exactly what crypto/mlkem exposes.

It's not that simple! What about intermediate values during arithmetic computations? What about registers spilling during signal handling?

I honestly thought it could not be done safely, but the runtime/secret proposal discussion proved me wrong.

You might find this proposal and the upcoming runtime/secret package interesting.

https://github.com/golang/go/issues/21865

> I don't know why the standard library crypto packages insist on passing around `[]byte` for things like a seed value

These are actually very deliberate choices, based on maybe unintuitive experience.

We use []byte instead of e.g. [32]byte because generally you start with a []byte that's coming from somewhere: the network, a file format, a KDF.

Then you have two options to get a [32]byte: cast or copy. They both have bad failure modes. If you do a ([32]byte)(foo) cast, you risk a panic if the file/packet/whatever is not the size you expected (e.g. because it's actually attacker controlled). If you do a copy(seed, foo) it's WAY WORSE, because you risk copying only 5 bytes and leaving the rest to zero and not noticing.

Instead, we decided to move the length check into the library everywhere we take bytes, so at worst you get an error, which presumably you know how to handle.

> why we can't just pass in a seed value to a single unambiguous constructor when generating asymmetric keys

I am not sure what you are referring to here. For e.g. ML-KEM, you pass the seed to NewDecapsulationKey768 and you get an opaque *DecapsulationKey768 to pass around. We've been moving everything we can to that.

> Or how the constructor for a key pair could possibly return an error, when the algorithm is supposed to be deterministic.

Depends. If it takes a []byte, we want to return an error to force handling of incorrect lengths. If the key is not a seed (which is only an option for private keys), it can also be invalid, deterministic or not. (This is why I like seeds. https://words.filippo.io/ml-kem-seeds/)

> removing all dependencies on rand would make it obvious where the entropy must be coming from (the seed parameter)

Another place where experience taught us otherwise. Algorithms that take a well-specified seed should indeed just take that (like NewDecapsulationKey768 does!), but where the spec annoyingly takes "randomness from the sky" (https://words.filippo.io/avoid-the-randomness-from-the-sky/) in an unspecified way, taking a io.Reader gave folks the wrong impression that they could use that for deterministic key generation, which then breaks as soon as we change the internals.

There is only one place to get entropy from in a Go program, anyway: crypto/rand. Anything else is a testing need, and it can be handled with test affordances like the upcoming crypto/mlkem/mlkemtest or testing/cryptotest.SetGlobalRandom.

128 bits of symmetric keys are enough for post-quantum security. See https://words.filippo.io/post-quantum-age/.

The public key algorithm has been frustratingly blocked on the IETF and CFRG, which are taking more than 15 months since FIPS 203 to stabilize a simple hash-based hybrid combiner.

No, in CSRF the browser is not the adversary, it is a confused deputy, and it’s perfectly reasonable to collaborate with it against the attacker (which is another site).

You might want to read https://words.filippo.io/csrf.

> Users can move their follows, followers and posts to zeppelin.social fron BlueSky transparently?

Yes, even if Bluesky was down (as long as they have a backup) which is not the case for ActivityPub.

For CSRF (and for SameSite), you are not looking at what cookies are sent to attacker.example.com, but what cookies are sent to target.example.com if a request is originated from attacker.example.com (or from attacker.com).

Same-Site cookies are, well, same-site. Not same-origin. This is already a deal-breaker for many deployments, because they don't trust blog.example.com and partner.example.com as much as admin.example.com (both in the strict sense of trust, and in the senso of not having XSS vulnerabilities the attacker can pivot off).

Worse, by the original definition http://foo.example.com and https://admin.example.com are same-site, and unless the site uses HSTS with includeSubDomains, any network attacker controls the former. Chrome changed that with Schemeful Same-Site in 2020, but Firefox and Safari never deployed it.

I have never seen real Go code (i.e. not code written purposefully to be exploitable) that was exploitable due to a data race.

This doesn’t prove a negative, but is probably a good hint that this risk is not something worth prioritizing for Go applications from a security point of view.

Compare this with C/C++ where 60-75% of real world vulnerabilities are memory safety vulnerabilities. Memory safety is definitely a spectrum, and I’d argue there are diminishing returns.

Thomas and I are both talking about the Go cryptographic library overall, not about the ChaCha20 implementation in particular. Anyway, I don’t find arguing semantics around the “soup-to-nuts” expression particularly productive.

We avoided the DIV by deliberately not using a modulus operation and doing Barrett reduction instead.

Well, ML-KEM has zero assembly and was written entirely from scratch, for example, so it must be more than you'd think if you think we "reuse the same machine code for this that you'd find in everybody else's implementation." In fact, almost everyone else's was found to be producing a variable-time DIV instruction, while ours was unaffected.

Porting the assembly to higher-level generators has nothing to do with lawyers (??), the goals are stated in https://go.dev/wiki/AssemblyPolicy.

The idea that one day we'll write All Of The Cryptography Code Once And For All In The Perfect Language and reuse that across languages comes up pretty regularly, and has never panned out.

Yes, it calls out to OpenSSL on Linux and to CNG on Windows. I think, but I am not certain, that at least the OpenSSL cgo bindings are derived from the Go+BoringCrypto ones (which makes sense, since the BoringSSL and OpenSSL APIs are still very similar).

Off the top of my head, there might be some old assembly by Andy Polyakov and by Vlad Krasnov that was contributed to both Go and OpenSSL. Even there, we’ve been working for years to port hand-written assembly to higher level generators, and there’s not as much as you’d think. Everything else is original.

Besides integrating properly with Go applications, this lets us optimize for readability and correctness, with IMHO excellent empirical results.

https://words.filippo.io/a-literate-go-implementation-of-pol...

https://go.dev/blog/tob-crypto-audit

https://www.youtube.com/watch?v=lkEH3V3PkS0

[ Big I am a cryptographer, not your cryptographer disclaimer ]

It depends, but if you are targeting Security Level 1 (which is what most folks think about when they think about FIPS 140) you generally don't need your entire application to be validated, only the cryptographic module.

So (again, depending on your requirements and on the Operating Environment you deploy to and on what algorithms you use and how) setting GOFIPS140 might actually be all you need to do.

To nitpick, there is no special crypto/fips140 package. (Ok, there is, but it just has an Enabled() bool function.)

FIPS 140-3 mode is enabled by building with GOFIPS140=v1.0.0 (or similar, see https://go.dev/doc/security/fips140), but it shares 99% of the code with non-FIPS mode.

Still, your message is right, just GOFIPS140=off (the default!), not GOFIPS140=v1.0.0.

No, the Go 1.24 native module effort that they talk about in https://devblogs.microsoft.com/go/go-1-24-fips-update/ is this effort, which Microsoft was not involved in. We simply decided to delay the official announcement until the module reached the In Process list.

The system libraries approach used by Microsoft Go is cgo based IIUC, and I think derived from Go+BoringCrypto. I understand they are working on migrating their bindings to fit better downstream of the new native mode.

> Applications that have no need for FIPS 140-3 compliance can safely ignore [this page], and should not enable FIPS 140-3 mode.

https://go.dev/doc/security/fips140

Yup.

You'll never believe what I (and a bunch of folks) have been working on for years :)

https://www.sigsum.org

https://github.com/FiloSottile/torchwood/tree/main/cmd/apt-t...

https://www.youtube.com/watch?v=SOfOe_z37jQ

https://c2sp.org/tlog-tiles

Huh, iCloud Keychain supports the prf extension when used with Chrome, so I had assumed they added support to Safari as well, but I just tested it and sure enough, you're right.

Edit: well https://webauthn-passkeys-prf-demo.explore.corbado.com/ works with an iCloud Keychain passkey on Safari on macOS 15.5, but Typage doesn't work with a YubiKey 5, so there is some support (the MDN data is out of date) but also something weird.

That instead was a draft that should have not gone out yet, but the API filter didn’t work :)

I’ll mail that one towards the end of the week.

I added a footnote about it. It’s indeed read traffic, so it’s (certificate volume x number of monitors x compression ratio) on average. But then you have to let new monitors catch up, so you need burst.

It’s unfortunately an estimate, because right now we see 300 Mbps peaks, but as Tuscolo moves to Usable and more monitors implement Static CT, 5-10x is plausible.

It might turn out that 1 Gbps is enough and the P95 is 500 Mbps. Hard to tell right now, so I didn’t want to get people in trouble down the line.

Happy to discuss this further with anyone interested in running a log via email or Slack!

My bad! This is what I get for doing a deploy to fix the layout while the post is on HN. Back up now.

Team sharing with a non-technical person, mostly.

I still have high-value passwords and CLI credentials in passage + age-plugin-yubikey.

Currently it just fetches latest if a version is not specified. It should be pretty easy to use the current project version if available, assuming llm plugins stay in the working directory of the main call. PRs welcome :)

Once the module version is in GOMODCACHE, it's extremely fast, not even noticeable.