Cifrado de extremo a extremo, explicado de verdad

Lo que cifrar significa, de verdad

Cifrar un mensaje es transformarlo en algo que parece ruido para cualquiera que no posea cierta información llamada clave. La operación se hace en el dispositivo del que envía y, con la clave correcta, se deshace en el dispositivo del que recibe. En medio, el mensaje viaja como una sucesión de bytes sin significado aparente. Esa es la idea sencilla. El resto del artículo se ocupa de los matices que la convierten, según el caso, en una garantía real o en una etiqueta de mercado.

El adjetivo de extremo a extremo —en inglés end-to-end, abreviado E2EE— añade una precisión. El cifrado no se hace para que un servidor intermedio pueda leerlo y entregarlo. Se hace para que solo los dos extremos —el dispositivo del que envía y el dispositivo del que recibe— posean la clave. Cualquier servidor por el que el mensaje pase ve el ruido, no el mensaje. Esa es la diferencia técnica con el cifrado en tránsito, donde el contenido va cifrado de un servidor al siguiente, pero cada servidor por el que pasa lo descifra para reenviarlo, recuperando temporalmente el texto en claro.

La paradoja del secreto compartido

Hay un problema obvio. Para que dos personas puedan cifrar y descifrar mensajes entre sí, ambas necesitan la misma clave. Pero, ¿cómo se ponen de acuerdo en esa clave si todo lo que se mandan, por definición, pasa por un canal donde alguien podría estar escuchando? Acordar la clave en el mismo canal donde después la usarán parece imposible: si el atacante la oye al acordarla, podrá descifrar todo lo posterior. Durante decenios, la criptografía clásica resolvió esto por la vía dura: las claves se entregaban en persona, antes de empezar a usarse, en encuentros físicos. Los embajadores cargaban con maletines de claves cosidos al forro del abrigo.

En el correo electrónico contemporáneo, esa solución no escala. Si tuviéramos que ir físicamente a casa de cada persona con la que pretendiéramos comunicarnos de forma cifrada, no llegaríamos a hablar con nadie. La pregunta planteada hace cincuenta años por la comunidad criptográfica era esta: ¿es posible que dos personas que no se conocen y que solo comparten un canal público acuerden, en ese mismo canal público, un secreto que nadie que escuche el canal pueda conocer?

La elegancia de Diffie-Hellman

En 1976, dos matemáticos llamados Whitfield Diffie y Martin Hellman demostraron algo aparentemente imposible: que dos personas, hablando solo por un canal público —un canal donde cualquiera puede escuchar todo lo que dicen—, pueden ponerse de acuerdo en una contraseña secreta sin que ningún oyente pueda descubrirla. Suena a magia. No lo es: es matemática. El intercambio de claves Diffie-Hellman, como se conoce desde entonces, es la base de prácticamente toda la comunicación cifrada de internet, y medio siglo de uso intensivo y escrutinio académico mundial avalan su solidez. Quien quiera ver la intuición visual o la matemática puede seguir leyendo. Quien prefiera confiar en que funciona también puede continuar sin perder el hilo del artículo.

Para quien quiera intuirlo en una imagen, hay una analogía conocida con colores. Imagina que Alicia y Bruno acuerdan en abierto un color base —digamos amarillo— a la vista de Eva, que les escucha. Cada uno elige en privado un segundo color secreto y mezcla su secreto con el amarillo. Alicia obtiene un naranja particular; Bruno obtiene un verde particular. Intercambian los resultados a la vista de Eva. Ahora cada uno mezcla el color recibido con su propio secreto, y ambos llegan al mismo color final, porque el orden de las mezclas no importa. Eva ha visto el amarillo y las dos mezclas intermedias, pero no los secretos; sin alguno de los secretos no puede llegar al color final. La matemática real cambia los colores por exponenciaciones en grupos modulares o curvas elípticas, pero la idea es la misma: el secreto compartido se construye en público sin que nadie en el canal pueda reconstruirlo.

De Diffie-Hellman al protocolo Signal

El cifrado de extremo a extremo que usan hoy las aplicaciones de mensajería profesional descansa, casi sin excepción, sobre una versión elegante y endurecida del intercambio Diffie-Hellman. El protocolo Signal, diseñado por Trevor Perrin y Moxie Marlinspike entre 2013 y 2016, es la referencia. Combina dos ideas clave. La primera, el intercambio de claves en curvas elípticas (X25519), que produce el secreto compartido inicial entre dos dispositivos. La segunda, el llamado Double Ratchet —doble engranaje—, que renueva las claves automáticamente con cada mensaje, de modo que comprometer el dispositivo hoy no permite descifrar mensajes pasados, ni mensajes futuros una vez se ha rotado el engranaje.

En Zig, el intercambio X25519 que produce el secreto compartido entre dos dispositivos cabe en seis líneas, usando la biblioteca estándar:

const std = @import("std");
const X25519 = std.crypto.dh.X25519;

// Alicia y Bruno generan cada uno un par (privada, pública).
const par_alicia = X25519.KeyPair.generate(io);
const par_bruno  = X25519.KeyPair.generate(io);

// Cada parte recibe la clave pública de la otra y deriva el mismo secreto.
const secreto_alicia = X25519.scalarmult(par_alicia.secret_key, par_bruno.public_key) catch unreachable;
const secreto_bruno  = X25519.scalarmult(par_bruno.secret_key,  par_alicia.public_key) catch unreachable;
// secreto_alicia == secreto_bruno  (32 bytes)

Y dentro de std.crypto.dh.X25519, ¿qué hay exactamente? No magia oculta. Son dos funciones cortas que se pueden leer enteras en la propia biblioteca estándar de Zig. La primera deriva la clave pública desde la privada — el «gᵃ» del intercambio:

pub fn recoverPublicKey(secret_key: [secret_length]u8) IdentityElementError![public_length]u8 {
    const q = try Curve.basePoint.clampedMul(secret_key);
    return q.toBytes();
}

En el lenguaje del artículo: la clave privada se «multiplica» —en el sentido elíptico, no en el aritmético elemental— por el punto base de la curva Curve25519, y el resultado se serializa en treinta y dos bytes. La operación clampedMul es la versión endurecida de esa multiplicación escalar: incorpora las salvaguardas que la comunidad criptográfica fue añadiendo a lo largo de años para resistir familias conocidas de ataques. Dos líneas de cuerpo de función.

La segunda función combina tu clave privada con la clave pública que la otra parte te envía. Es el «(gᵇ)ᵃ» del intercambio, el que produce el secreto compartido de treinta y dos bytes que ninguno de los dos llegó a transmitir:

pub fn scalarmult(secret_key: [secret_length]u8, public_key: [public_length]u8) IdentityElementError![shared_length]u8 {
    const q = try Curve.fromBytes(public_key).clampedMul(secret_key);
    return q.toBytes();
}

Otras dos líneas. La clave pública recibida se interpreta como un punto sobre la curva, y se «multiplica» por la clave privada propia. Por la conmutatividad de la operación de curva —análoga a la conmutatividad de la multiplicación de exponentes que vimos en el ejemplo numérico—, ambas partes acaban con el mismo punto serializado: exactamente el secreto compartido del que habla el artículo.

Qué protege el cifrado de extremo a extremo

Lo que el E2EE protege bien, asumiendo una implementación correcta, es el contenido del mensaje en tránsito. Un servidor intermedio que reciba y reenvíe los datos cifrados verá una sucesión de bytes ininteligibles. Un atacante con acceso al cable, al router, al punto de acceso wifi, verá lo mismo. Un proveedor del servicio que conserve copias del tráfico no podrá leerlo a posteriori. Un Gobierno que ordene al operador del servicio entregar el contenido recibirá los mismos bytes ininteligibles que tenía el servidor en primer lugar.

Esto, en términos prácticos, es mucho. Es la diferencia entre escribir una carta dentro de un sobre opaco y escribirla en una postal. Las dos llegan. Solo una preserva el contenido frente al cartero.

Qué no protege el cifrado de extremo a extremo

Conviene saberlo igual de bien. El E2EE no protege los metadatos: el servidor sigue sabiendo que el usuario A envía datos al usuario B, a qué hora, con qué frecuencia y desde dónde, aunque no sepa qué dice. Estos metadatos, ya lo hemos argumentado en Cifrar no es ser privado, son a menudo más reveladores que el contenido. Saber que alguien llamó a un despacho de abogados especializado en divorcios un viernes a las 22:00 durante treinta minutos cuenta una historia que el contenido de la llamada nunca contó. Es la misma situación que ver a una persona entrar y salir varias veces de una clínica oncológica: no hace falta oír nada de lo que se habla dentro para imaginar lo que está pasando. Un solo metadato suelto puede no significar nada; varios cruzados entre sí dibujan algo demasiado parecido a la verdad. El E2EE no protege los extremos: si el dispositivo del receptor está comprometido por un programa malicioso, el mensaje se descifra normalmente para ese receptor y el programa malicioso lo lee. El E2EE no protege contra la identidad del interlocutor en sí: si Alicia cree estar hablando con Bruno pero un atacante se ha interpuesto al inicio (un man in the middle) y el protocolo no incluye verificación independiente, las dos partes acaban hablando con el intruso pensando que hablan entre sí.

Hay una cuarta cosa que conviene formular sin ambigüedad. El E2EE no impide que un proveedor que afirma ofrecerlo guarde, además, una copia del mensaje sin cifrar en sus propios sistemas. La afirmación «mis mensajes están cifrados de extremo a extremo» y la afirmación «el proveedor no conserva mi contenido» no son la misma. Una aplicación puede cumplir la primera mientras incumple la segunda; lo hemos visto en titulares de prensa repetidamente desde 2018. El usuario, salvo que el código del cliente sea verificable, no tiene forma técnica de distinguir un caso del otro sin investigación experta. El caso más conocido en el público general: WhatsApp cifra los mensajes de extremo a extremo en tránsito, pero si el usuario activa la copia de seguridad en iCloud o Google Drive sin cifrado adicional, esa copia se almacena legible en infraestructura de un tercero, y el cifrado se rompe en el extremo del propio usuario.

La pregunta que el operador no quiere oír

Una aplicación que afirma cifrar de extremo a extremo puede, técnicamente, hacer una de tres cosas con respecto a las claves:

1. Las claves residen solo en los dispositivos. Se generan y residen exclusivamente en los dispositivos de los usuarios; el operador no las conoce ni las almacena. Es el caso óptimo.
2. Las claves residen en los dispositivos, pero el operador conserva una copia. Bajo formulaciones como «recuperación de cuenta», «sincronización entre dispositivos» o «funcionalidad opcional». En este caso el cifrado es de extremo a extremo solo nominalmente; el operador, si quiere o si se lo ordenan, puede descifrar.
3. Las claves las gestiona el operador entero. Con un envoltorio criptográfico que conserva la apariencia del E2EE sin la sustancia. Este último caso es menos frecuente, pero existe.

La pregunta operativa para el profesional, por tanto, no es si el proveedor afirma cifrar de extremo a extremo. La pregunta es: ¿dónde residen las claves, quién las controla, y qué pasaría si una orden judicial llegara mañana al operador pidiendo descifrar mis conversaciones? Las tres respuestas a esa pregunta son completamente distintas, aunque las tres aplicaciones se presenten en su publicidad con la misma etiqueta.

Para el lector profesional

Cuatro preguntas operativas a formular al evaluar un servicio de comunicación profesional que afirma ofrecer cifrado de extremo a extremo:

1. ¿Dónde se generan las claves criptográficas y dónde residen físicamente? Si el operador puede acceder a ellas (incluso temporalmente, incluso bajo formulación de recuperación), el E2EE es nominal.
2. ¿Existe verificación independiente del interlocutor (números de seguridad, códigos QR, comparación fuera de banda) que impida un ataque de hombre en el medio durante el establecimiento de la conversación?
3. ¿El código del cliente es auditable —abierto, publicado, reproducible— o exige confiar en la palabra del proveedor sobre lo que el cliente hace en realidad?
4. ¿Qué metadatos genera y conserva el servicio, y por cuánto tiempo? Aunque el contenido sea opaco, los metadatos pueden reconstruir buena parte de la información sensible.

Estas cuatro preguntas no piden información técnica avanzada; piden información que cualquier operador honesto puede responder en su documentación pública. La calidad y precisión de la respuesta dice tanto del producto como la respuesta misma.

---

El cifrado de extremo a extremo, hecho bien, es una de las construcciones más finas que la criptografía contemporánea ha entregado a la práctica cotidiana. La idea original —dos personas pueden acordar un secreto en un canal público— pertenece a Whitfield Diffie y Martin Hellman, 1976; medio siglo después seguimos viviendo en su consecuencia. Pero, como sucede con cualquier promesa técnica, su valor depende del cumplimiento real, no de la etiqueta. La pregunta del profesional honesto no es «¿está cifrado?», sino «¿quién tiene las claves?». Las respuestas tienen consecuencias distintas. Conviene saberlas.