We're currently having a conversation about the api for signers supporting NIP 44. Currently it looks like we're going to provide a `getConversationKey` method, which clients can use to generate and store keys used to decrypt DM history.

The justification is performance — it's expensive to re-calculate the keys on every call to encrypt or decrypt. It's also expensive to make lots of network calls as in the case of NIP 46. Both of these are easily solved though — the signer can cache keys just as easily as the client, and the network latency issue could be solved by adding `encrypt_bulk` type calls.

The downside of having a getConversationKey method is that clients can generate and store keys that are valid forever. Evil clients could do this without the user knowing, and send the keys to a server somewhere. From that point on, that person would be able to snoop on and forge messages between two participants. For me, this complete defeats the purpose of signer extensions.

Am I wrong?

https://github.com/nostr-protocol/nips/pull/940

Reply to this note

Please Login to reply.

Discussion

It's deterministic. You are not wrong.

It's not the right way to do it, there needs to be entropy between the key and the usage.

It brings up a good question about trust because you really can't trust either the client or a network connected (especially not in-browser) keychain.

Is there some specific reason why you aren't going with an embedded return encryption key? This at least gives you a buffer of protecting future messages via entropy and doesn't let you gain more than the past out of a key breach.

Going further than this requires the use of rendezvous points and such similar things. Preparing entropy ahead of time inherently requires you conceal the location where it is stored, or it's a key to future messages.

Just complexity I assume, you're also not guaranteed to get a reply

yeah, I am very inclined to say that there is no easy solution to the problem without an onion routing rendezvous scheme in the picture, and then you have a spam cost problem and a payment association problem.

Lightning can solve a lot of this. I got super excited when I learned that LN uses onions. Client side onions, not crummy stateful bidirectional ones.

Sharing a conversation key does not allow anyone to forge messages. Just decrypt.

Also, GiftWraps come from a random key. So, there will be a new conversation key for every wrap. The shared key only works in the internal Seals.

But NIP 44 isn't limited to gift wraps

I suppose so, since you need to sign the note as well as encrypt