Los nuevos DM cifrados de Twitter no son mejores que los anteriores

 (mjg59.dreamwidth.org)
2 puntos por GN⁺ 2025-06-07 | 1 comentarios | Compartir por WhatsApp
  • Los nuevos DM cifrados de Twitter(X) (XChat) afirman ofrecer cifrado de extremo a extremo a nivel técnico, pero siguen teniendo graves fallas de seguridad como robo de claves privadas, MITM y exposición de metadatos
  • Aunque incorporan Libsodium Box (cifrado basado en claves secretas), no ofrecen forward secrecy y usan una protección débil de claves basada en un PIN de 4 dígitos, por lo que extraer la clave privada es relativamente fácil
  • Usan el protocolo Juicebox para respaldo y recuperación de claves, pero la seguridad real depende por completo de la confianza en el backend, y como Twitter opera directamente todos los backends, el sharding casi no aporta nada
  • No existe un procedimiento fuera de banda para autenticar/verificar claves públicas, así que Twitter puede sustituir claves en un ataque MITM (man-in-the-middle), y los metadatos del usuario siguen expuestos
  • A diferencia de Signal, por ahora la protección real de la privacidad es insuficiente, por lo que se recomienda Signal como mensajero cifrado confiable

Análisis de los nuevos DM cifrados de Twitter

Contexto y resumen

  • Twitter(X) presentó su nueva plataforma de mensajería cifrada XChat, promocionada como desarrollada en Rust y con una estructura criptográfica al estilo Bitcoin
  • Pero al revisar la implementación real, Twitter sigue teniendo una arquitectura que le permite acceder a claves privadas, hacer MITM y recopilar metadatos
  • Conclusión: se recomienda usar Signal; los DM de Twitter(X) no son seguros por sus limitaciones estructurales

Estructura de cifrado y limitaciones

1. Método de cifrado

  • Usa box de Libsodium (cifrado de clave pública)
  • No soporta forward secrecy: si la clave privada se filtra, todos los mensajes anteriores pueden descifrarse (es decir, es más débil que mensajeros modernos como Signal)
  • La implementación real no usa Rust, sino una biblioteca en C enlazada mediante jni

2. Almacenamiento y recuperación de claves (protocolo Juicebox)

  • La clave privada generada en el dispositivo se guarda mediante el protocolo Juicebox
  • La clave se almacena tras cifrarse con un PIN de 4 dígitos, y para recuperarla hay que ingresar ese PIN
  • El servidor no conoce el PIN, pero como solo tiene 4 dígitos (10 mil combinaciones posibles), puede romperse rápidamente con fuerza bruta en paralelo
  • Incluso usando Argon2id con 16MB de memoria y 32 iteraciones, esto no supone un gran obstáculo para un atacante real (menos de 0.2 segundos incluso en una laptop de gama baja)

3. Limitaciones de la estructura de distribución de claves (sharding)

  • Juicebox soporta distribución entre múltiples backends (sharding), pero Twitter opera directamente los tres backends
  • En la práctica, la recuperación de claves depende por completo de confiar en Twitter, así que no existe el beneficio de seguridad fundamental del sharding
  • Tampoco hay procesos de verificación de hardware, como HSM o SGX, para comunicarse de forma segura con el backend

4. Vulnerabilidades en autenticación/intercambio de claves públicas

  • La clave pública de la otra persona solo se recibe a través de los servidores de Twitter, sin un método de verificación separado (fuera de banda)
  • Twitter puede entregar una clave pública arbitraria en cualquier momento y realizar un ataque MITM
  • La página oficial de soporte también reconoce esta debilidad y solo promete mejoras futuras, sin medidas concretas por ahora

5. Metadatos y otros problemas

  • Twitter puede conocer por completo metadatos como quién habla con quién y cuándo se intercambian mensajes
  • Aunque la clave privada no se exponga, los patrones de comunicación del usuario siguen quedando visibles para la empresa

Conclusión y recomendación

  • Debido a las limitaciones de diseño de estos DM cifrados, no alcanzan a mensajeros probados como Signal en seguridad real y privacidad
  • Mientras Twitter controle la clave pública, el almacén de claves y la ruta de comunicación, no puede considerarse verdadero cifrado de extremo a extremo
  • Se recomienda enfáticamente usar mensajeros con protocolos abiertos y transparentes como Signal

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-06-07
Comentarios de Hacker News

  • Soy fan de todo lo que escribe Matthew Garrett, pero quiero señalar de forma obsesiva que Signal siempre ha tenido soporte para forward secrecy desde hace mucho. El concepto moderno de mensajería segura nació casi con OTR (Borisov y Goldberg), que introdujo por primera vez las ideas de "perfect forward secrecy" y negación plausible. Signal me parece el resultado de desarrollar tanto esas ideas como su lado de ingeniería (mejor criptografía, mejor código, mejor empaquetado). Lo frustrante es que los mensajeros nuevos no están retrocediendo al nivel "pre-Signal", sino al nivel de seguridad previo a 2001, es decir, premoderno

    • Hay tres cosas que conviene recordar de varias filtraciones del pasado. (1) El FBI "obligó" en secreto a empresas a poner puertas traseras. También se mencionó que la corte FISA podía imponer multas devastadoras a una compañía. (2) A grandes empresas se les pagaron decenas o cientos de millones como costo de la puerta trasera. Además, hubo presión por distintas vías como contratos gubernamentales o licencias de exportación. En el fondo, puede interpretarse como una política de "plata o plomo". (3) En el caso judicial de Lavabit, el FBI exigió entregar las claves y, al mismo tiempo, prácticamente forzó a mentirles a los clientes. Al pensar en casos así, dan ganas de sospechar que el cifrado dentro de grandes plataformas a menudo se debilita deliberadamente por exigencias del gobierno, o se implementa de forma floja simplemente porque no les importa mucho. Hasta que desaparezcan leyes y prácticas relacionadas como el Patriot Act, la FISC, las interpretaciones secretas y hasta que se castigue a quienes las violen, parto de la idea de que el cifrado dentro de un Estado policial ya fue destruido por los Five Eyes

    • Mientras la gente siga instalando apps de PC desde el App Store, esta situación atrasada va a continuar

  • Si usa ephemeral key y no tiene forward secrecy ni historial de interacción, me pregunto qué tiene realmente de estilo "bitcoin"

    • Sí se usó criptografía, pero en general da la impresión de ser una derivación poco interesante y casi inútil

    • O sea, no tiene mucho valor práctico

    • Además, Bitcoin en sí tampoco es un canal de comunicación seguro

    • Está el punto de que usa derivación de claves basada en PIN. Pero eso se parece más a cómo se implementa un respaldo que a algo propio de la mensajería, así que cuesta verlo como una característica esencial

    • También se menciona que usa una función hash

  • Comparten enlace a una discusión anterior:
    El nuevo XChat "cifrado" de X-Twitter tampoco es mucho más seguro

    • En el comentario principal del enlace de arriba lo tratan con bastante profundidad técnica, y la conclusión puede resumirse así: "Como también lo dice la documentación de ayuda, no es forward secure, así que con la clave se puede descifrar todo. Ni siquiera está al nivel de poder llamarse una plataforma e2ee."
      Ver comentario relacionado

  • Pienso que, si de verdad se quiere cifrar, sería mejor usar software aparte e intercambiar las claves públicas en persona

  • Pregunta: pronto voy a visitar Beijing y quiero saber si se puede usar Twitter sin VPN

    • Algunas SIM de roaming a veces no quedan sujetas al Gran Firewall, pero en la mayoría de los casos se necesita VPN

  • Hay dudas sobre la expresión "Bitcoin style encryption". Mi impresión es que, en realidad, Bitcoin depende más de firmas criptográficas que de lo que normalmente entendemos como "encryption"

    • En la práctica, este término no significa nada; es solo una frase de marketing para sonar convincente ante gente que no conoce bien la tecnología

    • También conviene tener presente que la fuente de esa frase no parece ser alguien muy profundo en lo técnico

    • Se interpreta que usó ese término porque sabía que iba a generar ruido. Una elección estratégica para llamar más la atención

    • Comparten un video explicativo
      https://www.youtube.com/watch?v=sJNK4VKeoBM

    • Es solo una palabra de moda para que se vea cool y se sienta como si fuera algo “valioso”

  • Me pregunto si el verdadero XChat (el cliente IRC) podría demandar a X-Twitter por infracción de marca
    http://xchat.org/

    • Tengo recuerdos de cuando usaba IRC en la época en que se pasó de XChat a HexChat. Y aun así me sorprendió enterarme de que HexChat también dejó de desarrollarse
      Fin de HexChat

    • Probablemente sí podría, pero para que sea más fácil de sostener, XChat tendría que demostrar bien la comercialización en cada área donde X estaría infringiendo, y además tener la marca registrada en cada jurisdicción. Si no, sería más difícil, según esa opinión

  • Algo curioso de la librería que usa Twitter (según el artículo fuente) es que el propio desarrollador escribió en la descripción de la librería:
    “Advertencia: ¡Librería experimental! No la usen en producción hasta que sea revisada. Hay un alto riesgo de problemas y bugs”
    https://github.com/ionspin/kotlin-multiplatform-libsodium

    • En vez de innovación disruptiva, parece cifrado disruptivo

  • Impresiona que el poder de marca de Twitter siga siendo tan fuerte que, incluso después del rebranding, todavía no pierda vigencia

    • En una nota al pie, el autor explica en detalle por qué usó el nombre anterior