mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 16:35:52 -05:00
101 lines
5.0 KiB
Markdown
101 lines
5.0 KiB
Markdown
NIP-101
|
|
======
|
|
|
|
Algorithm Transition for Signatures and Encryption
|
|
--------------------------------------------------
|
|
|
|
`draft` `optional` `author:eznix86`
|
|
|
|
This NIP introduces a generic method to transition from an old cryptographic algorithm to a new one for signatures and encryption without breaking compatibility with existing implementations. The proposal allows for a smooth upgrade path as new cryptographic algorithms become available or necessary.
|
|
|
|
Transition Event
|
|
----------------
|
|
|
|
A new event `kind` `101`is created for the transition between algorithms. The event structure is as follows:
|
|
|
|
jsonCopy code
|
|
|
|
```json
|
|
{
|
|
"id": <id>,
|
|
"kind": 101,
|
|
"created_at": <created_at>,
|
|
"content": '[["old_pubkey","<old_public_key>"],["new_pubkey","<new_public_key>"],["old_alg","<old_algorithm_name>"],["new_alg","<new_algorithm_name>"]]',
|
|
"old_signature": "<old_signature>",
|
|
"new_signature": "<new_signature>"
|
|
"tags": [],
|
|
}
|
|
```
|
|
|
|
|
|
**`content`**: A string of array of arrays containing the following information:
|
|
|
|
* `["old_pubkey", "<old_public_key>"]`: The old public key being transitioned from.
|
|
* `["new_pubkey", "<new_public_key>"]`: The new public key being transitioned to.
|
|
* `["old_alg", "<old_algorithm_name>"]`: The old algorithm being transitioned from.
|
|
* `["new_alg", "<new_algorithm_name>"]`: The new algorithm being transitioned to.
|
|
|
|
**`old_signature`**: The signature generated using the old private key and old algorithm.
|
|
|
|
**`new_signature`**: The signature generated using the new private key and new algorithm.
|
|
|
|
Event Serialization and Signing
|
|
-------------------------------
|
|
|
|
1. Serialize the event structure, excluding the `old_signature` and `new_signature` fields, into a format suitable for signing (e.g., JSON string).
|
|
|
|
2. Sign the serialized event using the old private key and old algorithm, then add the resulting signature to the `old_signature` field.
|
|
|
|
3. Sign the serialized event using the new private key and new algorithm, then add the resulting signature to the `new_signature` field.
|
|
|
|
|
|
Metadata Update (kind: 0)
|
|
-------------------------
|
|
|
|
Users who want to transition to a new encryption and signature algorithm should create a new `set_metadata` event (`kind: 0`) with an additional tag that indicates the new public key and the algorithm used, in the form `["alg", "<algorithm_name>", "<new_public_key>"]`. The relay may delete past `set_metadata` events once it gets a new one for the same pubkey.
|
|
|
|
Example:
|
|
|
|
```json
|
|
{
|
|
"pubkey": "<old_pubkey>",
|
|
"created_at": "",
|
|
"kind": 0,
|
|
"tags": [
|
|
["alg", "falcon", "<new_falcon_public_key>"]
|
|
],
|
|
"content": "",
|
|
"sig": "<new_signature>
|
|
}
|
|
```
|
|
|
|
|
|
NIP-04 Encrypted Messages
|
|
-------------------------
|
|
|
|
During the transition period, clients should support decrypting messages encrypted with both the old and new key pairs. This can be done by storing both key pairs and attempting decryption with each key pair when receiving an encrypted message.
|
|
|
|
To allow users to receive encrypted messages with their new key pair, they should update their metadata (using `kind: 0` event) to include the new public key. This ensures that others can discover the new public key and use it for encrypting future messages.
|
|
|
|
In the case of NIP-04, the sender of an encrypted message should be aware of the recipient's public key transition and encrypt the message using the appropriate key. To facilitate this, the sender's client could fetch the recipient's metadata to obtain the most recent public key and use it for encryption.
|
|
|
|
|
|
Compatibility and Transition
|
|
----------------------------
|
|
|
|
Clients and relays implementing this NIP should be able to handle both the old and new algorithms, as well as the transition events that signal the change. This ensures backward compatibility while providing a path for upgrading to new cryptographic standards as they become available.
|
|
|
|
Upon receiving a transition event, clients and relays should update their records to associate the new public key and algorithm with the user. They should also be prepared to handle events signed using either the old or the new algorithm during the transition period.
|
|
|
|
Clients and relays that don't implement this NIP can still communicate with those that do, but they won't benefit from the upgraded cryptographic features and may become less secure over time as older algorithms are deprecated or broken.
|
|
|
|
As long as users maintain their old key pairs and clients support decrypting messages with both the old and new key pairs, users should not lose access to their encrypted messages and `kind: 1` events when upgrading their encryption and public key.
|
|
|
|
Notes
|
|
-----
|
|
|
|
1. This NIP is designed to be generic and applicable to any cryptographic algorithm transitions.
|
|
2. The event `kind: 101` must be reserved for transition only.
|
|
3. Clients should be prepared to handle events with various combinations of old and new public keys, algorithms, and signatures.
|
|
4. Clients may choose to display a special indicator for events signed with new algorithms, signaling the higher level of security to users.
|