suele explicarse en una sola frase: solo el remitente y el destinatario pueden leer el mensaje. Esa frase es correcta y casi inútil — describe la garantía sin explicar cómo dos dispositivos que nunca se han visto, comunicándose a través de un servidor en el que ninguno de los dos confía, llegan realmente a establecer un secreto compartido y mantenerlo a salvo mensaje tras mensaje, año tras año. Este artículo abre esa caja: cómo funciona el handshake inicial cuando el destinatario está desconectado, cómo cambia la clave de cifrado en cada mensaje, y qué deja el E2EE deliberadamente sin proteger.

Puntos clave

  • El E2EE se establece mediante un protocolo de acuerdo de claves, no una contraseña compartida — el handshake X3DH del protocolo Signal permite que dos dispositivos acuerden un secreto incluso cuando uno de ellos está desconectado en ese momento.
  • Una vez que existe una sesión, el algoritmo Double Ratchet deriva una clave completamente nueva para cada mensaje, lo que aporta confidencialidad hacia adelante (los mensajes pasados siguen a salvo si se filtra una clave) y seguridad poscompromiso (la sesión se cura sola tras un compromiso).
  • Los chats de grupo no pueden simplemente ejecutar el mismo handshake por parejas a escala — Sender Keys sacrifica algo de confidencialidad hacia adelante a cambio de cifrar cada mensaje una vez en lugar de una vez por destinatario.
  • El E2EE protege el contenido, no los metadatos — quién habló con quién, cuándo y con qué frecuencia sigue siendo visible para el servidor en la mayoría de las implementaciones.
  • El problema más difícil sin resolver en el E2EE de producción no es la criptografía, es la verificación de claves: demostrar que la clave pública que recibiste pertenece realmente a tu contacto, y no a un atacante interpuesto.

Qué significa realmente "establecido"

Los cifradores simétricos como AES necesitan que ambas partes ya tengan la misma clave. Eso funciona bien una vez que existe un secreto compartido, pero no explica cómo llegó a existir en primer lugar — no puedes enviar la clave por el mismo canal que intentas proteger, y no puedes esperar que las apps de dos desconocidos hayan compartido algo de antemano. Establecer el E2EE significa resolver ese problema de arranque: derivar un secreto compartido entre dos dispositivos usando solo información pública, a través de una red controlada por una parte en la que ninguno de los dos dispositivos confía.

El mecanismo que usa prácticamente todo mensajero seguro moderno es el protocolo Signal, diseñado por Trevor Perrin y Moxie Marlinspike. Funciona en el propio Signal, en WhatsApp y en el nivel cifrado de Google Messages (RCS). Su handshake se llama X3DH — Extended Triple Diffie-Hellman — y resuelve un problema que un simple intercambio Diffie-Hellman no puede: iniciar una sesión con alguien que no está conectado en ese momento.

El handshake X3DH: acordar un secreto con alguien que está desconectado

Una llamada telefónica exige que ambas partes descuelguen al mismo tiempo. Un mensaje de texto no — lo envías, y espera. Las apps de mensajería necesitan construir el cifrado con esa misma propiedad asíncrona: Alice debería poder iniciar una conversación cifrada con Bob aunque el teléfono de Bob esté apagado.

X3DH lo consigue haciendo que cada usuario publique de antemano en el servidor un pequeño paquete de claves públicas, antes de necesitarlas:

  1. Clave de identidad (IK) — un par de claves de largo plazo que identifica al dispositivo. Rara vez cambia, y es lo que en última instancia comprueba la verificación por número de seguridad.
  2. Prekey firmada (SPK) — un par de claves de plazo medio, rotado periódicamente (la especificación X3DH sugiere un intervalo del orden de varias semanas a un mes), firmado con la clave de identidad para que el destinatario pueda verificar que realmente vino de ese dispositivo.
  3. Prekeys de un solo uso (OPK) — un lote de pares de claves de un solo uso. El servidor entrega una por cada nueva sesión entrante y la descarta después de usarla, y cada dispositivo sube periódicamente otras nuevas para reponer el conjunto.

Cuando Alice quiere escribirle a Bob por primera vez, obtiene del servidor uno de estos paquetes (nunca una clave privada, solo las mitades públicas). Después calcula tres o cuatro intercambios Diffie-Hellman distintos entre combinaciones de sus propias claves y las de Bob:

  • DH1 = su clave de identidad con la prekey firmada de Bob
  • DH2 = su clave efímera (generada al momento, de un solo uso) con la clave de identidad de Bob
  • DH3 = su clave efímera con la prekey firmada de Bob
  • DH4 = su clave efímera con la prekey de un solo uso de Bob, si había alguna disponible

Concatena los resultados y los pasa por una función de derivación de claves (HKDF) para producir un único secreto compartido. Bob, en cuanto se conecta, tiene todas las mitades privadas necesarias para calcular él mismo el valor idéntico — DH es conmutativo exactamente de la forma que hace que esto funcione. Ninguna de las partes transmite nunca el secreto en sí; cada uno calcula de forma independiente el mismo número a partir de una mezcla de claves de largo plazo, plazo medio y un solo uso.

¿Por qué cuatro cálculos DH separados en lugar de uno? Cada uno compra una propiedad concreta:

  • DH1 y DH2 atan la sesión a las identidades de largo plazo de ambas partes — esto es lo que hace que el intercambio esté autenticado, y no solo sea secreto.
  • DH3 (y DH4 cuando había una clave de un solo uso disponible) añade material fresco y desechable, de modo que si más adelante se compromete una clave de identidad de largo plazo, las sesiones pasadas negociadas antes del compromiso no puedan recalcularse. Este es el principio de la confidencialidad hacia adelante, incluso antes de que arranque el ratchet.
  • La prekey de un solo uso defiende específicamente contra un servidor que mienta sobre la prekey firmada — usar cada OPK exactamente una vez limita cuánto puede repetir un servidor malicioso o comprometido.

El resultado de X3DH es un único secreto compartido de 256 bits. Por sí solo, usar ese único secreto para todos los mensajes durante toda la vida de la conversación sería exactamente el problema de "una clave filtrada lo expone todo" con el que abría este artículo. Ese secreto no es el final de la historia — es la semilla del Double Ratchet.

El Double Ratchet: una clave nueva para cada mensaje

Un trinquete, mecánicamente, solo gira en un sentido. El algoritmo Double Ratchet toma prestado ese nombre a propósito: el estado del cifrado solo avanza, y no hay forma de rebobinarlo para recuperar una clave anterior a partir de una posterior.

Combina dos ratchets funcionando a la vez:

El ratchet de clave simétrica. Cada parte mantiene una "chain key" (clave de cadena). Cada vez que se envía un mensaje, la chain key actual pasa por una función hash (HMAC) para producir dos salidas: una clave de mensaje, usada para cifrar ese único mensaje y luego descartada, y una nueva chain key, que sustituye a la anterior. Las claves de mensaje nunca se reutilizan y no pueden derivarse unas de otras a la inversa — una función hash solo corre hacia adelante. Si un atacante graba el texto cifrado y más tarde roba una chain key, puede descifrar todos los mensajes enviados después de ese punto, pero ninguno anterior.

El ratchet Diffie-Hellman. El ratchet simétrico por sí solo todavía tiene una debilidad: una chain key robada compromete todo lo que viene después, indefinidamente. Para arreglar eso, cada vez que la conversación "gira" — a grandes rasgos, cada vez que la otra parte responde — cada lado genera un nuevo par de claves DH efímero, realiza un nuevo intercambio Diffie-Hellman con la última clave pública de la otra parte, y mezcla el resultado en la chain key. Esto significa que entra en el sistema un nuevo fragmento de entropía fresca e impredecible a un ritmo regular que un atacante no puede predecir ni precalcular.

La combinación aporta dos garantías distintas que a menudo se confunden pero no son lo mismo:

  • Confidencialidad hacia adelante — comprometer la clave de hoy no expone los mensajes de ayer. La aporta el ratchet simétrico: las chain keys antiguas ya han desaparecido, encadenadas hacia adelante por hash y descartadas.
  • Seguridad poscompromiso (post-compromise security; la especificación del Double Ratchet la llama "recuperación tras una brecha", break-in recovery, y de forma informal "autocuración") — comprometer la clave de hoy tampoco expone los mensajes de mañana, porque el siguiente paso del ratchet DH inyecta aleatoriedad nueva que el atacante nunca vio. La aporta el ratchet DH.

Juntas significan que un compromiso puntual — un dispositivo robado, una clave obtenida bajo coacción — tiene un radio de explosión, no una ruptura permanente. La conversación se cura sola en uno o dos mensajes de intercambios DH frescos, lo cual es un modelo de seguridad sustancialmente distinto de "la clave está comprometida, la conversación está comprometida para siempre".

Mensajería de grupo: por qué el protocolo por parejas no escala

X3DH más el Double Ratchet describen una sesión uno a uno. Un grupo de 200 personas no tiene "una sesión" — tiene hasta 200×199 sesiones potenciales por parejas, y cifrar cada mensaje una vez por destinatario supondría 200 operaciones de cifrado separadas (y 200 veces el ancho de banda) para un solo texto.

La respuesta de Signal son las Sender Keys. En lugar de ratchets por parejas entre todos los miembros, cada participante genera una "sender key" simétrica y la distribuye individualmente a todos los demás miembros del grupo, a través de sus sesiones Double Ratchet por parejas ya establecidas (esta distribución inicial es la parte cara, la que ocurre una vez por cada cambio de composición del grupo). Después de eso, el remitente cifra un mensaje de grupo exactamente una vez con su sender key, y cualquier miembro que haya recibido esa clave puede descifrarlo directamente — sin cifrado por destinatario en la ruta crítica.

Eso compra enormes ganancias de rendimiento al precio de algunas propiedades del ratchet: una sender key no avanza mensaje a mensaje de la misma forma que lo hace una cadena Double Ratchet por parejas, así que ofrece una confidencialidad hacia adelante más débil dentro de su propio ciclo de vida, y debe rotarse explícitamente cada vez que cambia la composición del grupo — que alguien deje un grupo significa que todos los miembros restantes tienen que regenerar y redistribuir una nueva sender key, o la copia de quien se fue seguiría descifrando los mensajes futuros. Precisamente por eso quitar a alguien de un grupo grande y con mucha rotación de miembros es notablemente más caro que enviarle un mensaje normal — la rotación está haciendo trabajo criptográfico real, no solo una actualización de base de datos.

El problema que la criptografía sola no puede resolver: verificar claves

Todo lo anterior asume que Alice recibió realmente del servidor las claves públicas de Bob, y no las de un atacante. Si el servidor (o cualquiera que pueda hacerse pasar por él) le entrega a Alice en su lugar un paquete de claves controlado por un atacante, X3DH se ejecuta perfectamente y produce un secreto compartido perfectamente válido — con la persona equivocada. Este es un clásico ataque de hombre en el medio (man-in-the-middle), y ninguna cantidad de matemáticas de derivación de claves lo arregla, porque las matemáticas nunca comprueban de quién era la clave que recibieron.

La mitigación es la verificación fuera de banda: Signal y WhatsApp generan un número de seguridad (una huella derivada de las claves de identidad de ambas partes) que los usuarios pueden comparar en persona, por voz o escaneando un código QR. Si los números coinciden, las claves de identidad son genuinas y nadie está interceptando el intercambio. Este paso es opcional, la mayoría de los usuarios nunca lo hace, y esa brecha — no la criptografía — es donde ocurren de verdad los ataques realistas contra los mensajeros con E2EE: un servidor de distribución de claves comprometido o coaccionado, no un cifrador roto.

Qué te da esto, y qué no

Ventajas:

  • La confidencialidad sobrevive al compromiso del servidor. Como el servidor solo llega a tener texto cifrado (y, en X3DH, claves públicas), una base de datos vulnerada, una copia de seguridad requerida judicialmente o un empleado deshonesto no pueden exponer el contenido de los mensajes — no hay nada legible que entregar.
  • La confidencialidad hacia adelante limita el daño del robo de claves. Un dispositivo robado o una clave de largo plazo comprometida no desbloquea retroactivamente todo el historial de mensajes de un usuario.
  • La seguridad poscompromiso significa que el sistema se recupera. A diferencia de una única clave estática, una sesión Double Ratchet comprometida se repara sola en unos pocos mensajes.
  • La mensajería de grupo escala sin recifrar por destinatario, gracias a las Sender Keys — rendimiento utilizable a tamaños donde el cifrado por parejas se vendría abajo.

Inconvenientes:

  • Los metadatos quedan intactos. El servidor sigue viendo quién escribe a quién, con qué frecuencia, desde qué IP y durante cuánto tiempo — la investigación muestra sistemáticamente que los metadatos por sí solos revelan patrones sensibles de relación y comportamiento, a veces de forma más fiable que el propio contenido.
  • El compromiso del terminal lo salta todo. El E2EE protege los datos en tránsito y en reposo en el servidor — no en un dispositivo ya comprometido por malware o acceso físico. Los mensajes descifrados son, por definición, legibles en el dispositivo que los descifró.
  • La verificación de claves es manual y casi siempre se omite. El protocolo es tan fuerte como su eslabón más débil, y para la mayoría de los usuarios ese eslabón es "nunca comprobé el número de seguridad".
  • Es caro añadirlo a posteriori. Las funcionalidades que asumen visibilidad en el servidor — búsqueda, detección de spam, vistas previas de enlaces, moderación de contenido, copias de seguridad — tienen que reconstruirse o rediseñarse por completo en torno a un texto cifrado que el servidor no puede leer. Esta es exactamente la migración que el equipo de ingeniería de Meta documentó para Messenger, y también por eso la retirada del E2EE de los mensajes directos de Instagram en 2026 fue una decisión de producto y regulatoria, no criptográfica — el mecanismo que describe este artículo ya estaba construido y funcionando. Cubrimos ese giro, y cómo encaja el E2EE junto a AES, TLS y la criptografía poscuántica en una arquitectura de seguridad más amplia, en El cifrado explicado.
  • Los cambios de composición del grupo cuestan trabajo criptográfico real. Quitar a un miembro exige rotar y redistribuir las sender keys, no cambiar un indicador de control de acceso.

Diseñarlo desde el principio, no añadirlo después

La lección que se repite en todos los sistemas de E2EE en producción — Signal, WhatsApp, iMessage — es que las partes de un producto de mensajería que parecen no tener relación con la criptografía (búsqueda, vistas previas de notificaciones, filtros de spam, copias de seguridad, sincronización multidispositivo) son las que en realidad determinan si el E2EE es viable. A estas alturas, un protocolo de intercambio de claves y un ratchet son piezas bien entendidas y revisadas públicamente; la ingeniería difícil está en todos los lugares donde el servidor solía tener visibilidad y ahora ya no la tiene.

Si estás construyendo o auditando un producto que maneja datos sensibles de usuarios — historiales médicos, comunicaciones financieras, correspondencia legal —, la decisión de diseño sobre el cifrado de extremo a extremo tiene que tomarse en la etapa de arquitectura, no como un añadido posterior. Ese es exactamente el tipo de brecha que buscamos en una auditoría de código generado por IA: lugares donde una funcionalidad asume silenciosamente acceso en el servidor a texto plano que el modelo de seguridad prometía que nunca existiría. Si quieres un segundo par de ojos sobre cómo encaja el cifrado en la arquitectura de tu aplicación, ponte en contacto.

Referencias