Subnostr

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 2y ago

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.

Reply to this note

Please Login to reply.

Discussion

hodlbod 2y ago

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

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 2y ago

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.