nips/37.md

NIP-37

Methods for dealing with lost or compromised keys

draft optional author:fiatjaf

This NIP defines a series of methods that can be used to make catastrophic key loss events less horrible.

The intention here is not to claim that there is a generalized "key rotation" scheme on Nostr, but still make it so that in most cases people are able to move to new keys and not lost 100% of their followers and reputation when that happens, and also that it is possible to prevent most of the reputational damage that could be caused by having an evil hacker take control of someone else's keys.

The implementation of this NIP could be done directly in social clients or in dedicated clients that users would visit from time to time in order to have an automated scan be done on their contacts and then the dedicated app could suggest migrating from old keys to new keys, or suggest stop following compromised keys, or even perform these migrations automatically.

Method A: Simple Key Deletion

Based on https://github.com/nostr-protocol/nips/pull/377, the idea is that someone, after noticing that their key has been compromised and deciding that it is not possible to use any of the other methods here described, can proceed to publish the following event:

{
  "kind": 10529,
  "pubkey": "<compromised-pubkey>",
  "tags": [
    ["reason", "I typed my key on anigma"]

    // this is unnecessary, but it's an extra requirement to prevent people from making a 10529 event by chance
    ["key-compromised"],
  ],
  "content": "",
  // ...
}

Upon receiving this, relays implementing this NIP SHOULD somehow mark it as invalid and refuse to store any more events from this key. Relays MAY also decide to also delete all events from this key.

Upon receiving this, clients implementing this NIP SHOULD stop following the key.

Clients may give users the option to "delete your public key" with this type of event. Clients SHOULD display a prominent message explaining that the action is not reversible, SHOULD explain that this does not guarantee their posts are deleted forever, and SHOULD require special confirmation such as requiring the user to type a message.

Method B: Social Key Migration

The idea here is that users could pick some friends from their contact list and a threshold number to signal to the rest that the old key has been lost and what is the new key -- e.g. Alice can determine that, from Bob, Carol and Derek, if any 2 of these 3 agree, their recommendation is authoritative.

This is done by publishing an event like this (for example):

{
  "kind": 10520,
  "pubkey": "<user-pubkey-that-will-be-compromised>",
  "tags": [
    ["p", "<friend1-pubkey>"],
    ["p", "<friend2-pubkey>"],
    ["p", "<friend3-pubkey>"],
    ["threshold", "2"]
  ],
  "content": "",
  // ...
}

And then, when the friends want to recommend the switch to a new pubkey, they can publish events like

{
  "kind": 1521,
  "pubkey": "<friend1-pubkey>",
  "tags": [
    ["p", "<compromised-pubkey>"],
    ["e", "<event-of-kind-10520-that-this-refers-to>"],
    ["new-key", "<new-key>"]
  ],
  "content": "",
  // ...
}

Very importantly, when evaluating events of kind 1521 for a given p, clients should ensure that their corresponding event 10520 is at least 3 months older and that an OpenTimestamps proof exists for that.

Method C: Hierarchically Pregenerated Keys

I'll write this later, just a placeholder. It's probably better to see if methods A and B work first.