Key Transparency (in support of end-to-end encryption) on the Fediverse.
What is this?
Any attempt to build End-to-End Encryption for the Fediverse will confront a difficult engineering challenge: How do your users know which Public Key belongs to someone they want to communicate with?
Historically, there have been many attempts to solve this problem:
- SSH, by default, asks the user to manually verify a key fingerprint and then trusts only that key fingerprint unless manually changed by the user.
- TLS, which protects most web traffic, requires Certificate Authorities that are trusted by your browser or Operating System.
- PGP encouraged a "Web of Trust" system that was complicated and brittle.
Any system that attempts to solve this problem at scale is called a Public Key Infrastructure.
Neither of the above approaches are a good fit for the Fediverse. However, there is a reasonable precedent: To keep the Certificate Authorities honest, cryptographers and engineers invented Certificate Transparency, built on an append-only data structure called a Merkle Tree.
The Public Key Directory adopts ideas from Certificate Transparency in order to have a Federated Public Key Infrastructure without Authorities.
Key Features
📜 Append-Only Transparency Log
All key events are recorded in an append-only ledger built with a Merkle Tree, ensuring an honest view of history.
🔍 Verifiable Auditing
Anyone can verify the consistency and integrity of the key directory.
✂️ Shreddable History
GDPR takedown requests are possible through granular key erasure.
🌐 Distributed Trust
Witness co-signing and verifiable replication.
➕ Auxiliary Data (Advanced)
Developers can build atop the PKD to add key transparency to other systems.
❌ In-Band Revocation
Attackers cannot selectively censor revocation; it’s all-or-nothing.
Learn More
- Read the Specification
- Key Transparency — activitypub-e2ee issue tracker
- Fediverse Auxiliary Service Provider Discussion