Renoters: Proposal for Anonymous Event Relaying in Nostr

Renoters: Proposal for Anonymous Event Relaying in Nostr

This document is a proposal and not an official NIP.

This Document proposes “Renoters,” a mechanism for anonymous event relaying in Nostr, inspired by the Mixminion remailer design. Renoters aim to enhance privacy by obscuring the origin of events, making it difficult to trace the author of a message.

Motivation

While Nostr offers a decentralized platform, current relay mechanisms can potentially reveal the source of events. Renoters address this by introducing an onion-routing-like system where events are encrypted and relayed through a series of nodes, making it harder to link the event to its originator. This enhances privacy for users who wish to communicate anonymously or protect their identity.

In some totalitarian regimes, the use of Tor and VPNs is criminalized, making online anonymity dangerous. Even in some democratic countries, merely downloading Tor can mark individuals as suspects. This underscores the need for a decentralized and anonymous communication system that operates independently of commonly surveilled privacy tools.

Proposed Solution

Renoters operate on the principle of “gift-wrapping” events, using asymmetric encryption. A user wishing to send an event anonymously performs the following steps:

1. Event Creation: The user creates the Nostr event they wish to publish.
2. Renoter Path Selection: The user selects a path of Renoters through which the event will be relayed. This path can be pre-configured or dynamically chosen.
3. Gift Wrapping (Encryption and Signing): The user encrypts and signs the event for each Renoter in the path, working in reverse order:
   • A new random Nostr private key (sk_wrapper) is generated.
   • The event (or the previously wrapped event) is encrypted using the next Renoter’s Npub (npub_next) using Nostr’s standard encryption mechanism (e.g., using shared secrets derived from the private key and the recipient’s public key).
   • A new Nostr event is created. This “wrapper” event’s content contains the ciphertext. The wrapper event is signed using the newly generated private key sk_wrapper. The wrapper event also includes the next hop’s npub_next (or the final destination if it’s the last renoter) in cleartext, to allow for routing.
4. Publication: The user publishes the first gift-wrapped event (the one encrypted for the last Renoter in the path). This event is sent to a regular Nostr relay, which then forwards it to the first Renoter in the path.
5. Renoter Relaying: Each Renoter in the path receives the gift-wrapped event, verifies the signature using the sk_wrapper’s corresponding public key, decrypts it using its own private key, and forwards the decrypted event (now wrapped for the next Renoter) to the next Renoter in the path. This process continues until the event reaches the final Renoter.
6. Final Delivery: The final Renoter decrypts the event and publishes it to the Nostr network.

Example

Let’s say Alice wants to send an event anonymously through Renoters R1, R2, and R3.

1. Alice creates her event.
2. She generates a random private key sk3 and encrypts the event with R3’s public key npub_r3.
3. She creates a wrapper event containing the ciphertext and npub_r3, signed with sk3.
4. She generates a random private key sk2 and encrypts the previous wrapper event with R2’s public key npub_r2.
5. She creates a wrapper event containing this ciphertext and npub_r2, signed with sk2.
6. She generates a random private key sk1 and encrypts the previous wrapper event with R1’s public key npub_r1.
7. She creates a final wrapper event containing this ciphertext and npub_r1, signed with sk1.
8. Alice publishes this final wrapper event.

R1 decrypts with its private key, verifies the signature with the public key corresponding to sk1, and forwards to R2. R2 decrypts, verifies the signature with the public key corresponding to sk2, and forwards to R3. R3 decrypts, verifies the signature with the public key corresponding to sk3, and publishes the original event.

Renoter Incentives (using Cashu)

To incentivize Renoters to participate in the network, this NIP proposes integrating Cashu tokens as a payment mechanism.

• Token Inclusion: When a user creates the initial gift-wrapped event (the one sent to the first Renoter), they include a Cashu token within the event content. This token is itself encrypted and wrapped along with the original message, so only the receiving Renoter can access it.
• Renoter Redemption: Upon receiving a gift-wrapped event, the Renoter decrypts it. If the event contains a Cashu token, the Renoter can decrypt the token and redeem it.
• Renoter Behavior: Paid Renoters would be configured not to relay events that do not contain a valid Cashu token. This ensures that Renoters are compensated for their service. Free Renoters could still exist, but paid Renoters would likely offer faster or more reliable service.
• Token Value and Tiers: Different Cashu token denominations could represent different levels of service (e.g., faster relaying, higher priority). This could create a tiered system where users can pay for better anonymity or speed.
• Token Generation: Users would need a way to acquire Cashu tokens. This could involve purchasing them from a Cashu mint or earning them through other means.

Security Threats and Mitigations

• Anonymity Against Correlation Attacks: Even when using Tor, traffic patterns can still be analyzed to infer the origin of events. To mitigate this risk, Renoters can introduce:

  • Random delays in event relaying.
  • Dummy packets to complicate statistical analysis by malicious observers.

• Replay Attacks: To mitigate replay attacks, each Renoter must store, for a reasonable period, the IDs of received events and the decrypted events that were forwarded. This ensures that duplicate messages are not processed again.

• Sybil Attacks: Sybil attacks can be mitigated by requiring payments via Cashu tokens for relaying events, increasing the cost of launching such attacks. By ensuring that each relay operation has a monetary cost, attackers are discouraged from creating large numbers of fake identities to manipulate the network.

• Traffic Analysis: Traffic analysis can be mitigated by using Tor for Renoters. Routing events through the Tor network adds an additional layer of anonymity, making it more difficult to track message origins or infer sender-recipient relationships. While Renoters enhance privacy, sophisticated traffic analysis might still be a threat.

Operational Considerations

• Renoter Reliability: The reliability of the Renoter network is crucial.
• Latency: Relaying through multiple Renoters will introduce latency.
• Key Management: While each layer uses a new key, the initial key generation and path selection process need to be secure.

This NIP provides a robust framework for anonymous event relaying in Nostr, leveraging encryption and Cashu-based incentives to enhance privacy and usability.

References

• Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms: David L. Chaum (https://dl.acm.org/doi/10.¹¹⁴⁵⁄₃₅₈₅₄₉.358563)

• Mixminion Design: Mixminion: Design of a Type III Anonymous Remailer (https://www.mixminion.net/minion-design.pdf)

• Nostr Protocol: Official Nostr Documentation (https://github.com/nostr-protocol/nostr)

• Cashu Token System: Cashu: Ecash for Bitcoin Lightning (https://cashu.space/)

• Tor Project: The Tor Project - Anonymity Online (https://www.torproject.org/)

• Onion Routing: The Second-Generation Onion Router (https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf)

#Privacy #Nostr #Anonymity #Crypto #CensorshipResistance #OnlinePrivacy #Decentralization #Encryption #Security #ThreatMitigation #Micropayments #CryptoEconomy #NextSteps #Development