La trastienda del cifrado
--- Fecha: mar 10 mar 2026 19:24:52 CEST ---
NOTA: No es mi intención crear polémica con este artículo. Quizá esté equivocado, quizá no, solo quiero salir de los errores que yo mismo he cometido en todo lo que rodea al cifrado, por que no es tan simple como algunos piensan.
Cuando se habla de programas de criptografía, ya sea un gestor de contraseñas, aplicación de mensajería instantánea, o de cifrado, la gente suele decir que muchas de ellas han sido testeadas por expertos informáticos, hackers, etc. Defienden programas como GPG, Matrix, Tox o Session, y son programas bastante buenos, pero no cumplen lo que prometen, luego veremos por qué.
Muchos de estos programas aseguran que los datos de comunicación se mantienen únicamente en el dispositivo del usuario, que usan cifrado de extremo a extremo (E2EE), que no recopilan ni almacenan datos, que no tienen puertas traseras, y lanzan a los vientos aquel lema del marketing tecnológico del "cifrado militar", pero se "les olvida" mencionar la generación de Metadatos, porque entonces su marketing sobre la privacidad se les cae. Luego lo veremos más a fondo.
Estos programas, actualmente suelen usar cifrado AES, pero ojo, porque el cifrado AES tiene varias variantes (CBC, CCM, CTR, ECB, SIV) que no son seguras y están obsoletas muchas de ellas. Deberías huir de todo lo que no esté basado en AES-GCM de 256 bits, un estándar criptográfico moderno ampliamente utilizado.
NOTA: Aun así, cuidado, porque AES-GCM es mejor si tienes aceleración por hardware, tipo AES-NI de intel. Si no, es más lento, consume más recursos y filtra sus claves de cifrado en tiempo de caché.
Si además usan sistemas de curva elíptica del tipo Curve25519 para intercambio de claves X25519 o algoritmos poscuánticos como Kyber, ML-KEM o ML-DSA, aun mejor.
Por aquí os dejo una comparativa de varios algoritmos de cifrado. No están todos ni mucho menos, pero sí los más habituales:
Comparison of simmetric encryption methods
Errores que cometemos
Cometemos muchos errores a la hora de defender estos programas. No basta con decir que es seguro, hay que demostrarlo. Yo mismo he cometido estos errores, y por eso decidí informarme mejor, no en redes, no de "expertos" informáticos o de hackers que tienen empresas de ciberseguridad.
Y este es el primer error. Me he dado cuenta de que, por lo general, las empresas de ciberseguridad o la gente freelance que trabaja en ese ámbito, son muy buenos descubriendo vulnerabilidades en los propios programas, redes o a nivel básico en cuanto al cifrado, pero muchos andan cojos en cuanto a la criptografía porque no son ingenieros criptográficos, por muchos conocimientos que puedan tener.
Otro error es creer que por que usemos software libre o de código abierto, el código se puede auditar y mejorar, y es cierto, lo que pasa es que se repite otro mantra de “es de código abierto” como si eso borrara mágicamente cualquier responsabilidad del desarrollador hacia sus usuarios, cuando muchos desarrolladores no aplican correctamente las especificaciones, o no las actualizan como toca.
Si los desarrolladores de código abierto no están dispuestos a aceptar la responsabilidad que requiere la ingeniería de criptografía, no deberían publicar la criptografía en un formato que anime a otras personas a usarla.
Otro error muy común son las auditorías. Si un proveedor no tiene auditorías de los últimos 2 años, y encima su software ha cambiado mucho desde entonces, no confíes en él, especialmente si su informe de auditoría es de un proveedor de seguridad sin nombre y afirma que el producto del proveedor es perfecto.
También es muy común pensar que cuantos más algoritmos modernos se usen o más larga sea la clave, mejor, y no, el tamaño de la clave no lo es todo.
Más clave no significa más seguridad. El cifrado por bloques, como AES-GCM, usa claves de 256 bits y cifra bloques de 128 bits, en cambio, otras opciones, como Blowfish, usan claves más largas (448 bits) pero el cifrado de bloques es de 64 bits.
Mejores algoritmos tampoco es una solución fiable si luego no se aplican correctamente y generan fugas.
Y además, hay que tener en cuenta que un buen cifrado no solo proporciona confidencialidad al cifrar el mensaje, sino que también debe proporcionar integridad, lo que garantiza que nadie haya manipulado el mensaje cifrado, y además, autenticidad, para saber que quien lo envía es realmente a quien pertenece
Metadatos
De qué sirve que un sistema tenga un buen cifrado si el flujo de metadatos que genera deja un rastro visible a 200 kms.
Muchos de los programas, sobre todo los de mensajería, no exigen número de teléfono, email ni ningún otro dato, pero en cambio, genera una serie de datos únicos como dirección IP, ID de usuario, horarios de conexión y tiempos, hardware del equipo, versiones, etc, que echa por tierra la privacidad.
Como dijo hace años el MI6, "no seguiremos intentando violar los algoritmos de cifrado, no nos hace falta saber qué dice el mensaje"
Cuanto menos metadatos se generen, más privada se podrá considerar el programa. Contrastalo con lo que dice su marketing.
LO QUE HAY DETRAS DEL CIFRADO
El cifrado siempre ha sido una manera de proteger de miradas ajenas nuestros secretos. Desde la cifra Cesar hasta los algoritmos de curva elíptica, el cifrado ha tenido dos objetivos: cifrar y ser robusto.
Pero como yo siempre digo, todo lo que se hace se puede deshacer, y así es. Existen mentes brillantes que son capaces de descifrar mensajes cifrados con los mejores algoritmos, y vienen con mucha fuerza. Si los desarrolladores no son capaces de plantar cara, estamos perdidos.
Servicios "caseros"
Cada desarrollador cree que la criptografía es fácil, y usan modelos propios basados en otros.
Los modelos de amenazas contra el cifrado son muy variados. El más habitual es contra los intercambios de claves autenticadas (AKE - Authenticated Key Exchange), aunque existen otros modelos habitualmente utilizados, como los ataques de colisión.
Es por esto que no se recomienda usar sistemas "caseros" o propios. Si realmente queremos las máximas garantías, evita el uso de estos sistemas y usa algo diseñado por un experto con muchas batallas a sus espaldas, no reinventes la rueda.
La mayoría de ingenieros criptográficos que trabajan en esto a tiempo completo cortocircuitan con todo esto, aconsejan no usar tu propia criptografía si vas a cometer errores embarazosos, ser negligente con la seguridad de los usuarios o simplemente descartar los problemas de criptografía que se te informen.
Irresponsabilidad
Por desgracia y en el mejor de los casos, muchos desarrolladores soberbios te responden con el mantra: "El impacto real está fuera de nuestro modelo de amenazas", que viene siendo, traducido, "nuestro programa está pensado para cositas menos exigentes para los que no somos objetivo de ciertos ataques", aunque no sea verdad.
Muchos desarrolladores de software de criptografía están descuidando el deber de cuidado que tienen para sus usuarios. Cuando se enfrenta a investigaciones sobre nuevas estrategias de ataque, el viejo y confiable “esto está fuera de nuestro modelo de amenaza” es invocado por el vendedor, con documentos formales de modelos de amenazas a menudo vagos, mal especificados, desactualizados y tontamente considerados.
Este es el pecado original de la mayoría del software de criptografía: no comenzaron con una especificación, y nunca tuvieron un modelo claro de las amenazas que están mitigando y cuáles están eligiendo no mitigar.
Muchos dicen “Ciframos los datos en SQL y asumimos que son confidenciales” y esto no es suficiente, desconfía.
En cambio, otros dicen “Ciframos los datos en SQL, utilizando claves por cliente en un modo de cifrado AEAD, y vinculamos el contexto al AAD para garantizar la confidencialidad y la integridad", y esto está mucho mejor.
El caso de los nonces es un ejemplo. Los meten para todo, por ejemplo para las funciones hash, donde el vector de inicialización es una constante que nunca cambia, pero para los cifrados de bloque, siempre debe cambiar y ser aleatorio, y el software no siempre está desarrollado con esto en mente; un nonce siempre está destinado a ser utilizado una vez, y nunca reutilizado. Los nonces y los IV pueden ser públicos, pero en cambio los ECDSA tienen que ser secretos y no se debe repetir.
Confianza
Para que la criptografía funcione tiene que haber confianza en primer lugar.
Un grupo de investigadores de criptografía publicó recientemente un artículo titulado Zero Knowledge (About) Encryption, que profundiza en la seguridad de varios administradores de contraseñas basados en la nube. Presentarán su artículo en Real World Cryptography 2026.
Comienza señalando lo vagos que son los modelos de amenaza publicados para estos productos, y luego hace un argumento razonable de que sus clientes probablemente crean que proporciona propiedades de seguridad específicas que son importantes para ellos. Luego pasa a eviscerar la seguridad de LastPass, Bitwarden y Dashlane
Evangelización
Mucha gente no experta, confundida por esos "gurús" que todo lo saben, confiarán ciegamente en algún software e intentarán hacer que los demás lo usen, y en parte se puede llegar a entender. Tú, camarera, reponedor de supermercado o zapatero, no tienes conocimientos técnicos suficientes. Pero quien sí los tiene (o cree tenerlos), tienen mayor culpa por no exigirse más en cuanto al software y evangelizar a otras personas con programas que quizá no son lo que prometen.
Parece que mucha gente usa criptografía insegura porque los criptógrafos y los ingenieros de seguridad no les proporcionaron alternativas seguras para empezar. Pero cuando se trata de algún software, la gente hablará sobre los expertos reales para evangelizar su aplicación favorita.
Algunos programas que no cumplen
Algunos de los programas que todo el mundo da por sentado que son lo que dicen ser realmente no ofrecen la privacidad, incluso el anónimato que prometen. Además, algunos de ellos se han mostrado soberbios al ser alertados de sus problemas de seguridad.
Session/Tox
Los desarrolladores de Session, un buen día decidieron eliminar el "forward secrecy", que es una importante propiedad de seguridad de los protocolos criptográficos que heredaron de forma gratuita de las librerias de Signal.
Por lo tanto, su programa se coloca en el ámbito de los ataques de imitación de compromiso de clave (KCI) o el método "Rho de Pollard” para realizar ataques de colisión contra cualquier función aleatoria, que las aplicaciones de cifrado de extremo a extremo deben prevenir si quieren cumplir lo que prometen y estar a la altura.
Tienen una insuficiente entropía en claves Ed25519 claves. Usan Ed25519 de 128 bits en lugar de X25519 de 253 bits.
Y lo mismo que ocurre con Tox, cuyo handshake es vulnerable a KCI con la suplantación de compromiso de claves.
Después de todo, eliminar importantes propiedades de seguridad de un protocolo de seguridad criptográfica es exactamente el tipo de cosas que haría un gobierno malicioso.
Matrix
Hace unos años, el ingeniero de criptografía aplicada Soatok descubrió que la biblioteca Olm de Matrix tenía varias vulnerabilidades de canal lateral. Después de arrastrar sus pies durante 90 días, terminaron sin molestarse en arreglar nada de eso.
Haciendo un ataque de hombre de paja, el equipo de Matrix hizo una publicación intentando demostrar una falta crítica de comprensión, y se quedaron tan anchos con el mantra "el impacto real está fuera de nuestro modelo de amenazas."
Empezó una desaprobación y desprecio, y cuando se hizo público, insistieron en que sabían sobre los ataques de canal lateral desde el principio.
A sabiendas, enviar criptografía vulnerable a millones de personas que insisten felizmente en que su producto es mejor que Signal es un nivel de irresponsabilidad que raya en el deslumbramiento.
Más tarde, las vulnerabilidades volvieron a libolm y vodozemac, con dos vulnerabilidades bastante graves:
1. Olm Diffie-Hellman acepta el elemento de identidad
2. Ataques de degradación de V2 a V1
El BSI de Alemania financió otra auditoría en 2023. La publicación del blog element.io en ese momento también aludía a una vulnerabilidad aún no publicada, CVE-2023-49953.
Si quieres más información al respecto y pruebas de concepto, te dejo estos enlaces:
Security issues in Matrix Olm library
Cryptographic issues in Matrix rust library vodozemac
GPG
Mi amado GPG, del que desconocía el gpgfail y la controversia que trajo consigo. Además, los criptógrafos profesionales no lo aconsejan.
Yo mismo he conseguido crear una colisión siguiendo varias instrucciones que hay por las webs, como este:
Practical collision attack in PGP
Desaconsejan su uso en general, pero sobre todo para el cifrado del correo.
Everything you need to know about email encryption in 2026
Telegram
¿Qué decir de Telegram? Sin cifrado, solo para grupos con su propio cifrado MTproto. Mejor no lo uses, su autenticación es deficiente y se niegan a implementar un cifrado realmente seguro.
Telegram cryptanalysis contest
Conclusión
Como ves, se instala entre la gente un argumento de marketing por encima de los argumentos reales del cifrado.
De todo esto he aprendido a dejar de confiar, a no dar nada por sentado, a no prestar demasiada atención a comentarios de gente defendiendo algo que realmente no conoce. Ahora soy más cauto, leo a los que sí saben y aun así, lo cojo todo con pinzas.
Si te interesa todo este tema, recomiendo leer a Filippo Valsorda, Matthew Green, Jason A. Donenfeld y Soatok, y visitar las siguientes webs:
https://blog.cryptographyengineering.com/
Tag: #cifrado #encriptado #matrix #session #tox #gpg #aes
/gemlog/