El cifrado de conocimiento cero (zero-knowledge), explicado

Respuesta rápida. El cifrado de conocimiento cero (zero-knowledge) es una arquitectura en la que el servicio que aloja tus datos no puede descifrarlos: la clave de cifrado no sale nunca de tu dispositivo en claro. Aunque roben la base de datos del servidor, la entreguen ante una solicitud de una autoridad o la explore un administrador malintencionado, lo único que contiene son datos cifrados opacos. Lo usan Signal, Tutanota, Proton, Bitwarden y la sincronización en la nube de Filarr.

Cuando un servicio en la nube dice «tus datos están cifrados», suele ser verdad, pero rara vez basta. Los datos están cifrados durante el tránsito (TLS) y en reposo (cifrado del lado del servidor, con claves que guarda el propio servicio). Pero el servicio sigue teniendo las claves. Si quiere leer tus datos, puede. Si un tribunal se lo exige, lo hará.

El cifrado de conocimiento cero es la arquitectura que lo hace imposible por diseño. El servicio literalmente no puede leer tus datos, porque las claves para descifrarlos nunca salen de tu dispositivo.

Este artículo explica el conocimiento cero con palabras sencillas, muestra cómo funciona en la práctica y aclara la confusión habitual con el cifrado de extremo a extremo.

¿Qué significa cifrado de conocimiento cero?

En este contexto, «conocimiento cero» es un término de marketing que toma prestado el nombre de un concepto criptográfico real (las pruebas de conocimiento cero) y lo usa con cierta libertad. El término técnico más claro es cifrado del lado del cliente sin acceso a las claves desde el servidor.

La promesa es sencilla:

• Tu dispositivo genera las claves de cifrado
• Tu dispositivo cifra tus datos antes de enviarlos al servidor
• El servidor solo almacena blobs cifrados y nunca tiene las claves para descifrarlos
• Cuando inicias sesión desde otro dispositivo, tu contraseña (o un secreto derivado de ella) descifra las claves en local

El resultado: el servicio tiene un conocimiento nulo del contenido de tus datos. Puede ver metadatos (tamaños de archivo, marcas de tiempo de sincronización, direcciones IP), pero el contenido en sí le resulta opaco.

¿En qué se diferencia del cifrado habitual en la nube?

Hoy casi todos los servicios en la nube cifran los datos en reposo. Dropbox, Google Drive, iCloud, OneDrive: todos cifran tus archivos en sus servidores. La pregunta decisiva es: ¿quién tiene la clave?

Modelo de cifrado	¿El servidor puede descifrar?	Ejemplos
Solo TLS (en tránsito)	Sí: el servidor guarda texto plano	Muchos servicios pequeños
Cifrado en reposo del lado del servidor	Sí: el servidor tiene la clave	Dropbox, Google Drive, iCloud (en su mayor parte)
Cifrado del lado del cliente, con la clave en el servidor	Sí (¡también!)	Algunos servicios «cifrados» en los que el servidor guarda una copia de la clave maestra
Conocimiento cero / de extremo a extremo	No: la clave solo está en el cliente	Signal, Proton, Tutanota, Bitwarden, sincronización en la nube de Filarr

El cifrado del lado del servidor protege contra una sola amenaza: un ladrón que se lleva los discos físicos del centro de datos. No protege contra el operador del servicio que lee tus datos, contra los atacantes que vulneran el servicio ni contra un gobierno que obliga al servicio a entregar tus datos.

El conocimiento cero protege contra las tres.

¿Cómo funciona realmente el cifrado de conocimiento cero?

El mecanismo es una cadena de operaciones que se ejecuta por completo en tu dispositivo. Un servicio típico de conocimiento cero para una app de notas funciona así:

EN TU DISPOSITIVO                               EN EL SERVIDOR
─────────────────                               ──────────────

1. Introduces tu contraseña
        │
        ▼
2. KDF (PBKDF2 / Argon2id)
   convierte la contraseña en la KEK
        │
        ▼
3. Clave aleatoria de cifrado (FEK),
   generada una vez para la cuenta
        │
        ▼
4. AES-256-GCM(archivo, FEK, IV nuevo) ─► blob cifrado ──► guardado como bytes opacos
        │
        ▼
5. AES-256-GCM(FEK, KEK) ──────► FEK cifrada ─────────► guardada junto al blob
        │
        ▼
6. La KEK nunca sale del dispositivo
   (algunos servicios suben una copia
   cifrada de la clave que solo tu
   contraseña puede abrir: ver más abajo
   lo que cuesta la recuperación)

Lo que ve el servidor: un flujo de bytes opacos. Incluso con acceso root completo al servidor, un atacante solo lee ruido cifrado.

Para que todo funcione en varios dispositivos, la clave cifrada también suele subirse, pero siempre en forma cifrada. Para desbloquearla en un dispositivo nuevo, vuelves a introducir tu contraseña, y el desbloqueo se hace en el propio dispositivo.

¿Qué ve realmente el servidor en un sistema de conocimiento cero?

Esta es la pregunta clave. Un servidor nunca puede no ver nada: siempre hacen falta algunos metadatos para que el servicio funcione. En un sistema de conocimiento cero bien diseñado, el servidor ve:

• Un blob cifrado opaco por archivo
• El tamaño de cada blob (con cierto margen: algunos sistemas añaden relleno)
• Las marcas de tiempo de sincronización (cuándo se actualizan los blobs)
• El identificador de tu cuenta (normalmente un correo electrónico o un nombre de usuario)
• Metadatos de autenticación (un verificador de contraseña, no la contraseña en sí)

No ve:

• El contenido de los archivos
• Los nombres de archivo (los sistemas bien diseñados también los cifran)
• La estructura de carpetas (también cifrada)
• Los títulos de las notas, las etiquetas ni ningún otro metadato de la app

Lo que sí se filtra (tamaño, momento, correo de la cuenta) constituye un riesgo de canal lateral: un adversario con suficiente interés a veces puede deducir información solo a partir de los tamaños. Las implementaciones serias de conocimiento cero rellenan los blobs hasta tamaños fijos y añaden variación aleatoria a las marcas de tiempo para mitigarlo.

¿Por qué importa el conocimiento cero para tus datos?

Tres escenarios concretos. En una arquitectura de conocimiento cero:

Escenario 1: el servicio sufre un ataque. Un atacante roba la base de datos entera. Obtiene blobs cifrados y direcciones de correo, nada más. Los blobs no sirven de nada sin las claves, que están en los dispositivos de los usuarios.

Escenario 2: el servicio recibe una solicitud de una autoridad. Un gobierno obliga al servicio a entregar los datos de los usuarios. El servicio cumple entregando lo que tiene: blobs cifrados. El gobierno tampoco puede descifrarlos.

Escenario 3: un empleado malintencionado o descuidado. Un administrador con acceso a la base de datos intenta leer los archivos de los usuarios. Ve bytes cifrados. No puede descifrarlos sin la contraseña del usuario, que el sistema nunca almacenó.

El servicio literalmente no puede traicionarte, ni aunque quiera ni aunque lo obliguen. Ese es el valor del conocimiento cero: la necesidad de confiar desaparece gracias a las matemáticas, no a las promesas.

¿Qué cuesta el cifrado de conocimiento cero?

El conocimiento cero tiene contrapartidas técnicas reales.

1. Perder la contraseña significa perder los datos. Si el servicio no puede descifrar tus datos, tampoco puede restablecer tu contraseña. La mayoría de los servicios de conocimiento cero ofrecen códigos o frases de recuperación, pero si pierdes a la vez tu contraseña y tu secreto de recuperación, tus datos quedan inaccesibles para siempre. Es el precio de una privacidad real.

2. Las funciones del lado del servidor son limitadas. El servicio no puede buscar en tus datos, ni generar vistas previas en el servidor, ni resumir tus notas con IA, porque no ve nada. Todas esas funciones tienen que ejecutarse en tu dispositivo.

3. La sincronización entre varios dispositivos es más difícil. Compartir claves entre tus dispositivos exige un protocolo de emparejamiento cuidadoso (normalmente ECDH con derivación HKDF). Diseñarlo bien no es trivial.

4. La colaboración en tiempo real es más difícil. Si dos usuarios editan el mismo documento cifrado, la fusión tiene que hacerse en el cliente o mediante protocolos criptográficos (los CRDT sobre datos cifrados son un campo de investigación activo).

Son costes asumidos. La garantía de privacidad vale demasiado como para renunciar a ella a cambio de mejoras marginales en las funciones.

¿En qué se diferencia el conocimiento cero del cifrado de extremo a extremo?

Los dos términos se usan a menudo como sinónimos. Se solapan, pero no son idénticos.

El cifrado de extremo a extremo (E2E) describe una propiedad: solo los extremos de una comunicación pueden leer el contenido. Ningún intermediario (servidor, proveedor de internet) puede hacerlo. El ejemplo clásico es Signal: un mensaje se cifra en tu teléfono, pasa por los servidores de Signal y solo se descifra en el teléfono del destinatario.

El conocimiento cero es un modelo de despliegue para servicios de almacenamiento: el servidor guarda tus datos cifrados con claves que no tiene. Puede verse como un cifrado de extremo a extremo aplicado a una «comunicación» entre tu yo del pasado (cuando subiste los datos) y tu yo del futuro (cuando los descargas en otro dispositivo).

La mayoría de los servicios de conocimiento cero también aplican el cifrado de extremo a extremo al compartir (cuando compartes un archivo con otro usuario, las claves se intercambian de cliente a cliente sin que el servidor las vea). Pero puedes tener conocimiento cero sin compartir nada (una bóveda personal) o cifrado de extremo a extremo sin almacenamiento (una app de chat que no guarda el historial).

Para una comparación más a fondo, consulta extremo a extremo frente a conocimiento cero: ¿cuál es la diferencia?.

¿Qué apps usan cifrado de conocimiento cero?

Servicios destacados que aplican correctamente el conocimiento cero:

• Signal: mensajería de extremo a extremo
• Bitwarden: gestor de contraseñas (también de conocimiento cero para el almacenamiento de la bóveda)
• 1Password: gestor de contraseñas
• Proton (Mail, Drive, Calendar): proveedor suizo, totalmente de conocimiento cero
• Tutanota: correo, calendario y contactos cifrados
• Standard Notes: notas cifradas
• Cryptomator: cifrado local para el almacenamiento en la nube
• Filarr: espacio de trabajo local-first (primero en local) con sincronización en la nube de conocimiento cero opcional

Servicios que mucha gente cree de conocimiento cero y que no lo son: iCloud (Apple tiene las claves de la mayoría de los datos, salvo los protegidos por la Protección de Datos Avanzada), Dropbox, Google Drive y OneDrive.

¿Cómo aplica Filarr el conocimiento cero?

Filarr es un espacio de trabajo local-first cuya capa de sincronización en la nube es de conocimiento cero. La arquitectura:

1. Los archivos viven primero cifrados en tu disco. La app local funciona sin nube: esa es la parte local-first.
2. Cuando activas la sincronización en la nube, tu dispositivo cifra cada archivo con AES-256-GCM usando la clave de tu cuenta (FEK), con un valor aleatorio nuevo para cada archivo. Consulta cómo funcionan las claves KEK y FEK para ver la jerarquía de claves.
3. El servidor solo almacena blobs cifrados. Los datos se guardan en Cloudflare R2. Sin tu contraseña, los blobs son ruido.
4. El emparejamiento entre dispositivos usa ECDH (Diffie-Hellman de curva elíptica) con claves de sesión derivadas por HKDF para compartir tu clave maestra entre tus dispositivos sin exponerla nunca al servidor.
5. El inicio de sesión de tu cuenta pasó a una clave derivada el 16 de octubre de 2026: una cuenta nueva, o una que ha iniciado sesión desde entonces, envía una clave derivada en tu dispositivo en lugar de la contraseña. Durante una transición de unos dos meses, una cuenta que aún no ha vuelto a iniciar sesión, o una versión antigua de una app, todavía envía la contraseña por HTTPS, donde se coteja con un hash bcrypt y nunca se almacena.

El resultado: si mañana nos robaran la base de datos, los atacantes obtendrían ruido cifrado, direcciones de correo y claves envueltas que no pueden abrir sin tu contraseña o tu frase de recuperación. No podrían leer ni un solo archivo. El límite conocido era el propio inicio de sesión, y se está cerrando: desde el 16 de octubre de 2026, al iniciar sesión se envía una clave derivada en tu dispositivo. Solo una cuenta que aún no ha vuelto a iniciar sesión, o una versión antigua de la app, sigue enviando la contraseña durante la transición, y un servidor comprometido en ese momento podría capturarla y, con ella, desenvolver tu clave. Si recibiéramos una solicitud de una autoridad, solo podríamos entregar lo que almacenamos (blobs cifrados), y no podemos descifrarlos.

Lee la arquitectura de seguridad completa de Filarr para ver los parámetros exactos y el modelo de amenazas.

Para saber más

• «Cryptographic Right Answers», de Latacora: elecciones criptográficas pragmáticas (en inglés)
• Qué es AES-256-GCM y por qué importa
• Cifrado de extremo a extremo frente a conocimiento cero: ¿cuál es la diferencia?
• Cómo funcionan las claves KEK y FEK
• La arquitectura de seguridad de Filarr
• ¿Qué es el software local-first?