Whitenoise - The Hidden Cost of Forward Secrecy: Multi-Device Messaging in MLS and NOSTR

Introduction

In the pursuit of private, tamper-resistant messaging, protocols like MLS (Messaging Layer Security) have emerged as the new cryptographic backbone for secure group communication. They bring strong guarantees—forward secrecy, post-compromise security, and membership authentication—to real-time messaging.

However, these gains come with a significant constraint: multi-device access under a single identity becomes non-trivial. This issue is particularly relevant in decentralized environments like NOSTR, where a user’s identity is not bound to a device but to a globally shared public key (NPUB). In protocols like NIP-44, this enables different clients to transparently resume encrypted conversations using the same identity key.

But MLS doesn’t work that way. And it’s not a bug—it’s a feature.

The Problem: Identity vs. Device Scope

MLS does not operate on the level of identities. It operates on the level of devices, each of which holds a distinct credential, key package, and ratcheting state. When you want a second device to join the conversation, it isn’t just a new interface—it’s a new participant in the cryptographic group.

In MLS, each device has its own leaf node in the group tree. There is no such thing as a “shared identity key” with shared state across clients.

This breaks the NOSTR-style model of seamless, identity-based conversation continuity.

Adding a Device ≠ Replaying the Past

When a new device is added to an MLS group:

• It receives a Welcome message containing the current epoch secret.
• This allows it to derive future encryption keys from that moment onward.
• But all prior epoch secrets—and their derived message keys—are permanently unrecoverable.

There is no cryptographic path backward. This is enforced by the forward secrecy property of MLS: even the original sender cannot help the new device decrypt those messages unless they explicitly re-share the plaintext.

Synchronization Without Compromise

Systems like White Noise, a NOSTR-compatible messenger built on MLS, do address this by:

• Treating each client as a distinct MLS leaf.
• Ensuring that each device participates directly in the ratcheting process.
• Not replicating or synchronizing state across devices.
• Maintaining full forward secrecy and post-compromise security.

Thus, White Noise preserves the MLS model without violating its assumptions, but sacrifices automatic access to message history. If a device wasn’t present when a message was sent, it simply cannot read it.

Design Tradeoffs

If a messaging system wants:

• Full device portability,
• Stateless message access,
• Seamless client switching,

Then it cannot also enforce strict forward secrecy and post-compromise security without significant compromises. Shared symmetric keys (as used in NIP-44) enable such portability, but they undermine the trust boundaries enforced by MLS.

To combine both worlds, an application must either:

• Build a secure message re-sharing layer above MLS, or
• Choose a weaker protocol that prioritizes device portability over uncompromised security.

Conclusion

Multi-device access under a single identity is fundamentally at odds with forward secrecy.
MLS resolves this by grounding trust in devices, not abstract identities. While this enables robust cryptographic recovery and containment of compromise, it also requires a new device to start fresh—deaf and blind to history.

In decentralized systems like NOSTR, this tension defines a key tradeoff between secure state separation and identity-level continuity. Future systems must navigate this boundary with care, designing intentionally around the limits of cryptography, not against them.