Re: NIP-17. TLDR: if I am not wrong, it does not make Nostr DMs safer 🐶🐾🫡
(I am glad to be proven wrong) nostr:note1wx323qyqsyhc0gwept8e6cj7c25tmgjmle3vre4jvdtk8j6q8ndqk5h0y8
Discussion
People have to be able to read their DMs. If they can do that, by any means, whatever means that is, leaked, would allow an attacker to read all of their DMs too. So I don't think it's possible to secure them more strongly than their nsec is secured.
Therefore we have NIP-46 so you can use a bunker and stop pasting your nsec into web apps.
Only one party can keep a secret. And in fact, there is a solution, device specific key (only that device can decrypt the DMs) and same for the sender. If each client on that specific device generates a random priv/pub keys that are shared for the purposes of DM encryption, then leaked nsec (your nostr identity) does not compromise your DMs. Lost device does, but that is a different ballgame. If people are OK to lose their DMs with device loss and only (migrations can be solved), then we will be in a much better position 🐶🐾🫡
This is not true, implementing a protocol with forward secrecy would stop an attacker from reading past DMs if the nsec is leaked.
Are you saying that the user cannot read their past DMs? If they can, what secret unlocks them? Can't they lose that secret? Why not?
You can do forward secrecy if you don't need to remember the old session keys (e.g. in SSL) but I don't see how to do it if you want to have a folder full of DMs.
Afaik 0xchat does this by creating ephemeral keys that are then stored to be able to decrypt old messages. If any of the keys are leaked, then only a subset of the messages can be decrypted (I'm not sure how many, might be just one). But then this also goes the other way: if you don't have access to those keys anymore, then your DMs are gone. I guess it's just a matter of tradeoffs.
So digging into the double ratchet protocol, I think the device has to have both medium-term and long-term keys available to decrypt everything in the past, and an attacker would likely steal both of those and decrypt everything in the past. The protocol then would generate future keys that the attacker wouldn't have unless they continued to control the user's device. I think it does the best thing possible, but it is still quite possible to steal all the past messages even under Signal's double ratchet protocol. It makes no sense to me that an attacker would only get one key or the other -- maybe they are presuming a cryptanalysis only attack.
I guess to get all past keys you need full device access where leaking an nsec can be done "easily" by putting it into a malicious website or app.
That’s what I proposed, a separate pair of keys for DMs that user does not have direct access to. Rotate them every period and keep old keys on the device. Publish public part as part of your profile and we are good. All the gift wrapping and extra steps in the new encryption are not making anything safer, just making the implementation more convoluted and opening clients to potential bugs that would make security worse and not better. People always forget to include human factor into the design of security products, it is the weakest link. The easier it is to implement (e.g., NIP-04) the safer it is from sloppy bug or a missed step during implementation 🐶🐾🫡
My 2 sats worth of opinion
That makes sense.
What about creating a 'disappearing messages' UX where clients would automatically drop keys after a certain amount of time?
I'm not sure if this has already been discussed.
The risk of leaking your nsec is FAR greater than anything NIP-17 improves upon. NIP-17 / NIP-44 are not a panacea, and the end user message should be that it is a minor technical change, and 99% of their security comes with handling their nsec properly.
Not leaking metadata is an improvement (except the relay taking the message knows something).
The technical encryption algorithm changes probably make no practical difference for a long time yet.
That’s why I think this nip solves the problem that was not there in a first place. Giving people false sense of security, is worse than no security 🐶🐾🫡
I think the NIP is good, but the messaging isn't. It is strictly an improvement (actually a whole slew of improvements), it is just that the net effect of those improvements is practically very small compared to the real other risks people face.
The NIP does open the door to solve it with keybaliases for GiftWraps. You don't need to use your main index to receive and save your messages. :)
We just need a client to implement it.
This NIP does not actually address the issue of all DM leaks caused by nsec leaks. We proposed a solution that involves generating a temporary key through key exchange, ensuring that not all DMs are leaked when nsec is leaked. You can experience this feature on 0xchat.
https://github.com/0xchat-app/0xchat-core/blob/main/doc/secretChat.md
It does address it with key aliases. You don't need to use your nsec to implement NIP 17. You can use any other key. :)
We just need somebody to start that implementation.
I think that should have been in the NIP-17 as a standard and a requirement from the beginning then. Otherwise we are making fragmentation and confusion of who is or is not supporting secure implementation of DMs 🐶🐾🫡
Nah, it would have been too much change. I coded a lousy way of doing it very easily but creates additional security questions. In fact, you can do Double Hatchet (another dev is building it right now) or MLS inside of NIP17. It's just 10x the complexity.
I’ll agree to disagree! At least I hope there will be a separate NIP for properly secured DMs🐶🐾🫡🫂
