18 KiB
Passive Sniffing Relay — Plausible Deniability for Nostr Event Transmission
The Core Idea
A relay that overhears Nostr events from traffic passing by, rather than being the explicit destination of the packet. The sender's packet is addressed to an innocent destination (e.g., 8.8.8.8), and the relay copies the event out of the traffic without stopping or modifying the packet.
Sender → [Internet] → Innocent Destination (e.g., 8.8.8.8:53)
↑
Watching Relay
(copies the Nostr event
without stopping the packet)
The sender's claim: "I was sending a DNS query to Google. I have no idea what that Nostr relay is talking about."
Why This Matters
The Problem with Direct UDP
In the standard UDP Nostr model:
Sender → UDP datagram → Relay (port 443)
An observer on the network path sees:
- Source IP: sender's IP
- Destination IP: relay's IP
- Protocol: UDP
- Port: 443
Even if the content is encrypted, the observer knows the sender is talking to a Nostr relay. In an authoritarian regime, that's enough to flag the user.
The Passive Sniffing Inversion
Sender → UDP datagram → 8.8.8.8:53 (DNS)
↑
Watching Relay
(somewhere on the path)
An observer sees:
- Source IP: sender's IP
- Destination IP: 8.8.8.8
- Protocol: UDP
- Port: 53 (DNS)
This is indistinguishable from a normal DNS query. The relay is invisible in the traffic — it's not a destination, it's a passive observer on the path.
How to Embed the Event
DNS Query Encoding
A DNS query for a subdomain like:
<base64_event>.nostr.example.com
The sender crafts a DNS query where one of the labels contains the base64-encoded Nostr event. The watching relay, which is sniffing DNS traffic on the path, extracts the event.
DNS Label Constraints
| Constraint | Value | Impact |
|---|---|---|
| Max label length | 63 bytes | Event must fit in 63 bytes per label |
| Max total query length | ~255 bytes | Total encoded event + domain overhead |
| Character set | alphanumeric + hyphen | Base64url encoding required |
Binary Event Fit
Using the .bne binary event format from max_single_packet_event.md:
| Format | Event Size | Base64 Size | Fits in DNS? |
|---|---|---|---|
| JSON (kind 1) | ~400 bytes | ~533 bytes | No — exceeds 255 byte limit |
Binary .bne (kind 1) |
~200 bytes | ~267 bytes | Borderline — may exceed 255 bytes |
Minimal .bne (no tags, short content) |
~120 bytes | ~160 bytes | Yes — fits comfortably |
A minimal binary event with a short message (e.g., 40 characters of content) fits in ~120 bytes raw, ~160 bytes base64-encoded. This leaves ~95 bytes for the domain name overhead.
Splitting Across Multiple Labels
If the event is too large for a single label, it can be split across multiple labels:
<part1>.<part2>.<part3>.nostr.example.com
Each label can hold up to 63 bytes. Three labels give ~189 bytes of base64 data, which is ~141 bytes raw — enough for most single-packet events.
Alternative: EDNS0 Option
EDNS0 (Extended DNS) allows custom options in DNS packets. A Nostr event could be placed in a custom EDNS0 option, making the query look like it's from a resolver that supports some exotic extension. This is more隐蔽 but requires the relay to understand EDNS0 parsing.
Alternative: CoAP / QUIC / Custom UDP
DNS is the most natural choice because it's universally allowed and looks innocent. But any UDP protocol could work:
| Protocol | Port | Deniability | Complexity |
|---|---|---|---|
| DNS | 53 | Excellent — every device makes DNS queries | Low — simple query format |
| QUIC/HTTP3 | 443 | Good — looks like web traffic | High — requires TLS handshake |
| NTP | 123 | Good — every device syncs time | Medium — need valid NTP format |
| CoAP | 5683 | Moderate — IoT protocol | Medium |
| Custom | Any | Poor — unknown protocol stands out | Low |
Two DNS Models: Passive Sniffing vs. Authoritative Server
There are two fundamentally different ways to receive data via DNS. The document above describes Model A, but Model B is simpler and more practical.
Model A: Passive Sniffing (The Document Above)
Sender → DNS query to 8.8.8.8 → [Watching Relay sniffs the query] → 8.8.8.8 responds normally
- You do NOT own the DNS endpoint. The query is addressed to someone else (e.g.,
8.8.8.8). - The relay is a passive observer on the network path between sender and
8.8.8.8. - The relay uses
libpcaporAF_PACKETsockets to capture packets it wasn't addressed to. - No DNS server needed. The relay just watches traffic go by.
- Constraint: The relay must be physically on the network path. This is the hard part.
Model B: Authoritative DNS Server (Simpler)
Sender → Sender's DNS resolver (8.8.8.8, 1.1.1.1, etc.)
↓ "What is the IP of <base64_event>.yourdomain.com?"
Root DNS servers → TLD servers
↓ "yourdomain.com is managed by ns1.yourdomain.com at 1.2.3.4"
Sender's DNS resolver
↓ "Hey 1.2.3.4, what is the IP of <base64_event>.yourdomain.com?"
Your authoritative nameserver (1.2.3.4) ← YOU RECEIVE THE QUERY HERE
↓ "I don't have that record. NXDOMAIN."
Sender's DNS resolver → Sender
- You DO own the DNS endpoint. You run an authoritative nameserver for
yourdomain.com. - The sender queries a subdomain like
<base64_event>.yourdomain.com. - Your DNS server receives the query, extracts the event from the subdomain label, and responds with whatever it wants (NXDOMAIN, a fake IP, etc.).
- No packet capture needed. The DNS server receives the query normally through the standard DNS resolution chain.
- You do NOT need to control the sender's DNS resolver. The global DNS system automatically routes the query to your authoritative nameserver, regardless of which resolver the sender uses (8.8.8.8, 1.1.1.1, ISP's DNS, etc.).
- Constraint: The sender's DNS query goes to your nameserver, which is a known destination. Traffic analysis can see the sender is querying your domain. But the content is hidden in the subdomain label.
Comparison
| Property | Model A: Passive Sniffing | Model B: Authoritative DNS |
|---|---|---|
| Relay needs to be on path? | Yes — must overhear traffic | No — receives queries normally via DNS chain |
| Destination visible to observer | 8.8.8.8 (innocent) |
yourdomain.com (your domain) |
| Plausible deniability | High — looks like normal DNS to Google | Moderate — querying a specific domain |
| Legal risk | Medium — packet capture laws | Low — running a DNS server is normal |
| Reliability | Low — depends on being on the path | High — query arrives at your server guaranteed |
| Complexity | High — packet capture, path positioning | Low — just run a DNS server |
| Sender needs | Custom DNS query tool | Custom DNS query tool |
| Relay needs | Root/raw socket access | Standard DNS server software (nsd, bind) |
What You Need for Model B
- A domain name (e.g.,
nostr-relay.example) - A server with a public IP running DNS software (e.g.,
nsd,bind, or a custom UDP listener on port 53) - Domain registrar configuration pointing
nostr-relay.exampleto your server's IP - A script that polls the DNS logs, extracts base64 events from subdomain labels, decodes them, and injects them into the relay
The sender can be on any network, using any DNS resolver, anywhere in the world. The query will find your server through the standard DNS resolution chain.
Tor Compatibility
Can You Send a Single UDP Packet Over Tor?
No, not directly. Tor is TCP-only. The Tor network transports data as TCP streams, not UDP datagrams. There is no UDP support in the Tor protocol.
Tor works by building a circuit of encrypted TCP connections:
Your client → Entry node (TCP) → Middle node (TCP) → Exit node (TCP) → Destination (TCP)
Each hop is a TCP connection. The data is stream-oriented. There is no concept of a datagram boundary.
What You Can Do Instead
| Method | Works? | Notes |
|---|---|---|
| Raw UDP over Tor | No | Tor protocol doesn't support it |
| TCP over Tor, then UDP from exit | Yes | Run a bridge on the exit side |
| UDP over TCP tunnel over Tor | Yes | Encapsulate UDP in TCP, send over Tor |
| Tor + Bridge Server | Yes | See below |
The Bridge Pattern Over Tor
This is the most practical approach for sending UDP over Tor:
Sender → Tor (TCP) → Your Bridge Server (exit side) → UDP datagram → Relay
- Sender connects to your bridge server via Tor (TCP connection)
- Bridge server receives the Nostr event over the Tor TCP stream
- Bridge server fires a UDP datagram to the relay
- Relay receives the UDP datagram normally
The relay sees the bridge server's IP, not the sender's. The sender's IP is hidden by Tor.
Passive Sniffing (Model A) + Tor
The passive sniffing model does not work over Tor because:
- Tor encrypts the entire DNS query inside the circuit
- The exit node decrypts it and sends the actual DNS query
- The sniffing relay would need to be on the path between the exit node and
8.8.8.8 - You don't control where the exit node is — it's randomly chosen by the Tor network
So passive sniffing only works for non-Tor traffic where you can position yourself on the path.
Authoritative DNS (Model B) + Tor
This does work:
Sender → Tor → DNS query for <event>.yourdomain.com → Your DNS server
The sender's DNS query goes through Tor, exits at a random exit node, and reaches your DNS server. Your DNS server sees the exit node's IP, not the sender's.
Caveat: DNS over Tor is unusual. Most people don't route DNS through Tor. It may stand out to an observer who knows what to look for. However, the content of the query (the event in the subdomain) remains hidden.
How to Get on the Path
This is the fundamental challenge. The relay must be positioned somewhere between the sender and the innocent destination.
1. Public Wi-Fi Hotspot (Most Practical)
Run a free Wi-Fi hotspot. All DNS traffic from connected users passes through the hotspot's router.
User's laptop → Wi-Fi Router (your relay) → ISP → 8.8.8.8
Plausible deniability for the relay operator: "I just run a free Wi-Fi hotspot. I don't inspect traffic."
Plausible deniability for the sender: "I was just using the free Wi-Fi at the coffee shop."
Advantage: No technical sophistication required from the sender — they just connect to Wi-Fi and use Nostr normally.
Disadvantage: Limited geographic range. Only works for users physically near the hotspot.
2. Self-Hosted Innocent Server
The sender runs a server that pretends to be something innocent (a personal blog, a file host, a game server). The server also runs a packet capture that watches for Nostr events in incoming traffic.
Sender → Sender's own server (port 443, HTTPS) → (event extracted, forwarded to relay)
↓
Responds with innocent content (blog page, file, etc.)
The sender sends UDP packets to their own server, which:
- Responds with whatever the innocent service would respond with
- Silently extracts the Nostr event and injects it into the relay network
Advantage: Full control over the sniffing point. No legal risk.
Disadvantage: The sender's server is a known destination. Traffic analysis could correlate the sender with their server.
3. BGP Peering / AS Operation (Impractical for Individuals)
Run your own autonomous system (AS) and peer with an ISP. All traffic passing through your network is visible.
Advantage: Can see traffic from many users.
Disadvantage: Extremely expensive and complex. Requires physical infrastructure.
4. Compromised Router (Illegal)
Gain access to a router on the path and install packet capture software.
Advantage: Can see traffic from many users.
Disadvantage: Illegal. High risk. Ethically problematic.
5. Physical Tap (Illegal)
Physically tap a fiber optic cable or network switch.
Advantage: Can see all traffic on that link.
Disadvantage: Illegal. Requires physical access. High risk.
Comparison with Traditional Relay Architectures
| Property | Direct UDP | Bridge Pattern | Passive Sniffing |
|---|---|---|---|
| Sender connects to relay? | Yes | Yes (via bridge) | No |
| Relay visible in traffic? | Yes | Yes (bridge IP) | No |
| Plausible deniability | None | None | High |
| Sender sophistication | Low | Low (browser) | Low (Wi-Fi) or Medium (self-host) |
| Relay sophistication | Low | Low | Medium (packet capture) |
| Works in browser? | No | Yes | No (needs raw socket) |
| Event size limit | 1472 bytes | 1472 bytes | ~200 bytes (DNS constraint) |
| Real-time delivery | Yes | Yes | Delayed (depends on sniffing window) |
| Legal risk for relay | Low | Low | Medium (packet capture laws) |
The Cypherpunk Implications
1. Inversion of the Connection Model
Every existing communication system requires the sender to explicitly address the recipient. The passive sniffing relay inverts this — the recipient finds the sender's message in the noise of the internet.
This is analogous to dead drops in physical espionage: an agent leaves a message in a pre-arranged location, and another agent retrieves it later. No direct handoff.
2. Traffic Analysis Resistance
Even if an adversary can observe all traffic to and from the sender, they cannot determine which packets contain Nostr events. Every packet is addressed to an innocent destination. The adversary would need to:
- Decrypt the content (if encrypted)
- Know the encoding scheme
- Distinguish Nostr events from random noise
Without all three, the traffic is indistinguishable from normal internet activity.
3. The Wi-Fi Hotspot as a Cypherpunk Tool
A free Wi-Fi hotspot is a natural censorship circumvention tool:
- Anyone can use it without suspicion
- Traffic is mixed with all other users' traffic
- The operator has plausible deniability
- No registration or identity required
- Can be mobile (a phone hotspot) or fixed
A network of such hotspots, each running a passive sniffing relay, creates a mesh of dead drops — users can publish Nostr events from any hotspot without ever connecting to a known relay.
4. Relationship to Protocol Hardening
This approach is a form of protocol substrate hardening (approach 6 from 2Approaches.md) — it makes the transport medium itself resistant to censorship by hiding the communication inside a protocol that cannot be blocked (DNS).
It also incorporates steganography (approach 4) — the existence of the communication is hidden within innocent-looking DNS traffic.
Open Questions
1. Reliability
DNS queries are not guaranteed to pass through any particular path. How does the sender know the relay will see the query?
- Answer: They don't. This is a fire-and-forget model, like UDP itself. The sender publishes and hopes a relay picks it up. Multiple relays on multiple paths increase the probability.
2. Latency
DNS queries are resolved quickly (milliseconds). The relay must capture the packet in real-time. Is this feasible?
- Answer: Yes, with
libpcaporAF_PACKETsockets. The relay doesn't need to store all traffic — it can filter for DNS queries matching the expected pattern and ignore everything else.
3. Legal Risk
Packet capture without consent is illegal in many jurisdictions. How does the relay operator avoid legal liability?
- Answer: The Wi-Fi hotspot model provides a legal framework — the operator can argue they are providing a service and not inspecting content. The DNS queries are captured transiently for the purpose of routing, and the Nostr event extraction is incidental.
4. Event Size
DNS queries are limited to ~255 bytes. How do you send larger events?
- Answer: You don't. This approach is limited to single-packet events that fit in the
.bnebinary format. Larger events must use the standard bridge pattern or direct UDP.
5. Bidirectional Communication
The passive sniffing model is one-way (sender → relay). How does the relay communicate back to the sender?
- Answer: It doesn't need to. Nostr events are self-validating. The relay stores the event and serves it to subscribers. The sender doesn't need a response.
6. Multiple Relays
How does the sender ensure multiple relays receive the event?
- Answer: The sender can send multiple DNS queries, each addressed to a different innocent destination, with the same event embedded. Each query passes through different paths and may be captured by different relays.
Relationship to the Bridge Pattern
The passive sniffing relay is not a replacement for the bridge pattern — it's a complementary approach for different threat models:
| Scenario | Best Approach |
|---|---|
| User wants to publish from a browser | Bridge pattern (HTTP → UDP) |
| User is in a low-risk environment | Direct UDP (native app) |
| User is in a high-risk environment | Passive sniffing (DNS tunneling) |
| User wants maximum reach | All three simultaneously |
The bridge pattern solves the browser constraint. The passive sniffing relay solves the traffic analysis constraint. Together, they cover a wide range of censorship scenarios.
Summary
The passive sniffing relay is a novel approach to censorship-resistant Nostr event transmission that:
- Inverts the connection model — the relay finds the sender's traffic, not the other way around
- Provides plausible deniability — the sender appears to be making innocent DNS queries
- Leverages existing infrastructure — DNS is universally allowed and cannot be blocked
- Works with the binary
.bneformat — small events fit within DNS label constraints - Is deployable today — a Wi-Fi hotspot with packet capture is simple to set up
The core insight: if you cannot hide the destination, make the destination innocent and let the relay find you.