NIP-101 Fix for stolen secret key problem
2.1 KiB
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.
{
"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.
{
"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
{
"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.