FiloSottile

> you should either be writing your code such that it is timing agnostic, or you could read the platform documentation rather than making assumptions

Have you even read the paper? Especially the part where the attack applies to everyone’s previous idea of “timing agnostic” code, and the part where Apple does not respect the (new) DIT flag on M1/M2?

> download random programs onto their computers and run them at random

To be clear that includes what we're all doing by downloading and running Javascript to read HN.

Maybe I can say "don't run adversarial code on my same CPU" and only care about over-the-network CPU side-channels (of which there are still some), because I write Go crypto, but it doesn't sound like something my colleagues writing browser code can do.

Names are critical to enable discussion.

The "marketing" page is where documentation is. Summaries that don't require reading a whole academic papers are a good thing, and they are the place where all the different links are collected. Same reason software has READMEs.

Logos... are cute and take 10-60 minutes? If you spend months on some research might as well take the satisfaction of giving it a cute logo, why not.

Speaking as a cryptography implementer, yes, these drive us up the wall.

However, crypto coprocessors would be a tremendously disruptive solution: we'd need to build mountains of scaffolding to allow switching to and off these cores, and to share memory with them, etc.

Even more critically, you can't just move the RSA multiplication to those cores and call it a day. The key is probably parsed from somewhere, right? Does the parser need to run on a crypto core? What if it comes over the network? And if you even manage to protect all the keys, what if a CPU side channel leaks the message you encrypted? Are you ok with it just because it's not a key? The only reason we don't see these attacks against non-crypto code is that finding targets is very application specific, while in crypto libraries everyone can agree leaking a key is bad.

No, processor designers "just" need to stop violating assumptions, or at least talk to us before doing it.

We considered this design and rejected it because it requires an ultimately unwinnable cat-and-mouse game of fingerprint resistance.

Things the log can use to partition the users include their Tor version, HTTP library behavior, contact periodicity... the list goes on and on, and keeps restricting the use cases where it can be deployed securely even just in theory.

Witness cosigning is secure even if the way you fetch the proofs is completely attacker-controlled, which is closer to user expectations of regular digital signatures.

Purely coincidental! ;-)

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.