Update encryption section; add section for replaceable events

This commit is contained in:
Mike Dilger 2025-03-17 08:39:35 +13:00
parent 2b10ac46aa
commit d38153476f
No known key found for this signature in database
GPG Key ID: 47581A78D4329BA4

52
A0.md
View File

@ -61,8 +61,8 @@ To verifying a keychain connection, clients MUST refer to the keychain events (k
Relays MAY verify this as well to help mitigate DoS attacks.
Encryption
----------
Encryption to Self
------------------
The master key should generate a random 32-byte nonce root and send it to each device via giftwrap using a kind-19001 rumor:
@ -77,19 +77,49 @@ The master key should generate a random 32-byte nonce root and send it to each d
}
```
Since now each device has the same nonce root, encryptions can occur using derived keypairs and be decrypted by every device.
Encryption keypairs are generated as follows:
From this root nonce, and an additional per-encryption nonce called `<kd-nonce>` that is included with the encryption, an encryption keypair is derived as follows:
```
secret_key = sha256(hkdf(<nonce_root>, salt: utf8_encode('nipA0') + <kd-nonce-byte-array>))
secret_key = sha256(hkdf(<nonce_root>, salt: utf8_encode('nipA0') + <kd-nonce>))
```
Where `<kd-nonce-byte-array>` is specified by the party doing the encryption, and included within the encryption. This requires
NIP-44 v3 (not yet finalized).
Since each device has the same nonce root (via kind 19001 shown above), encryptions can occur using derived keypairs and be decrypted by any device.
Any device can decrypt because they all share the secret `<nonce_root>` and the `<kd-nonce-byte-array>` is available in plaintext
with the encrypted content.
This requires NIP-44 v3 (not yet finalized).
Receiving Encrypted Content
---------------------------
One particular keypair should be generated and published for receipt of encrypted content from others:
```
inbox-secret-key = sha256(hkdf(<nonce_root>, salt: utf8_encode('nipA0-inbox')))
```
The cooresponding public key should be published in an event so that anybody can send encrypted content to this party:
```
{
"pubkey": "<master-key-pub>",
"kind": 19002,
"content": "",
"tags": [
["encryption-inbox", "<inbox-public-key>"],
]
}
```
Giftwraps using this keypair to send content to the user should tag the master key, not any of the device keys.
Replaceable and Addressable events
----------------------------------
Addressable events are defined such that each user only has one of them per kind (and 'd' tag). But if users have multiple keypairs, they could end up having one per keypair. This may violate the assumptions of a number of existing NIPs.
On a per-kind basis, any event by any key under the same master key overrides any other event by any (other) key under the same master key. That is, all keys should be treated as the same person and only the latest event from any of those keys should be honored.
Deletion
@ -97,6 +127,8 @@ Deletion
[NIP-09](09.md) deletion requests made by one key for an event authored by another key should be honored if they share the same master key.
Phased Rollout
--------------