Archive

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.

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!

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!