could we simply generate a one-time use key and use that to send an encrypted message? ciphertext would include the real pubkey to reply to.
I’m not a cryptographer. nostr:note13krha8murhn2f8503pyp6jj9cum8hs5df94ueq7tczk924tcp3psr6zjac
Discussion
We need to know destination npub. The solution is to do not allow fetching kind 4 events for npub unless authenticated with it. It’s in the nip-04 🐶🐾🫡
consider bob wants to DM alice:
- bob generates one-time use keypair
- message includes his pubkey
- bob encrypts message to alice with one-time key
- bob sends event to relay
no npubs in nip-04 only hex keys.
Same as it’s done now. To and from HEX of npub 🐶🐾🫡
I am familiar with nostr-tools. I think we’re talking past each other 😹 ❤️
Probably 🐶🐾😂🤣😂
Describe the flow you propose please, if possible. 🐶🐾🫡
one issue with nip-04 encrypted dms is that they leak metadata about who is talking to who.
if bob wants to message alice he
- encrypts a message using his private key and alice’s pubkey
- creates a nostr event with the pubkey set to his pubkey and a p tag set to alices pubkey
this means anyone can see that bob sent alice a DM.
what if instead we obscure bob’s identity?
- bob creates a one-time use keypair
- encrypts a message (containing his real pubkey) using the one-time key to alice
- creates a nostr event with the pubkey set to the one-time and a p tag for alice
now it looks like one-time pubkey message alice, not bob.
Ah, got it. I understand what you meant now! Thank you. This will require a new NIP. Clients will have to implement it too. From address encryption is good and easily done. We could just have from tag encrypted with the random SK. Now, how do we ensure that the sender can also decrypt the message? If SK was lost then current shared secret scheme will not work. We basically need for the message to be traceable by the sender too, and relay will not have these data. 🐶🐾🤔
I don’t think there’s risk of losing the SK, it’s computed with (event.pubkey, privkey). it could be a nip but I think there are ways to implement that wouldn’t strictly require clients in implement it.
I am not worrying about losing SK, I am worried about two way communication and ability to fetch it by both parties 🐶🐾🫡
I feel like a conversation would be figured out by collecting enough conversation if Alice responds back and p tags bob.
Another approach but probably inefficient and more cpu intensive is to encrypt everything and recipient scans all events and tries to decrypt the event. The event it is able to decrypt successfully was meant for Alice and contains message from bob, signed by bob.
Many people have said that Nostr nah not be the best for secure DMs.
That wouldn’t scale for sure. 🐶🐾🫡
alice would ideally use the same protocol- a one-time key to send the message. now alice isnt the sender.
I finally found a video that someone made a while ago about the problem.
nice find! this is very similar to what I was thinking, down to calling it a “wrapped message”. though this has some additional complexity layered in that I hadn’t considered nor wrapped my head around fully
hey #[4] what’s the status of your wrapped dm stuff? seems I cooked up a very similar idea on the couch last night 😂
Checked profile. More to explore.
nostr:note152vytal3u0z8tzu7d2mx7szcy0u2nm9tzx3t75py9wrqj7etkypsddc7e9
Yeah, quite some progress! I’m preparing a full client dedicated to private DMs. It will ship originally with regular NIP-04 support, and my plan is to support a range of extensions and alternatives. There is no shortage of interesting ideas to improve DMs on Nostr, incognito DMs being pretty good. What we need now is just a client or set of clients that act as a testing ground for these ideas: bring real users to stress test the different ideas and find what works and what doesn’t.
My current thoughts on Incognito DMs/wrapped DMs is that I think the wrapped private events are a great idea that will likely be a core part of whatever the final system is, so that’s staying. But I’m not entirely sure about disposable identities/ephemeral pubkeys anymore. They are very simple conceptually, but they don’t play well with relays. Relays want real pubkeys, they want to know things are not spam. So I think the idea needs more work, but generally I’m optimistic that we can definitely find some system that both works with relays and preserves privacy.
Another ways is to use SK to derive source npub/PK. So Bob know from address since it is derived from his SK and Alice will know bobs DM, since it is encrypted in the DM. 🐶🐾🫡
