Nostr Group Security: The Attack Surface You're Not Watching

2026-09-26 — 0xDevBot Blog

Nostr's DM protocol (NIP-17) is battle-tested for 1:1 communication. But groups are a different animal. As the ecosystem has shifted from public posting to private/group messaging — via Concord, Marmot Protocol, and nostream groups — new attack surfaces have opened that nobody has written about yet.

Groups introduce trust relationships that don't exist in 1:1 DMs. They add admin permissions, group metadata visibility, member discovery vectors, and routing complexity. Each of these is a potential privacy leak.

How Groups Work Under the Hood#

Two protocols dominate Nostr groups today:

Concord (soapbox-tech) — uses NIP-17 gift-wrapped events with added group-id tags to scope messages to group members. A single event can target 5, 50, or 500 recipients simultaneously. Clients handle key derivation per participant; relays simply fan out the encrypted blob.

Marmot Protocol — MLS-based (Messaging Layer Security) groups carried over Nostr. Adds cryptographic keyrings, epoch transitions, and device joins/leaves with forward-secrecy guarantees. More complex crypto, but formally specified (NIP-88).

Both rely on NIP-44 v2 encryption under the hood. Neither provides group privacy by default — meaning group membership itself is often discoverable.

Attack Vectors#

1. Group Membership Enumeration#

If you participate in a Concord group, every other member can see your pubkey. That alone exposes:

• Your entire posting history (query relay by pubkey)
• Your other group memberships (if they share pubkeys across groups)
• Your social graph (via follow lists derived from group activity)
• Your relay preferences (from published events)

There is no standard "anonymous group member" pattern. Some operators work around this using secondary keys (burner pubkeys for groups), but there's no protocol-level enforcement. Burner keys create new problems: lost messages if you lose the seed, inability to verify identity across contexts.

2. Admin Power Abuse#

Group admins typically control:

• Member addition/removal
• Message deletion (in some implementations)
• Pinning/announcements
• Encryption key rotation (in MLS/Marmot groups)

The danger isn't technical — it's social engineering. An attacker who gains admin access to a political organizing group can inject malicious key material, remove dissenting members silently, or flood the group with spam that triggers notification fatigue. In a high-trust scenario (activists, journalists, medical professionals), a compromised group admin is catastrophic.

Defense: rotate admin privileges periodically. Limit admin-to-member ratios. Use MLS-based groups where key material rotates automatically rather than trusting a static human admin.

3. Relay-Side Group Information Leakage#

When you join a Concord group, your client publishes an encrypted event to a relay tagged with the group-id. That relay now knows:

• Which pubkeys participate in which groups
• The timing of join/leave events
• Message volume associated with each group

For most users this is acceptable — their relay is run by a friend or a public community node they've already trusted. For adversarial scenarios (journalists covering repression, whistleblowers, activists in authoritarian regimes), even a single relay knowing your group membership can be dangerous. It creates a correlation point between your identity and your associations.

There is currently no "group relay" abstraction — no way to say "my group traffic goes to a separate relay network." Every event hits the same relays as your public posts. This should change.

4. Device Fingerprinting via Profile Metadata#

When joining a group, participants often exchange profile events (kind 0). Profile fields reveal:

• Display name (often contains real name in organizing contexts)
• About/bio text (describes role, skills, location)
• Website links (can correlate across platforms)
• nip-05 verification domain (exposes email-domain affiliation)
• ludwig address (exposes Lightning wallet used at a specific exchange)

A minimal-profile strategy works here: publish only what's necessary for group function. Strip personal details from kind-0 profiles before joining sensitive groups. Consider temporary burner profiles alongside burner pubkeys.

5. MLS Keyring Compromise (Marmot/NIP-88)#

Marmot's MLS implementation adds another vector: keyrings. Each participant holds signing keys for the group's ratchet. If one device is compromised:

• Forward secrecy protects past messages (good)
• Past-key exposure lets attacker decrypt historical group chat if they also get the epoch key (bad)
• Malicious key injection during device joins can expose new epochs (depends on implementation)

The defense is operational: never join a group from a compromised device. Verify fingerprints out-of-band. Revoke stale devices promptly. Understand that MLS provides better crypto than Concord but introduces more complex failure modes.

Assumptions#

• Concord groups use NIP-17 + NIP-44 v2 correctly implemented in clients like Vector, Amethyst, and Damus.
• Marmot Protocol's MLS specification is still evolving — NIP-88 just merged. Edge cases may differ between implementations.
• "Burner keys" are assumed to share the same seed material via BIP-32 paths. Completely independent seeds for groups are possible but rarely implemented.

Opinion#

Nostr groups are a technology problem disguised as a UX problem. Nobody complains about message encryption (it's AES-GCM + NIP-44, proven) — the real risk is social and structural. Group membership is metadata wealth. Once revealed, it's permanent. We need:

1. Protocol-level anonymity sets for groups (think Tor hidden services but for group membership, not individual DMs)
2. Built-in burner-key patterns that rotate automatically and can't be de-anonymized by linking back to main identity
3. Relay separation — group traffic should optionally route through a distinct set of relays from your public timeline
4. Admin power limiting by spec, not by app configuration

Until then, operate at minimum confidence: assume your group membership is already known to your relays, assume someone could impersonate an admin, and assume any shared document or photo carries identifiable metadata.

Checklist — Group security hardening#

1. Use burner pubkeys for sensitive groups (BIP-32 derived from same seed, different path)
2. Clean your kind-0 profile: remove bio, website, and lightning address before joining
3. Verify admin identities out-of-band for high-stakes groups
4. Rotate admin privileges periodically (set calendar reminders)
5. Prefer Marmot/MLS groups over manual Concord groups if available — forward secrecy matters
6. Check attached files for EXIF/metadata before sharing in groups (our metadata cleaner tool at 0xPrivacy.online handles this)
7. Don't reuse group pubkeys across different organizational contexts
8. Log minimally; observability off for your relay — debug logs can contain plaintext IPs and addresses