The Long Tail of Work Left Until ActivityPub Has E2EE
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).…