Política de seguridad

Herkos maneja claves privadas y mensajes cifrados, así que nos tomamos en serio los informes de seguridad y preferimos enterarnos pronto antes que tarde.

Cómo informar de una vulnerabilidad

No abras una incidencia pública para un problema de seguridad.

Comunícalo en privado por correo a security@herkos.email.

Conviene incluir: cuál es el problema, cómo reproducirlo, en qué plataforma y versión lo has probado, y qué podría conseguir un atacante. Una prueba de concepto ayuda mucho.

Nunca incluyas tu propia nsec, clave secreta o secreto de bunker en un informe.

Intentamos acusar recibo en unos pocos días. Como Herkos es un proyecto pequeño, te pedimos un plazo razonable para corregirlo antes de hacerlo público. Nos gusta acreditarte en el aviso, salvo que prefieras lo contrario.

Qué entra en el alcance

La propia aplicación Herkos: el manejo y almacenamiento de claves, el cifrado y descifrado de mensajes (incluidas las comprobaciones de remitente NIP-59 y el aislamiento de Bcc en local_packages/nostr_mail), el bloqueo de la app, la comunicación con relays y bridges, el manejo de adjuntos, y el proceso de compilación y publicación.

Qué queda fuera

El protocolo Nostr y sus NIP en sí — eso se reporta upstream.
Relays, bridges y servidores Blossom operados por terceros. Herkos trae valores por defecto, pero no los gestiona; informa a sus operadores.
El proyecto original Nostr Mail Client, salvo que el problema sea específico de los cambios hechos en Herkos.
El endurecimiento que ya documentamos como limitación conocida (más abajo).

Limitaciones conocidas, dichas claramente

Son decisiones de diseño, no vulnerabilidades. Preferimos escribirlas que dejar que alguien las descubra por las malas:

El correo a direcciones tradicionales no va cifrado de extremo a extremo. Entre usuarios de Nostr se usa gift wrap NIP-17 y sí lo está. Cuando escribes a una dirección de correo normal, un bridge convierte el mensaje y puede leerlo.
El bloqueo de la app (PIN y biometría) es una barrera de conveniencia, no cifrado en reposo. Frena a quien coge un dispositivo desbloqueado; no protege frente a un atacante con acceso completo al dispositivo o a su almacenamiento.
En Windows no se puede exigir solo biometría. Windows Hello no permite seleccionar el método, así que el PIN del sistema sigue siempre disponible como alternativa.
Perder tu clave es perder la cuenta. No hay recuperación, por diseño.
Los metadatos no están del todo ocultos. Los relays pueden observar patrones de conexión, y todos ven tu dirección IP, aunque no puedan leer el contenido. Lo que Herkos no revela (desde el 30-09-2026) es quién escribe a quién cuando un relay pide autenticación NIP-42:
Consultar dónde entregar. Las listas de relays y de Blossom del destinatario se piden por una conexión aparte que nunca te identifica, primero a relays que no exigen autenticación (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Perfiles y programador. El nombre y la foto que se muestran de cualquier otra persona (kind 0), y la lista de relays del DVM programador cuando programas o cancelas un correo, se piden igual: primero de forma anónima y, si un relay insiste, con la clave temporal que se explica abajo, nunca con la tuya (desde el 01-10-2026; antes, un relay que pedía autenticación recibía tu clave y podía saber de quién mirabas el perfil). Solo tu propio perfil se sigue leyendo como tú.
Entregar. Los gift wraps van a los relays de mensajes privados del destinatario, por esa misma conexión aparte. Si alguno exige autenticarse, Herkos responde con una clave creada para eso y guardada solo en memoria, nunca con la tuya; cada cuenta del dispositivo tiene la suya. El relay sí puede ver que el mismo dispositivo (misma IP, misma clave temporal) envió varios sobres durante una sesión.
Correos grandes. La copia cifrada de un correo de más de 32 KB se sube a servidores Blossom, también a los del destinatario. Solo tus propios servidores (tu lista de Blossom) reciben la subida autorizada con tu clave. Cualquier otro la recibe de forma anónima y, si exige una autorización, firmada con la misma clave temporal de antes (desde el 01-10-2026; antes, todos recibían tu clave). Un servidor que solo acepta claves conocidas la rechaza, y la copia queda en los demás.
Tus propios datos. Al sincronizar tu buzón, etiquetas, ajustes y borradores, Herkos se identifica, si el relay lo pide, como la cuenta a la que pertenecen esos datos, también durante un cambio de cuenta. En tus propios relays eso no les dice nada nuevo: las peticiones ya nombran tu clave. Tus listas de relays y de Blossom son públicas y se piden sin identificarte; también se pregunta sin identificarte a los relays que vengan en un enlace.
El estado de lectura y las carpetas son metadatos públicos (por ahora). Marcar un correo como leído, destacado o archivado, o moverlo, publica un evento de etiqueta NIP-32 sin cifrar ligado a tu clave pública, incluidos los nombres de las carpetas personalizadas. Quien te envió un correo y conoce su id puede saber cuándo actuaste sobre él. Cifrar esas etiquetas está previsto; hasta entonces, trata los nombres de carpeta como públicos.
Las notificaciones push y el envío programado usan servicios de terceros. El servidor push (api.nmail.li por defecto) conoce tu clave pública, un token push y cuándo recibes correo; el DVM programador conoce tu clave pública y los mensajes —ya cifrados— que debe publicar. Ambos son opcionales y están documentados en PRIVACY.md. El texto de una notificación push lo elige el servidor push, y Herkos solo se fía de él cuando UnifiedPush lo entrega cifrado (RFC 8291); un aviso sin cifrar solo sirve para despertar a la app, que va a buscar el correo por su cuenta.
La versión web guarda tu clave en el navegador, que es el peor sitio para ella. Las apps instaladas entregan la clave secreta al almacén seguro del sistema (Android Keystore, administrador de credenciales de Windows, libsecret, llavero de iOS/macOS). Un navegador no tiene nada de eso: la clave vive en el almacenamiento del sitio y pasa por JavaScript en cada firma, al alcance de cualquier código que se ejecute en la página —una extensión con acceso a todos los sitios, un fallo de XSS en la app o en una dependencia, un despliegue manipulado— y de cualquier ladrón de información que copie el perfil del navegador. Tampoco hay un momento en el que verifiques el código una vez: un binario firmado se comprueba al instalarlo, mientras que una web sirve código nuevo en cada visita. Entra en la versión web con un firmante remoto (bunker NIP-46, Amber), y así la clave nunca llega al navegador, o úsala con una identidad desechable y guarda la de verdad en una app instalada.
El correo puenteado vale lo que valga el bridge. Herkos verifica que un mensaje marcado como procedente de un bridge realmente fue firmado por un bridge que tienes configurado (o uno de los de serie). No puede verificar nada sobre la dirección From: tradicional que el bridge retransmite.
Los adjuntos los abre el sistema operativo. Herkos nunca lanza ficheros ejecutables ni de script, y pregunta antes de entregar al sistema cualquier otro adjunto que no pueda previsualizar, pero la aplicación que abre el fichero queda fuera de nuestro control.

Versiones con soporte

Las correcciones de seguridad se aplican a la última versión publicada. Dado el tamaño del proyecto, las versiones anteriores no se mantienen: actualiza antes de informar.