The Gossip Vulnerability: Why NIP-17's "Deniable" Messages Aren't
- The rumor that wasn’t
- The zero-knowledge twist
- The fundamental triangle
- How Signal solves this
- The Marmot reality check
- The uncomfortable truth
- What this means for Nostr
The rumor that wasn’t
NIP-17 gift-wrapped messages promise privacy through a clever three-layer design: an unsigned “rumor” (the actual message), wrapped in a signed “seal” (encrypted to recipient), wrapped in an ephemeral “gift wrap” (hides metadata). The unsigned rumor supposedly provides deniability: if leaked, the signed outer layer obscures its authorship.
This is cryptographic theater.
Here’s why: Bob receives a gift wrap, decrypts it to find a seal signed by Alice’s real key, then decrypts the seal to read the rumor. Now Bob faces a devious choice. He can prove to anyone that Alice sent him something by showing the signed seal. The seal’s signature is undeniable; only Alice’s private key could create it. Bob can prove Alice sent him something by showing the seal, and proving the message content requires only a zero-knowledge proof, with the private key kept secret.
This creates the perfect gossip attack: “Alice sent me something inappropriate, here’s cryptographic proof she messaged me, though I won’t reveal my key to show you what.” The signed seal enables reputation destruction absent any proof of content.
The zero-knowledge twist
It gets worse. Bob can prove the exact message content via zero-knowledge proofs while keeping his private key entirely secret.
The ZK circuit proves: “I know a private key that corresponds to Bob’s public key, decrypts this signed seal to reveal specific content, and the seal carries Alice’s valid signature.” The proof takes 10-30 seconds to generate on modern hardware and instantly convinces anyone that Alice sent that exact message.
The rumor being unsigned is irrelevant; the signed seal already breaks deniability. The signature on the envelope proves you sent that specific content, even when the letter itself is unsigned.
The fundamental triangle
You can only have two of these three properties:
Decentralized + Authenticated = NIP-17/MLS → Messages are signed, creating proof
Authenticated + Deniable = Signal/OTR → Uses symmetric MACs, requires server coordination
Decentralized + Deniable = Anonymous systems → Authentication is absent
Why? In decentralized systems, messages must be self-authenticating so relays can verify them independently. This requires signatures. Signatures create non-repudiable proof, which is the exact opposite of deniability.
How Signal solves this
Signal achieves deniability through a completely different approach:
- No signatures on messages, only on one-time key exchanges
- Symmetric authentication using HMACs that both parties can forge
- Trusted servers that coordinate and accept messages at face value
- Malleable transcripts, where either party can fabricate entire conversations
After a Signal conversation, Bob can create a fake transcript showing Alice said anything, and it’s cryptographically indistinguishable from real messages. This is deniability: proof is meaningless because forgeries are undetectable.
Signal’s approach requires centralized coordination. Messages flow through trusted servers that accept them unverified. Keys are distributed by servers that clients trust. This is antithetical to Nostr’s decentralized philosophy.
The Marmot reality check
The Marmot protocol (using MLS) has the same vulnerability: every message contains a FramedContentAuthData with the sender’s signature.
RFC 9750 states explicitly: “MLS does not make any claims with regard to deniability.” MLS deliberately chose non-repudiation to enable abuse reporting, the opposite of deniability.
The MLS architects made the same choice as Nostr: accountability over deniability. This is a fundamental tradeoff, not a bug or oversight.
The uncomfortable truth
Perfect deniability is architecturally incompatible with Nostr.
Achieving Signal-style deniability would require symmetric MACs (breaking relay verification), trusted coordinators (defeating decentralization), synchronous key exchange (killing asynchronous messaging), and per-message forgery capability. Each requirement dismantles a core Nostr design property.
The current NIP-17 design provides real value: gift wrap hides who’s talking, only recipients can decrypt, and proving exact content requires key revelation. What it cannot provide is gossip protection or proof that communication occurred at all.
What this means for Nostr
The Nostr community should acknowledge this tradeoff explicitly. NIP-17 is excellent for censorship resistance and metadata privacy, but unsuitable for deniable communications. Users needing real deniability should use Signal or Session.
Psychological comfort comes from the unsigned “rumor,” but cryptographic protection does not. Fixing the signed seal vulnerability requires redesigning Nostr’s entire authentication model.
The tradeoff is physics, not failure. Cryptography has limits. Decentralized, authenticated, and deniable messaging form an impossible triangle; every protocol must choose its compromises.
Nostr chose decentralization and authentication. That’s a valid choice. Calling the messages “deniable” because the inner layer is unsigned is marketing, not cryptography.
The gossip attack is real, the ZK proof works, and the rumor is attributable.
Loading comments…