Whitepaper de seguridad

• Intercambio de claves (PQXDH): híbrido X25519 (Diffie-Hellman sobre Curve25519) + ML-KEM-1024 (Kyber, FIPS 203) → resistente a computadoras cuánticas.
• Cifrado autenticado (AEAD): XChaCha20-Poly1305 (nonce de 192 bits).
• Derivación de claves: HKDF-SHA256 (raíz del ratchet) y HMAC-SHA256 (cadenas del ratchet).
• Contraseñas de backup: Argon2id (RFC 9106).
• Motor: libsignal, la librería oficial de Signal (Rust), auditada de forma independiente upstream. Las constantes de separación de dominio de las KDF de nuestra capa de backups/almacenamiento son propias del proyecto; el resto sigue las especificaciones de Signal.

No hay número de teléfono. Cada cuenta es un usuario elegido por la persona. Cada dispositivo genera un par de identidad X25519 de largo plazo, un signed prekey, un prekey Kyber (ML-KEM-1024) y prekeys de un solo uso. Las claves privadas nunca salen del dispositivo (viven en el Keystore/Keychain del sistema); el servidor solo publica las claves públicas para que otros puedan iniciar una sesión.

La primera vez que A le escribe a B, A baja el bundle de prekeys de B (identidad + signed prekey + prekey Kyber, más un one-time prekey si hay disponible) y libsignal ejecuta el acuerdo híbrido PQXDH: combina varios Diffie-Hellman sobre X25519 con un encapsulado ML-KEM-1024 (Kyber) y deriva un secreto de sesión compartido (SK) idéntico en ambos lados, resistente a computadoras cuánticas. El primer mensaje que recibe B es un PreKeySignalMessage, que le permite reconstruir SK.

A partir de SK se ejecuta el Double Ratchet auditado de libsignal: una raíz (root key) que evoluciona con cada ida y vuelta mezclando un nuevo Diffie-Hellman, y cadenas simétricas de envío/recepción de las que se derivan las claves de mensaje.

• Forward secrecy: cada clave de mensaje se deriva por una KDF de un solo sentido y se descarta tras usarse; comprometer el estado actual no revela mensajes ya entregados.
• Post-compromise security (auto-sanación): cada round trip mezcla un DH fresco en la raíz, así un compromiso puntual se cura tras un intercambio más de cada lado.
• Tolerancia a desorden/pérdida: se guardan claves de mensajes saltados, acotadas para evitar DoS.

Cada mensaje se cifra con XChaCha20-Poly1305 bajo la clave de mensaje. El encabezado (clave pública del ratchet, número de mensaje y longitud de la cadena previa) NO se cifra pero se autentica como datos asociados (AAD): un encabezado alterado hace fallar la verificación MAC al descifrar. El servidor solo retransmite tres campos opacos: encabezado, payload cifrado y nonce.

Para que el servidor no conozca al remitente ni el par de una conversación, un mensaje 'sellado' se envía sin remitente ni referencia de conversación. Cada usuario genera una clave de acceso, sube solo su hash SHA-256 y la comparte con sus contactos por el canal E2E; presentarla autoriza el envío (anti-spam sin identificar). El enrutado usa un delivery token DIRECCIONAL derivado de la clave de acceso del destino + las claves de identidad de ambos, para que el servidor no correlacione la arista por un token simétrico. Estado actual (v3, fail-safe): el *ENVÍO* sellado está activo. Para evitar el agujero negro que un token obsoleto podía causar tras una rotación de claves, solo se sella cuando ya hay confianza establecida con el contacto (recibiste algo suyo con clave de acceso vigente); y si el sellado no se confirma con un recibo de entrega en pocos segundos, el mensaje se reenvía identificado — así nunca se pierde. En el primer contacto o tras una rotación, el envío es identificado y el servidor ve el par de entrega, pero lo elimina al entregar (no retiene el grafo).

• Recibos de entrega/lectura: viajan como mensajes de control cifrados por el mismo ratchet (y sellados si aplica); el servidor no ve metadatos de estado.
• Almacenamiento local: el historial se cifra en reposo con XChaCha20-Poly1305; la clave vive en el Keystore del sistema.
• Backups: passphrase → Argon2id → clave → XChaCha20-Poly1305 sobre una foto del estado local. Sin la passphrase el archivo es indescifrable (ni nosotros podemos abrirlo).
• Notificaciones push: solo despiertan la app ('mensaje nuevo'), sin contenido.

El servidor retransmite texto cifrado y ve metadatos mínimos de entrega, que elimina en cuanto entrega el mensaje (no guarda un historial del grafo). Con el envío sellado activo (v3), un mensaje sellado llega sin remitente, así que el servidor no ve quién lo envía; solo ve el par de entrega en los mensajes identificados (primer contacto o tras una rotación de claves). En cualquier caso, el servidor y tu operador de red pueden observar que TU dispositivo se conecta y recibe tráfico, y cuándo.

• Nuestra integración aún sin auditar. El núcleo libsignal está auditado de forma independiente upstream, pero nuestra integración a su alrededor (keystore del dispositivo, puente nativo, manejo de prekeys, sealed sender) todavía no fue revisada por un tercero independiente.
• iOS pendiente. El motor nativo de libsignal está verificado en Android; el port a iOS aún está en curso.
• Sin cifrado de encabezado. El encabezado del ratchet va autenticado pero en claro (metadatos que el servidor de todos modos ve).
• No protege los extremos. Un dispositivo comprometido, o que el receptor copie/capture, están fuera del alcance de la criptografía.

La migración a libsignal (la librería auditada de Signal) con PQXDH = intercambio híbrido X25519 + ML-KEM-1024 (Kyber, FIPS 203) YA ESTÁ HECHA y verificada on-device: el motor de cifrado ya es 'auditado upstream + resistente a cuántica'. Lo que queda en agenda: una auditoría criptográfica independiente de NUESTRA integración de libsignal (cuyos resultados publicaremos), completar el port del motor nativo a iOS, y firmas post-cuánticas ML-DSA como hardening opcional.