Currently if a private key `A` is compromised, for example, due to usage in a malicious or compromised client, the owner can generate a new key and send events from `A` saying: "hey, this key was compromised, my new key is `B`".
This is not a **secure** way to rotate keys, because the attacker who has `a` could publish a competing event with a lower `created_at` value pointing to a new key `X` (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.
If we can create a formalized communication for key rotation and a scheme whereby new keys can cryptographically verifiably verified that could both _negate the possibility of identity theft,__exclude the possibility of hijacked key rotation,_ and _allow clients to perform the unfollow/follow_ process automatically.
The way this NIP achieves this is by pre-generating a sequence of extended key pairs 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. Initially only the last key is published and it used for identity. In case of a compromise, the key can be rotated to the _previous_ one, and it is possible to verify that it is a genuine pre-existing key, as the compromised can can be genreated from it.
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.
The first version of this NIP employed a custom derivation scheme, using key hashing and arithmetics, quite similar to BIP32 but different. Employing the established BIP32 standard allows for easier implementation.
## Notation
The following abbreviations are used:
-`SK` secret key (32 bytes)
-`PK` public key
-`ESK` extended secret key, consisting of private key part (32 bytes) and 'chain code' part (32 bytes), as defined in BIP32.
-`EPK` extended public key, consisting of public key part (33 bytes) and 'chain code' part (32 bytes), as defined in BIP32.
-`CC` is the chain code
## Implementation
Generation of keys uses key generation used by Bitcoin BIP-32 'Hierarchically Deterministic' wallets
Verification operates on public keys only, taking use of the BIP-32 property that a public key derived from the corresponding public key of an extended private key is the same as the one corresponding to the derived private key.
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.
Note that in the iterations _non-hardened_ derivation is used, this is in order to allow verification to proceed on the extended public keys (in case of hardened derivation this is not possible),
Another way to define the extended private keys is that they are derived from the seed using the following derivation paths:
```
m/44'/1237'/41'
m/44'/1237'/41'/41
m/44'/1237'/41'/41/41
m/44'/1237'/41'/41/41/41
...
```
Note that the keys are children of each other, not siblings, as is the case e.g. for Bitcoin addresses in an HD wallet.
### Rotation and Verification
If at some point the key gets compromised, the user can publish a special event to rotate to a new identity.
The form of the event is:
```
{
"kind": 13,
"tags": [
["p", "PK_N"],
["hidden-key", "CC_N-1'"]
],
"content": "optional explanation",
"pubkey": "PK_N-1"
"created_at": ...
}
```
From this event alone any client will be able to verify that `PK(f'(EPK(PK_N-1, CC_N-1))) = PK_N`. `f'()` here is very similar to `f()`, but it performs derivation on the public keys.
The verified relationship means that the newly published key must have been generated _before_ the compromised key (as the latter can be generated from it), so it can be assumed to be belonging to the user and not made up by an attacker, so the clients can start using the new key.
### 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.
32 vs 33-byte public keys. In Nostr usually the 32-byte 'X-only' format public key is used. However, in the BIP32 scheme employed here the 33-byte 'compressed' format public key is used. The 32-byte format misses the parity. In practice this means that at verification both parity alternatives have to be checked.
For derivation an 'off-the-shelve' BIP32-capable library implementation can be used directly, or an own implementation. The own implementation is recommended, for the reasons:
- Due to a limitation that stems from serialization format that is not relevant here, implementations typically limit the maximum depth of a derivation path to 256, meaning that at most 253 keys could be generated in this scheme (though in practice that's probably sufficient).
- Constructing an extended public key from its parts is needed at verification, but this is not a typical operation in the BIP32 use cases, and it cannot be easily accessed, only through some workarounds.
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!").
