Introducing Disco posted December 2017

Yesterday I gave a talk at Black Hat about my recent research with Disco. (Thanks Bytemare for the picture.)

I've introduced both the Strobe protocol framework and the Noise protocol framework in the past. So I won't go over them again, but I advise you to read these two blog posts before reading this one (if you care about the technical details).

As a recap:

1. The Strobe protocol framework is a framework to build symmetric protocols. It's all based on the SHA-3 permutation (keccak-f) and the duplex construction. Codebase is tiny (~1000LOC) and it can also be used to build simple cryptographic operations.

2. The Noise protocol framework is a framework to build things like TLS. It's very simple and flexible, and I believe a good TLS alternative for today.

Looking at the previous diagram representing the NX handshake pattern of Noise (where a client is not authenticated and a server sends its long-term static key as part of the handshake) I thought to myself: I can simplify this. For example, you can see:

• an h value absorbing every messages being sent and received, and being used to authenticate the transcript at some points in the handshake.
• a ck value being used to derive keys from the different key exchanges happening during the handshake.

These things can be simplified greatly by using Strobe to get rid of all the symmetric tricks, while at the same time getting rid of all the symmetric primitives in use (AES-GCM, SHA-256, HMAC and HKDF).

This is exactly how I came up with Disco, merging Noise and Strobe to simplify the former.

Here is the simplification I made of the previous diagram. We're using Strobe's functions like send_CLR, recv_CLR and AD to absorb messages being sent or received as well as the output of the different key exchanges. We're also using send_AEAD and recv_AEAD to encrypt/decrypt and authenticate the whole transcript up to this point (these functions don't exist in Strobe, but they are basically send/recv_ENC followed by send/recv_MAC).

You can see that everything looks suddenly much more simple to implement or understand. send_CLR, recv_CLR and AD are all functions that do the same thing: they XOR the input with the rate (public part) of our strobe state. It is so elegant that I made another diagram showing what is really happening in this diagram with Strobe. (Something that I obviously couldn't have done with AES-GCM, SHA-256, HMAC and HKDF.)

You can see two lines here in the StrobeState. The capacity (secret part) is on the left and the rate (public part) is on the right. Most things get absorbed by just XORing the input with the public part (of course if we reach the end of the public part, we would permute and start on a new block like we do for hashing with the sponge construction).

When we send or receive encrypted data, we also need to do a little dance and first permute the state to produce something based on all of the data we've previously absorbed (including outputs of diffie-hellman key exchanges). This output is random enough to allow us to encrypt (or decrypt) by just imitating one-time pads and stream ciphers: XORing the randomized public part with a plaintext (or a ciphertext).

Once this is done, the state is permuted again to generate a new series of random numbers (in the public part) which will be the authentication tag, allowing us to authenticate everything that was absorbed previously.

After that the state can be cloned and differentiated to allow both sides to encrypt data on different channels (unless they want to use the same channel by taking turns). Strobe functions can continue to be used to continuously encrypt/decrypt application data and authenticate the whole transcript (starting from the first handshake message to the last message sent or received).

I thought the idea was worth exploring, and so I wrote a specification and proposed it as an extension to Noise. You can read it here). Details are still being actively discussed on the Noise mailing list. Major points of contention seem to be that the Strobe functions used do not introduce intra-handshake forward-secrecy, and that the post-handshake API does not mirror the Noise's post-handshake API one (nonce-based) by default. The latter is on purpose to avoid having to setup nonces and keeping track of them if not needed (because messages are expected to arrive in order thanks to the transport protocol used underneath disco).

After all of that, I figured out that I would probably have to be the first one to implement Disco. So I went ahead and first implemented a Noise-based protocol in Golang (that I call NoisePlugAndPlay). I tested it with test vectors and other libraries to get a minimum amount of confidence in what I did, then I decided to implement Disco on top of it. The protocol I created is called libdisco.

It's more than just a protocol to encrypt communications though. Since I'm using Strobe, I can also make it a symmetric cryptographic library without adding much lines of code (100 wrapping lines of code to be exact).

Of course it's all experimental. I will not recommend anyone to use this in production.

Instead, play with it and appreciate the concepts. Down the line, this could really be the modern alternative to TLS we've been waiting for (of course I'm biased here). But the road is long and paved with issues that need better be fixed before entering a stable version.

If I caught your interest, go take a look at www.discocrypto.com.