giftwraps without the spam issues? I think it makes sense to establish an approved channel before you should be able to send private notes to someone. Then you can start building a private network of friends without metadata leakage. This is very cool đź‘€ #privatenostr nostr:note1pwkvjh3ytef58wzmugqmrpc4s6870vtsw4cesh7nw5c57ma4f49scstjke
Discussion
also, plausible deniability.
someone can’t prove that you said you’re running an unregistered money transmitting business in a DM
private write and public read relay
nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc i think this would be better than giftwraps for the ratcheting spec. In signal you need to approve chats. This spec you create and approve channels (device keys/prekeys) that are easy to query on, dos/spam resistant, deniable and forward secret.
we could probably even integrate this natively into the channel spec.
I’m down to try implementing it with it!
I’m down to E2EE communications. Hope it isn’t too much extra work. Fixin’ to renew my Purple sub once *May 1 arrives BTW.
*my #nostr anniversary
đź’ś
I looked into it more and I think that the simplified DR protocol doesn’t provide the full security guarantees as the standard DR protocol, and it’s basically on par with my proposal.
Explain more as to why?
The protocol provides no benefit compared to ephemeral key exchanges.
One part of DR is post-compromise security: if the current state of the ratchet is leaked, the mixing of new secret information via say key exchanges will render it unusable. The NIP lacks this functionality.
The rotation of encryption keys every message does not provide any benefit except the fact you can authorize new devices without giving them access to previous communications, without the post-compromise security bit.
The message key being leaked without the ratchet state being leaked is a very unlikely, if not impossible, scenario.
I need the left side of the curve description of how this actually works. I don’t really understand how this hides metadata from what nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj has written.
Looks like you’d have to publish prekeys for every conceivable person you might want to talk with?
There is also no post compromise security
Establish a new channel. Done.
fyi, your protocol lacks post-compromise security as the ratchet state is advanced deterministically. the post-compromise security comes from extra data being mixed into the state when advancing the ratchet that may not be observed by an attacker post-compromise.
The new data being mixed in is a new ephemeral key that is generated as the root ratchet is turned, which in turn derives the chain keys. That new key would only be visible/accessible to an attacker if the users device was completely compromised to an attacker. At which point nothing is going to be useful.
Post-compromise security refers to recovery from a total leakage of internal state.
The DH ratchet uses continuous key exchanges to update itself in a non deterministic way.
In your case, this is not actually a DH ratchet, but a symmetric ratchet without any data mixed in (the root) being used to feed the sender and receiver ratchets. This makes the system state determinstic and gets rid of post-compromise guarantees, and has equivalent security guarantees as using a single ratchet for send and one for receive.
I also do not see how the “active participant changing” would be defined in contexts where there’s concurrent events being sent.
No. You only need one prekey.
The initiating party uses an ephemeral key.
The shared secret is used to derive 2 private keys, one for initiator to target, and one for target to initiator.
When sending a message you pick the private key depending on your role in the channel, encrypt the message to the key itself, and put it in an event signed by the key. To receive messages you look for events by the other side.
This also comes with plausible deniability.
Channels can be rotated and this provides stronger security guarantees than gift wraps (sender and recipient anonymity).
What pubkey and p tag pubkey is used in the channel info event (373)? Some random ephemeral pair?
The real pubkeys.
I believe this is strongly metadata leak resistant as channels can be established before they are needed, or when not needed to obscure other details like who was ever communicated with.
This can be, and the specification permits future re-initializations to be performed in the same channel.
Where can I find info on giftwraps?