Durante años, la narrativa fue casi seductora en su simplicidad:si eliminas al intermediario, eliminas el abuso. Esa idea, repetida hasta convertirse en dogma dentro de ciertos círculos tecnológicos, impulsó el nacimiento de protocolos como Nostr, una redsocial descentralizada que prometía algo que el ecosistema digital parecía haber perdido definitivamente: control real sobre la identidad.
La premisa era elegante. En lugar de depender de servidores centrales —como ocurre en plataformas tradicionales—, en Nostr cada usuario gestiona su identidad mediante claves criptográficas. No hay cuentas en el sentido clásico, no hay una autoridad que pueda expulsarte, y los servidores (relays) no validan nada; simplemente retransmiten. La verificación, la confianza, la integridad… todo se traslada al cliente, es decir, a la aplicación que decides instalar.
Y ahí, precisamente ahí, es donde empieza a resquebrajarse la promesa.
La investigación presentada en Black Hat USA 2025, junto con análisis académicos posteriores publicados en el ámbito criptográfico, no vino a destruir Nostr, sino a exponer su punto más vulnerable: no el protocolo en sí, sino la forma en que es interpretado, implementado y, en demasiados casos, simplificado. Porque la criptografía puede ser sólida, pero si quien la implementa decide omitir pasos críticos por rendimiento, usabilidad o simple desconocimiento, el sistema deja de ser seguro sin necesidad de romperlo.
Uno de los hallazgos más incómodos —y más reveladores— fue que múltiples clientes populares no verificaban correctamente las firmas digitales, o directamente omitían ese proceso en determinadas condiciones. En un entorno donde la identidad depende exclusivamente de claves, esto no es un detalle menor, es el pilar. Sin verificación, cualquier entidad puede suplantar a otra, alterar contenido o redirigir información sin que el usuario tenga forma evidente de detectarlo. No se trata de un ataque sofisticado; se trata de aprovechar una decisión de implementación.
Y esa es la grieta real.
Durante el periodo posterior a la divulgación de estas vulnerabilidades, muchos de los clientes más conocidos comenzaron a corregir estos fallos, integrando verificación estricta, mejorando la gestión de caché y, en algunos casos, migrando hacia esquemas de cifrado más robustos que reemplazan al antiguo AES-CBC, cuya maleabilidad permitía manipular mensajes sin necesidad de conocer la clave. En términos técnicos, el ecosistema ha evolucionado. Negarlo sería injusto.
Pero asumir que el problema está resuelto sería ingenuo.
Porque Nostr no es una aplicación, es un conjunto de interpretaciones. Y en un entorno donde cualquier desarrollador puede crear un cliente, la seguridad deja de ser una propiedad del sistema para convertirse en una propiedad de cada implementación individual. Eso significa que mientras algunos clientes avanzan, otros se quedan atrás, replican errores antiguos o introducen nuevos, ya sea por falta de recursos, desconocimiento o decisiones de diseño orientadas a priorizar experiencia de usuario sobre seguridad.
La consecuencia es incómoda, pero inevitable: no todos los clientes son seguros, y no todos los usuarios lo saben.
Este punto cambia completamente el eje de la discusión. Durante años se criticó a los sistemas centralizados por concentrar poder y riesgo en una sola entidad, pero ese mismo modelo permitía algo que ahora se vuelve escaso: actualizaciones inmediatas y homogéneas. Cuando una plataforma centralizada corrige una vulnerabilidad, la corrección se propaga de forma casi instantánea a toda su base de usuarios. En Nostr, eso no ocurre. Cada cliente debe actualizarse de forma independiente, y cada usuario debe decidir —con mayor o menor conocimiento— si confía en esa implementación.
La seguridad, entonces, deja de ser un servicio y se convierte en una responsabilidad activa.
Y aquí es donde la narrativa de la soberanía digital empieza a mostrar su lado menos romántico.
Porque no basta con tener el control de tus claves si utilizas un cliente que no verifica firmas correctamente. No basta con cifrar tus mensajes si el esquema utilizado permite manipulación sin detección. No basta con participar en una red descentralizada si tu punto de entrada —la aplicación— introduce vulnerabilidades que el protocolo, en teoría, no tenía. La seguridad no desaparece; se fragmenta, se distribuye y, en muchos casos, se diluye.
Los análisis más recientes, incluidos debates técnicos en comunidades de desarrolladores y foros especializados, han dejado algo claro: incluso después de los parches, el ecosistema sigue siendo heterogéneo. Algunos clientes han corregido de forma rigurosa los fallos identificados, mientras que otros mantienen implementaciones parciales o desactualizadas. Además, nuevos clientes continúan apareciendo, y no todos parten de una base sólida. La repetición de errores no es una excepción, es una consecuencia natural de la falta de especificaciones estrictas y obligatorias.
Esto introduce una tensión difícil de resolver: la libertad de desarrollar sin restricciones frente a la necesidad de garantizar un mínimo de seguridad coherente.
En ese equilibrio inestable, el usuario se convierte en el último eslabón… y también en el más expuesto.
Porque ahora es el usuario quien debe:
— elegir qué cliente utilizar
— verificar si está actualizado
— confiar en que la implementación es correcta
— entender, al menos superficialmente, qué implica cada decisión
Y la realidad es que la mayoría no lo hará.
No por negligencia, sino porque el sistema exige un nivel de alfabetización técnica que no es razonable asumir como estándar. La descentralización, en este punto, no elimina la necesidad de confianza; la traslada hacia lugares menos visibles, donde evaluar riesgos se vuelve más complejo.
Eso no invalida a Nostr como propuesta, pero sí obliga a replantear cómo se comunica. No es una solución mágica contra la censura ni un entorno intrínsecamente seguro por diseño. Es una infraestructura que puede ser segura bajo ciertas condiciones, pero que depende profundamente de cómo se implemente y de quién la utilice.
Quizá el mayor error no haya sido técnico, sino narrativo.
Se vendió como liberación lo que en realidad es delegación. Se prometió autonomía sin enfatizar el coste que implica sostenerla. Porque tener el control también significa asumir las consecuencias cuando algo falla, incluso si ese fallo no está en el protocolo, sino en la herramienta que decidiste usar para interactuar con él.
Y en ese punto, la pregunta deja de ser si Nostr es seguro.
La pregunta real es si estamos preparados para vivir en sistemas donde la seguridad ya no es algo que alguien nos da, sino algo que debemos mantener por nuestra cuenta, con todas las implicaciones —y todos los errores— que eso conlleva… Y claro, antes de dicha divulgación ¿Cuanto tiempo se mantuvo expuesto y si alguien lo explotó? >:)
