I am not going to lie.. trying to separate encryption keys from identity keys on Nostr is frying my brains.
Discussion
Completely separate or encryption keys derived from identity?
Both cases kinda suck
Hmm.. Myeah, but there is a different kind of key management involved. Deriving keys also means they're easier to vary and requires less need for persistence.
The issue is really on how to assemble the encrypted payload to let the receiver know which keys to use to decrypt without breaking the privacy or increasing the anonymity set.
Hmm.. that still leaves a lot of options open. E.g. is there prior info to work with? Would you be able to lookup "profile info" that gives a hint or provides some info, then you need less of an announcement message. I think you are aware that the basic encrypted DMs derive a single fixed key per pair of users.
I know it's not exactly what you asked for, but I played around with a small experiment which I hadn't had time to follow up on. Maybe it can give you some inspiration. (It didn't receive much attention at the time.)
I had explained it here:
https://lists.cypherpunks.ca/pipermail/otr-dev/2024-October/002574.html
Have you considered HD wallets to derive nostr keys? It's BIP-85 I think.
MLS is the way, man, it's frustrating to build and super easy to screw something up midway through and force you to rewrite stuff but once it's built it's just so good, full forward secrecy, encryption and identity are separate
No, the main issue is for the payloads you encrypt to yourself, when you have many keys.
For derived keys, can the encryption include the derivation path in plaintext? I don't think that's an anonymity breaker if those paths are common well known things.
That's kinda what I was trying to go for with the nonce, but the nonce is unique. It's super easy to find the destination key. The path might be better, but we still need to connect the path to a pubkey and the link makes the recipient visible 🤔
My usecase is probably a little different from yours because it's for community based group encryption, but what I do is that have nip-44 encrypted payloads to an address to which eveeu member has the private key, so there's only one address to monitor, but then I have MLS as an additional layer on top of it basically, so all members of the community check for messages to one key, decrypt them (if a few things pass), and then do the second description using the rachet tree, so then I don't have the problem you're describing... But again it sounds like a different use case perhaps?
would ephemeral keys help?
Hierarchical determanistic keys solves this.
The issue is really on how to assemble the encrypted payload to let the receiver know which keys to use to decrypt without breaking the privacy or increasing the anonymity set.
Encryption is an area I'd always want an expert's help with. It's a complex topic.
isn't possible to have a public key (master/identity) and we would have a know function that we could add a salt/nouce let's say 1 as eg. so that would generate new key pair and it's my sub key. Now when posting, I will would post also the nouce, and a client seeing the nouce would run the reverse of the function to get the root public key, and that is your identity and all the notes from 1, 2,N belong to the same root identity.
MLS fixes this.