Recently, I shared my thoughts on the Twitter Exodus. The short of that post is: Even though I’m quite happy on the Fediverse, I think the best outcome is for Bluesky to “win” the popularity contest today. It’s also in a good position to do so: People yearning for “old Twitter” find Bluesky comfortable.

Everything posted on Bluesky is public, due to architectural decisions they made early in their design. Bluesky is currently centralized, though a “credible exit” is possible. I highly recommend reading the linked article before continuing to read my thoughts here.

Earlier this year, Bluesky announced several possible items on their Protocol Roadmap. Today, I’d like to look at two of the items on the horizon (Protocol-Native DMs; Limited Audience (Non-Public) Content) and explore ways the Bluesky developers could implement these without significantly changing their architecture.

Instead, we can use cryptography to satisfy both use cases (although they will almost certainly have different key management requirements). If that sounds surprising to you, I promise I will explain my reasoning for this statement.

The organization of this blog post will be as follows: First, I’ll briefly recap some of my prior and ongoing work to build end-to-end encryption for direct messages on the Fediverse. Then, I’ll introduce the cryptographic algorithms and protocols relevant to our discussion. With the basics settled, we can explore how these protocols can be used to satisfy the use cases for Bluesky users. Finally, I’ll discuss a few considerations for building atop this work to enable use cases and small business opportunities for the Bluesky community.

Due to the nature of what I’m discussing today, it’s highly likely that this post will be many people’s first introduction to my blog, and to me. So I feel a brief introduction is warranted.

Feel free to skip this section if you don’t care.

Soatok Dreamseeker is the name of my fursona, and my pen name for this blog, Dhole Moments (the first word being pronounced like “dole”, which refers to a species of wild canid).

Most of my blog posts include some furry art between large sections of text, as this website is a furry blog first and foremost. Sometimes I write about technical topics (mostly software security and applied cryptography), which inspires people to share my writing on message boards and leads to some downright exhausting comment threads.

I’m only going to include one piece of furry art in this post (aside from the header image), but if you read anything else on my blog, be prepared to see much more.

(None of the art on this website is adult-oriented or not-safe-for-work by any reasonable person’s measure.)

Behold!

Relevant Prior and Ongoing Work

In 2022, after Elon Musk bought Twitter, I moved to the Fediverse and was unimpressed with the lack of progress on building end-to-end encryption (E2EE) for direct messages, so decided to take matters into my own paws.

The biggest challenge for deploying E2EE in such an environment is a mix of key management and trust. After puzzling over this for a while, I decided to focus on a tangential concern: Federated Key Transparency.

In the coming months, I plan to tag v0.1.0 of my proposed specification for Public Key Directory software, build a reference implementation, and then shift gears back to E2EE for the Fediverse (for which I have also decided to use post-quantum KEMs in the initial version, rather than a later update).

Separate from all this, I have written a lot about applied cryptography over the years. Nearly half of the posts on this website involve it at some point.

I don’t really like talking about my professional life (and, barring one exception in its history, I haven’t). The main purpose of this blog is for me to have fun. Sometimes my writing helps people understand new or complex ideas, and I’m always delighted to hear when it does.

This is all to say: I’m deeply familiar with the relevant problem space and have been involved in it for years now.

However, like all mortals, I do occasionally make mistakes; sometimes, very embarrassing ones. You should always ask your favorite security experts to fact-check anything I write before you trust my word on any topic.

Cryptography Basics

This section is intended to make the overall blog post more accessible to a wider and less technical audience.

If you’re already familiar with the basic cryptographic algorithms and protocols, the next section about how Bluesky could use them is where the juicy stuff begins.

If you’d like to go further in learning cryptography, I recommend So you want to be a cryptographer? to begin your journey.

Algorithms

Hash Functions

Hash functions transform arbitrary-length input messages into a fixed-length output. They are a handy building block for cryptography designs, but programmers often use them poorly.

A good, secure cryptographic hash function, such as BLAKE3, has a few important properties:

It’s a trapdoor. If you know the input, it is trivial to calculate the output of a hash function. Conversely, if you only know the output, it should be computationally infeasible to find an input that produces the same value. (Succeeding at this is called a “preimage attack”.)

It’s collision-resistant. Finding two different inputs that produce the same hash should be quantifiably difficult. The emphasis here on “two different inputs” cannot be understated: If you can produce the same input from multiple code paths, the output will also be identical. (See also: My trivial attack against IOTA’s hash function.)

It avalanches. The “avalanche effect” means if you take two inputs that differ only very slightly, they should produce wildly different hash functions. This is an informal notion, of course; the formal property that cryptographers care about is indistinguishability from a random oracle, which necessarily implies an avalanche effect between input and output bits.

It’s fast. People sometimes get tripped up by this one. Cryptographic hash functions need to be fast, while password hashing functions need to be computationally expensive. I previously wrote a lot about password-based cryptography if you’d like to learn more.

That said, hash functions are some of the easiest cryptographic primitives to reason about for one simple reason: There are no secret keys to manage. You have an input (the message) and an output (the digest).

Things quickly become much more complex once you go beyond hash functions.

Symmetric-Key Encryption

There is a lot of complexity about ciphers that I’m going to sweep under the rug for this post. Read Serious Cryptography by JP Aumasson if you’d like a formal treatment on the subject.

The short list of things you need to know about modern symmetric-key encryption today is as follows:

1. Symmetric key means that the same key is used in both directions: encryption, decryption. There are encryption algorithms that use different keys for each operation (and only one can be shared publicly).
2. AEAD. This acronym stands for “Authenticated Encryption with Additional Data”, which refers to a class of algorithms that provide both confidentiality and integrity guarantees.

   AEAD algorithms allow you to encrypt messages with some assurance that decryption will fail if an attacker attempts to tamper with it at all.

   The integrity guarantees also cover Additional Associated Data (AAD), which lets you bind an encrypted message (called the ciphertext) to the context in which it’s intended. Without this property, you have Confused Deputy attacks. I wrote about confuse deputy attacks a fair bit when covering database cryptography last year.

   The only thing you need to care about here is: If a symmetric encryption mode is not AEAD, that’s a red flag.

3. Commitment. There’s a class of attacks called “invisible salamanders” against some AEAD schemes, which can be defeated with a technique called key-commitment.

   Unfortunately, this attack is poorly understood by most technologists. Nevertheless, only AEAD algorithms or protocols that provide key-commitment (at least) are worthy of our consideration.

4. Nonces (UK folks can call them IVs instead, if they want, since “nonce” has an unfortunate slang meaning there) are numbers that must not repeat for the same symmetric key. That is to say, they are numbers that must only be used once.

   Most modern AEAD schemes rely on nonces to provide security for many messages encrypted under the same key, but explode catastrophically if a nonce is ever repeated.

   If the nonce can be repeated safely, it’s either referred to as a “tweak” instead of a nonce, or the whole shebang aims to be nonce misuse resistant mode of operation.

   You don’t need to care about most of this; it will not be on the final. Just know that nonces repeating is very bad and should be avoided unless you’re using different keys.

That might sound like a lot to remember, but please believe that this is the extremely simplified list.

In contrast with hash functions above, symmetric-key encryption is shaped like this:

Where:

If you find yourself twiddling with block ciphers and padding schemes directly, something has probably gone horribly wrong.

Key Encapsulation Mechanisms (KEMs)

KEMs are what you should be using instead of asymmetric encryption (a.k.a. public-key encryption).

Truth be told, KEMs actually wrap public-key encryption or key exchange algorithms, but does so in a way that avoids the risk of recreating common mistakes or introducing security vulnerabilities that are old enough to legally drink alcohol in the United States.

The API for a KEM is pretty straightforward:

Where:

Modern KEMs prevent you from having to care about cryptography nerd stuff like padding oracle attacks, invalid curve or subgroup attacks, the inevitable convergence of iterated surjective hash functions, complex conjugates in quaternion space, or the output of group operations not being uniformly random bit strings.

And only one of those things was made up! If you can’t tell which, and you find yourself typing the letters R-S-A into your code, you’re doing it wrong.

Digital Signatures

A digital signature is pretty simple: You have a signing key and a verifying key, which have some mathematical relationship.

You can then sign messages with your signing key, and your recipients can verify them with the verification key.

Where:

There are some nuances to consider about what properties you get out of signature algorithms, but modern ones (i.e., Ed25519 and ML-DSA) spare you from having to care about those details.

Protocols

Now that we have some cryptographic algorithms under our belt, it’s time to use them to create useful protocols.

Or rather, that’s what I would be saying if the protocols I plan on discussing today weren’t already invented years ago and well-studied by cryptographers.

Hybrid Public Key Encryption (HPKE)

HPKE is what you get when you combine a KEM with symmetric-key encryption and gift-wrap it nicely.

When I talk about HPKE, I’m specifically referring to IETF RFC 9180.

The HPKE API is pretty much what you’d expect if you combined these algorithms in a straightforward way, though the under-the-hood details may be different from what you might get if you naively combined them.

Messaging Layer Security (MLS)

The Messaging Layer Security Protocol (RFC 9420) is an elegant combination of KEMs, symmetric encryption, and binary trees to establish a shared symmetric key for group messaging.

The important thing to know about MLS is that the bandwidth cost of key rotation scales logarithmically to group size.

If you have a private chat of 8 friends, you only need to invoke your KEM algorithm 4 times to update everyone to the latest shared key.

If you have a less private chat of 1000 people, it only requires 11 KEMs to update everyone.

But what about 1 million? Only 21 KEMs invocations!

Caveat: There are some situations (such as removing a user from the group) that can have a worse-case performance that’s linear to the number of users.

If you had every Bluesky user today join a MLS group, each group operation would only involve 25 KEM operations.

That’s what “scaling logarithmically” means.

Key Transparency

Key Transparency is a different use of binary trees for cryptography.

Using hash functions, you can create a Merkle Tree.

With this in hand, you can build an append-only cryptographic ledger where every entry has a proof of inclusion.

If you build an append-only ledger to publish the verification keys used to generate digital signatures, you have key transparency: Everyone can independently prove that a specific key was published when the user claims it was.

Building a key transparency protocol atop a Merkle Tree is the subject of much of my recent and ongoing work for the Fediverse.

Private Airspaces for Bluesky

With a basic understanding of the relevant algorithms and protocols, we can now move onto my ideas for private airspaces in Bluesky.

Limited Audience / Non-Public Content

If you’re familiar with what was written above, and how Bluesky uses Decentralized Identifiers, implementing limited audiences is somewhat straightforward:

1. Use the public keys embedded in the Decentralized Identifiers as verification keys for digital signatures.
2. Use MLS to establish group keys for followers, using the digital signatures from above to authenticate key bundles for MLS.

When a Bluesky user wants to send a message to a limited audience, they can either use HPKE with the group public key, or symmetric encryption as a member of the group, to ensure that only their followers can read its contents–even if the ciphertext exists in the same channels as public messages.

Bluesky could additionally offer different “circles”, such that some posts could be public, some could be only read by followers, and some could be only a smaller subset of followers. More on this in a bit.

Protocol-Native DMs

The same underlying cryptography could also be used for direct messages between groups of Bluesky users. However, key management is going to matter a lot more.

For limited audiences, the main benefit of encryption is to prevent a malicious relay from understanding what was communicated. It doesn’t really matter as much how the secret keys are managed for limited audiences, as long as it’s not incredibly stupid.

Direct messages are more personal, more direct, and likely more sensitive. Therefore, the following needs to be true:

1. Secret keys should be generated on users’ hardware, and should never leave them. Not even for backups.
2. For multi-device support, a private MLS group could be used (for simplicity).
3. Public keys shouldn’t be your DIDs, they should be managed separately (from end-to-end) with a key transparency protocol baked in.

However, once you have vended the appropriate public keying material for groups, you can just use MLS as with limited audiences, and then encrypt between users. This keeps the plaintext out of the hands of any Bluesky relay operators, and therefore improves privacy.

The Wild Blue Yonder

An astute reader may notice that I spent more time explaining the background knowledge than my actual ideas.

This is no accident: Once you understand the algorithms and protocols, explaining how to use them to build the desired features is straightforward.

Premium Limited Audiences

In the section pertaining to how Bluesky could implement Limited Audiences using MLS, I mentioned having different “circles”.

Many artists and other creative work currently rely on platforms like Patreon to earn an income. The ability to make access to another user’s “circle” require a subscription would give artists a viable alternative.

Because the actual protocol contents would be encrypted, the relays wouldn’t be able to bypass this protection. The business models this enables would be compatible with the decentralization goals of Bluesky.

The actual mechanics of the payment gateway, however, may be a bit more thorny: If a centralized payment processor, such as Stripe, isn’t an option, the only alternative we can consider is cryptocurrency–which is certainly controversial.

To build subscriptions out of cryptocurrency without giving a payment provider too much power (or potential for abuse), embedded wallets could be developed–which users could then fund directly the same way we currently use virtual credit cards.

We don’t need embedded wallets to build recurring subscriptions out of existing payment gateways; they’re already first-class features of Stripe, Square, and others. However, they are vulnerable to MasterCard and the anti-porn lobbyists threatening to blacklist their executives from the US banking system, as OnlyFans was threatened with.

Closing Thoughts

“From simple abstractions, great power may bloom.”

Mark Miller

I’ve briefly explored how existing cryptography protocols can be used to build limited audiences and private DMs.

The cryptography engineering involved in actually building such a thing is much more complex than I can cover in a single post on my personal blog, but I hope that this can serve as a sketch from which Bluesky developers can build a concrete proposal and implementation in the future.