FiloSottile

We're working on it! RFC 6962 specifies inclusion and consistency proofs, but indeed it's missing test vectors. Keep an eye on https://c2sp.org and https://c2sp.org/CCTV.

Exactly! It's a growing ecosystem including things like https://transparency.dev, the Go Checksum Database, https://www.sigsum.org, SigStore, and even key transparency solutions like WhatsApp's.

One thing you end up needing to deploy tlogs is a way to reassure clients the tree is not forked, and for that you mostly need witness cosigning, where a quorum of third parties attest that a signed tree head is consistent with all the other ones they've seen. I've worked with the Sigsum project and the Google TrustFabric team on an interoperable specification for witnessing (which Sunlight interoperates with), and I am now working to develop a public, reliable ecosystem of witnesses.

Once you have witnessing, running a log can be as easy as hosting a few files in a GitHub repo or S3 bucket, updated with a batch script. I am very excited to make it possible for any project to get better-than-CT accountability for ~free.

(You might want to catch my RWC 2024 talk about this once it comes out!)

This is one of the projects I've been most excited about in the last few years. It let me backport to Certificate Transparency some of the modern designs ideas that came after it.

Beyond the Let's Encrypt announcement and the ct-policy thread (which includes a technical and advantages summary), here are a few resources that might be interesting.

- Design document, including architecture and tradeoffs: https://filippo.io/a-different-CT-log

- Implementation: https://github.com/FiloSottile/sunlight

- API specification: https://c2sp.org/sunlight

- Website, including test logs and feedback channels: https://sunlight.dev/

If you’re thinking “oh we could use something similar” please reach out! Sunlight is retrofitting some of the modern tlog designs on a legacy system. With a greenfield deployment you can do even better! I’m working with the Sigsum project on specs, tooling, and a support ecosystem to make deploying tlogs easier and safer.

Go has good reasons not to bring C/C++ into every build, starting from the ability to cleanly cross-compile.

I can't comment on the rest, but the security track record of the crypto libraries is stellar compared to pretty much any other library (and it already was before my tenure).

(BTW, I am not at Google anymore, although I still maintain specifically the crypto libraries.)

Do you know of any cryptography implementation that sets the Data Independent Timing flag? We've been trying to figure out what others are doing about it, because as far as I can tell nobody is.

Anyway, not sure why relying on C/C++ would have helped us here.

Not really, a number of our crypto implementations are pure Go. In fact, we always have a pure Go fallback that you can select with "-tags purego". As of Go 1.23 we will be systematically testing it, too, because it enables other compilers like TinyGo. They might be slower, but with the notable exception of AES (because implementing AES in constant time without AES-NI is hell) the pure Go implementations are just as secure.

Moreover, some of the assembly cores are a couple dozen lines for the hottest loops. I guess you could call the whole Go package a safe wrapper around that unsafe code, but I am used to think of a wrapper as not the place where the substantial logic is.

It's also meaningfully different from AWS-LC, discussed here, which has the entire cryptographic operation (like a signature or encryption API) implemented in C. (It's still great progress to move the TLS and X.509 implementations to a safe language, as that's where most memory safety bugs are!)

They have different use cases: with PAKEs you encrypt a connection, not a file. You can’t use PAKEs to encrypt backups. Or, rather, you can but then the two sides just have to store the key, making it not fit for e2ee use cases. It’s password authenticated key exchange, not password derived keys.

(Well, the WhatsApp solution actually uses a PAKE to talk to the HSM, but the HSM is still necessary.)

No, we use assembly for access to specialized (e.g. AES-NI) or vector instructions, and we do so reluctantly. We much prefer writing cross-platform constant time Go. https://go.dev/wiki/AssemblyPolicy

The actual implementations are in that tree, too: https://cs.opensource.google/go/go/+/master:src/crypto/

Hah, touché my friend. It's just that every time I think about touching that page it scope creeps into making it autogenerated from the kernel sources via CI etc. etc. :)

Go is as susceptible to timing side channels as C, if not less. (The difference being that while there is one major Go compiler, which usually does not go overboard with optimizations, when writing C you have to do increasingly complex tricks to defend against the compiler realizing what you are trying to do and replacing it with a more efficient variable-time branch.) This implementation was written to avoid any secret dependent code path.

Power side channels, which require physical access, are indeed outside the threat model of Go.

Cryptography has a peculiar approach to the threat of quantum computers, because it is not acceptable for some of the data and connections encrypted today to become decryptable even thirty, fifty years in the future. That means that the question is not "are QC coming soon" but "might QC plausibly come into existence in the next half century". Since the answer, despite not having a precise consensus, is not "no", here we are.

This is also why you are seeing a lot more progress on PQ key exchanges, as opposed to signatures: signature verification today is not affected by QC fifty years from now, while encryption is.

age is intentionally stable as a format and as a core tool.

There is a lot of activity in the integration and plugin ecosystem, which I am very happy about. https://github.com/FiloSottile/awesome-age

I have a wishlist for v2 changes, and I am considering slowly and carefully making such a release this year, but the difference in security between scrypt and Argon2 doesn't really justify making a change there.

Yeah, replacing the hash would take a fork. Note that this implementation spends only about 20% of CPU time in SHA-3, so the gain wouldn't be massive. That proportion would probably grow after optimizing the field implementation, but almost certainly not enough to make it worth using a non-standardized, less-tested mode.

No, something being under github.com/google means the person who started it was paid by Google, not paid by Google to code this. Google contracts (like most tech contracts in the US) have ridiculously broad IP assignment clauses, so unless you go through a lengthy process to request Google disown something, they own anything you code, and they insist you open source your things under github.com/google.

You decide your own definitions, but that's very different from "Gmail by Google" or even "Go by Google" in my book. Note how the main author has "Ex-Google" in their bio, too.

No, please don't send me emails in a format that will not reflow readably on my phone, especially if I didn't use the same format when emailing you. (The Fastmail instructions explicitly say to disable "When replying, use the same format as the original message".)

> An unencrypted webby stream does not expose a browser to anything nastier than an encrypted webby stream. The eventual payload is the same, regardless of the transport.

No, my point is that an unencrypted payload is controlled by anyone on your network path (your ISP, anyone on the same open WiFi, ...), so it can be nastier than an encrypted payload. Remember that TLS provides not just encryption, but also authentication.

The benefits of not exposing the massive attack surface of modern browsers to every network attacker are not cargo culting.

That's the whole point of a TKey as a security device: the secret available to an application depends on both the device it's running on and the application, and can't be extracted, so you can do things like "sign a blob only if it follows these rules" and enforce it in hardware. If the device wasn't locked, you could just... change the rules.

How is that not a legitimate form of security?

You might be interested in Capslock, which attempts to do that through static analysis. https://security.googleblog.com/2023/09/capslock-what-is-you...

Footnote [1] is about different strategies to select trustworthy standard parameters. I believe they are all good enough to make it so that if someone can still "backdoor" the result, they are so far ahead of the outside world that they might as well have broken the whole scheme, without influencing the parameters.

[1] https://words.filippo.io/dispatches/parameters/#fn1

(Yes, I hide too much stuff in the footnotes.)

For anyone that would like to catch up with this unfortunate saga, I recommend reading the following, that (partially due to being presented less inflammatorily and through the appropriate channels) are getting much less coverage.

Ray Perlner (NIST PQC), Re: Kyber security level? https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VO...

Christopher J Peikert, Re: Kyber security level? https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VO...

Matthew Green on Mastodon https://ioc.exchange/@matthew_d_green/111227593416987176

tptacek on HN https://news.ycombinator.com/item?id=37874682

Personally, I am woefully unqualified to judge the intricacies of attack cost estimation myself, but I have followed enough of the process to find some of the conspiracy claims risible. For example, that NIST made a graph a little smaller on a slide to "deemphasize" it (search for "thinner red bars" in https://blog.cr.yp.to/20231003-countcorrectly.html).

Moreover, I fail to understand why NIST would pick a weak algorithm (designed by independent researchers) to secure the data of US federal agencies and industry. This is critically different from Dual_EC_DRBG in that there is nowhere to hide a NOBUS (https://en.wikipedia.org/wiki/NOBUS) backdoor, so it would be a ridiculous bet that no one else in the world will find the weakness in the next fifty years.

The one bit of color I will add is that every community of cryptographers I am in has had enough of this, as far as I can tell, and is not taking Bernstein seriously anymore. The most common reactions are eyerolls and popcorns. As I said before (https://news.ycombinator.com/item?id=37868974), I am worried that Bernstein has increasingly argued in bad faith and alienated his peers (through spurious accusations, personal attacks, endless never-retracted arguments, and legal threats) to the point that they're unwilling to engage with him, which from the outside can look like his points are unrefutable. Like Matthew Green, I am worried about what that will do to confidence in modern cryptography, given Bernstein's following.

From the proposal:

"There is one last, special wildcard: {$} matches only the end of the URL, allowing writing a pattern that ends in slash but does not match all extensions of that path. For example, the pattern /{$} matches the root page / but (unlike the pattern / today) does not match a request for /anythingelse."

FWIW, I don't believe Bernstein is evil.

I do believe he has increasingly argued in bad faith and alienated his peers to the point that they're (we're) unwilling to engage with him, which from the outside can look like his points are unrefutable.

I'm very proud that we implemented server-side support for the keystroke timing obfuscation mechanism in golang.org/x/crypto/ssh already.

(I just clicked the Submit button! https://go.dev/cl/524775)

It's a small change, but it's a signal that we're much more on top of x/crypto/ssh maintenance, compared to a year ago when we had to scramble to implement rsa-sha2-256/512 support just hours before GitHub (rightfully) dropped SHA-1 support, potentially breaking every x/crypto/ssh client.

The main reason is that thanks to the funding of my clients (https://words.filippo.io/full-time-maintainer/) I was able to hire Nicola Murino, the maintainer of SFTPGo, to pick up maintenance of x/crypto/ssh. This is benefiting both my clients and the whole ecosystem, and is a little step in growing the professional maintainer model.

The article claims all data and algorithms are public, are you saying that's not true or that the data is doctored?

To me, the examples make a convincing case that the emergent [-1, +1] range ended up aligning with what most people call right/left.

Firefox's implementation of MV3 allows both async permission-less blocking (declarativeNetRequest API) and permissioned synchronous blocking (webRequest API). uBO Lite uses the former to provide an ad-blocker without read/write permissions.

You can still write a unsandboxed extension with MV3 (and in Firefox it will still be able to intercept requests, while in Chrome it will not be on the network hot path) but the point is that you can also write a permission-less ad-blocker now, which is what I want.

I considered that a few times, but eventually complex things like modern ad-blockers rot, so I would be forced to update every once in a while, and let's be honest: I am neither qualified nor prepared to audit the diff.

I guess deferring updates would give me lead time to let others get targeted / detect an issue before it's likely I would get the update. Still, installing the permission-less version is so much simpler and reassuring.

This is the uBlock Origin edition based on the much-maligned WebExtensions Manifest V3, which implements blocking declaratively instead of allowing/requiring live request interception.

Firefox—my daily driver—still supports the "main" uBlock Origin (and I'm a somewhat heavy user of features unavailable in Lite like custom filters), but I had been waiting for Lite to be available and immediately went ahead and replaced uBlock Origin with uBlock Origin Lite.

The security win can't be understated: with its permission-less design (enabled by MV3) I am down to zero third-party developers that can get compromised and silently push an update that compromises all my web sessions. Sure, attackers could still get into Mozilla, Apple (as I run macOS), or cause a backdoored update to be pushed via Homebrew (how I install unsandboxed applications when no web app is available, which thanks to the likes of WebUSB is getting less common), but unsandboxed browser extensions were clearly the lowest hanging fruit, so this update (and MV3) significantly raised my security posture (and transitively that of projects I have access to, and that of their users).

Long term intentional effort: https://go.dev/issue/27151

Nope :) I'm still a maintainer, and actually happen to be the one that drove those two deprecations. https://words.filippo.io/full-time-maintainer/