Thread

It's a shared *secret*. Only sender and receiver know s (Diffie-Hellman key exchange).

I still don't get it. If "s" is only known to the 2 involved parties, seems like this message needs both parties online at the same time. Can the "s" be stored by relays and kept there so when the receiver logs in, the message will be displayed to thst client?

NIP-92: Rendezvous Beacons (draft;

GitHub

NIP-92: Rendezvous Beacons by shafemtol · Pull Request #333 · nostr-protocol/nips

Draft, a bit unstructured at the moment. Related: #306 Things that may be worth discussing at this point: expiration tag. Rendezvous beacons gene...

) enables anonymous establishment of communication between two parties, addressing the issue of receiving messages from unknown contacts. A shared secret is derived using ECDH like in NIP-04, but this shared secret is only used through *tagged hashes*, with a different tag (not to be confused with nostr tags) for each purpose. From the shared secret, a *rendezvous keypair* is established, where the sender knows the private key and the recipient knows the public key. This is done by tweaking the sender's key (an ephemeral key in the case of NIP-92) using a tweak value derived from the shared secret.

The shared secret is not the same key used for encrypting DM's. I don't understand how you believe that anyone would be able to decrypt anything.

Cool I'll have a look at this

Maybe something's missing in the pictures. Note that I'm not talking about decrypting *silent inbox* DMs. Here's an example of it going wrong as I understand it: First, Alice (keypair p1, Q1) sends Bob (keypair p2, Q2) a *regular* NIP-04 DM (no silent inbox). NIP-04 uses shared secret `S = p1 * Q2 = p2 * Q1` to encrypt the message. In NIP-04, this is given in the example code as: `let sharedPoint = secp.getSharedSecret(ourPrivateKey, '02' + theirPublicKey)` Eve also picks up this DM. She sees that Alice sent Bob a DM of a certain length at a certain point in time. She can't decrypt it yet, but stores it in her collection for later. Next, they Bob decides to try using a silent inbox. This time, Bob sends a message to Alice. Silent inbox uses shared secret `S = p1 * Q2 = p2 * Q1` (from the picture titled "Shared Secrets"). Bob constructs the event using an ephemeral key `w`, encrypting to `Q1` (I presume using `w * Q1` as the NIP-04 encryption key, but this is not relevant to the attack). She puts `S` in the `p` tag of the event and signs it (from the picture titled "Send and receive flow"). Eve also picks up this DM. She doesn't yet know its sender or recipient, but she reads the `p` tag and starts trying to decrypt the DMs she's got in her collection one by one, using the contents of the `p` tag as the shared secret. One of the DMs does decrypt to a valid message, namely the first, regular, DM from Alice to Bob. Eve can now decrypt every past and future regular (not silent inbox) DM between Alice and Bob. Furthermore, while Eve can not decrypt silent inbox messages due to the use of different encryption keys here, she learns that the silent inbox in question belongs to Alice and Bob and can see the length and timing of each message going to it.

What you could do is hash the shared secret curve point `S` (preferably using a tagged hash function) into a shared private key `r`, then use the corresponding public key `R = r * G` for the `p` tag. This would not leak the actual shared secret.

Ah now I get it, you're perfectly right, thank you! Massive issue that i had overlooked and yes, hashing fixes this, I'll add it to my implementation, thank you!