NIP-704 ====== Key derivation for Encrypted Direct Messages ----------------------------------- `draft` `optional` `author:motorina0` This NIP defines a way for two clients to derive `one-use-only` keys for sending and recieving `kind:4` events. ## Motivation The content of `Direct Messages` [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md) is encrypted, but everyone can see who is chatting with whom. Privacy wise this is far from ideal. This NIP describes a way to obfuscate DM communications from the "general public", it does not deal with the relay tracking of clients (for that see [NIP XXX](xxx)). ## Suggestion For the maximum of privacy the two participants of a `Direct Message` exchange SHOULD use a different public key for **each** `kind:4` event. This means that each participant has to: - build a `direct message parent key` from which it will derive keys to send and keys to receive (listen for) `kind:4` events - share this `direct message parent key` with its DM peer Each client has a `master` key (denoted with `m`). This key can be the profile `nsec...`, but it is not mandatory. ## Derive the `direct message parent key` A client must generate multiple `direct message parent keys`, one for each peer that it is communicating with. The [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) structure to be used is: ``` m / purpose' / conin_type' / part1' / part2' / ... / part8' ``` - this NIP defines the `purpose` `25709'` (`dm` -> `0x646d` -> `25709`) for deriving `Direct Messages` related keys - nostr `coin_type'` is `1237'` (see [NIP-06](https://github.com/nostr-protocol/nips/blob/master/06.md)) - `part1' / part2' / ... / part8'` is the public key hex string (of the peer) split in 8 chunks: - the reason for using the peer's (`Bob`) public key is to always arive at the same value even if prio state is lost - the reason for splitting the public key is that each level of the path can have a max value of 232-1
Example If Alice wants to build he dm parent key for Bob then she has to:
We notate the above derived `direct message public key` with `dmpk`. Then we can define paths of the form `dmpk//index`. | Action Name | Value | Path | Derive keys for | |-----------------------|--------|---------------------|-----------------------------------| | **send** | `0` | `dmpk/0/` | sending `direct messages` | | **receive** | `1` | `dmpk/1/` | receiving `direct messages` | | `draft`: republish | `2` | `dmpk/2/` | sending `republish events` | | `draft`: market-order | `4500` | `dmpk/4500/` | sending NIP45 `market orders` | The client (creator of the `dmpk`) must: - use a new send key (`dmpk/0/`) for each event it signs. It starts from `0` and increments after an event is signed. - create filters for the public keys it expects to receive messages to (`dmpk/1/`). It is recommended to listen for the next `10` keys. ## Exchange the `direct message parent key` If `Alice` wants to signal `Bob` that she is ready to use this NIP (for more privacy) she must: - build a JSON data of the form: ```json { "key": , "send_index": , "receive_index": , } ``` > **Note** `send_index` and `receive_index` are optional, but they help the client a lot in knowing what the state is. Alternatively (when an account is retored) the client would have to scan the public keys until unused ones are found. - publish a `Parameterized Replaceable Event` ([NIP-33](https://github.com/nostr-protocol/nips/blob/master/33.md)) having: ```json { ... "kind": 35709, "content": , "tags:" [ "d": ] } ``` > **Note** the reason for using `sha256(shared_secret)` for the `d` tag is so that outside observers do not even know that `Alice` and `Bob` have started to communicate. Any other value for the `d` tag would reveal that the message is intended for `Bob.` After both `Alice` and `Bob` have published the `kind: 35709` event, they can start to publish and listen to events using the `one-use-keys`.