Speed and Cryptography posted January 2019

At Real World Crypto 2019, Mihir Bellare won the Levchin Prize (along with Eric Rescorla) and gave a short and inspiring speech. You can watch it here. In it, he briefly mentioned what I'll call the speed issue:

when I started it was a question of being responsive to the industry and practical needs [...] Now I think these are much deeper questions [...] Who benefits from the work we do? [...] Who benefits from making things faster beyond a certain point? The constant search for speed. What sort of people do we become when we cannot wait half a second for a web page to load because TLS is doing a round trip and we're cutting corners.

In here, Bellare is obviously hinting at Eric Rescorla's work with TLS 1.3, in particular the 0-RTT or early data feature of the new protocol. If you don't know what it is, it's a new feature which allows a client to send encrypted data as part of its very first flight of messages. As I explained in this video, it does not protect against replay attacks, nor benefits from forward secrecy.

Replay: a passive observer can record these specific messages, then replay them at a later point in time. You can imagine that if the messages were bank transactions, and replaying them would prompt the bank to initiate a new transaction, then that would be a problem.

Forward Secrecy: TLS sessions in TLS 1.3 benefits from this security property by default. If the server's long-term keys are stolen at a certain point in time, previous sessions won't be decryptable. This is because each session's security is augmented by doing an ephemeral key exchange with keys that are deleted right after the handshake. To break such a session you would need to obtain these ephemeral keys in addition to the long-term key of the server. Sending 0-RTT data happens before any ephemeral key exchange can happen. The data is simply encrypted via a key derived from a pre-shared key (PSK). Here the lack of forward secrecy means that if the PSK is stolen at a later point in time, that data will be decryptable. This is much less of an issue for browsers as these PSK are often short-lived, but it's not always the case in other scenarios.

0-RTT has been pretty controversial, it has generated a lot of discussion on the TLS 1.3 mailing list (see 1, 2, 3) and concerns about its security have taken an entire section in the specification itself.

While I spent quite some time telling you about TLS 1.3's 0-RTT in this post, it is just one example of a security trade-off that WE made, all of us, for the benefit of a few big players. Was it the right thing to do? Maybe, maybe not.

What are the other examples? Well guess why we're using AES-GCM? Because it is hardware accelerated. But who asked Intel for it? Why are we standardizing a shitty WPA 3.0 protocol? Probably because some Wi-Fi Alliance is telling us to use it, but what the F is going on there? Why is full disk encryption (FDE) completely flawed? I am not even talking about the recent Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs) research, but rather the fact that vendors implementing FDE are never using authentication on ciphertexts! and continue to refuse to tackle the issue via primitives like wide-block ciphers. Probably because it's not fast enough!

Now look at what cryptographic primitives people are pushing for nowadays: AES-GCM, Chacha20-Poly1305, Curve25519, BLAKE2. This is pretty much what you're forced into if you're using any protocol in 2019 (yes even the Noise Protocol Framework). Are these algorithms bad? Of course not. But they are there because large companies wanted them. And they wanted them because they were fast. I touched on that in Maybe you shouldn't skip SHA-3 after Adam Langley's wrote an article on SHA-3 not being fast enough.

We're in a crypto era where the hotness is in the "cycles per byte" (cpp).

All of this is concerning, because once you look at it this way, you see that big players have a huge influence over our standards and the security trade-offs we end up doing for speed are not always worth it.

If you're not a big player, you most likely don't care about these kinds of optimizations. The cryptography you use is not going to be the bottleneck of your application. You do not have to do these trade-offs.