Una semana para arreglarlo y escándalo público: un hacker ético demuestra que el cifrado de extremo a extremo puede vulnerarse
Hace años que no se lanzaba un desafío tan audaz a la comunidad de expertos.
El autor del blog Soatok publicó un análisis de los problemas en Vodozemac —la biblioteca criptográfica en Rust que el ecosistema Matrix utiliza para el cifrado de extremo a extremo. El motivo fue una revisión de código tras anteriores objeciones a la antigua biblioteca Olm y disputas sobre cómo Matrix responde a los informes de vulnerabilidades.
Según el autor, el problema más grave está relacionado con que la implementación de Olm permite un caso en el que uno de los participantes entrega una clave pública "nula", correspondiente al elemento neutro en X25519. En ese escenario, los cálculos de Diffie–Hellman producen un secreto compartido predecible, y a partir de él se derivan de forma determinista las claves. Soatok afirma que, para los chats grupales privados, esto crea el riesgo de filtración del historial de conversaciones al operador del servidor o a cualquiera que tenga el texto cifrado, porque la clave de la sesión grupal se transmite al nuevo participante mediante Olm, y un apretón de manos débil permite extraer esa clave sin señales de error.
La segunda vulnerabilidad, según el autor, tiene que ver con la posibilidad de "rebajar" el modo de intercambio de mensajes de V2 a V1. En V2 la biblioteca debería usar un HMAC completo, mientras que V1 limita la etiqueta de autenticidad a 64 bits. Según la descripción de Soatok, la implementación por defecto se mantiene en V1, y un atacante activo puede provocar una transición inadvertida a la variante más débil, por ejemplo mediante el recorte de la etiqueta o por particularidades de la deserialización de datos con ajustes de versión.
Se enumeran aparte puntos discutibles y potencialmente peligrosos en el código. Entre ellos, un CheckCode de dos dígitos en ECIES con pocas variantes posibles, un IV determinista en el formato pickle al volver a usar la clave, el descarte silencioso de claves tras alcanzar un límite establecido, así como la verificación estricta de Ed25519 desactivada por defecto, lo que reduce la resistencia a modificaciones de la firma. Otro fragmento, relacionado con la desactivación de comprobaciones para compilaciones orientadas a fuzzing, fue aclarado más tarde por el autor: no se trata de un típico flag de función, sino de un modo que se activa de forma deliberada.
Soatok describió una cronología de divulgación de una semana, dijo haber entregado una demostración de ataque y el código de corrección, y criticó la postura del equipo de Matrix.org, que según él insistió en la ausencia de impacto práctico en la seguridad. En el texto también se mencionan comentarios públicos de Matthew Hodgson y la discusión sobre las comprobaciones del resultado "nulo" en X25519, incluida la referencia a los argumentos de Trevor Perrin, pero el autor subraya que el problema surge a nivel del protocolo y sus envoltorios, no del primitivo.