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.

Reply to this note

Please Login to reply.

Discussion

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 🐶🐾🫡

I would argue for something similar but different. I don't want DMs tied to a specific device. But I'm too sleepy right now to expound upon that.

No way to like, have a virtual device? Idk

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.