Thread

🛡️
Article header

The Gossip Vulnerability: Why NIP-17's "Deniable" Messages Aren't

NIP-17 promises deniable messaging with its three-layer design: an unsigned "rumor," a signed "seal," and an ephemeral "gift wrap." However, this setup has a hidden vulnerability. The signed seal allows recipients to prove that a message was sent by the claimed author, even without revealing the content. This creates a perfect scenario for gossip attacks, where the mere proof of communication can damage reputations. As we explore NIP-17, we find that the rumor, despite being unsigned, is not as deniable as it seems, making it a potential risk for exposure.

Published:

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, no one can prove who wrote it.

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. But Bob can't prove what the message says without revealing his private key, which would compromise all his messages.

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 without proof of content.

The Zero-Knowledge Twist

But it gets worse. Bob doesn't need to reveal his key at all. Using zero-knowledge proofs, Bob can prove the exact message content without revealing his private key.

The ZK circuit proves: "I know a private key that (1) corresponds to Bob's public key, (2) decrypts this signed seal to reveal specific content, and (3) the seal has 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. It's like putting an unsigned letter in a signed envelope. The signature on the envelope proves you sent that specific contents, even if the letter itself has no signature.

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 → No authentication at all

Why? In decentralized systems, messages must be self-authenticating so relays can verify them without coordination. This requires signatures. But signatures create non-repudiable proof, the exact opposite of deniability.

How Signal Actually Solves This

Signal achieves deniability through a completely different approach:

  1. No signatures on messages, only on one-time key exchanges
  2. Symmetric authentication using HMACs that both parties can forge
  3. Trusted servers that coordinate without verifying signatures
  4. Malleable transcripts, 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: not that messages can't be proven, but that "proof" is meaningless because forgeries are undetectable.

Signal's approach requires centralized coordination. Messages flow through trusted servers that don't verify signatures. Keys are distributed by servers that clients trust. This is antithetical to Nostr's decentralized philosophy.

The Marmot Reality Check

I investigated whether the Marmot protocol (using MLS) solves this. It doesn't. MLS has the exact same vulnerability: every message contains a FramedContentAuthData with the sender's signature.

RFC 9750 explicitly states: "MLS does not make any claims with regard to deniability." In fact, 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 isn't a bug or oversight, it's a fundamental tradeoff.

The Uncomfortable Truth

Perfect deniability is impossible in Nostr's architecture.

To achieve Signal-style deniability, Nostr would need:

  • MACs instead of signatures (breaks relay verification)
  • Trusted coordinators (defeats decentralization)
  • Synchronous key exchange (kills asynchronous messaging)
  • No per-message authentication (enables forgery)

The current NIP-17 design provides:

  • Network privacy: Gift wrap hides who's talking
  • Content secrecy: Only recipients can decrypt
  • Partial deniability: Can't prove exact content without key revelation

But it deliberately sacrifices:

  • True deniability: Recipients can prove communication occurred
  • Gossip protection: Vulnerable to "Alice sent me something bad" attacks

What This Means for Nostr

The Nostr community should acknowledge this tradeoff explicitly. NIP-17 is excellent for censorship resistance and metadata privacy, but it's not suitable for truly deniable communications. Users needing real deniability should use Signal or Session.

The unsigned "rumor" provides psychological comfort but no cryptographic protection. The signed seal is the vulnerability, and it's unfixable without redesigning Nostr's entire authentication model.

This isn't a failure, it's physics. Cryptography has limits. The impossible triangle of decentralized, authenticated, and deniable messaging is truly impossible. Every protocol must choose its compromises.

Nostr chose decentralization and authentication. That's a valid choice. But calling the messages "deniable" because the inner layer is unsigned? That's not cryptography, that's marketing.

The gossip attack is real. The ZK proof works. And the rumor isn't deniable after all.

Replies (6)

Great point! Tbh i always thought OTR itself was kind of pointless theater, but that was more a rather vague thought about its practical usefulness. This is much worse!
🛡️
So, the receiver can make a ZK proof that the receiver could decrypt the package and authenticate the sender and the text outside the seal (if this ZK-method actually works). It's kinda similar with the leak that simply shares the conversation secret between Alice and Bob. The receiver can share that secret and allow anyone to decrypt the seal. That's why NIP-17 doesn't promise plausible deniability in the list of benefits in the spec. The introduction cites it but only against coding mistakes: "Omitting signatures makes messages deniable in case they are accidentally or maliciously leaked"
🛡️
It seems like 'deniability' only matters for communications where protection against state level actors is necessary. Which is likely only for a few situations for a few people. Whereas, proof of authenticity of the source IS a feature, not a flaw, in most cases for most users. For instance, in communications within families and businesses deniability would be a drawback. Which by far constitute most users in most communications. With AI deepfakes causing The Great Disillusionment, (where ALL digital content must be considered 'suspect' until proven otherwise), having cryptographic proof that a message was sent from a Nostr account using its Nsec for 'sealing' is a VERY good thing! Perfect privacy is NOT always desirable in all cases by all people. Privacy advocates often fall prey to the Nirvana Fallacy, ignoring the fact that in the real world 'perfection' is NOT possible, and rarely necessary. Of course, acknowledging what data is exposed, to whom and when, is a good thing. Knowing what data leaks exist is essential for mitigating risks and assessing trade offs, as risks and tradeoffs always exist in one form or another.