You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: D8.md
+23-23Lines changed: 23 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,41 +8,41 @@ Nostr Key Rotation
8
8
9
9
By default nostr public keys solely represent a user's identity, which makes it impossible to recover from key loss or compromise.
10
10
11
-
This NIP defines a simple mechanism for key rotation by means a ratchet mechanism involving the use of a single-purpose key which can be stored more securely than a user's main key.
11
+
This NIP defines a simple mechanism for key rotation by means a migration mechanism involving the use of a single-purpose key which can be stored more securely than a user's main key.
12
12
13
13
Some terms:
14
14
15
15
- An `identity` key is a user's initial nostr public key and serves as the user's persistent identifier.
16
16
- An `authorized` key is a nostr public key that can sign on behalf of a user's `identity` key. A user's `identity` key is itself an `authorized` key until it is invalidated.
17
-
- A `ratchet` key is a nostr public key authorized in advance as the only way to generate or invalidate `authorized` keys.
17
+
- A `migration` key is a nostr public key authorized in advance as the only way to generate or invalidate `authorized` keys.
18
18
19
19
A tree of these keys is created using three new event kinds, defined below. The current state of this tree MUST be validated as described in the [validation](#Validation) section below.
20
20
21
-
## Creating a Ratchet Key
21
+
## Creating a Migration Key
22
22
23
23
Any `authorized` key can be used to sign a `kind 260` event with the following tags:
24
24
25
-
- A `p` tag containing the new `ratchet` pubkey and a relay hint
26
-
- A `proof` tag containing a schnorr signature of the `authorized` pubkey using the new `ratchet` key
25
+
- A `p` tag containing the new `migration` pubkey and a relay hint
26
+
- A `proof` tag containing a schnorr signature of the `authorized` pubkey using the new `migration` key
27
27
28
-
Only the first `ratchet` key published by a given `authorized` key is valid. If multiple conflicting `kind 260` events exist, the first one published MUST be used. Ratchet keys cannot be invalidated except by invalidating the corresponding `authorized` key.
28
+
Only the first `migration` key published by a given `authorized` key is valid. If multiple conflicting `kind 260` events exist, the first one published MUST be used. Migration keys cannot be invalidated except by invalidating the corresponding `authorized` key.
29
29
30
-
Ratchet keys MUST NOT be used for anything other than creating and invalidating `authorized` keys
30
+
Migration keys MUST NOT be used for anything other than signing a single `kind 261` event.
31
31
32
32
## Migrating to a new Authorized Key
33
33
34
34
A `kind 261` migration event MUST have the following tags:
35
35
36
36
- A `p` tag containing a new `authorized` pubkey and a relay hint
37
-
- A `proof` tag containing a schnorr signature of the `ratchet` pubkey using the new `authorized` key
37
+
- A `proof` tag containing a schnorr signature of the `migration` pubkey using the new `authorized` key
38
38
39
39
It MAY also include:
40
40
41
41
- An `as_of` tag containing a seconds-resolution timestamp for retroactive key invalidation
42
42
43
-
Only a `ratchet` key can sign a `kind 261` migration event. Only the first `kind 261` event published by a given `ratchet` key is valid. If multiple conflicting events exist, the first one published MUST be used.
43
+
Only a `migration` key can sign a `kind 261` migration event. Only the first `kind 261` event published by a given `migration` key is valid. If multiple conflicting events exist, the first one published MUST be used.
44
44
45
-
Migrating away from an `authorized` key also invalidates the `ratchet` key used. All events created by an `authorized` key or its corresponding `ratchet` key after migration MUST be ignored.
45
+
Migrating away from an `authorized` key also invalidates the `migration` key used. All events created by an `authorized` key or its corresponding `migration` key after migration MUST be ignored.
46
46
47
47
This event MAY include a message in the `content` field. Clients SHOULD fetch this event and notify its users that a migration has taken place.
48
48
@@ -57,8 +57,8 @@ Because event timestamps can be forged, a sequencer is required in order to esta
57
57
Key state transitions MUST be validated according to the following process:
58
58
59
59
1. Select a `target` pubkey to validate.
60
-
2. Fetch `kind 260` events signed by the `target` key in order to identify the `target`'s `ratchet` key.
61
-
3. Fetch `kind 261` events signed by the `target`'s `ratchet` key. If any exist, events created by the `target` after its `as_of` (or `created_at`) field are invalid and should be ignored.
60
+
2. Fetch `kind 260` events signed by the `target` key in order to identify the `target`'s `migration` key.
61
+
3. Fetch `kind 261` events signed by the `target`'s `migration` key. If any exist, events created by the `target` after its `as_of` (or `created_at`) field are invalid and should be ignored.
62
62
4. Fetch all `kind 260` events `p`-tagging the `target`. If no valid ones exist, the `target` key is an `identity` key and is `authorized` on its own behalf.
63
63
5. Repeat steps 1-4 for the author of the `kind 260` event which `p`-tags the `target` key until an `identity` key is reached, or a link fails to be established.
64
64
@@ -68,15 +68,15 @@ When checking the validity of an event published by an `authorized` key, it's im
68
68
69
69
## Threat Model
70
70
71
-
This NIP relies on the assumption that `ratchet` keys can be stored more securely than `authorized` keys.
71
+
This NIP relies on the assumption that `migration` keys can be stored more securely than `authorized` keys.
72
72
73
73
Current nostr users have already exposed their keys in many places. This NIP allows those users to upgrade their account's security today without immediately migrating to the new key.
74
74
75
-
A general-purpose `authorized` key has to be stored on an internet-connected device in order to support frequent usage, while a single-purpose `ratchet` key can be stored offline and still remain useful.
75
+
A general-purpose `authorized` key has to be stored on an internet-connected device in order to support frequent usage, while a single-purpose `migration` key can be stored offline and still remain useful.
76
76
77
-
Even if an attacker gains control of a user's `identity` key, they can't do any permanent damage if the user has already generated and secured a `ratchet` key.
77
+
Even if an attacker gains control of a user's `identity` key, they can't do any permanent damage if the user has already generated and secured a `migration` key.
78
78
79
-
However, if the user has **not** generated a `ratchet` key for their account, or their `ratchet` key has been compromised, an attacker can *lock the owner out of their account*, escalating key compromise to permanent account loss. They is the key trade-off of this NIP and exists for all users, regardless of whether they adopt it. For this reason, it is recommended that users generate a `ratchet` key early and store it securely. Additionally, if a `ratchet` key is generated and then lost, the user loses the ability to rotate their key.
79
+
However, if the user has **not** generated a `migration` key for their account, or their `migration` key has been compromised, an attacker can *lock the owner out of their account*, escalating key compromise to permanent account loss. They is the key trade-off of this NIP and exists for all users, regardless of whether they adopt it. For this reason, it is recommended that users generate a `migration` key early and store it securely. Additionally, if a `migration` key is generated and then lost, the user loses the ability to rotate their key.
80
80
81
81
## Usage Recommendations
82
82
@@ -109,7 +109,7 @@ Clients SHOULD implement key validation. Relays MAY implement key validation and
109
109
In this example, Alice creates three different keys:
110
110
111
111
- Key `A` is her `identity` key, since it's the first key she creates and where she begins her attestation chain. It is also by default an `authorized` key.
112
-
- Key `A'` is her `ratchet` key, which is used in turn to create a new `authorized` key `B`.
112
+
- Key `A'` is her `migration` key, which is used in turn to create a new `authorized` key `B`.
113
113
- Key `A` is later compromised and subsequently invalidated by `A'`
114
114
115
115
Throughout, Bob and Carol interact with Alice's account. Bob uses a client that lacks support for key rotation, while Carol uses a client that has it.
@@ -134,7 +134,7 @@ At this point, nothing special needs to happen. Alice continues signing events w
134
134
135
135
The attacker also attempts to publish a new `kind 260` event, `A.2` in an attempt to hijack Alice's key state and point people to key `X`. However, both Alice and Carol properly reject it based on OTS attestations, while Bob ignores it entirely.
136
136
137
-
At this point, Alice needs to switch to a new key, so she publishes a `kind 261` event signed by her `ratchet` key `A'` designating a new key `B` to switch to:
137
+
At this point, Alice needs to switch to a new key, so she publishes a `kind 261` event signed by her `migration` key `A'` designating a new key `B` to switch to:
138
138
139
139
```json
140
140
{
@@ -165,19 +165,19 @@ Carol is also following Alice, but her client automatically picks up events `A.1
165
165
166
166
This returns both of Alice's `kind 1` events: `A.3` (via the `authors` filter), and `B.1` (because of the `#=` filter), while successfully ignoring events created by the attacker after key invalidation took place.
167
167
168
-
Finally, Alice publishes event `B.2`, which is a `kind 260` event designating key `B'` as her new `ratchet` key.
168
+
Finally, Alice publishes event `B.2`, which is a `kind 260` event designating key `B'` as her new `migration` key.
169
169
170
170
At the end of the day, this is the state of Alice's keys:
171
171
172
172
-`A` remains her `identity` key, but is no longer `authorized` as of `A'.1.as_of`.
173
-
-`A'` (her first `ratchet` key) is invalid as of `A'.1.as_of`.
173
+
-`A'` (her first `migration` key) is invalid as of `A'.1.as_of`.
174
174
-`B` is `authorized` to publish events on behalf of her `identity` key `A`.
175
-
-`B'` is a valid `ratchet` key, able to invalidate `B` and create new `authorized` keys.
176
-
-`X` is not and never was a valid `ratchet` key, because `A'` was created first. Any attempts by the attacker to create new `authorized` keys will be ignored.
175
+
-`B'` is a valid `migration` key, able to invalidate `B` and create new `authorized` keys.
176
+
-`X` is not and never was a valid `migration` key, because `A'` was created first. Any attempts by the attacker to create new `authorized` keys will be ignored.
177
177
178
178
## Appendix: Ownership Proofs
179
179
180
-
Kinds `260` and `261` require that users prove they own a given pubkey before designating it either as a `ratchet` key or an `authorized` key.
180
+
Kinds `260` and `261` require that users prove they own a given pubkey before designating it either as a `migration` key or an `authorized` key.
181
181
182
182
This proof is deliberately designed **not to use common event signing APIs** in order to ensure that the user has direct access to their private key. This helps prevent a malicious signer or client from signing key rotation events via bunker URL or browser extension.
0 commit comments