nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 16:35:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

NIP-101 Fix for stolen secret key problem

Browse Source 
NIP-101 Fix for stolen secret key problem
This commit is contained in:
etemiz 2023-03-21 21:38:13 -05:00 committed by GitHub
parent 2394e5cc63
commit d3e70c3dce
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 67 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
101.md Normal file
View File

@ -0,0 +1,67 @@
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.