Oddbean new post about login | logout We already 'discarded" double ratchet for not adding much on top of nip 17. Now, the focus is on MLS because of the need for large group chats.
Am I right that nip-17 reveals the message recipient public key?
If you don't use aliases, yes. But in Nostr, your key is always receiving something. Since the public doesn't know if it is a valid message or noise, you can't see the sender and even the time is unreliable for time-collision algos, it's a simple scheme that's truly powerful. You can always add new keys to it, if you want more privacy, but all algos that I have seen make it worse by leaving extra breadcrumbs in Nostr to be found and broken into.
If you are interested in exploring it.. This PR seems clean enough, but adds a little complexity with multiple relays and multiple keys per conversation pair. It works even for group chats, since users can have access to separate aliases even inside the same group. https://github.com/nostr-protocol/nips/pull/1306
In the end, you can always simply use a Private Inbox relay (like inbox.nostr.wine) and no one will see your DMs, even if your keys are listed there. It's hard to beat that simplicity.
The solutions you mentioned for mitigating the issue of NIP-17 exposing the recipient's identity do not completely solve the problem. A better solution would be to automate the updating of the recipient's address. nostr:note1ck7kjmlmcfwjl6cp4wwne9nneg2nzw484w4l3gwrjjhlysjvcxjq5tx62j
NIP-17 exposes the recipient's identity and lacks both forward and backward secrecy. However, its advantage lies in better multi-device synchronization capabilities. Because the encryption key and receiving address remain unchanged, users can receive and decrypt all messages simply by importing their nsec. NIP-17 is designed for DM in microblogging applications, not as a standalone chat application. It prioritizes multi-device synchronization over enhanced encryption security. This is not a flaw, as it has suitable application scenarios.
Nothing completely solves the problem since any app will always have to ask the relay or a server for messages that match a given query. That query is the public identifier of the user and can be simply traced over time and mapped out with IP and other actions in the protocol.
You are mixing up issues from different layers.
Yep, because the reality includes all these layers. And they break each other constantly. You can't truly claim any privacy without considering all these layers combined.
If we can solve an issue on a specific layer, such as the metadata privacy of recipients and senders at the application layer, that is definitely progress. IP issue is a network layer issue and needs to be resolved at the network layer. Moreover, the solution to the recipient's metadata privacy issue is the same as the solution for the sender's metadata privacy issue: both are addressed by continuously updating addresses.
Sure, it's progress. But if you have progress in one, but doesn't solve the other layer, you can't claim being better. Sorry. I have seen too much of these BS with "private" comms in the last 20 years. people love to fool users into more complicated stacks and then leaving IP all there to be fully traced by servers.
Exactly 💯 If playing with relays and keys like this already solves the "super secret activist" use case, then why bother with MLS? What does it add? Except for the bad UX for everyone that's not a secret agent.
I guess cryptographic forward & backward secrecy would be the most important addition, along with hiding the recipient metadata. I see Jeff started double ratchet at https://github.com/nostr-protocol/nips/pull/1206 and moved on to MLS. I'll take a look.
I think forward and backward secrecy are unachievable in Nostr. You can either be able to load your DMs in many clients and not have any type of real forward and backward secrecy OR you can have DMs that are only visible in the originating client, and thus "broken UXs" everywhere else and then yes with forward and backward secrecy. There is no way to do both.
Maybe we can have something like Signal for connecting sessions on different devices / clients so they see the same messages.
Then you have just broken forward and backward secrecy: Attackers can use that feature to reassemble the ratchet state and decrypt all your messages, past and future.
They can only see message history as far as the linked device allows and can't see future messages if the device unlinks. I don't know the exact details how Signal does this, but I don't think its forward and backward secrecy is broken because of the feature.
Actually even without device linking, I'd rather use forward-secret messages even if they're out of sync with some other client.
As long as you never let the ratchet state be exported from the main client, you should be fine. But that blocks people from using multiple DM clients, which is a core motivation behind Nostr. You are blocking users into your client and locking them out of others. Same data silos Twitter and Facebook gave today.
There's nothing preventing users from moving to another DM client. You can always go back to the old client or export or copy paste message histories if you need them. It's not comparable to Twitter or Facebook, because you own your identity key and can always change the client or relays. There's always a tradeoff between availability and security of messages, and maybe there are different use cases for both kinds of messaging. On Nostr, we are free to choose.
If you can export and import it, you don't have any forward secrecy... Ever.
Signal doesn't have forward secrecy if you can save a backup of your chat? I don't think that's the definition.
Signal started by not allowing anyone to export it. That was forward secrecy. But when they added the import/export and desktop clients, forward secrecy became irrelevant because all an attacked needs to do is to attack the import feature. They don't need to decrypt individual messages anymore. It's just way easier to attack the "seed" Also Signal is terrible because their servers know everything. It's not private at all. The server can pinpoint anyone, geolocate and uniquely identify all of a user's messages. If a protocol doesn't operate with multiple servers chosen by the user, privacy is pretty much gone. Regardless of the quality of underlying protocol.
Forward secrecy means that compromise of a long-term key doesn't reveal past messages. Signal does provide that. It's a different category of attack if someone gets access to your device and sees your chat history, or tricks you to link an untrusted device. Export is possible in any client, at the very least with screenshots or by writing the message history on a piece of paper, but that's not related to forward secrecy. Disappearing messages is the solution when you don't want your message history potentially seen by anyone later. You can use a VPN to hide your geolocation from Signal (which you should do on Nostr as well if you need privacy), but it's true that they can connect your messages to your phone number, see when and probably with whom you're chatting. Not surprised if intelligence agencies are mining that data. With Nostr we're at least over the phone number part, there's no single service that sees all traffic and there are different ways to fix the metadata issue — and do forward & backward secrecy when desired.
i've found this one of the most frustrating features in signal where you cannot really export your message history, and every time you need to re-link your computer (which expires after 30 days of non-use or so) it will start with an empty one i do understand it from a privacy point of view but still fwiw, matrix does provide message history for E2EE rooms even with new devices nostr:nevent1qvzqqqqqqypzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqqsgt0zpg6tslgxjx9raff5nusuqapwj7nf5hvpvaxzh5ux3ddlmq4qjk6ldh
Any thoughts on simplex ?
If Alice has two phones and Bob has one phone, and Alice's two phones have different Keychat IDs, when Alice chats with Bob, if she feels it necessary, she can create a pairwise group with her two Keychat IDs and Bob. This can achieve multi-device synchronization to a certain extent.
this was the same way Simplex advocated for a long time. it works but it is inconvenient