nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-13 23:39:08 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Typos, minor fixes

Browse Source
This commit is contained in:
Adam B 2023-04-15 16:49:22 +02:00
parent b984e4a452
commit 83480de077
No known key found for this signature in database
GPG Key ID: 9ED7B5FB86547DAD
1 changed files with 10 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
41.md
View File

@ -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.