diff --git a/41.md b/41.md index 28f8ea3..748f9dd 100644 --- a/41.md +++ b/41.md @@ -8,12 +8,10 @@ Stateless Unambiguous Key Invalidation The idea of this NIP is that compromised keys can be invalidated to prevent identity theft, in a secure way. -Cryptographers must forgive me for trying to write this in a way that humans like myself can understand. - ## Motivation and explanation -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`". +Currently if a private key `A` is compromised, e.g. 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`". ### Problems with the approach above @@ -25,9 +23,9 @@ Even if the attacker doesn't do anything, it is still not a **scalable** way (fo ### A better solution -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. +If we can create a formalized communication for key rotation, and a scheme whereby new keys can be cryptographically 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 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 key can be genreated from it. ### Justifying the NIP title @@ -48,14 +46,14 @@ 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 (BIP-32)[https://bips.xyz/32). -- `EPK` extended public key, consisting of public key part (33 bytes) and 'chain code' part (32 bytes), as defined in (BIP-32)[https://bips.xyz/32). -- `CC` is the chain code +- `ESK` extended secret key, consisting of private key part (32 bytes) and 'chain code' part (32 bytes), as defined in (BIP-32)[https://bips.xyz/32]. +- `EPK` extended public key, consisting of public key part (33 bytes) and 'chain code' part (32 bytes), as defined in (BIP-32)[https://bips.xyz/32]. +- `CC` is the chain code (hidden part of the extended key; term from BIP-32) ## Implementation -Generation of keys uses key generation used by Bitcoin (BIP-32 'Hierarchically Deterministic')[https://bips.xyz/32) wallets +Generation of keys uses key derivation used by Bitcoin (BIP-32 'Hierarchically Deterministic')[https://bips.xyz/32] 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. @@ -64,7 +62,7 @@ Verification operates on public keys only, taking use of the BIP-32 property tha 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). +A (BIP-32)[https://bips.xyz/32] seed is generated by any means (probably using BIP-39 words is the best idea). The extended private keys are then derived iteratively: ``` @@ -78,7 +76,7 @@ ESK_N = f(ESK_N-1) where: - the `f()` function takes the BIP-32 `41`th child of the previous extended private key, -- `ESK_0` is derived from the seed, using derivation path `m/44'/1237'/41'` (using values from NIP-06, and `41` as present NIP number) +- initial `ESK_0` is derived from the seed, using derivation path `m/44'/1237'/41'` (using values from NIP-06, and `41` as present NIP number) - N is an arbitrary number, such as 256. The user will take the key pair `(SK_N, PK_N)` of the last extended key `ESK_N`, and use them. @@ -119,6 +117,7 @@ The form of the event is: ``` 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.