Know Your Enemy, Name Your Defenses

Security is a relationship, not a property. It exists between three things: the asset you are protecting, the adversary you are protecting it from, and the resources that adversary can bring to bear. A bank vault that defeats a lone burglar may crumble before a state intelligence agency. A disguise that fools your neighbors will not deceive facial recognition. Any security claim that fails to specify all three elements is not a claim at all. It is poetry.

This is why threat models matter. A threat model is a document that names your enemies and describes what they can do. It forces engineers to think clearly about what they are building and for whom. It forces users to ask whether a product actually addresses their situation. Without a threat model, security discussions devolve into vague reassurances and marketing slogans.

The Marmot Protocol, a specification for encrypted group messaging built on Nostr's decentralized network, publishes exactly such a document. It enumerates what the protocol defends against, what it does not defend against, and why. This is not a minor documentation choice. It is the difference between engineering and theater.

The Adversaries Marmot Actually Fights

The Marmot threat model specifies four categories of adversaries the protocol is designed to defeat, and for each one, it deploys specific countermeasures.

First, passive relay operators. Nostr relays are the servers that store and forward encrypted messages. Unlike centralized messengers, Nostr relays can be run by anyone, which means you cannot know or trust who operates them. Marmot assumes relay operators will attempt to surveil communications. The defense is layered. Message contents are encrypted using MLS's authenticated encryption with associated data, specifically AES-128-GCM, which provides both confidentiality and integrity. But content encryption alone would still leak sender identity through Nostr's standard event signatures. Marmot defeats this by using fresh ephemeral keypairs for every message. Each group message is signed with a disposable key that is used exactly once and then discarded. Relay operators see encrypted ciphertext, group identifiers as SHA-256 hashes that cannot be reversed to group names, timestamps, and ephemeral public keys that cannot be linked across messages. They cannot determine message content, sender identity, recipient identity, or group membership. The social graph remains invisible.

Second, active relay operators who interfere with message delivery. A malicious relay might drop messages, delay them, reorder them, or replay old messages in an attempt to confuse or compromise group state. This is a serious threat because MLS group state depends on members processing messages in a consistent order. Marmot handles this through deterministic commit ordering rules. When two conflicting state changes arrive for the same epoch, clients resolve them by selecting the commit with the lowest timestamp. If timestamps match, they use the lexicographically smallest event identifier. This deterministic tiebreaker means all honest clients converge to the same group state without requiring a trusted coordinator. Message replay is defeated by MLS's epoch and generation counters: each message includes identifiers that prevent an old message from being accepted twice. Message dropping is handled at the application layer through acknowledgment schemes, and clients can query multiple relays for redundancy.

Third, compromised group members from previous epochs. This is forward secrecy in practice, and Marmot inherits it from MLS's TreeKEM construction. The mechanism works as follows: each epoch of the group derives its encryption keys from the previous epoch's secrets using one-way cryptographic functions, specifically HKDF with SHA-256. When a member sends a message, they use a key derived from the current epoch's secret. After sending, they delete the key material used for previous epochs. If an attacker compromises a member's device today and extracts the current epoch keys, they cannot reverse the one-way functions to recover keys from earlier epochs. Those messages remain encrypted with keys that no longer exist anywhere. The attacker can read current messages, but the past is cryptographically sealed.

Fourth, state-level network surveillance. Assuming users employ VPN or Tor to mask their IP addresses, network observers see only encrypted traffic flows to public Nostr relays. They cannot determine who is communicating with whom, what groups exist, or what is being discussed. The decentralized architecture means no single server observes the sender, recipient, and timestamp of every message. Metadata remains distributed across whatever relays each user chooses. The ephemeral keypairs provide an additional layer: even if an observer correlates traffic to a specific relay, they cannot link messages to persistent identities because each message appears to come from a different sender.

What Marmot Cannot Save You From

Here is where the threat model earns its credibility. Marmot explicitly acknowledges four classes of attacks it does not and cannot defend against.

Compromised end-user devices. If malware controls your phone, it reads your messages after decryption. No cryptographic protocol survives the adversary already being inside the castle. This is not a failure of Marmot. It is a fundamental limitation of all software security. The protocol protects messages in transit and at rest on relays. It cannot protect them from the person holding the device.

Traffic correlation attacks by colluding relays. If multiple relay operators share information, they might link users by timing patterns, even without reading message contents. Alice connects to Relay A at 3:47 PM. Bob connects to Relay B at 3:47 PM. Both relays report activity in the same encrypted group. A sophisticated adversary might infer they are communicating. Marmot's ephemeral keys make this harder, but not impossible.

Quantum computers breaking elliptic curve cryptography. The X25519 key exchange and Ed25519 signatures that underpin Marmot's current implementation will fall to sufficiently powerful quantum computers. The protocol's architecture supports future migration to post-quantum ciphersuites like X-Wing, but this has not yet been deployed at scale. For now, the threat is theoretical. It will not remain so forever.

Coercion to reveal keys. Cryptography does not survive someone holding a wrench to your kneecap. Marmot's forward secrecy means coerced key disclosure reveals only current and future messages, not past ones, but this is cold comfort to someone facing state-sponsored interrogation. The protocol makes no promises about rubber hose cryptanalysis.

Why This Honesty Matters

The Marmot threat model matters because it tells you whether the protocol solves your actual problem.

Are you a journalist protecting sources from corporate surveillance? Marmot's metadata protection and decentralized architecture address your threat model directly. No single server operator can be compelled to produce communication records, because no single server has them.

Are you an activist organizing against a state with nation-state surveillance capabilities and a willingness to detain and torture? Marmot helps, but it is not sufficient. You need operational security beyond the protocol itself: air-gapped devices, physical security practices, compartmentalized communication networks. The protocol cannot compensate for a compromised device or a coerced member.

This is the value of an explicit threat model. It lets you make informed decisions rather than purchasing false confidence.

The Architectural Foundation

Marmot achieves its security properties by combining the MLS protocol, standardized by the IETF as RFC 9420, with Nostr's decentralized relay network. MLS provides the cryptographic machinery: TreeKEM for efficient group key management, automatic key rotation for forward secrecy and post-compromise security, and authenticated encryption for message confidentiality. But MLS deliberately leaves two critical components out of scope: the Delivery Service that routes messages between participants, and the Authentication Service that binds cryptographic keys to human identities.

Nostr fills both gaps. As a Delivery Service, Nostr's network of independent relays stores and forwards encrypted events without requiring trust in any single operator. As an Authentication Service, Nostr enables users to declare their own identity. Users control their own keypairs, choose their own usernames, and publish their own MLS KeyPackages to relays they select. There is no central authority issuing credentials or vouching for identity claims. You are your key. Other users verify you through whatever out-of-band methods they choose, whether that means checking a website, a social media profile, or a face-to-face exchange of public keys.

This combination addresses weaknesses in both component technologies. MLS alone requires some delivery service to route messages, traditionally a central server that creates a surveillance chokepoint. Nostr alone provides only basic encryption without forward secrecy, post-compromise security, or efficient group messaging. Together, they enable something neither achieves independently: decentralized secure group communication that scales to thousands of members without trusting any infrastructure operator.

The Landscape of Secure Messaging

Different messaging systems make different tradeoffs, and those tradeoffs matter for different threat models.

Signal offers excellent cryptography, careful implementation, and polished user experience. Its tradeoffs are architectural: phone number registration ties identity to telecommunications infrastructure, its servers observe communication metadata even when contents remain encrypted, and its operation depends on a single nonprofit organization. These are reasonable choices for Signal's mission, which prioritizes mainstream adoption and usability.

Nostr's existing direct message implementations, using NIP-04 and NIP-17, provide decentralization without the cryptographic sophistication of modern group messaging protocols. They lack forward secrecy and struggle with group conversations at scale.

Marmot occupies a different point in the design space. The specification is under active development and may introduce breaking changes, but Marmot and MDK, its reference implementation, are currently undergoing a formal security audit. This represents a coherent answer to a specific question: what does secure group messaging look like when you cannot trust any infrastructure operator?

The answer, apparently, begins with honesty about what you are defending against. The Marmot threat model is not a marketing document. It is an engineering specification. And that distinction, more than any feature comparison, tells you what kind of project this is.