Publish by peers

[motorina0]

TL;DR:

• problem: relays know the IP of clients and can track their private messaging activity
• solution: clients can use onion-routing like events to obscure activity from relays

One way to increase the privacy of Encrypted Direct Messages is for peers to derive new keys when they communicate. See this (draft) issue for more details.

• in the strictest mode, two peers (Alice and Bob) can use a new key for each new DM
• this approach hides to any outside observer that Alice and Bob are having a private conversation

Not all relays can be trusted

However, the relay(s) that Alice and Bob are connected to can learn that Alice and Bob are chatting.

• for the scenario where Alice sends a message to Bob:
  • 
• AB1, AB2, AB3, etc are keys that Alice derives in order to communicate with Bob. They are one-use-only keys.
• BA1, BA2, BA3, etc are keys that Bob derives in order to receive messages from Alice. They are one-use-only keys.

The relay can see that Bob is subscribed to public keys to which Alice sends messages. Therefore it is trivial to deduce that Alice and Bob are having a private conversation.

Re-publisher

The concept is similar with that of a remailer [1]:

• Alice will NOT publish messages with Bob as the direct destination.
• instead Alice will choose one (or more) of her "contacts" (say Carol) to forward the message to Bob:
  • Alice builds a direct message for Carol where the content is the full nostr event for Bob
  • Carol decrypts the direct message and publishes the nostr event to the relay
  • it is NOT possible for Carol to discover that the message is for Bob. The destination is just an one-use-only public key that cannot be connected to any participant. Only the relay knows that Bob has a filter for that public key.
  • the relay sees Alice's message for Bob as coming from Carol (from the IP perspective)
    • 
  • Alice might trust her peers more that she trusts any particular relay.
  • in order to make it harder for the relay to correlate the messages, Alice can:
  • add random padding data to the wrapped nostr event that Carol will ignore (avoid correlation by size)
  • split the wrapped nostr event for Bob in two or more events sent to Carol (avoid correlation by size)
  • if Carol is mostly an idle participant then the relay can easier correlate by frequency. It is desirable for Alice to choose re-publishers that are very active (publish a lot).

Cross relay re-publisher

The privacy can be increased even more if Alice uses one relay to communicate with Carol (Relay X), but Carol uses a different relay (Relay Y) to forwards the nostr event to Bob.

• this assumes Relay X and Relay Y are not colluding
  • 

Notes:

• a new kind for Typed Encrypted Direct Messages is required in order for clients to easily differentiate between normal messages and re-publish requests. See this issue.
• Alice must make sure that Carol is online, but she (Alice) can use multiple re-publishers.
• if Bob advertises which relays it uses, then it is easy for Alice to find a common peer to re-publish her message(s)
• Carol can accept to be a re-publisher for a "selected list of contacts"/"followers"/"following"/"everyone" etc.
• Carol does not have to be in contact with Bob, they just have to share a common relay
• the more re-publishers there are, the more private the DMs become
• being a re-publisher is very easy. It is a client-side task (in the browser/app). It requires no storage, only bandwidth. Respectable Nostr clients should have the option to also act as re-publishers.
• it is possible for volunteers to run re-publish bots
• more hops should be possible Alice -> Carol -> Dave -> Bob, but with each hop the re-publishing becomes less reliable since any hop can go offline at any moment.
• paid relays are not covered here (so far). An e-cash solution like cashu [3] could help.
• using re-publishers can be activated for more sensitive chats only
• suggestion: add ttl (Time To Live)[2] tag for DM events. This way re-publish event do not have to be kept for long (only a few minutes)

References

[1] Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms [2] Time to live [3] cashu spec

[fiatjaf]

I like this a lot. I see a possible NIP for this as having a standardized very generic republish event with kind 20001 (ephemeral) in the form

{
  "kind": 20001,
  "content": "<encrypted JSON of the event that is to be republished>",
  "tags": [
    ["p", "<pubkey of the person that is chosen to republish this>"],
    ["relays", "wss://relay.com", "wss://otherrelay.com", "and so on, there could be many of these"]
  ]
}

Then whenever the chosen republisher sees a note like that they automatically decrypt it using NIP-04 method and publish it to the chosen relays.

• The chosen relays could (and probably should) be different from the relay used to broadcast the republish event.
• There could be many republish events with the same underlying encrypted event.
• There could be multiple nested levels of republish events.

People can easily run very lightweight republish services for free and provide anonymity for everybody else.

[motorina0]

What is "encrypted-secret" used for in:

["p", "<pubkey of the person that is chosen to republish this>", "encrypted-secret"],

[fiatjaf]

Something that shouldn't have been present in that comment. I'll remove that.

[motorina0]

NIP PR: https://github.com/nostr-protocol/nips/pull/430 Preview here

[ghost]

Very interesting, but how do we avoid sybil attacks on the "republisher" network? If a large entity just wanted to host tons of republishers, it could read the metadata of most forwarded messages.

And as Michael Hayden said, we kill people based on metadata, so I think we should first look into scrubbing the metadata from NIP-4 before implementing this

Also, what's there to stop the republishers from simply accepting, then dropping the events? Or what about trying to manipulate the event data? Or the ciphertext? Since it's encrypted using AES-256-CBC, rather than some Authenticated mode, it's hard to verify

Imo, we grant the republishers a lot of power, since you have to trust them with the entire event. Who says they're going to keep the public key and signature the same?

[motorina0]

Very interesting, but how do we avoid sybil attacks on the "republisher" network? If a large...

• the republish only makes sense in the context of DMs (encrypted data). For public data the identity of the publisher must be public.

it could read the metadata of most forwarded messages.

• that is true if the events are published in the current NIP-04 form
• however, there is a proposal (by me) here such that no metadata is revealed to the world

Also, what's there to stop the republishers from simply accepting, then dropping the events?

• nothing, a re-publisher can do that
• a re-publisher is not necessary a 3rd party service. It can be any of your peers (friend list) that signals that it wants to be a re-publishers
• a user can choose many re-publishers (public ones, or a random subset of its friend list)
• a client-side application (like coracle, iris, etc) can be a re-publisher while online. You too can be a re-publisher for your peers.

Or what about trying to manipulate the event data...

• the content of the write event is encrypted with the shared secret
• the wrapped event is hashed and signed
• so the cryptographic functions (hash, sign and encrypt) guarantee that the data is not manipulated

Imo, we grant the republishers a lot of power, since you have to trust them with the entire event...

• we do not, it is trustless
• the same question can be asked of relays trying to manipulate data

[earonesty]

nip-59 gift-wrap dm's effectively scrub metadata. we should probably "bake that in" as an optional way to dm someone for security-minded people.