Dónde vive la clave: clientes, extensiones y firmantes remotos

La página es la septima sección de la demo educativa sobre Nostr. Aquí se explica dónde reside físicamente la clave privada cuando usas diferentes tipos de aplicaciones, y cómo el protocolo NIP-46 permite que una app firme eventos sin nunca ver tu clave.

Funcionalidades principales

• Comparación de modelos de custodia: presenta tres escenarios — la propia página web, una extensión de navegador (NIP-07) y un firmante remoto (NIP-46) — mostrando las diferencias de seguridad entre ellos.
• Permisos granulares: el firmante remoto se configura con restricciones específicas (por ejemplo, sign_event:1), lo que le permite firmar solo notas de texto y rechazar otras operaciones como cambios de perfil.
• Visualización del tráfico cifrado: muestra en tiempo real cómo la app y el firmante se comunican mediante eventos kind 24133 cifrados, donde un relay intermediario no puede leer el contenido.
• Explicación de las tres claves: desglosa el modelo de NIP-46 que utiliza una clave desechable para el cliente, una clave propia del firmante para la comunicación, y la clave real del usuario que nunca abandona el dispositivo firmante.

Idea central

Una aplicación puede obtener una firma válida de un firmante remoto sin nunca acceder a la clave privada del usuario.

Esto invierte el modelo de seguridad tradicional: en lugar de confiar en que la app no robe la clave, el sistema garantiza criptográficamente que la app no puede acceder a ella, limitando el daño potencial incluso si el cliente es malicioso.

Dónde reside la clave según el modelo

1. La propia página web

La clave vive en el JavaScript del navegador. Cualquier script de terceros (analítica, publicidad, dependencias comprometidas) puede leerla. Es el modelo más inseguro.

2. Extensión del navegador (NIP-07)

La clave reside en el almacenamiento aislado de la extensión. La página web pide firmas a la extensión, que actúa como intermediaria. Es más seguro que la web, pero la clave sigue en el mismo dispositivo y navegador.

3. Firmante remoto (NIP-46)

La clave está en otro dispositivo o aplicación (como Amber en Android o un bunker remoto). La app web se comunica mediante eventos cifrados a través de relays. La clave nunca toca el navegador.

Las tres claves de NIP-46

El protocolo utiliza tres pares de claves distintos:

1. Clave del cliente: generada por la app web solo para esta sesión de comunicación. Es desechable y no representa identidad.
2. Clave del firmante: pertenece al dispositivo que guarda tu clave real. Sirve para cifrar la comunicación con el cliente.
3. Clave del usuario: tu identidad real en Nostr. Nunca sale del firmante. Solo se usa para firmar los eventos que apruebas.

Solo la tercera es tu identidad permanente. Las otras dos son canales de comunicación temporales.

Permisos limitados como defensa

El firmante se inicia con permisos específicos como sign_event:1. Esto significa:

• Puede firmar notas de texto (kind 1).
• Rechaza automáticamente solicitudes para cambiar perfiles, borrar eventos o modificar contactos.

La aplicación no puede portarse mal porque el firmante no le concede la capacidad técnica, eliminando la necesidad de confiar en la buena voluntad del desarrollador.

La lección demuestra que la custodia de claves no es binaria (tenerla o no tenerla), sino un espectro de riesgo. Al separar la identidad (tu clave) de la capacidad de firma (mediante firmantes remotos con permisos limitados), Nostr permite usar aplicaciones web con la seguridad de que, incluso si son maliciosas, el daño está limitado y la clave permanece a salvo fuera de su alcance.

• Aqui esta el link de la fuente: https://rookery-six.vercel.app/

La casilla que nunca debes rellenar: por qué ninguna web necesita tu nsec

La página de la quinta sección de la demo educativa sobre Nostr. Aquí se aborda el riesgo más crítico de seguridad en la red: la exposición de la clave privada.

La lección simula un escenario realista de phishing para demostrar por qué ninguna página web legítima debería pedir tu nsec.

Funcionalidades principales

• Simulación de phishing: presenta un formulario de inicio de sesión falso pero convincente que solicita pegar el nsec para cargar el perfil.
• Demostración de exfiltración: muestra cómo una página hostil podría enviar la clave capturada a un servidor externo mediante una petición POST, aunque la demo aclara que es una simulación y no envía nada realmente.
• Explicación del riesgo de scripts: advierte que cualquier script cargado en la página puede leer campos de formulario, no solo el código visible o principal del sitio.
• Diferenciación de contextos: distingue entre aplicaciones web (que nunca deberían pedir el nsec) y aplicaciones nativas móviles como Damus o Amethyst, que históricamente lo aceptan por limitaciones técnicas de las plataformas.
• Alternativas seguras: introduce los estándares NIP-07 (extensiones de navegador) y NIP-46 (firmantes remotos) como métodos correctos para autenticar sin exponer la clave.

Idea central

Una vez que el nsec sale de tu dispositivo, el control se pierde permanentemente. No hay contraseña que restablecer ni servidor al que recurrir.

La lección enfatiza que una página web no tiene por qué custodiar tu clave privada. El código abierto de la demo permite verificar que la simulación no realiza peticiones reales, reforzando la transparencia sobre cómo funcionan estos ataques.

Por qué las webs no deben pedir tu nsec

• Superficie de ataque: cualquier script de terceros (analítica, publicidad, dependencias) puede acceder al valor del campo de texto.
• Irreversibilidad: a diferencia de una contraseña tradicional, no existe un "olvidé mi clave" ni un soporte técnico que pueda revocar el acceso.
• Suplantación permanente: quien posea el nsec filtrado es indistinguible del legítimo propietario para toda la red, de forma irreversible.

Alternativas seguras

La demo distingue entre contextos de ejecución:

• Navegadores web: deben usar extensiones NIP-07 (como Alby o nos2x) o firmantes NIP-46, manteniendo la clave fuera del alcance del JavaScript de la página.
• Aplicaciones nativas: en móviles, apps como Damus o Amethyst pueden aceptar el nsec por restricciones de las APIs del sistema operativo, aunque se recomienda usar herramientas como Amber en Android para aislar la clave.

La lección establece una regla de seguridad fundamental para el ecosistema: ninguna interfaz web legítima necesita tu clave privada. Al mostrar el mecanismo exacto del robo y sus consecuencias irreversibles, la demo prepara al usuario para reconocer y rechazar este tipo de solicitudes, promoviendo el uso de firmantes externos que mantienen el control de la identidad en manos del usuario.

• Aqui esta el link de la fuente: https://rookery-six.vercel.app/

Firmar eventos en Nostr: por qué ningún relay puede falsear un mensaje

La página de la cuarta sección de la demo educativa sobre Nostr. En esta ocasión se explica de forma interactiva, cómo se firma un evento y qué ocurre cuando alguien intenta alterar un mensaje ya firmado.

Funcionalidades principales

• Firma interactiva paso a paso: el visitante escribe un mensaje y la demo lo firma localmente, mostrando cada etapa del proceso.
• Forma canónica del evento: expone la serialización estándar del evento, formada por seis valores en orden fijo y sin espacios, sobre la que todos los clientes deben estar de acuerdo para que los identificadores coincidan.
• Cálculo del identificador: muestra que el identificador del evento es el hash SHA 256 de la forma canónica. Nadie lo asigna, se deriva del propio contenido.
• Firma Schnorr: genera una firma sobre el identificador usando la clave privada, demostrando que solo esa clave podría producirla.
• Prueba de alteración: al cambiar un solo carácter del mensaje firmado, el relay local lo rechaza indicando que la firma o el identificador no coinciden con el evento.
• Monitor de tráfico en vivo: un panel muestra los mensajes EVENT y OK que viajan entre el cliente y el relay, incluyendo la aceptación del evento legítimo y el rechazo del manipulado.

Idea central

Cambiar un solo carácter de un evento firmado es detectable por cualquier relay. El identificador deja de coincidir con el contenido y la firma deja de coincidir con el identificador.

Esta propiedad explica por qué los relays de Nostr pueden ser simples e intercambiables. Un relay puede negarse a transmitir un evento, pero ninguno puede falsificarlo ni modificarlo. La verificación es puramente matemática y no requiere confiar en el servidor.

Estructura del proceso de firma

1. Serialización canónica: el evento se convierte en un array JSON con seis valores en orden fijo, sin espacios en blanco.
2. Identificador: se calcula el hash SHA 256 de esa cadena serializada.
3. Firma: se firma el identificador con la clave privada usando Schnorr sobre la curva secp256k1.

La demo convierte un concepto criptográfico abstracto, la integridad mediante firmas digitales, en un experimento tangible. El visitante escribe, firma, publica y luego intenta engañar al relay modificando el mensaje. Al ver el rechazo en tiempo real, comprende que en Nostr la autenticidad no depende de la confianza en un intermediario, sino de las matemáticas.

• Aqui esta el link de la fuente: https://rookery-six.vercel.app/

Identidad en Nostr: una demo educativa interactiva

La página https://rookery-six.vercel.app/ es una demo educativa e interactiva sobre identidad en Nostr. Su objetivo es enseñar, de forma práctica, cómo funciona una cuenta en esa red.

Funcionalidades principales

• Generación de cuenta con un clic: al presionar el botón, el navegador crea una cuenta Nostr funcional, sin correo, contraseña ni servidor.
• Visualización de la clave secreta: muestra los 32 bytes aleatorios generados localmente por el equipo del usuario, tanto en bytes como en formato hexadecimal.
• Derivación de la clave pública: calcula la clave pública a partir de la secreta, destacando que la operación es de un solo sentido (no se puede invertir).
• Formatos legibles: presenta la clave pública como npub... y la secreta como nsec..., los formatos Bech32 estándar de Nostr.
• Regeneración instantánea: cada pulsación crea una identidad nueva, ilustrando que crear una cuenta no contacta con ningún servidor.

Idea central

El mensaje pedagógico de la página es que una cuenta Nostr son solo 32 bytes aleatorios: los números son la cuenta, y la clave pública siempre se deriva de la secreta, nunca al revés.

Esto coincide con el funcionamiento real de las claves Nostr (curva secp256k1, formatos npub/nsec), como describen nostrich.love y docs.nostria.app.

Conclusión

La demo consigue explicar un concepto criptográfico complejo con una sola acción: pulsar un botón. Sin registros, sin servidores y sin pasos intermedios, el visitante entiende que en Nostr la identidad no se crea en ninguna plataforma, sino que nace de las matemáticas en su propio dispositivo.

• Aqui esta el link de la fuente: https://rookery-six.vercel.app/

Los 5 clientes web de Nostr más populares

1. Primal – Disponible en web, iOS y Android, es uno de los clientes más versátiles y populares. Ofrece una experiencia completa y fácil de usar, ideal para quienes quieren un solo cliente que funcione en todas partes.

2. Snort – Un cliente web rápido y ligero que corre directamente en el navegador. Es una excelente puerta de entrada para nuevos usuarios que no quieren descargar ninguna app.

3. Coracle – Cliente web con buen soporte de funciones del protocolo, incluyendo publicaciones tipo "kind 1" y otras características avanzadas.

4. Iris – Otro cliente web popular con amplio soporte de funcionalidades de Nostr.

5. Nostrudel – Cliente web/escritorio mencionado frecuentemente en listas de recursos de la comunidad hispanohablante.

Menciones adicionales

Si buscas algo más especializado, también vale la pena explorar:

• Yakihonne y Habla.news – enfocados en contenido de formato largo (blogs y artículos).
• Ditto – otra opción web/escritorio con una comunidad activa.

Recomendación

Prueba un par de ellos (por ejemplo Primal y Snort) y quédate con el que mejor se adapte a tu forma de usar la red.

Get information about news, new releases, new themes or new plugins on our social networks Facebook, Twitter and YouTube or visit our Blog.