Cifrado de extremo a extremo vs zero-knowledge: ¿cuál es la diferencia?

Q: ¿Contra qué protege cada uno?

Respuesta rápida. El cifrado de extremo a extremo (E2EE) es una propiedad de la comunicación: solo los dos extremos pueden leer el mensaje; los intermediarios, no. El zero-knowledge (conocimiento cero) es un modelo de despliegue para el almacenamiento: el servidor guarda tus datos cifrados con claves que no tiene. La mayoría de los servicios modernos centrados en la privacidad aplican los dos: Signal es E2EE para los chats, Filarr es zero-knowledge para la sincronización en la nube. Los términos se solapan, pero no son sinónimos.

Los dos términos se usan como sinónimos en los textos de marketing, en los blogs de seguridad e incluso en artículos académicos. No son lo mismo.

Este artículo da la definición precisa de cada uno, muestra dónde se solapan y dónde no, y explica cómo evaluar lo que promete sobre cifrado cualquier servicio centrado en la privacidad.

¿Qué es el cifrado de extremo a extremo (E2EE)?

El cifrado de extremo a extremo es una propiedad de los sistemas de comunicación. La definición es sencilla: solo los dos extremos pueden leer el contenido; ningún sistema intermedio que gestione el mensaje puede hacerlo.

El ejemplo canónico es Signal Messenger. Cuando envías un mensaje:

Tu teléfono cifra el mensaje con una clave que tiene el teléfono del destinatario (y que los servidores de Signal no tienen)
El blob cifrado viaja a través de los servidores de Signal
El teléfono del destinatario lo descifra

Los servidores de Signal ven entrar bytes cifrados y salir bytes cifrados. Nunca ven el texto en claro. Aunque quisieran, no podrían: las claves nunca salen de los dispositivos de los usuarios.

El E2EE no se limita a la mensajería. La misma propiedad se aplica a:

Las llamadas de voz y vídeo (Signal, FaceTime, WhatsApp)
El correo electrónico (Proton Mail, Tutanota)
El intercambio de archivos (Wormhole, Magic Wormhole, OnionShare)
La edición colaborativa (algunas alternativas a Google Docs compatibles con E2EE)

El rasgo que lo define es siempre el mismo: los datos los cifra un extremo y solo los descifra el otro extremo. Los servidores intermedios son mensajeros ciegos.

¿Qué es el cifrado zero-knowledge?

El cifrado zero-knowledge es una propiedad de los servicios de almacenamiento. La definición: el servidor guarda tus datos cifrados con claves que no tiene.

Frente al E2EE, el zero-knowledge tiene otra forma:

El E2EE es una propiedad de una comunicación uno a uno o uno a muchos entre usuarios
El zero-knowledge es una propiedad de la relación de un solo usuario con su almacenamiento en la nube

El ejemplo de manual es Bitwarden. Tu bóveda de contraseñas se cifra en tu dispositivo con una clave derivada de tu contraseña maestra. La bóveda cifrada se sube a los servidores de Bitwarden. Ellos guardan un blob opaco. Cuando inicias sesión desde otro dispositivo, tu contraseña maestra descifra la bóveda localmente: los servidores de Bitwarden nunca la ven.

Otros servicios zero-knowledge: 1Password, Proton Drive, Tutanota Calendar, la sincronización en la nube de Filarr, Cryptomator (combinado con cualquier nube).

Si replanteas el zero-knowledge como una «comunicación» entre tu yo del pasado (cuando subiste los datos) y tu yo del futuro (cuando los descargas en un dispositivo nuevo), se convierte en un caso particular de E2EE. Pero los patrones de despliegue, los modelos de amenazas y los retos de ingeniería son lo bastante distintos como para merecer otro nombre.

¿Dónde se solapan el E2EE y el zero-knowledge?

En la práctica, los servicios modernos centrados en la privacidad suelen aplicar los dos a la vez.

Una app de notas cifrada típica:

Usa el zero-knowledge para el almacenamiento personal: tus notas se guardan cifradas en el servidor, y el servidor no puede leerlas
Usa el E2EE cuando compartes una nota con otro usuario: el enlace compartido o la invitación contiene una clave cifrada que solo el destinatario puede descifrar

Así que un mismo producto puede ser las dos cosas. Filarr, por ejemplo, es zero-knowledge para el almacenamiento (tus blobs cifrados están en Cloudflare R2 y los servidores de Filarr no pueden leerlos) y E2EE para compartir (ver más abajo).

¿Dónde no se solapan?

Tres casos concretos.

E2EE sin zero-knowledge. Una app de mensajería que no guarda los mensajes en el servidor (o solo los guarda cifrados brevemente para entregarlos). Signal es E2EE; el servidor no conserva casi nada.

Zero-knowledge sin E2EE. Una bóveda personal sin funciones para compartir ni comunicarse. Un usuario de Bitwarden que lo usa solo, un usuario de Filarr que no comparte nada: los datos están cifrados con zero-knowledge en el servidor, pero no hay un «otro extremo» porque no hay comunicación.

Ninguno de los dos. La mayoría de los servicios en la nube. Google Drive cifra en reposo, pero Google tiene las claves. Dropbox, igual. iCloud, igual (salvo los elementos protegidos por el ajuste de Protección de datos avanzada de Apple, que es zero-knowledge).

¿Por qué importa la distinción a los usuarios?

La distinción importa cuando evalúas una promesa de privacidad. Fíjate en estas afirmaciones:

«Usamos cifrado de extremo a extremo para proteger tus datos.»

Tiene sentido en una app de mensajería. En una app de notas o un gestor de contraseñas que guarda datos en la nube, «cifrado de extremo a extremo» es técnicamente forzar el término, que en rigor se aplica a la comunicación. La afirmación correcta es «zero-knowledge» o «cifrado del lado del cliente sin acceso a las claves en el servidor».

Cuando los equipos de marketing usan «E2EE» para productos de almacenamiento, en la práctica suele significar lo mismo que zero-knowledge, pero un uso tan laxo puede ocultar lagunas. Lee la documentación de la arquitectura, no la página de marketing.

«Tus datos están cifrados en tránsito y en reposo.»

Esto no dice nada sobre quién tiene las claves. Un servicio puede cifrar en reposo con claves que controla: es seguridad en la nube estándar, no zero-knowledge. Pregunta siempre: ¿tiene el servicio una copia de la clave de descifrado?

«Nunca compartiremos tus datos.»

Una promesa, no una garantía. Con zero-knowledge o E2EE, el servicio literalmente no puede compartir tus datos porque no puede leerlos. Sin ninguno de los dos, confías en que el servicio cumpla su promesa incluso bajo presión legal.

¿Contra qué protege cada uno?

Amenaza	¿Protege el E2EE?	¿Protege el zero-knowledge?	¿Protege el cifrado en el servidor?
Escucha en la red	✓	✓ (con TLS)	✓ (con TLS)
Servidor comprometido por atacantes	✓	✓	✗ (las claves están en el servidor)
El operador del servicio lee tus datos	✓	✓	✗
Solicitud de una autoridad al servicio	✓	✓	✗
Empleado con acceso a la base de datos	✓	✓	✗
Malware en tu propio dispositivo	✗	✗	✗
Contraseña perdida / clave de recuperación perdida	✓ pero datos irrecuperables	✓ pero datos irrecuperables	✗ (el servicio puede restablecerla)

El E2EE y el zero-knowledge ofrecen las mismas protecciones frente a las amenazas, cada uno en su ámbito. La diferencia está en el qué (comunicación frente a almacenamiento) y en el cómo.

¿Qué preguntas hay que hacer antes de confiar en un servicio?

Una lista breve cuando un servicio dice ofrecer E2EE o zero-knowledge:

¿Dónde está documentada la derivación de claves? Un servicio serio publica los parámetros de su KDF (memoria de Argon2id, iteraciones de PBKDF2) en su documentación técnica o de seguridad.
¿Qué ve el servidor? Blobs cifrados, bien. ¿Nombres de archivo en claro? ¿La estructura de carpetas? ¿Los asuntos? Cada metadato filtrado es un posible canal lateral.
¿Qué pasa al restablecer la contraseña? Si el servicio puede restablecer tu contraseña y devolverte el acceso a tus datos, no es zero-knowledge. El zero-knowledge de verdad significa contraseña perdida = datos perdidos (solo recuperables con tu propio código de recuperación).
¿El código es abierto o está auditado? Una afirmación sin prueba pública es una afirmación de marketing. Las auditorías independientes y el código abierto hacen que las afirmaciones se puedan verificar.
¿Cómo funciona compartir? Si el servicio permite compartir, el modelo para compartir debe conservar el E2EE: el servidor nunca debería ver sin cifrar el contenido compartido.

Aplica estas preguntas a cualquier servicio cifrado antes de confiarle tus datos.

¿Dónde se sitúa Filarr en esta escala?

Filarr es un espacio de trabajo local-first cuya sincronización en la nube es zero-knowledge. Si lo situamos en el marco anterior:

Primero, local-first. Tus archivos viven cifrados en tu disco. No interviene ningún servidor para que la app local funcione: no hay ninguna «comunicación» ni ningún «almacenamiento» que la nube tenga que mediar.
Sincronización en la nube zero-knowledge. Cuando activas la sincronización en la nube, tus archivos se cifran con AES-256-GCM, con la clave de tu cuenta (la FEK) y un valor aleatorio nuevo para cada archivo, y se suben como blobs opacos. El servidor guarda los blobs cifrados, las copias de tu FEK envueltas con tu contraseña y con tu frase de recuperación, y un hash bcrypt que comprueba tu inicio de sesión; nunca ve tu FEK en claro ni el contenido de ningún archivo. Desde el 16 de octubre de 2026, una app actualizada inicia sesión con una clave derivada de tu contraseña, no con la propia contraseña. Durante una transición de unos dos meses, una cuenta que todavía no ha vuelto a iniciar sesión, o una versión antigua de la app, sigue enviando la contraseña (por HTTPS), donde un servidor comprometido podría capturarla.
Emparejamiento multidispositivo. Cuando emparejas un dispositivo nuevo, tu dispositivo existente le envía tu clave maestra mediante un intercambio ECDH, cifrada con una clave de sesión efímera que el servidor no puede derivar. El servidor deja pasar los bytes de la clave cifrada y no ve nada útil.
Compartir. Desde que se publicó este artículo por primera vez, Filarr ha lanzado la posibilidad de compartir, y es E2EE. Un enlace compartido lleva su clave después del #, que un navegador nunca envía al servidor; la clave de una bóveda compartida se sella para el par de claves personal de cada miembro, y el servidor solo la retransmite sellada.

Lo que el servidor de Filarr puede ver: blobs cifrados opacos, el tamaño de los blobs, las marcas de tiempo de sincronización, el correo electrónico de la cuenta, las copias envueltas de tu clave y un hash bcrypt que comprueba tu inicio de sesión. Lo que no puede ver: el contenido de los archivos, los nombres de los archivos, la estructura de carpetas, los títulos de las notas, los nombres de las bóvedas compartidas y de los enlaces compartidos, ni tu clave en claro.

Lee la arquitectura de seguridad completa de Filarr para conocer los parámetros exactos y el modelo de amenazas que hay detrás de cada decisión de diseño.