Gzuuus's avatar
Gzuuus gzuuus@nostree.me 1 month ago
Hey, that's interesting. I've never heard about this one-shot ECDH. I was digging a bit and thinking about how apps can respect user privacy more. AFAIK, the one-shot approach generates a new derived key each time, which is great. However, for app-specific data where a long-term relationship is expected and it should be possible to recover data without knowing the previous key used, for example, while jumping between different platforms in a multi platform app, this approach might not be ideal. So, maybe something interesting is that users and apps can generate a stable 'channel' to use for this kind of thing. One initial idea is to use DH where the app exposes a public key, for example, the same one used to sign NIP-89 events. Then, the user, each time the app needs to persist settings or whatever, derives the key using DH and publishes the encrypted data using that key. In this case, the DH secret can be taken as the secret key, and the public key can be derived from it. The only entities capable of knowing where the key comes from are the user and the app. However, this might work but present some limitations. Instead of a pure DH approach, it could be a deterministic KDF. This way, the app itself can have a stable identifier and use it as a salt, so the user can generate a key pair deterministically without requiring the app to maintain a stable public key. I don't know, just rambling here, but I think it's a topic worth exploring.
↑ Parent

Replies (1)

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ's avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ me@mleku.dev 1 month ago
it's what is used with giftwraps, a one time key used for creating the encryption with a fresh private key, with your pubkey as the other half, and then labeled with the one-shot pubkey so it can be used to make encryption that you can decrypt because you have the pubkey (it's addressed to you). i'm pretty sure it's how the encryption works for DMs and application specific data and private mute lists and so forth. i used it with indranet for the packet encryption, the key was known for one side, who will receive it, and used a key generated only for that packet, as the message isn't intended to be read by the sender, only by the receiver. also, with giftwraps, idk why nobody ever really seems to explain it but in order for this kind of "one party only is mentioned" scheme it means when you giftwrap a DM, you have to send a copy to yourself, which is a pretty distinctive timing pattern. nip-04 doesn't do this and IMO it's pointless as far as adding any security goes (since probably both copies are going to have the same timestamp. anyhow, yes, you can encrypt data using ECDH using an ephemeral message key, which you don't need to remember because the message contains the public key, and is encrypted to your private key, ECDH isn't just for shared secret negotiation, it can be used with a key pair to encrypt as well.
↑