El cifrado explicado: de AES a la criptografía poscuántica y la mensajería de extremo a extremo

Cada mensaje que envías, cada pago que haces y cada contraseña que tecleas dependen del cifrado. Es la capa invisible que mantiene privada la vida digital, y está integrada en prácticamente todas las aplicaciones de las que depende tu negocio. Este artículo explica cómo distintos tipos de cifrado protegen aplicaciones reales, por qué tecnologías emergentes como las curvas elípticas y los algoritmos poscuánticos importan para tus productos, y qué nos dice la reciente decisión de Instagram de retirar el cifrado de extremo a extremo sobre la tensión entre privacidad y regulación.

Qué hace realmente el cifrado

El cifrado transforma datos legibles (texto plano) en una forma ilegible (texto cifrado) usando un valor secreto llamado clave. Solo quien posee la clave correcta puede revertir el proceso y recuperar los datos originales.

Dos propiedades son las que más importan:

• Confidencialidad: un atacante que intercepte el texto cifrado no aprende nada del texto plano.
• Integridad: los esquemas modernos de cifrado además detectan si el texto cifrado fue manipulado en tránsito.

Todo cifrado práctico cae en una de dos familias: simétrico y asimétrico. Los sistemas reales los usan juntos, y entender por qué te ayuda a tomar decisiones informadas sobre las aplicaciones que construyes o usas.

Cifrado simétrico: el caballo de batalla de la protección de datos

En el cifrado simétrico se usa la misma clave para cifrar y descifrar. Piénsalo como una caja fuerte con una sola combinación: cualquiera que conozca la combinación puede abrirla, y mantener esa combinación en secreto es lo que mantiene seguro el contenido.

Dónde te lo encuentras cada día

AES (Advanced Encryption Standard) es el cifrador simétrico más usado del mundo. Adoptado por el NIST en 2001, admite longitudes de clave de 128, 192 o 256 bits y cuenta con aceleración por hardware en prácticamente todos los procesadores modernos.

Aquí es donde AES protege tus datos en la práctica:

• Almacenamiento en la nube. Cuando subes archivos a AWS S3, Google Cloud Storage o Azure Blob Storage, se cifran en reposo con AES-256. Aunque alguien consiga acceso físico al hardware de almacenamiento, los datos son ilegibles sin la clave.
• Cifrado de bases de datos. PostgreSQL, MongoDB y MySQL ofrecen cifrado basado en AES para proteger los datos en disco. Eso significa que una copia de seguridad robada no sirve de nada sin las claves de cifrado.
• HTTPS / TLS. Cada vez que tu navegador muestra un candado, AES está haciendo el trabajo pesado. TLS 1.3 usa AES-GCM (Galois/Counter Mode) como cifrador principal: cifra los datos y verifica su integridad a la vez, protegiendo desde las credenciales de inicio de sesión hasta las llamadas a la API.
• Aplicaciones móviles. Tanto el cifrado basado en archivos de Android como la Protección de Datos de Apple usan AES-256 para cifrar los datos del dispositivo. Cuando un usuario bloquea el móvil, las claves de cifrado se expulsan de memoria y los datos almacenados quedan inaccesibles.
• Procesamiento de pagos. PCI DSS —el estándar de seguridad para manejar datos de tarjeta— exige cifrado AES para los datos del titular tanto en tránsito como en reposo.

ChaCha20-Poly1305 es otro cifrador simétrico que gana adopción. Es más rápido que AES en dispositivos sin aceleración AES por hardware, en particular móviles antiguos y dispositivos IoT. Google lo eligió para las conexiones TLS en Android, y es el cifrador por defecto de la VPN WireGuard.

Pruébalo tú: cifrado AES en tu terminal

No necesitas software especial: OpenSSL viene preinstalado en macOS, Linux y la mayoría de los entornos de servidor. Abre una terminal y prueba estos comandos.

Cifra un mensaje con AES-256:

echo "I want to secure my app with AES" | openssl enc -aes-256-cbc -a -salt -pass pass:nerdy_pro

La salida será un bloque de texto Base64 de aspecto aleatorio: tu texto cifrado. Para descifrarlo, coge esa salida y ejecuta:

echo "U2FsdGVkX181dnX8SWIhZTumWK0Uc7Kh947omVSNpH8lujB43L5OjlubfkGa3Y1dyxj5cfzyPZjhWiyGzIWdPw==" | openssl enc -aes-256-cbc -a -d -salt -pass pass:nerdy_pro

Recuperarás tu mensaje original. OpenSSL puede mostrar un aviso: *** WARNING : deprecated key derivation used.; es esperable. Significa que OpenSSL recurre a un método de derivación de claves más antiguo cuando se usa -pass pass:. En producción usarías -pbkdf2 para una derivación más fuerte, pero para esta demostración el valor por defecto sirve.

Ahora prueba a cambiar un solo carácter de la contraseña y descifrar otra vez: fallará. Eso demuestra la propiedad central del cifrado simétrico: sin la clave exacta, los datos son irrecuperables.

También puedes cifrar archivos enteros:

# Encrypt
openssl enc -aes-256-cbc -salt -in report.pdf -out report.pdf.enc -pass pass:nerdy_pro

# Decrypt
openssl enc -aes-256-cbc -d -in report.pdf.enc -out report-decrypted.pdf -pass pass:nerdy_pro

El problema de la distribución de claves

El cifrado simétrico es rápido y eficiente, pero ambas partes tienen que compartir la misma clave secreta antes de poder comunicarse. Si tu aplicación atiende a un millón de usuarios, no puedes precompartir un millón de claves distintas de forma segura. Ese es el problema que resuelve la criptografía asimétrica.

Cifrado asimétrico: confianza entre desconocidos

El cifrado asimétrico usa un par de claves: una clave pública que puede compartirse abiertamente y una clave privada que debe permanecer secreta. Los datos cifrados con la clave pública solo pueden descifrarse con la clave privada correspondiente.

RSA: el cimiento de la seguridad en internet

RSA, publicado en 1977, fue el primer criptosistema de clave pública práctico. Su seguridad descansa en la dificultad de factorizar el producto de dos números primos muy grandes: un problema fácil de plantear y prácticamente imposible de revertir con la tecnología actual.

Así es como RSA mueve aplicaciones reales:

• Certificados SSL/TLS. Cuando visitas un sitio por HTTPS, el servidor presenta un certificado firmado con RSA (o ECC). Tu navegador verifica esa firma para confirmar que hablas con el servidor real y no con un impostor. Autoridades de certificación como Let's Encrypt emiten millones de certificados firmados con RSA.
• Firma de código. Cuando descargas una app de la App Store de Apple o instalas una aplicación de Windows con firma digital, las firmas RSA verifican que el código no se ha manipulado desde que el desarrollador lo publicó.
• Cifrado de correo. PGP/GPG y S/MIME usan RSA para cifrar correos y firmarlos, garantizando privacidad y autenticidad del remitente.
• Acceso SSH. Los administradores de sistemas usan pares de claves RSA para acceder a servidores sin contraseña: ssh-keygen -t rsa es uno de los comandos más comunes de cualquier flujo de DevOps.

Pruébalo tú: cifrado RSA en tu terminal

Genera un par de claves RSA:

# Generate a 2048-bit private key
openssl genrsa -out private.pem 2048

# Extract the public key
openssl rsa -in private.pem -pubout -out public.pem

Ahora cifra un mensaje con la clave pública y descífralo con la privada:

# Encrypt — anyone with your public key can do this
echo "I want to secure my app with RSA" | openssl pkeyutl -encrypt -pubin -inkey public.pem -out message.enc

# Decrypt — only the private key holder can do this
openssl pkeyutl -decrypt -inkey private.pem -in message.enc

Esta es la idea central: tu socio comercial cifra los datos con tu clave pública, envía el texto cifrado por cualquier canal (incluso correo) y solo tú puedes leerlo. Sin la clave privada, el archivo cifrado no sirve de nada.

El enfoque híbrido

En la práctica, el cifrado asimétrico es demasiado lento para cifrar grandes cantidades de datos. En su lugar, los sistemas reales usan un enfoque híbrido: RSA (o ECC) intercambia de forma segura una clave simétrica de un solo uso, y después AES se encarga del grueso del cifrado a alta velocidad. Así es exactamente como funcionan TLS, SSH y PGP por dentro.

Criptografía de curva elíptica: más seguridad, claves más pequeñas

La criptografía de curva elíptica (ECC) alcanza el mismo nivel de seguridad que RSA con claves drásticamente más pequeñas. Eso se traduce directamente en conexiones más rápidas, certificados más pequeños, menos ancho de banda y mejor rendimiento en dispositivos móviles e IoT.

La diferencia práctica

Una clave ECC de 256 bits ofrece la misma protección que una RSA de 3072 bits: una reducción de 12× en tamaño de clave. Para aplicaciones que manejan miles de conexiones por segundo o funcionan con batería, esa diferencia es significativa.

Dónde se usa ECC hoy

• TLS 1.3. La última versión de TLS usa exclusivamente intercambio de claves basado en ECC (ECDHE). El intercambio de claves con RSA se ha eliminado por completo. Toda conexión HTTPS moderna que haces usa curvas elípticas.
• Signal y WhatsApp. El protocolo Signal usa Curve25519 —una curva elíptica concreta diseñada para alto rendimiento y resistencia a errores de implementación— para su intercambio de claves. Es el mismo protocolo que protege los mensajes de más de dos mil millones de usuarios de WhatsApp.
• VPN WireGuard. WireGuard usa Curve25519 para todos los intercambios de claves, lo que contribuye a su reputación de VPN más simple y rápida frente a OpenVPN o IPsec.
• Claves SSH. Ed25519 —un esquema de firma de curva elíptica— se ha convertido en el tipo de clave recomendado para SSH. Produce claves más cortas y firmas más rápidas que RSA: ssh-keygen -t ed25519 genera una clave a la vez más segura y más cómoda que el antiguo RSA por defecto.
• Criptomonedas. Bitcoin y Ethereum usan la curva elíptica secp256k1 para firmar cada transacción. Cuando envías criptomoneda, una firma ECC demuestra que eres dueño del monedero sin revelar tu clave privada.
• Inicio de sesión de Apple y Google. Iniciar sesión con Apple usa ECC (P-256) para sus tokens de identidad. El Cloud KMS de Google admite claves ECC para firmar y verificar.

Pruébalo tú: claves ECC en tu terminal

Genera un par de claves de curva elíptica y compáralo con RSA:

# Generate an ECC private key (Curve P-256)
openssl ecparam -genkey -name prime256v1 -noout -out ec-private.pem

# Extract the public key
openssl ec -in ec-private.pem -pubout -out ec-public.pem

# Compare file sizes — ECC keys are dramatically smaller
wc -c private.pem ec-private.pem

Verás que la clave privada ECC es unas 4-5 veces más pequeña que la de RSA, ofreciendo una seguridad equivalente. En un servidor que maneja miles de handshakes TLS por segundo, esa diferencia se acumula rápido.

Firmas digitales y sumas de verificación: demostrar autenticidad e integridad

El cifrado mantiene los datos secretos, pero quedan dos preguntas igual de importantes: ¿quién envió estos datos? y ¿se modificaron en tránsito? Las firmas digitales y las sumas de verificación responden a eso, y son tan fundamentales para la seguridad de una aplicación como el propio cifrado.

Sumas de verificación y CRC: detectar corrupción accidental

Una suma de verificación es un valor corto calculado a partir de un bloque de datos. Si cambia aunque sea un bit de los datos, la suma también cambia. La forma más simple es el CRC (comprobación de redundancia cíclica): un algoritmo rápido diseñado para detectar errores accidentales durante la transferencia o el almacenamiento.

Usas CRC más a menudo de lo que crees:

• Descargas de archivos. Cuando descargas una ISO de Linux o un paquete de software, el sitio suele listar una suma SHA-256 o MD5. Calculas la suma de tu archivo descargado y la comparas: si coinciden, el archivo llegó intacto.
• Protocolos de red. Las tramas Ethernet, los paquetes TCP y los archivos ZIP incluyen sumas CRC para detectar corrupción durante la transmisión.
• Replicación de bases de datos. Sistemas como PostgreSQL usan sumas de verificación para detectar corrupción en disco antes de que se propague a las réplicas.
• Git. Cada commit, archivo y árbol de un repositorio Git se identifica con un hash SHA-1. Por eso Git puede detectar cualquier modificación del historial.

Pruébalo en tu terminal:

# Create a file and compute its SHA-256 checksum
echo "I want to secure my app with checksums" > document.txt
shasum -a 256 document.txt

# Modify even one character and the checksum changes completely
echo "I want to secure my app with Checksums" > document.txt
shasum -a 256 document.txt

Las dos sumas serán completamente distintas: no ligeramente distintas, sino irreconocibles la una de la otra. Esta propiedad se llama efecto avalancha, y es lo que hace fiables las sumas de verificación para detectar cambios.

Distinción importante: los CRC y las sumas simples detectan corrupción accidental; no protegen frente a manipulación intencionada. Un atacante que modifique un archivo puede simplemente recalcular la suma. Para defenderse de una modificación deliberada necesitas firmas criptográficas.

Firmas digitales: demostrar quién envió los datos

Una firma digital usa la criptografía asimétrica al revés: en lugar de cifrar con la clave pública y descifrar con la privada, el remitente firma un mensaje con su clave privada, y cualquiera con la clave pública puede verificar la firma.

Eso te da dos garantías:

• Autenticación: el mensaje lo creó quien posee la clave privada y nadie más.
• Integridad: el mensaje no se alteró después de firmarlo.

Las firmas digitales están por todas partes en los sistemas de producción:

• Actualizaciones de software. Cuando tu móvil instala una actualización de iOS o Android, el sistema verifica la firma digital de Apple o de Google antes de aplicarla. Una actualización modificada sin firma válida se rechaza: es la defensa principal contra firmware malicioso.
• Autenticación de APIs. Los JWT (JSON Web Tokens) usados para autenticar APIs van firmados digitalmente. Cuando tu backend recibe un JWT, verifica la firma para confirmar que lo emitió tu servidor de autenticación y que no se ha manipulado.
• Gestores de paquetes. npm, PyPI, Docker Hub y APT usan firmas para verificar que los paquetes los publicaron los autores que dicen ser. Los ataques a la cadena de suministro —como el famoso incidente de event-stream— explotan huecos en esa verificación.
• Transacciones en blockchain. Cada transacción de Bitcoin o Ethereum se firma con la clave privada del emisor. La red verifica la firma antes de aceptar la transacción: así funcionan las criptomonedas sin una autoridad central.
• Firma de documentos. Los PDF, contratos y facturas pueden llevar firmas digitales que prueban la autoría y detectan modificaciones, reconocidas como legalmente vinculantes en la mayoría de las jurisdicciones bajo eIDAS (UE) y ESIGN (EE. UU.).

Prueba a firmar y verificar un mensaje tú mismo:

# Create a document
echo "I want to secure my app with digital signatures" > message.txt

# Sign it with your RSA private key (from the earlier example)
openssl dgst -sha256 -sign private.pem -out message.sig message.txt

# Verify the signature with the public key
openssl dgst -sha256 -verify public.pem -signature message.sig message.txt
# Output: Verified OK

# Now tamper with the file and verify again
echo "I want to secure my app with Digital Signatures" > message.txt
openssl dgst -sha256 -verify public.pem -signature message.sig message.txt
# Output: Verification Failure

El mensaje manipulado falla la verificación: la firma demuestra tanto quién creó el documento como que no se ha modificado. Es el mismo mecanismo que protege cada certificado HTTPS, cada commit de Git firmado y cada app que instalas desde una tienda.

HMAC: firmas para sistemas simétricos

Cuando ambas partes comparten una clave secreta (como en muchas integraciones de API), el HMAC (código de autenticación de mensajes basado en hash) aporta integridad y autenticación sin la sobrecarga de la criptografía de clave pública. Stripe, AWS y GitHub usan HMAC para firmar las cargas de sus webhooks para que tu servidor pueda verificar que son genuinas:

# Compute an HMAC-SHA256 of a message
echo -n "I want to secure my app with HMAC" | openssl dgst -sha256 -hmac "nerdy_pro"

Tu servidor calcula el mismo HMAC con su copia del secreto compartido y lo compara con la firma de la cabecera de la petición. Si coinciden, el webhook es auténtico.

JWT: las firmas en la práctica

Los JSON Web Tokens (JWT) son una de las aplicaciones reales más comunes de las firmas digitales. Si tu aplicación tiene autenticación de usuarios, hay bastantes probabilidades de que haya JWT de por medio. Un JWT es un token compacto y seguro para URL con tres partes separadas por puntos: cabecera, carga útil y firma.

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0Miwicm9sZSI6Im5lcmR5X2FkbWluIn0.oAi5ALawUM_KpWDkiJcfA8504oQ_Yjx7OhEM8nZxlIc

La cabecera especifica el algoritmo de firma. La carga útil lleva los datos reales: ID de usuario, rol, momento de expiración. La firma garantiza que ninguna de las dos se ha manipulado. Tu servidor verifica la firma en cada petición y solo confía en la carga útil si la verificación pasa.

Prueba a decodificar este token tú mismo: pégalo en jwt.io y mira qué hay dentro. Notarás que puedes leer la carga útil sin conocer el secreto. Es así por diseño: los JWT están firmados, no cifrados. La firma solo demuestra que el token no se ha manipulado; no oculta el contenido.

Los algoritmos de firma determinan el modelo de seguridad:

• HS256 (HMAC-SHA256): simétrico. La misma clave secreta firma y verifica el token. Sencillo de montar, pero cada servicio que necesite verificar tokens tiene que tener el secreto, lo que se convierte en un riesgo según crece tu arquitectura.
• RS256 (RSA-SHA256): asimétrico. El servidor de autenticación firma con una clave privada y cualquier servicio verifica con la pública. La clave pública puede distribuirse libremente sin comprometer la seguridad.
• ES256 (ECDSA-P256): asimétrico, con curvas elípticas. El mismo modelo de confianza que RS256, pero con claves más pequeñas y firmas más rápidas. Cada vez más la opción recomendada para aplicaciones nuevas.

Ventajas de los JWT:

• Autenticación sin estado. El servidor no necesita consultar una base de datos ni un almacén de sesiones en cada petición: el propio token contiene toda la información necesaria para autorizar al usuario. Eso simplifica escalar horizontalmente entre varios servidores.
• Confianza entre servicios. En arquitecturas de microservicios, el servicio de autenticación firma el token una vez y cada servicio posterior puede verificarlo de forma independiente con la clave pública. Sin base de datos compartida ni llamadas de red.
• Estándar y portable. Los JWT son un estándar abierto (RFC 7519) con librerías en todos los lenguajes importantes. Los tokens pueden pasarse en cabeceras HTTP, parámetros de URL o cookies.

Trampas a vigilar:

• Los tokens no se pueden revocar. Una vez firmado un JWT, es válido hasta que expira. Si se compromete la cuenta de un usuario, no puedes invalidar sus tokens existentes sin añadir una lista de bloqueo en servidor, lo que anula en parte el beneficio de no tener estado. Tiempos de expiración cortos (15 minutos) combinados con tokens de refresco lo mitigan.
• La carga útil no está cifrada. La carga codificada en Base64 está firmada pero no cifrada: cualquiera que intercepte el token puede leer su contenido. Nunca pongas datos sensibles (contraseñas, información personal, claves de API) en la carga de un JWT. Si necesitas un token cifrado, usa JWE (JSON Web Encryption), aunque añade complejidad.
• Ataques de confusión de algoritmo. Si el servidor acepta varios algoritmos y no valida estrictamente la cabecera alg, un atacante puede falsificar tokens; por ejemplo, cambiando de RS256 a HS256 y firmando con la clave pública como secreto HMAC. Impón siempre el algoritmo esperado en el servidor.
• Tokens sobredimensionados. A veces los desarrolladores meten demasiados datos en la carga: perfiles de usuario completos, listas de permisos, estado de sesión. Los JWT se envían en cada petición, normalmente en una cabecera HTTP. Los tokens grandes aumentan el ancho de banda, pueden superar los límites de tamaño de cabecera y ralentizan todas las llamadas a la API. Mantén cargas mínimas: ID de usuario, rol, expiración.

Para la mayoría de las aplicaciones, JWT con firma ES256 y tiempos de expiración cortos dan un buen equilibrio de seguridad, rendimiento y simplicidad. Si necesitas revocación, combínalos con una comprobación ligera en servidor contra una lista de revocación o usa tokens de refresco opacos que puedan invalidarse por separado.

La amenaza cuántica: un riesgo real que exige preparación ya

Los ordenadores cuánticos usan una física fundamentalmente distinta —cúbits que pueden existir en varios estados a la vez— para resolver ciertos problemas exponencialmente más rápido que cualquier ordenador clásico. Para el cifrado, eso tiene consecuencias concretas y bien entendidas.

Qué romperán los ordenadores cuánticos

En 1994, Peter Shor publicó un algoritmo cuántico que demostraba que un ordenador cuántico suficientemente potente podría romper RSA, ECC y Diffie-Hellman, es decir, prácticamente todos los algoritmos asimétricos en uso hoy. No es especulación teórica: es un resultado matemático demostrado. La única pregunta abierta es cuándo el hardware cuántico será lo bastante potente para ejecutarlo a escala.

Los cifradores simétricos como AES se ven afectados con menos gravedad. El algoritmo de Grover reduce a la mitad, en la práctica, la seguridad de las claves simétricas, lo que deja AES-128 insuficiente pero mantiene AES-256 con un margen cómodo de 128 bits.

«Cosechar ahora, descifrar después»

Esta es la amenaza que hace de la computación cuántica una preocupación urgente hoy y no en un futuro lejano. Agencias de inteligencia y atacantes sofisticados ya están interceptando y almacenando tráfico cifrado con el plan de descifrarlo cuando madure el hardware cuántico. Esta estrategia está bien documentada en las recomendaciones poscuánticas de ciberseguridad de la NSA.

Para cualquier aplicación que maneje datos con una vida útil larga de confidencialidad —historiales médicos, datos financieros, comunicaciones legales, propiedad intelectual— este es un riesgo presente, no hipotético.

Criptografía poscuántica: la respuesta del sector

En 2024, el NIST finalizó sus primeros estándares criptográficos poscuánticos:

• ML-KEM (CRYSTALS-Kyber): un mecanismo de intercambio de claves que sustituye a ECDH. Ya desplegado en producción: Chrome y Cloudflare usan por defecto un intercambio híbrido X25519 + ML-KEM.
• ML-DSA (CRYSTALS-Dilithium): un esquema de firma digital que sustituye a las firmas RSA y ECDSA.
• SLH-DSA (SPHINCS+): un esquema de firma de respaldo basado en funciones hash, que aporta diversidad algorítmica por si los esquemas basados en retículos resultan vulnerables.

Qué significa esto para tus aplicaciones

Si estás construyendo o manteniendo aplicaciones hoy, esto es lo que importa:

1. Pásate a AES-256. Es el paso más simple y ofrece cifrado simétrico resistente a lo cuántico prácticamente sin coste de rendimiento.
2. Activa el intercambio híbrido de claves. Las librerías TLS modernas (OpenSSL 3.x, BoringSSL) ya soportan X25519 + ML-KEM. Activarlo protege las conexiones frente a ataques clásicos y cuánticos.
3. Audita tus dependencias criptográficas. Ten claro dónde se usan RSA y ECC en tu stack: son los componentes que acabarán necesitando migración. Si tu aplicación se construyó rápido o con herramientas de programación con IA, una auditoría de código generado por IA es la forma más rápida de encontrar dónde se esconden los secretos y la criptografía débil.
4. Planifica para claves y firmas más grandes. Los algoritmos poscuánticos producen claves mayores que ECC. Comprueba que tus protocolos, certificados y almacenamiento puedan acomodarlas.

Cifrado de extremo a extremo: el estándar de oro de la mensajería privada

El cifrado de extremo a extremo (E2EE) significa que los mensajes se cifran en el dispositivo del remitente y solo pueden descifrarse en el del destinatario. El proveedor del servicio —sea una app de mensajería, una plataforma de correo o un almacenamiento en la nube— no puede leer el contenido, ni siquiera obligado por una orden judicial o comprometido por un atacante.

Cómo funciona el E2EE moderno en la práctica

El protocolo Signal, usado por Signal y WhatsApp, combina varias técnicas de cifrado en un sistema por capas:

1. Intercambio de claves de curva elíptica (Curve25519): dos dispositivos establecen un secreto compartido sin transmitirlo nunca por la red.
2. El algoritmo Double Ratchet: genera una clave de cifrado nueva para cada mensaje. Si un atacante obtiene de algún modo una clave, no puede descifrar mensajes pasados ni futuros. Esta propiedad se llama confidencialidad hacia adelante.
3. AES-256 o ChaCha20: cifra el contenido real del mensaje a alta velocidad.
4. Autenticación HMAC: garantiza que los mensajes no puedan manipularse en tránsito.

El resultado es que cada mensaje tiene una clave única, las claves nunca se reutilizan y el compromiso de cualquier clave individual queda contenido. Por eso los investigadores de seguridad recomiendan de forma consistente el protocolo Signal como el estado del arte en seguridad de mensajería.

El reto de la mensajería de grupo

El E2EE en conversaciones uno a uno es un problema resuelto. Los chats de grupo son bastante más difíciles. Cuando un grupo tiene 50, 200 o 1000 miembros, el protocolo tiene que manejar varias complejidades adicionales:

• Distribución de claves a escala. Cada mensaje tiene que cifrarse para que todos los miembros actuales del grupo —y solo ellos— puedan leerlo. El protocolo Signal usa un mecanismo llamado Sender Keys: cada participante comparte una clave simétrica con el grupo y los mensajes se cifran una vez en lugar de una vez por destinatario. Eso mantiene ágil la mensajería de grupo incluso a tamaños grandes.
• Cambios de miembros. Cuando alguien entra o sale de un grupo, las claves de cifrado tienen que rotarse para que el miembro nuevo no pueda leer mensajes pasados y el que se va no pueda leer los futuros. WhatsApp y Signal lo gestionan automáticamente, pero añade latencia y sobrecarga, sobre todo en grupos grandes con cambios frecuentes.
• Soporte multidispositivo. Si un usuario tiene móvil, tableta y cliente de escritorio, cada dispositivo tiene sus propias claves. El protocolo tiene que garantizar que todos puedan descifrar los mensajes de grupo manteniendo intacta la confidencialidad hacia adelante. El protocolo iMessage de Apple y la arquitectura multidispositivo de Signal abordan ese compromiso de formas distintas.

Para las empresas que construyen funcionalidades de colaboración en grupo —chats de equipo, canales de proyecto, espacios compartidos— esto no son preocupaciones teóricas. Las decisiones de arquitectura tomadas al principio del desarrollo determinan si el E2EE es viable a la escala que el producto acabará necesitando.

El giro de Instagram con el E2EE: una advertencia

En diciembre de 2023, Meta desplegó el E2EE por defecto en Messenger y empezó a extenderlo a los mensajes directos de Instagram. El esfuerzo de ingeniería fue enorme: el equipo de Meta describió la renovación de infraestructura de varios años necesaria para reconstruir funcionalidades como la búsqueda, las vistas previas de enlaces y la detección de spam sin acceso del servidor al contenido de los mensajes.

Después, en marzo de 2026, Meta cambió de rumbo. La empresa anunció que Instagram retirará el E2EE de los mensajes directos el 8 de mayo de 2026. A diferencia de WhatsApp, donde el E2EE es el valor por defecto para todos los usuarios, la mensajería cifrada de Instagram solo estaba disponible como opción voluntaria en determinadas regiones, y Meta citó la baja adopción como motivo para cerrarla.

Este giro es significativo por varias razones:

La privacidad como funcionalidad, no como garantía. El E2EE de Instagram nunca fue realmente «por defecto»: los usuarios tenían que activarlo chat por chat y solo estaba disponible en ciertos países. Eso contrasta radicalmente con WhatsApp, donde cada mensaje está cifrado de extremo a extremo desde 2016 sin que el usuario tenga que hacer nada. La lección: si el cifrado no está activado por defecto, la adopción seguirá siendo baja, y esa baja adopción se convierte en la justificación para retirarlo.

La presión regulatoria gana. Los gobiernos de EE. UU., Reino Unido, la UE y Australia han presionado con fuerza contra el E2EE en mensajería, argumentando que dificulta las investigaciones sobre explotación infantil y terrorismo. La Online Safety Act británica incluye disposiciones que podrían obligar a las plataformas a romper el E2EE. El reglamento europeo propuesto, conocido como «Chat Control», obligaría a escanear los mensajes en el cliente antes de cifrarlos. Retirar el E2EE de los mensajes directos de Instagram permite a Meta escanear mensajes en busca de material de abuso sexual infantil (CSAM) y otro contenido dañino, alineándose con las expectativas regulatorias.

Los usuarios pierden control. Meta dijo a los usuarios afectados que descargaran sus mensajes y contenidos cifrados antes de la fecha límite del 8 de mayo, porque el historial de chats cifrados no se migrará a chats estándar sin cifrar. A quienes quieren E2EE se les remite a WhatsApp.

El panorama del E2EE hoy. Así se comparan las principales plataformas tras el giro de Instagram:

La brecha entre las plataformas que tratan el cifrado como un compromiso arquitectónico central (Signal, WhatsApp, iMessage) y las que lo tratan como una funcionalidad opcional (Instagram, Telegram, Discord) nunca ha estado tan clara. Para las empresas que construyen funcionalidades de mensajería, esta es la decisión de diseño crítica: el E2EE tiene que ser fundacional, no atornillado después, porque un cifrado opcional se puede quitar.

Qué no protege el E2EE

Para cualquier aplicación que implemente o dependa del E2EE, es importante entender los límites:

• Metadatos. El E2EE protege el contenido, no los metadatos. La plataforma sigue sabiendo quién escribió a quién, cuándo, con qué frecuencia y desde qué dirección IP. Investigación de la EFF ha mostrado que los metadatos por sí solos pueden revelar información sensible sobre relaciones y patrones de comportamiento.
• Compromiso del dispositivo. Si el propio dispositivo está comprometido —por malware, spyware como Pegasus o acceso físico—, el atacante lee los mensajes después de descifrarlos. El E2EE protege los datos en tránsito y en el servidor, no en un dispositivo comprometido.
• Copias de seguridad en la nube. Si las copias de los chats se guardan sin cifrar en iCloud o Google Drive, el E2EE queda efectivamente sorteado. WhatsApp ofrece copias cifradas, pero el usuario tiene que activarlas.
• Factores humanos. Ningún protocolo criptográfico impide que un destinatario haga una captura de pantalla o que le manipulen socialmente para compartir una conversación.

Cómo encaja todo en una aplicación real

Cuando construimos aplicaciones seguras para nuestros clientes, el cifrado no es una funcionalidad única: es una arquitectura por capas donde cada tipo de cifrado juega un papel concreto:

1. La criptografía de curva elíptica establece la confianza entre las partes e intercambia claves de forma segura, con claves más pequeñas y rápidas que los enfoques antiguos basados en RSA.
2. El cifrado simétrico (AES-256) se encarga del cifrado a alta velocidad de los datos reales: archivos, mensajes, registros de base de datos, cargas de API.
3. Las firmas digitales y las sumas de verificación demuestran autenticidad y detectan manipulación, desde tokens de API firmados y actualizaciones de software hasta cargas de webhook verificadas.
4. El cifrado de extremo a extremo garantiza que ni siquiera el operador del servicio pueda acceder al contenido del usuario, algo esencial en salud, legal tech, finanzas y cualquier aplicación donde la privacidad sea un requisito regulatorio o competitivo.
5. La preparación poscuántica protege los datos de vida larga frente a amenazas futuras, una consideración que las empresas con visión ya están abordando.

La estrategia de cifrado correcta depende de qué estés construyendo: una app móvil que maneja datos personales, una plataforma B2B que procesa registros financieros, una funcionalidad de mensajería o un sistema IoT. Cada una tiene modelos de amenaza y requisitos regulatorios distintos, y la arquitectura de cifrado debería encajar con ellos.

Acertar con esa arquitectura —y detectar los puntos donde se rompe en silencio, como secretos subidos al control de versiones o datos personales registrados en texto plano— es exactamente lo que buscamos en una auditoría de código generado por IA. Si estás publicando una aplicación que maneja datos sensibles y quieres un segundo par de ojos sobre su seguridad, ponte en contacto.

Referencias

• Shor, P. (1994). Algorithms for quantum computation: discrete logarithms and factoring. Proceedings 35th Annual Symposium on Foundations of Computer Science.
• Grover, L. (1996). A fast quantum mechanical algorithm for database search. arXiv.
• Cohn-Gordon, K. et al. (2016). A formal security analysis of the Signal messaging protocol. Cryptology ePrint Archive.
• NIST (2024). Post-Quantum Encryption Standards.
• NSA (2022). Post-Quantum Cybersecurity Resources.
• Meta Engineering (2024). End-to-end encryption on Messenger.
• EFF (2013). Why metadata matters.
• Citizen Lab (2021). Hooking Candiru: another mercenary spyware vendor comes into focus.