Public Key Directory - Key Transparency for the Fediverse

2 min read Original article ↗

On the left side of the image, a purple and green protogen furry with a black face and green lights sits cross-legged while typing on a wireless keyboard. On the right side of the image, a blue dhole furry in a black sterotypical hacker hoodie smirks menacingly while typing on a laptop with RGB keys and a skull and crossbones sticker. Between the two is the ActivityPub logo, filled with static, signifying that some of their messages are encrypted over ActivityPub.

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

Project Status

  • Specification: v0.3.1
  • Cryptography library: v0.30.1
  • Server-side reference implementation: v0.3.4
  • Client-side reference library: v0.2.2
  • Formal proofs (ProVerif) and requirements traceability (Duvet): v0.2.0

Project Repositories