Claves de Nostr explicadas: tu identidad digital en dos cadenas

Tu cuenta de Nostr no es una combinación de nombre de usuario y contraseña. Es un par de claves criptográficas, una pública y una privada, que tú mantienes. Cada publicación que haces se firma con la clave privada; cada cliente que ve tu publicación verifica la firma contra tu clave pública.

Este es el único aspecto más importante de entender sobre Nostr, porque forma todo lo demás. Tu identidad no puede recuperarse si la pierdes, porque ninguna empresa jamás tuvo una copia. Tu cuenta no puede ser prohibida por una plataforma, porque no hay una base de datos de plataforma para eliminarla. Estas son las mismas propiedades vistas desde diferentes ángulos.

Esta guía explica qué son las claves, qué hace cada una, cómo se codifican, y los errores específicos que las pierden.

TL;DR. Tu npub1... es tu clave pública. Segura de compartir en cualquier lugar. Tu nsec1... es tu clave privada. Mantenla en un gestor de contraseñas o en un papel impreso en una caja de seguridad. Nunca la pegues en un formulario web. Piérdela y la identidad se ha ido permanentemente.

Cuando estés listo, pide tu dirección @nostr.blog →

Qué es realmente un par de claves

Un par de claves son dos números matemáticamente vinculados. Las matemáticas son criptografía de curva elíptica en una curva llamada secp256k1 (la misma curva que usa Bitcoin).

• La clave privada es un número aleatorio de 32 bytes. Cualquier número aleatorio de 256 bits funciona; nada especial sobre el tuyo.
• La clave pública se deriva de la clave privada mediante un cálculo específico en la curva elíptica. Dada la clave privada, calcular la clave pública es rápido. Dada la clave pública, se cree que calcular la clave privada de vuelta es prácticamente imposible.

"Prácticamente imposible" aquí significa: no hay ningún algoritmo conocido que pueda hacerlo en un tiempo razonable en ninguna computadora que exista o que plausiblemente exista. La seguridad descansa en esta asimetría. Publicas la clave pública libremente; guardas la clave privada absolutamente.

Qué hace cada clave

La clave pública es tu identidad. Cuando alguien te sigue, sigue la clave pública. Cuando alguien te menciona, etiqueta la clave pública. Cuando un relay almacena tus publicaciones, las indexa por clave pública. Todo lo visible sobre ti en la red está vinculado a este único valor.

La clave privada firma. Cada evento (publicación, reacción, actualización de lista de seguimiento, cambio de perfil) lleva una firma de Schnorr producida a partir del hash del evento y la clave privada. Cualquier cliente puede ejecutar la verificación inversa: dada la clave pública, el hash y la firma, verificar que solo el poseedor de la clave privada correspondiente podría haber producido esa firma.

El resultado: los relays y los clientes no tienen que confiar en nadie. Verifican las firmas ellos mismos. Una publicación falsificada con una firma inválida se descarta silenciosamente. Una publicación real firmada por la clave correcta se acepta sin importar de qué relay la sirvió.

Cómo se codifican las claves

Un número crudo de 32 bytes es incómodo de mirar o escribir. Nostr usa dos convenciones de codificación.

Hex. Los bytes crudos escritos como hexadecimal en minúsculas: 64 caracteres, a-f y 0-9. Esta es la forma canónica que aparece dentro de archivos JSON de NIP-05 y la mayoría de internos del protocolo.

Ejemplo de clave pública en hex: 0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88

Bech32. Los mismos bytes envueltos en un formato orientado a humanos con un prefijo y una suma de verificación. El prefijo indica a los humanos (y al software) qué tipo de cosa están mirando. npub1 significa "esto es una clave pública de Nostr." nsec1 significa "esto es una clave privada de Nostr."

Ejemplo de clave pública en Bech32: npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5

La suma de verificación en Bech32 es importante. Si accidentalmente cambias un carácter, la suma de verificación falla y cualquier herramienta rechaza la clave como inválida. Esto previene corrupción silenciosa durante copiar-pegar. Hex no tiene tal seguridad; un solo carácter incorrecto en una clave hex producirá una identidad diferente (pero de aspecto válido).

Los prefijos existen para otros tipos de datos de Nostr también. note1 es un ID de evento. nprofile1 es una clave pública agrupada con relays recomendados. nevent1 es un ID de evento agrupado con autor y relays. El 1 es parte del separador Bech32, no un número de versión.

Dónde viven las claves

Cuando instalas cualquier cliente de Nostr por primera vez, genera un par de claves pidiendo al sistema operativo 32 bytes aleatorios. Esa es toda la ceremonia. Las claves son tuyas en el momento en que el generador de números aleatorios termina.

Dónde el cliente las almacena depende de la aplicación:

• Las aplicaciones nativas para móvil almacenan el nsec en el llavero del SO (iOS Keychain, Android Keystore). Ambos están cifrados en reposo con el código de acceso del dispositivo o biométrico.
• Los clientes basados en navegador generalmente te piden que instales una extensión NIP-07 (nos2x, Alby, Flamingo) que mantiene el nsec en el almacenamiento seguro de la extensión. El cliente nunca ve el nsec directamente; le pide a la extensión que firme eventos bajo demanda.
• Los clientes que omiten NIP-07 te pedirán que pegues el nsec en el almacenamiento local del navegador, que es menos seguro. Esto está bien para cuentas de bajo riesgo y es una mala idea para valiosas.
• Los firmadores de Nostr de estilo monedero de hardware (aplicaciones bunker, firmadores remotos) mantienen el nsec en un dispositivo separado y firman remotamente a través de un canal cifrado. Lo más avanzado, la superficie de ataque más baja.

Cómo hacer una copia de seguridad del nsec

La regla de copia de seguridad más importante: el nsec debe existir en al menos dos lugares, pero nunca en una nube que el proveedor pueda leer.

Buenos lugares:

• 1Password, Bitwarden, KeePassXC, o cualquier gestor de contraseñas con cifrado de extremo a extremo
• iCloud Keychain (cifrado de extremo a extremo; Apple no puede leerlo)
• Un papel impreso en una ubicación física segura (una caja de seguridad, una bóveda de seguridad)
• Una placa de respaldo de acero estilo Bitcoin, si quieres durabilidad física

Malos lugares:

• iCloud Notes, Google Keep, Evernote, OneNote (estas se sincronizan en formatos que el proveedor puede descifrar)
• Una captura de pantalla en tu carrete de cámara (respaldada automáticamente a iCloud o Google Photos en texto plano)
• Correo electrónico para ti mismo
• "Mensajes Guardados" de Telegram o cualquier otro auto-DM de aplicación de chat
• Un archivo de texto plano en Dropbox, Google Drive, iCloud Drive

La distinción es: ¿puede el proveedor, si quisiera, leer el texto? Si sí, la ubicación es insegura. Si no (o el proveedor eres tú con una impresora), la ubicación es segura.

Para los paranoicos: fragmentación. Divide el nsec en múltiples piezas usando un esquema de umbral (Shamir's Secret Sharing) y almacena cada pieza por separado. Dos de tres piezas reconstruyen la clave. Excesivo para la mayoría de usuarios, sensato para usuarios con una identidad de alto valor.

Qué pasa si pierdes el nsec

La cuenta se ha ido permanentemente. No hay flujo de restablecimiento. Ninguna empresa tiene una copia. Ningún truco criptográfico puede recuperar la clave solo del npub.

La pérdida tiene tres consecuencias prácticas:

• Ya no puedes publicar desde esa identidad.
• Ya no puedes recibir zaps a esa identidad (la dirección Lightning señalada en ella aún está en tu viejo evento de perfil, pero como no puedes actualizar tu perfil, la dirección puede volverse obsoleta si el servicio subyacente cambia).
• No puedes actualizar tu lista de seguimiento, tu perfil, o responder a mensajes directos.

Tus publicaciones permanecen en relays, legibles por cualquiera. Tus seguidores aún ven las viejas publicaciones en sus clientes. Actividad nueva es imposible.

La respuesta pragmática: genera un par de claves fresco, publica tu viejo npub con una explicación de "migración" para cualquiera que esté observando, y reconstruye. Las personas que quieren seguirte a través del quiebre lo harán; perderás algunos y regalarás otros. No hay una forma a nivel de protocolo para hacer esto sin fricción aún.

Qué pasa si alguien obtiene tu nsec

El atacante puede hacer todo lo que podrías hacer:

• Publicar bajo tu identidad (para siempre)
• Leer tus mensajes directos descifrados
• Actualizar tu perfil (incluyendo cambiar tu identificador NIP-05)
• Enviar zaps usando cualquier saldo de cartera accesible a tu cliente
• Cambiar tu lista de seguimiento

Lo que no pueden hacer sin acceso adicional:

• Drenar directamente una cartera Lightning que no está emparejada con el cliente
• Robar zaps enviados a ti (esos van a tu dirección Lightning configurada)
• Impedir que también uses la clave (aún la tienes; esto no es un token de autenticación que se invalida)

La respuesta inmediata a una sospecha de compromiso de nsec es difícil. A diferencia de una contraseña, los nsecs de nostr no pueden revocarse. La mitigación realista es generar un nuevo par de claves, publicar desde el viejo para advertir a todos que estás rotando, y cambiar de identidades. NIP-41 y propuestas similares apuntan a hacer esto más limpio pero no son aún universalmente soportadas.

Múltiples identidades

Muchos usuarios de Nostr ejecutan más de una identidad. Una cuenta profesional de cara al público, una cuenta personal privada, una cuenta anónima para comunidades particulares. Cada es un par de claves separado; nada las vincula criptográficamente a menos que elijas vincularlas mediante publicación cruzada.

La mayoría de clientes soportan cambiar entre identidades desde un menú. Las claves son independientes; el mismo cliente puede estar conectado a todas ellas y cambiar con un toque. Esto es diferente de Twitter multi-cuenta, donde las identidades son entradas en la base de datos de la misma plataforma; en Nostr son criptográficamente no relacionadas.

Un consejo práctico: etiqueta las entradas del gestor de contraseñas claramente. nostr-main-nsec, nostr-anon-nsec, nostr-work-nsec. Mezclarlas durante un copiar-pegar es una forma de publicar accidentalmente desde la identidad equivocada.

Las claves son la cuenta

Todo lo demás en Nostr (el nombre legible, la foto de perfil, la biografía, los relays que usas, el identificador NIP-05) es metadatos secundarios. Todo puede ser reemplazado o movido. El par de claves es la única cosa que no puede ser reemplazada sin empezar de nuevo.

Trata el nsec en consecuencia. Hacer una copia de seguridad toma dos minutos el momento en que lo generes. Recuperarse de un nsec perdido toma semanas de reconstrucción y nunca funciona del todo.

Una nota sobre la generación. La forma segura de obtener un nuevo par de claves es dejar que un cliente lo genere localmente y nunca transmita la mitad privada sobre la red. El registro de nostr.blog hace esto lado del cliente en el navegador; el servidor nunca ve el nsec. Si algún flujo de registro envía la clave privada a un servidor primero, eso es una bandera roja. Sal y genera en otro lugar.