Biblioteca de criptografía/protocolo Voron — solicitud de revisión

Este es el núcleo criptográfico y de protocolo de mensajería de un pequeño proyecto de mensajería E2EE, extraído por separado para su revisión externa. No es el producto completo: el cliente Android y la configuración de despliegue se han omitido a propósito; esta es solo la parte que necesita que la examinen.

Qué contiene

• common/ — la biblioteca en sí:
  • e2ee/ — X3DH-lite (acuerdo de claves asíncrono) + un Double Ratchet por encima, construido sobre Curve25519/ChaCha20-Poly1305/Ed25519/HKDF (primitivas proporcionadas por el JDK, nada hecho a mano en esa capa).
  • crypto/ — envoltorios finos sobre esas primitivas del JDK.
  • group/ — mensajería de grupo mediante un esquema de claves de remitente (el enfoque pre-MLS que usaban los primeros grupos de WhatsApp/Signal), además de un registro de eventos de cadena hash firmada en el lado del cliente para la pertenencia y los roles, ya que el relé no tiene ningún concepto de grupos.
  • onion/ — un transporte opcional de cifrado por capas (número fijo de saltos, relleno por buckets de tamaño fijo) para impedir que el relé relacione directamente la IP de una conexión con su clave de identidad.
  • client/, transport/, backup/ — el protocolo de red, el handshake de transporte Noise_IK y un formato de copia de seguridad cifrada.
• server/ — una implementación de referencia del relé: enrutamiento de almacenamiento y reenvío, directorio de preclaves, buzón sin conexión, el rol de salto onion. Confianza deliberadamente mínima: el relé nunca ve texto plano, nunca retiene un mensaje más tiempo del que tarda la entrega y (por diseño) no tiene ningún conocimiento de la pertenencia a grupos.
• client/ — un sencillo banco de pruebas de consola JVM (no es una aplicación real) que se usa para hacer interactuar common/server entre sí en las pruebas de integración, además de algunos PoCs de explotación independientes (ver más abajo).
• security-audit/ — informes de rondas de revisión interna anteriores, los bugs que encontraron y los que ya se han corregido. Léelo antes de reportar algo: hay una probabilidad real de que ya esté aquí. REPORT.md es el principal; ADVERSARIAL_REVIEW_PAVEL.md es una pasada posterior y más limitada; fuzz/ y client/.../exploit/ contienen PoCs ejecutables, no solo descripciones.

Modelo de amenazas, versión corta

• El relé no es una parte de confianza. Enruta texto cifrado y datos del directorio (preclaves publicadas) y se asume que es activamente malicioso, no solo curioso — varios de los bugs corregidos en security-audit/ son exactamente "qué puede hacer un relé hostil".
• Las sesiones 1:1 buscan secreto hacia delante (X3DH) y seguridad post-compromiso (el DH-ratchet por encima). Las sesiones de grupo usan claves de remitente: un cambio de pertenencia renueva las claves de todo el grupo, pero una sola clave de remitente comprometida expone los mensajes de esa época — no hay un ratchet por mensaje en la capa de grupo (no es MLS/TreeKEM completo, un recorte de alcance deliberado, documentado en group/GroupCryptoSession.kt).
• El enrutamiento onion oculta el vínculo IP↔identidad de un relé que solo ve un salto, y rellena las tramas en buckets de tamaño fijo para que la correlación pasiva de tamaño entre saltos no desanonimice trivialmente un circuito. No oculta la correlación temporal de un adversario que observa ambos extremos a la vez — eso requeriría tráfico de cobertura / mezcla, que no está implementado. Esto se menciona explícitamente en security-audit/REPORT.md y ADVERSARIAL_REVIEW_PAVEL.md, no es algo que se esté ocultando.

Qué queremos que se revise específicamente

• La integración X3DH-lite ↔ Double Ratchet (common/src/main/kotlin/messenger/common/e2ee/) — es la única construcción criptográfica genuinamente hecha a medida de este proyecto; todo lo que hay por debajo es de catálogo. Se ha revisado internamente varias veces (ver security-audit/), pero nunca por alguien ajeno a este proyecto.
• El modelo de autorización del registro de control de grupo (common/src/main/kotlin/messenger/common/group/GroupControlLog.kt) — una cadena hash firmada del lado del cliente que el servidor no hace cumplir en absoluto.
• Cualquier cosa en la capa de enrutamiento onion que no esté ya cubierta por la advertencia documentada de correlación temporal anterior.

Ejecución

./gradlew test

Proyecto estándar de Gradle/Kotlin, JDK 17+. No se necesita acceso a la red ni servicios en ejecución para la suite de pruebas unitarias. security-audit/README.md tiene instrucciones para los PoCs de fuzzing en vivo del relé y de correlación onion, que sí requieren procesos locales en ejecución (nunca apuntes nada de esto a un host de producción).

Qué no es esto

No se ha realizado ninguna auditoría criptográfica independiente sobre esto. Todo lo que hay en security-audit/ es revisión interna de ingeniería — cuidadosa, pero es una auto-revisión, sin respaldo de pruebas formales ni trayectoria profesional/institucional detrás. Trátalo como un punto de partida para la revisión, no como una certificación.