Seguridad

Estado

Sin auditoría independiente. Este motor se escribió y se revisó internamente. Tiene una batería de conformidad (test/conformance.mjs) que cubre las construcciones de docs/SPEC.md, incluida la coincidencia entre implementaciones, el rechazo de manipulaciones y la negativa a degradar la versión. Que las pruebas pasen demuestra que el código hace lo que dice la especificación; no demuestra que la especificación sea correcta, y no sustituye a una revisión hecha por gente que rompe protocolos para ganarse la vida.

La copia incluida de ML-KEM-768 (vendor/mlkem768-noble.js, de @noble/post-quantum) lleva la misma advertencia: su autor la describe como autoauditada, no auditada de forma independiente. Mira vendor/PROVENANCE.md.

Informar de una vulnerabilidad

Escribe a security@flamenetmessenger.com. Por favor, no abras una incidencia pública para nada que afecte a la confidencialidad o a la autenticación. Acusaremos recibo en un plazo de 72 horas.

Modelo de amenazas

El modelo completo está en docs/SPEC.md §11 y §12.1. En resumen, este motor protege frente a un servidor malicioso o comprometido que lea el contenido de los mensajes y, en la v2, frente a un adversario pasivo que grabe tráfico hoy para descifrarlo cuando exista un ordenador cuántico.

No protege frente a:

• Un dispositivo comprometido. Las claves del dispositivo viven en el dispositivo. Un programa malicioso instalado en él lee el texto en claro.
• La recogida de metadatos. El servidor ve quién escribe a quién, cuándo y más o menos cuánto. El remitente sellado oculta al remitente en la fila almacenada (§14), pero no en la conexión que lo entregó, y el primer mensaje a un contacto nuevo va necesariamente sin sellar.
• Un adversario cuántico presente durante el intercambio. La v2 hace híbrido el acuerdo de claves, pero las claves de identidad siguen siendo Ed25519, así que un adversario capaz de falsificar firmas en tiempo real todavía puede montar un ataque activo de intermediario. La autenticación poscuántica no está implementada.
• Un operador de servidor hostil, cuando el cliente es una página web servida por ese mismo operador. Esto es estructural, no un fallo: el servidor entrega el JavaScript que guarda las claves, así que puede entregarle a una persona un JavaScript distinto. Los clientes nativos no tienen esa propiedad. Cualquier despliegue que haga promesas de confidencialidad a sus usuarios debe dejar claro a qué cliente se aplican.

Notas de despliegue

• Guarda el estado cifrado. DeviceIdentity.archive() y E2ESession.archive() contienen material de clave privada. localStorage no es un almacén aceptable.
• Mantén los dos depósitos de preclaves del mismo tamaño. Un depósito poscuántico más pequeño que el clásico se agota antes y degrada en silencio las sesiones nuevas a la clave de último recurso. §12.3.
• Fija minProto por dispositivo. Sin eso, un servidor puede quitar los campos de la v2 de un paquete y las dos partes honestas negociarán la v1. Fijarlo es lo que hace detectable la degradación; el primer contacto sigue siendo vulnerable hasta que pqMode sea required. §12.7.
• Limita la frecuencia de descarga de preclaves. GET /e2e/keys consume una preclave de un solo uso por dispositivo y por llamada, así que un atacante puede vaciar los dos depósitos con poco esfuerzo. Esto no está resuelto en la capa del protocolo.
• No afirmes más de lo que puedas demostrar. El §12.10 de la especificación enumera lo que hay que haber ejecutado realmente antes de hacer cada afirmación. Una versión anterior de este proyecto afirmaba en su especificación una interoperabilidad entre plataformas que nunca se había realizado y que, en ese momento, era imposible. Las afirmaciones se escriben después de las pruebas, no antes.