The Long Tail of Work Left Until ActivityPub Has E2EE - Dhole Moments

Skip to the content

Search

Search for:

Close search

Close Menu

Separate from my proposal for key transparency for the Fediverse (which I’ve certainly blogged about a lot), the W3C has been working on building out end-to-end encryption (E2EE) for ActivityPub.

The two projects are mostly being developed independent of each other, though connecting the two should be straightforward.

As I prepare to tie up the loose ends and call my side of the work "feature complete" and consider tagging a major version 1.0.0 for the specification and reference implementations, I thought it would be useful to lay out the work that needs to be done in order to get this over the finish line–in part, because this is where most technical folks can begin to meaningfully contribute without needing security or cryptography expertise .

Unlike most of my blog posts (which are intended to be what some bloggers call "evergreen"), I fully intend for this one to be less useful over time, as the work gets done.

To make the most sense, I’m going to work backwards from the desired end state, delving recursively into prerequisites of each unit of work necessary, and then follow it up with a roadmap that should have no surprises if you read the preceding prose.

Art: CMYKat

Working Backwards

This is a complicated effort, so I think it’s best to start by distilling the desired end state into three distinct goals.

Fundamental Goal : Fediverse users should be able to send each other end-to-end encrypted messages, which may include attachments. This must efficiently support group messages, not just 1:1 messaging. This is currently being implemented with Emissary and Bonfire, built on a protocol called Messaging Layer Security (MLS, RFC 9420).

Security Goal: Users should be able to know that the end-to-end encryption is being performed correctly, and with the correct encapsulation keys.

To that end, Each encapsulation key (which is shipped in what MLS calls KeyPackages) must be signed, client-side, by the user (using an asymmetric digital signature algorithm).

Authenticity Goal : The signing keys must be verifiably controlled by the user, and anyone must be able to verify this property. This verification must not rely on a central authority.

The Authenticity Goal is where key transparency comes in. By providing an append-only cryptographic transparency log of which Actor (in ActivityPub parlance) controls which signing keys, you can build a decentralized root of trust. This is where my focus has been for the past several years.

These goals build on each other:

Without satisfying the Fundamental Goal, none of this work has any real pay-off to end users.

Without satisfying the Security Goal, the end-to-end encryption must come with a giant fucking asterisk that nobody wants.

Without satisfying the Authenticity Goal, Fediverse clients that wish to support E2EE will resort to Safety Numbers of Key Fingerprinting–techniques that even professional cryptographers I respect do not bother themselves with, and therefore not a realistic expectation for most people either.

Let’s first discuss each of these three work streams as separately as possible.

Clipboard Sticker<br>" data-large-file="https://i0.wp.com/soatok.blog/wp-content/uploads/2021/04/soatok-telegrams-wave-3-commission-11.png?fit=512%2C512&ssl=1" src="https://i0.wp.com/soatok.blog/wp-content/uploads/2021/04/soatok-telegrams-wave-3-commission-11.png?resize=512%2C512&ssl=1" alt="Clipboard Sticker" class="wp-image-3102" style="width:auto;height:256px"/>CMYKat

Why Do Something Rather Than Nothing?

Note: This was added after the blog post was initially published because it’s important context.

The status quo is as follows:

Direct Messages today do not use end-to-end encryption

Regardless of jurisdiction, storing sensitive messages and attachments as plaintext is legally perilous for Fediverse instance hosts

The EU codifying ChatControl 1.0 into law is also noteworthy here

This may come as a surprise to some folks, but sending nude images or videos is kind of a normal thing that many adults want to do (hopefully with consenting recipients).

But if you have a large repository of such content, suddenly these instances becomes a juicy target for sextortion or revenge porn. This is also a risk if one of your instance administrators goes rogue, or is secretly evil to begin with.

End-to-end encryption mitigates most of this risk by virtue of not having any plaintext stored on any Fediverse instance servers to begin with.

For more on threat modeling, see my previous blog post.

MarleyTanuki<br>" data-large-file="https://i0.wp.com/soatok.blog/wp-content/uploads/2023/07/soatok-stickers4.png?fit=512%2C512&ssl=1" src="https://i0.wp.com/soatok.blog/wp-content/uploads/2023/07/soatok-stickers4.png?resize=512%2C512&ssl=1" alt="Soatok maximizing the use of rainbows" class="wp-image-8732" style="width:auto;height:256px"...