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 a user owns two accounts, 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.

________

Requesting for comments. What does everyone think?

#[0] #[1] #[2]

Reply to this note

Please Login to reply.

Discussion

what if B is stolen

#[1] what do you think?

Quick first impression: created_at can be back-dated. It's really only for sorting your history, not security (also a little problematic for its use in #nip26).

Thank you for the comment. Thats why relays should not accept old ones.

#[2] #[3] fyi

this is really cool, although I'm not sure how many people are going to setup a successor key and keep it safe before their secret key gets leaked

I like the idea of setting it up before hand as a solution to the hacker front-running the real users event though.

also it might not be necessary for relays to reject newer 101 events if clients dont look for the latest event. then again its possible the attacker could post a backdated event

Maybe key A and B can be derived from the same master key C which the user stores (so that B is like another derivation path?)

Maybe this could be handled by, the client and switching to B would just be pressing of an emergency button in the

settings

This is just me spitballing, but maybe its only necessary to have an event type that says "this key is compromised" then its up to the client/user to find the new pubkey through their social circle.

Then maybe there could be a new kind of event that would be published by anyone which would say "X's new key is Y". then the client could gather these events from your followers or random strangers? and show the user a few options (hopefully just one) for a new pubkey to follow. almost like a social voting system? idk