nip4e: decoupling encryption from identity

[fiatjaf]

this is inspired by MLS, but much simpler, and definitely not trying to be a group communication system, but only a way for users to encrypt things to themselves.

https://github.com/nostr-protocol/nips/blob/per-device-keys/4e.md

[vitorpamplona]

+1 for decoupling signing and encryption. The security requirements for signing events are different—not necessarily better or worse, just different—from those for encrypting and decrypting content. In my opinion, Nostr Signers shouldn't even bother with or control access to encryption/decryption.

I’m not sure if it makes sense to create "device keys" for lists and other kinds that are used between devices (private follow lists for instance). On top of that, the concept of attaching keys to "devices" is fundamentally flawed on Nostr, as multiple clients can run on the same device. In this PR, would they share the same key or would each app create their own?

Many clients now support multiple accounts, which complicates the user’s mental model. It becomes challenging to explain which clients can access specific sub keys for each account. Maintaining a clear understanding of which apps have authorization to perform specific actions is difficult even before introducing rotating keys.

If we are to operate with multiple encryption keys, we MUST include the key ID in each encrypted payload. This allows the receiving client to identify the correct key or prompt the user to provide it.

The challenge of determining which keys can encrypt/decrypt a given payload (or versions in a replaceable) was a key issue in our decision to place the keys directly in the event in 1228. That design separates signing and encryption without requiring the maintenance or resynchronization of key lists, neither on Nostr nor externally. In the same way, users don't even know the event is using a separate key to encrypt and don't need to keep track on which apps have which keys.

I don’t know which approach is better. But I am confident that signing and encryption should use separate keys—at the least one per kind / app usecase type. In more extreme cases, such as spreadsheets, a new key could be generated for each group collaborating on an event.

[fiatjaf]

Sorry, I wrote "device key" just because I thought that would be clearer, but actually a "device" here means a "client".

The challenge of determining which keys can encrypt/decrypt a given payload (or versions in a replaceable) was a key issue in our decision to place the keys directly in the event in 1228. That design separates signing and encryption without requiring the maintenance or resynchronization of key lists, neither on Nostr nor externally. In the same way, users don't even know the event is using a separate key to encrypt and don't need to keep track on which apps have which keys.

I don't get this. Granted I didn't read that NIP with my full attention, but how can you decrypt a thing without having a key? Or how else could we apply that technique to solve the current problem?

I don’t know which approach is better. But I am confident that signing and encryption should use separate keys—at the least one per kind / app usecase type. In more extreme cases, such as spreadsheets, a new key could be generated for each group collaborating on an event.

This is all fine but the problem remains that somehow different clients ("devices") have to learn what is the relevant encryption key -- how to do that (without relying on user identity keys for encryption) is the real question. This NIP is a proposal to address that.

[mikedilger]

I'm not a cryptographer but this looks good to me.