nips/41.md

NIP-41

Stateless Unambiguous Key Invalidation

draft optional author:fiatjaf author:RubenSomsen

The idea of this NIP is that compromised keys can be invalidated in a way that prevents identity theft.

Cryptographers must forgive me for trying to write this in a way that humans like myself can understand.

Notation

Lowercase letters denote private keys, uppercase letters denote public keys. || means concatenate. sk_ means "secret key", pk_ means "public key". G is the generator point of the secp256k1 curve.

Motivation and explanation

Currently if a private key A is compromised, for example, because they chose to input it in a malicious or infected client, they can generate a new key and send events from A saying: "hey, this key was compromised, my new key is B".

Problems with the approach above

This is not a safe way to rotate keys, because the attacker who has a could publish an recent with a lower created_at value pointing people to a new key X, for example, instead of B. And for any reader only seeing these two events it becomes at least very hard to decide which one, X or B, is the actual new key of A's owner.

Even if the attacker doesn't do anything, it is still not a scalable way (for the lack of a better word) to do this, since it will require manual action from all readers to migrate to stop following the previous key and start following the new. The amount of manual action required grows as the number of followers of A grows. And they may not even see the note from A because they have a giant feed with hundreds of notes, or they may forget to perform the manual unfollow-refollow process and so on.

A better solution

If we can create a cryptographically verifiable way to point users to a new key that could both negate the possibility of identity theft and allow clients to perform the unfollow/follow process automatically.

The way this NIP does it is by generating a sequence of keys such that each one of these commits (i.e., that hides a value in a way that it can't be changed but can be revealed later) to the following. The scheme is as follows:

A = A' + hash(A'||B)
B = B' + hash(B'||C)
C = C' + hash(C'||D)
D = ...

The idea here is that a client will pregenerate 256 keys in sequence (arbitrary number) and use the last one, which in this case will be A. If A gets compromised they can publish a special event

{
  "kind": 13,
  "tags": [
    ["p", "A"],
    ["hidden-key", "A'"]
  ],
  "content": "optional explanation",
  "pubkey": "B"
  "created_at": ...
}

And from this event alone any client will be able to verify that hash(A'||B) + A' = A, or, in other words, that hash(.tags["hidden-key"] || .pubkey) + .tags["hidden-key"] = .tags["p"], and that the next key in the sequence can't be anything other than B, which has a private key b that can be assumed to have not been compromised. So it is easy to just stop following A and start following B.

Justifying the NIP title

The invalidation is unambiguous, i.e., once an invalidation event is fired from the new key, the previous is invalidated. Even if new events come from the old key, they must be considered as coming from an unknown untrusted person, as the key is now in the hands of an attacker. Only the owner of the root key is able to figure out the next key.

The invalidation is stateless, i.e., the clients who see an invalidation event don't have to know anything else, by reading that and that only they can conclude that the previous key was irrevocably compromised and revoked, and can react properly, by, for example, unfollowing the previous key and following the new one.

Implementation

If, at the time of first generating their Nostr public keys, one decides to use this NIP, they will have a chain of 256 keys that can be used in sequence, which means a user can lose up to 255 keys, which should be much more than enough for any user that is not actively trying to lose their keys.

Key generation

This is intended to be run on safe and trusted hardware.

A (BIP-32)[https://bips.xyz/32) seed is generated by any means (probably using BIP-39 words is the best idea), then the sequence of 256 hidden keys is generated with the following paths:

sk0' = m/44'/1237'/41'/0'
sk1' = m/44'/1237'/41'/1'
...
sk2' = m/44'/1237'/41'/255'

• The "root" key, i.e. the last key in the sequence, is equal to the "hidden" key for the first position: sk0 = sk0'.
• Its immediate child, i.e. the second-to-last key in the sequence is calculated as follows:
  • calculate the public key for sk0: pk0 = sk0 * G;
  • take the bytes for the X coordinates of that: pk0x = getX(pk0);
  • calculate the public key for sk1': pk1' = sk1' * G;
  • take the bytes for the X coordinates of that: pk1x' = getX(pk1');
  • concatenate the bytes pk0x and pk1x' and calculate the sha256 hash of that: hash = sha256(pk0x || pk1x');
  • add that, as a number, to the hidden private key sk1' (which is a number): sk1 = sk1' + hash;
  • the result is the second-to-last secret key sk1.
• Now proceed to calculate sk2 using the same process above, but moving everything one number up.
• And so on and so forth until you get to sk255.
• sk255 is the key to be used first. If that gets compromised one must move to sk254 and so on.

Presumably this key generation process happens in somewhat trusted hardware by a trusted dedicated program, and from it users may copy the initial key and paste it in the normal (still trusted) client they use for day-to-day operations.

Reader implementation

Clients can query relays for the invalidation of key A whenever they want by using the filter {"#p": ["A"], "kinds": [13]}.

The verification process for the validity of an invalidation (kind: 13) event was given in the explanation above.

Additional comments

This is not a general "rotation" scheme for keys

This scheme is intended to make it less catastrophic when a key is compromised because it was input into a computer, phone or Nostr client softwre that turns out later to have been compromised. It isn't intended to allow people to rotate their keys every month as a routine practice, nor is it supposed to let users be reckless and give their private keys to any malware or trusted third parties. A compromised key is still a bad event, just not one of awful and unrepairable consequences if this NIP is followed and relied upon.

Fallback mechanism possibilities

What happens if Bob is following Carol and Carol publishes an invalidation event for her key, but Bob's client doesn't see it for any reason or doesn't support the automatic refollow mechanism for the new key? Well, in this case we are at least not worse than the current state of things, but Bob has other possibilities:

• there can be centralized third-party services keeping track of these invalidations and sending notifications through any means and Bob may be subscribed to one of these;
• or there could be a central directory Bob can use to check from time to time if any of their followed keys has been invalidated and perform the fixes manually in his client;
• anyone with a supporting client can be 100% sure the key was really invalidated, so they can alert others about that fact without any fear of spreading wrong information;
• and last but not least Bob may want to verify things manually if he sees suspicious activity from Carol's key. At least he doesn't have to ask her (and then get a response from the attacker stating that "no, it's just me, Carol!").