9.3 KiB
The No-Handshake Property of Nostr Events
The Core Insight
A Nostr event is self-validating. It contains everything needed to verify its authenticity:
- Pubkey — who claims to have sent it
- Signature — cryptographic proof that the pubkey's owner authorized this exact content
- Content — the message itself (possibly encrypted)
- Timestamp — when it was created
- Kind — what type of event it is
No prior relationship is needed between the sender and the relay. No handshake. No session. No connection state. The relay can receive the event, verify the signature, and decide whether to accept it — all without ever having communicated with the sender before.
This is different from almost every other protocol on the internet.
What Other Protocols Require
| Protocol | Handshake Required | Visible Pattern | State Created |
|---|---|---|---|
| TCP | 3-way handshake (SYN, SYN-ACK, ACK) | Yes — unmistakable | Yes — connection state on both sides |
| TLS | Multiple round trips (ClientHello, ServerHello, cert, key exchange, Finished) | Yes — certificate, cipher suites, etc. | Yes — session state |
| QUIC | 1-RTT handshake (Initial, Handshake packets) | Partially — Initial packet has recognizable structure | Yes — connection state |
| WireGuard | 1-RTT handshake (initiation, response) | Minimal — but still a recognizable exchange | Yes — session state |
| CurveCP | 2-packet handshake (cookie, server response) | Minimal — but still an exchange | Yes — server must track cookies |
| HTTP | Requires TCP + TLS first | Yes — full handshake stack | Yes — connection + session |
| Nostr event (over UDP) | None | No pattern at all | None — stateless |
Every other protocol requires some kind of handshake to establish a connection, exchange keys, or negotiate parameters. Nostr events need none of this because the event is already signed before it is sent. The signature replaces the handshake.
Why This Helps
1. No Handshake Pattern to Fingerprint
A TCP handshake is unmistakable: SYN, SYN-ACK, ACK. A QUIC Initial packet has a recognizable structure (version, connection ID, TLS ClientHello). Even minimal handshakes have patterns that can be detected by deep packet inspection.
A single Nostr event as a UDP datagram has no handshake pattern. It is just a blob of bytes. The adversary cannot distinguish it from any other UDP traffic without decrypting it.
2. No Active Probing Vulnerability
This is the most important advantage.
obfs4's weakness: obfs4 bridges are vulnerable to active probing. The adversary connects to a suspected bridge and sends data. If the server responds with a valid obfs4 handshake, the adversary knows it is a bridge. This is how China blocks many Tor bridges.
Nostr's strength: With a no-handshake protocol, the adversary can send a fake event to a suspected relay. The relay will try to verify the signature, fail (because the event is invalid), and either drop the packet or send back an error. But there is no handshake to distinguish. The relay's response to an invalid event looks the same as its response to random noise. The adversary cannot tell if the relay is a Nostr relay or just a server that happens to be listening on that port.
The adversary's active probing tools are designed to detect protocols that respond to a probe with a recognizable handshake. A no-handshake protocol does not respond with a handshake. It responds with nothing (if the event is invalid) or with a simple acknowledgment (if the event is valid). Neither response is distinguishable from any other UDP service.
3. Fire-and-Forget
The sender does not need to wait for a response. The event is sent as a single UDP datagram. If it arrives, the relay processes it. If it doesn't arrive, the sender may never know — but for many use cases (broadcasts, ephemeral messages, signaling), this is acceptable.
This is ideal for UDP because UDP is inherently fire-and-forget. There is no retransmission, no acknowledgment, no flow control. The protocol matches the transport.
4. No Amplification Attack Vector
Amplification attacks (like DNS amplification, NTP amplification) work because a small request triggers a large response. The attacker spoofs the source IP and sends a small query, and the server sends a large response to the victim.
Nostr events cannot be used for amplification because:
- The event is already the largest thing being sent
- The response (if any) is smaller than the event (a simple acknowledgment or error)
- The signature verification happens before any response is sent, so the relay can drop invalid events without responding at all
5. Stateless Relays
Because no handshake is needed, the relay does not need to maintain any state about the sender. It receives a UDP datagram, verifies the signature, stores the event, and forgets the sender. This makes relays simple, scalable, and resistant to state-exhaustion attacks (like SYN floods).
6. Hard to Distinguish from Noise
A single UDP datagram containing an encrypted Nostr event is indistinguishable from random bytes to a passive observer. The adversary sees:
- A UDP packet on some port
- 100-1400 bytes of seemingly random data
- No recognizable protocol structure
- No handshake
- No plaintext headers (if the event is encrypted)
This is the steganography approach combined with protocol hardening. The message is hidden in the noise of the network.
The Asymmetry
The adversary's problem is now much harder:
| Adversary Action | Cost | Effectiveness |
|---|---|---|
| Passive observation | Low — just watch the network | Low — cannot distinguish events from noise |
| Deep packet inspection | High — must inspect every UDP packet | Low — cannot read encrypted events |
| Active probing | Medium — send probes to suspected relays | Low — no handshake to detect |
| Block all UDP | Destructive — breaks the internet | High — but destroys the network |
| Block specific ports | Medium — breaks legitimate services | Low — events can use any port |
| Statistical analysis | High — must analyze traffic patterns | Medium — can detect unusual volumes, but not content |
The adversary's best option is statistical analysis (detecting unusual traffic volumes or patterns), but this is expensive and imprecise. It cannot determine the content of the communication, only that some communication is happening.
The Tradeoffs
No Delivery Guarantee
UDP does not guarantee delivery. Packets can be dropped, reordered, or duplicated. The sender does not know if the event arrived.
Mitigations:
- For important events, the sender can send multiple copies
- The sender can request an acknowledgment (a separate UDP packet back)
- The sender can use a higher-level protocol (like a simple ACK scheme) on top of UDP
- For broadcast events, delivery is not critical — the event is a signal, not a conversation
No Congestion Control
UDP does not have built-in congestion control. A sender could flood a relay with events.
Mitigations:
- The relay can rate-limit by pubkey (using a simple counter per pubkey)
- The relay can rate-limit by IP address
- The event itself contains a timestamp, so the relay can reject events that are too old or too frequent
- Proof-of-work (Nostr's NIP-13) can be required for events, making flooding expensive
Signature Verification Cost
The relay must verify the Schnorr signature on every event. This is computationally expensive compared to just accepting a TCP connection.
Mitigations:
- Schnorr signature verification is fast (~microseconds on modern hardware)
- The relay can use SIMD/AVX vector instructions for batch verification
- The relay can use eBPF to filter events at the kernel level before signature verification
- The relay can reject events based on other criteria (kind, pubkey, timestamp) before verifying the signature
Large Events
Events larger than 1472 bytes cannot fit in a single UDP datagram. They would need fragmentation, which adds complexity and creates a pattern that can be fingerprinted.
Mitigations:
- Most Nostr events are small (text notes, reactions, metadata) and fit easily in 1472 bytes
- Large events (files, images) can use a separate transport (TCP, or a reference in the event)
- The protocol can define a "large event" type that is sent over TCP while small events use UDP
The Bigger Picture
The no-handshake property is not just a technical detail. It is a fundamental asymmetry between Nostr and every other protocol.
Every other protocol requires the sender and receiver to agree to communicate before they can communicate. This agreement leaves traces — handshake packets, connection state, session keys. These traces can be detected, fingerprinted, and blocked.
Nostr events require no agreement. The sender creates the event, signs it, and sends it. The relay receives it, verifies it, and stores it. No prior relationship. No negotiation. No traces of an agreement.
This is the cypherpunk ideal: communication without permission, without negotiation, without trace.
The handshake is the point of vulnerability in most protocols. Nostr eliminates the handshake entirely. The signature replaces it. And a signature, unlike a handshake, is indistinguishable from random noise.