2.3 KiB
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 is encrypted, but everyone can see who is chatting with whom. This is far from ideal from a privacy perspective.
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).
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 recieve (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.
Deriving the direct message parent key
BIP32 is used to derive the paths. A client can generate multiple direct message parent keys
, one for each peer that it is communicating with. Nostr coin_type'
is 1237'
(see NIP-06). In this NIP we define the purpose 25709'
(dm
-> 0x646d
-> 25709
) for deriving Direct Messages
related keys.
When client Alice
wants to build its dm parent key
for Bob
it has to:
- get the public key of
Bob
(in hex). Eg:3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d
. - split the public key hex string in 8 chunks:
3bf0c63f
,cb934634
,07af97a5
,e5ee64fa
,883d107e
,f9e55847
,2c4eb9aa
,aefa459d
- derive the
dm parent key
:m/25709'/1237'/p1'/p2'/.../p8'
Note the reason for using the peer's public key (
Bob
) in thedm parent key
derivation is to always arive at the same value even if prio state is lost.Note the reason for splitting is that each level of the path can have a max value of 232-1.