Paso 1 de 5
Normalizar la contraseña
La contraseña se convierte a Unicode NFKC para que sea idéntica byte a byte en cualquier dispositivo y teclado.
NIP-49
BorradorCodificación
Define ncryptsec, una forma de clave secreta protegida con contraseña. La contraseña se refuerza con scrypt, la clave se cifra con XChaCha20-Poly1305 y el resultado es un string bech32 que empieza por ncryptsec1, seguro para copias de seguridad pero no para publicarlo.
Edita el formulario o el JSON: ambos se mantienen sincronizados, la insignia indica si el resultado es válido y, al tocar cualquier campo, se explica qué hace.
Selecciona cualquier campo del formulario o del JSON para ver qué hace.
Paso 1 de 5
La contraseña se convierte a Unicode NFKC para que sea idéntica byte a byte en cualquier dispositivo y teclado.
Usa bech32 como las entidades de NIP-19, con su propio prefijo ncryptsec.
Otra forma de respaldar una clave: una frase mnemónica.
Los firmantes remotos evitan por completo mover la clave de un sitio a otro.
El texto de las especificaciones se cita en inglés del repositorio nostr-protocol/nips. Nuestras explicaciones y la interfaz están traducidas. Código fuente en GitHub en el commit 0046368
This NIP defines a method by which clients can encrypt (and decrypt) a user's private key with a password.
PASSWORD = Read from the user. The password should be unicode normalized to NFKC format to ensure that the password can be entered identically on other computers/clients.
LOG_N = Let the user or implementer choose one byte representing a power of 2 (e.g. 18 represents 262,144) which is used as the number of rounds for scrypt. Larger numbers take more time and more memory, and offer better protection:
| LOG_N | MEMORY REQUIRED | APPROX TIME ON FAST COMPUTER |
|-------|-----------------|----------------------------- |
| 16 | 64 MiB | 100 ms |
| 18 | 256 MiB | |
| 20 | 1 GiB | 2 seconds |
| 21 | 2 GiB | |
| 22 | 4 GiB | |
SALT = 16 random bytes
SYMMETRIC_KEY = scrypt(password=PASSWORD, salt=SALT, log_n=LOG_N, r=8, p=1)
The symmetric key should be 32 bytes long.
This symmetric encryption key is temporary and should be zeroed and discarded after use and not stored or reused for any other purpose.
The private key encryption process is as follows:
PRIVATE_KEY = User's private (secret) secp256k1 key as 32 raw bytes (not hex or bech32 encoded!)
KEY_SECURITY_BYTE = one of:
ASSOCIATED_DATA = KEY_SECURITY_BYTE
NONCE = 24 byte random nonce
CIPHERTEXT = XChaCha20-Poly1305( plaintext=PRIVATE_KEY, associated_data=ASSOCIATED_DATA, nonce=NONCE, key=SYMMETRIC_KEY )
VERSION_NUMBER = 0x02
CIPHERTEXT_CONCATENATION = concat( VERSION_NUMBER, LOG_N, SALT, NONCE, ASSOCIATED_DATA, CIPHERTEXT )
ENCRYPTED_PRIVATE_KEY = bech32_encode('ncryptsec', CIPHERTEXT_CONCATENATION)
The output prior to bech32 encoding should be 91 bytes long.
The decryption process operates in the reverse.
The following password input: "ÅΩẛ̣"
Should be converted into the unicode normalized NFKC format prior to use in scrypt: "ÅΩẛ̣"
The encryption process is non-deterministic due to the random nonce.
The following encrypted private key:
ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p
When decrypted with password='nostr' and log_n=16 yields the following hex-encoded private key:
3501454135014541350145413501453fefb02227e449e57cf4d3a3ce05378683
Passwords make poor cryptographic keys. Prior to use as a cryptographic key, two things need to happen:
These are achieved using a password-based key derivation function. We use scrypt, which has been proven to be maximally memory hard and which several cryptographers have indicated to the author is better than argon2 even though argon2 won a competition in 2015.
XChaCha20-Poly1305 is typically favored by cryptographers over AES and is less associated with the U.S. government. It (or it's earlier variant without the 'X') is gaining wide usage, is used in TLS and OpenSSH, and is available in most modern crypto libraries.
It is not recommended that users publish these encrypted private keys to nostr, as cracking a key may become easier when an attacker can amass many encrypted private keys.
It is recommended that clients zero out the memory of passwords and private keys before freeing that memory.