mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-09-20 06:45:49 -04:00
68 lines
2.1 KiB
Markdown
68 lines
2.1 KiB
Markdown
|
NIP-101
|
||
|
|
=======
|
||
|
|
|
||
|
|
Fix for stolen secret key problem
|
||
|
|
----------------------------------
|
||
|
|
|
||
|
|
This NIP defines a solution that may be implemented by clients and relays for stolen keys problem. Lets say owner O owns two keys, uses A actively but wants to switch to B in case A is stolen.
|
||
|
|
|
||
|
|
|
||
|
|
- Secret key A sets a 'successor' pub B by storing an event with a new kind in a relay. Kind may be 101.
|
||
|
|
|
||
|
|
```json
|
||
|
|
{
|
||
|
|
"id": "...",
|
||
|
|
"pubkey": ".......AAAA........",
|
||
|
|
"created_at": 1669695536,
|
||
|
|
"kind": 101,
|
||
|
|
"tags": [
|
||
|
|
["successor", "...........BBBBBBBBB......."]
|
||
|
|
],
|
||
|
|
"content": "",
|
||
|
|
"sig": "...signature.by.AAAA........"
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
|
||
|
|
- In case secret key A is stolen, the owner of A uses secret B to start simply creating notes of any kind, or create one event with a new kind that says "B is now succeeding A". First option is easier, second is more elegant.
|
||
|
|
|
||
|
|
|
||
|
|
```json
|
||
|
|
{
|
||
|
|
"id": "...",
|
||
|
|
"pubkey": ".......BBBB........",
|
||
|
|
"created_at": 1769695536,
|
||
|
|
"kind": 1,
|
||
|
|
"tags": [],
|
||
|
|
"content": "Hey I am the owner of AAA and my secret key was stolen. This is my new account",
|
||
|
|
"sig": "...signature.by.BBBB........"
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
OR
|
||
|
|
|
||
|
|
```json
|
||
|
|
{
|
||
|
|
"id": "...",
|
||
|
|
"pubkey": ".......BBBB........",
|
||
|
|
"created_at": 1769695536,
|
||
|
|
"kind": 102,
|
||
|
|
"tags": ["p",".........AAAAAAAAAA..............."],
|
||
|
|
"content": "Hey I am the owner of AAA and my secret key was stolen. This is my new account!",
|
||
|
|
"sig": "...signature.by.BBBB........"
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
|
||
|
|
- Clients see B is active and show a warning that A is now stolen and B is the new one. Clients update the follows.
|
||
|
|
|
||
|
|
- Relays MUST block 101 events that are older than X days for this to work properly. X may be 7. Clients MUST fetch ONLY the first 101 from a relay that supports this.
|
||
|
|
|
||
|
|
|
||
|
|
What will happen if only a few relays implement this NIP?
|
||
|
|
---------------------------------------------------------
|
||
|
|
|
||
|
|
The attacker will use secret A to create a 101 with an older created_at. Clients will think the successor of A is actually was C..
|
||
|
|
|
||
|
|
The clients will see both B and C coming from relays. At this moment the client may choose to 'honor' the relays that implemented this NIP and choose B as the successor instead of C.
|