I’m consolidating all my writing at words.filippo.io. The new home of Cryptography Dispatches is here.

All email subscribers were migrated. You can subscribe here and manage your subscription here.

If you’re subscribed via RSS, the new feed is at https://words.filippo.io/dispatches/rss/ and you probably missed the latest issue, KEMs and Post-Quantum age.

The Go standard library provides crypto/tls, a robust implementation of Transport Layer Security (TLS), the most important security protocol on the Internet, and the fundamental component of HTTPS. In Go 1.17 we made its configuration easier, more secure, and more efficient by automating the priority order of cipher suites.

How cipher suites work

Cipher suites date back to TLS’s predecessor Secure Socket Layer (SSL), which called them “cipher kinds”. They are the intimidating-looking identifiers like TLS_RSA_WITH_AES_256_CBC_SHA and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 that spell out the algorithms used to exchange keys, authenticate certificates, and encrypt records in a TLS connection.

This is the story of a bug that was discovered and fixed in Telegram's self-rolled cryptographic protocol about seven years ago. The bug didn't get any press, and no one seems to know about it, probably because it was only published in Russian.

To this day, it's the most backdoor-looking bug I've ever seen.

Google Translate does a good enough job on the original article, which is still available on Habr, but I'm going to walk you through it along with some context.

A lot of my job is implementing specifications, and sometimes in a crypto spec you'll encounter something like this

         (p+3)/8      3        (p-5)/8
x = (u/v)        = u v  (u v^7)         (mod p)

and what you do is nod, copy it into a comment, break it down into a sequence of operations, and check that the result matches a test case.¹

Project Zero dropped a great bug in Vault which I think would have been prevented by one of the lessons learned of cryptography engineering: when you can, always prefer reconstructing a value rather than parsing and validating it.

You should read the blog post to understand the attack first, because my tl;dr will not do it justice, but here's an overview.

Vault is a thing that manages your secrets, like database credentials, and makes them accessible to the applications that need them through its various APIs. Of course, these APIs need some sort of authentication, which can be a bit of a chicken-and-egg situation. If you run on a cloud platform like AWS, the natural way to identify an application is through the IAM role it runs as, and Vault has a way to authenticate API calls through IAM roles.

How does Vault do that? Is there an AWS API for that? Nope!

When talking about high-level application cryptography APIs I usually hear mentioned libsodium, Tink, pyca/cryptography, and NaCl.

One of these things is not like the others! The value NaCl had 10 years ago was that it was an opinionated library at a time when all cryptography libraries were choose-your-own-adventure toolkits, but its APIs are not high-level, and even its constructions are unsafe by today's standards.

NaCl refers to a set of APIs implemented in C by an old library published at nacl.cr.yp.to. No one really uses the original library¹, partially because it was a pain to build and package, but two of its constructions got ported to a number of languages, including Go: box and secretbox.²

Cryptographic protocols and specifications often come with registries that map numeric or string identifiers to algorithms or suites.

Something like this.

1    RSA-PSS-SHA256
2    RSA-PSS-SHA512
3    ECDSA-P256-SHA256
4    ECDSA-P521-SHA512
5    Ed25519
...

I asked my Twitter followers what I should talk about in this issue, and those trolls picked PGP and security vulnerability reporting, so here goes nothing.

As you probably know, the school of modern cryptography thinking I subscribe to says that tools and protocols should be small, simple, and focused on a specific use case. Only then you can make opinionated choices that are safe by default, make the tool impossible to use wrong, and design with a single well-oiled joint avoiding all the issues that come from protocol negotiation, downgrades, and misuse.

This means that replacing PGP is a painstaking effort of finding and breaking down the use cases of this rusty old Swiss Army knife, and finding simple dedicated solutions for each of them. (It's also why people who say "age can't replace gpg, it doesn't do enough things" are missing the point by a few nautical miles.)

OpenSSH is on a roll. In February, OpenSSH 8.2 introduced first-class support for FIDO2 (née U2F) security keys, making hardware backed keys accessible for less than $20.

This is not some complicated PAM setup, or some janky cryptographic trick, but a proper public key type, where the private key is protected by the hardware token.¹ And it just works out of the box for USB security keys! No more tedious and unreliable gpg-agent setups, PKCS#11, or third-party agents.

I'm a big fan of hardware tokens because they allow a few things you can't do with just software cryptography: compromise recovery, because an attacker can't exfiltrate the key from the hardware to use it after losing access to it; explicit consent, where the user has to physically allow each operation by e.g. tapping the key; and short PINs that can't be bruteforced, because the retry counters or delays are enforced in hardware.

Go 1.14 is out and with it come a few nice updates to crypto/tls!

Will this certificate work?

Certificate selection in TLS¹ is a mess. I was going to try and describe it here to make the point, but I kept getting it wrong and it was even too messy for something just meant to make the point that it's a mess. Anyway, something nice that's coming to crypto/tls in Go 1.14 are SupportsCertificate methods on the structs that are passed to callbacks. They "simply" tell you if a peer is going to support a certificate or not based on the dozen interlocked negotiated parameters that come into play.

Oceans of ink and hours on stage have been spent to convince the world that the best random number generator is /dev/urandom, the kernel one. And it is, and it's always been.

However, an uncomfortable truth was that the Linux CSPRNG really could have been better than it was. Userspace CSPRNGs couldn't be better than the kernel one, so our advice was still valid, but that space for improvement always frustrated me.

Good news everyone!

Hello World

This is the inaugural issue of Cryptography Dispatches, meant to be quick, frequent and lightly edited discussions of cryptographic topics. Longer form can be found at blog.filippo.io. If you are not reading this in your email client, you can subscribe here.

For my first round, I am writing about the recent attack on the PGP keyservers. The overall goal of the newsletter is to explain cryptography rather than to comment on the news, so we will cover context and mechanics, not the last minute updates. Issues about Ristretto, Ed25519 in Go, AES-GCM-SIV, and OPRF based contact discovery are still coming as promised!

The point of these newsletters is to write more, so please forgive me a lower level of polish. Since I don't have any invasive tracking in these emails, reply to let me know what you think and what you'd like to read about!