¿Qué es el cifrado del lado del cliente? Tu navegador trabaja

El cifrado del lado del cliente significa que tu navegador o app cifra los archivos en tu dispositivo antes de que nada toque la red. El servidor recibe solo texto cifrado —la salida de AES-256-GCM indistinguible de ruido aleatorio— y la clave de descifrado nunca abandona el cliente. Esto es lo opuesto al cifrado del lado del servidor, donde el proveedor guarda las claves y técnicamente puede leer tus archivos. La Web Crypto API (window.crypto.subtle) hace esto posible en cualquier navegador moderno sin plugins, a aproximadamente 2–3 GB/s en hardware AES-NI. Servicios como HexaTransfer, SwissTransfer, Tresorit Send y Proton Drive usan este modelo para garantizar que los archivos siguen siendo privados incluso si el propio servicio es comprometido.

El navegador como motor criptográfico

Hace cinco años, el cifrado real requería instalar una app de escritorio o usar PGP en la línea de comandos. La Web Crypto API, estandarizada por el W3C en 2017, cambió esto. Expone AES-GCM, RSA-OAEP, ECDH, HMAC, PBKDF2 y SHA-256 directamente a JavaScript en cualquier navegador principal — Chrome, Firefox, Safari, Edge.

El rendimiento ya no es el obstáculo. Las instrucciones AES-NI de Intel alcanzan 3–5 GB/s por núcleo para AES-256-GCM. Las Cryptography Extensions de ARM en Apple M-series y chips Qualcomm Snapdragon ofrecen un rendimiento similar. Cifrar un archivo de 1 GB en el navegador tarda aproximadamente 300–500 ms en un portátil de gama media.

El desafío que queda es manejar archivos más grandes que la memoria del navegador. La Streams API y ReadableStream permiten al código procesar archivos en fragmentos de 4 MB, cifrando cada fragmento de forma independiente con un IV único en modo contador. Así es como los servicios elevan el límite a 10 GB o más.

Un flujo mínimo de cifrado del lado del cliente

Esta es la secuencia que ejecuta un servicio típico basado en navegador:

// 1. Genera una clave AES aleatoria de 256 bits
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]
);

// 2. Lee el archivo en fragmentos
const file = fileInput.files[0];
const chunkSize = 4 * 1024 * 1024;

// 3. Cifra cada fragmento con un IV único de 12 bytes
for (let offset = 0; offset < file.size; offset += chunkSize) {
  const chunk = file.slice(offset, offset + chunkSize);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv }, key, await chunk.arrayBuffer()
  );
  // 4. Sube [iv || ciphertext] al servidor
}

// 5. Exporta la clave e incrústala en el fragmento de la URL de compartición
const keyBytes = await crypto.subtle.exportKey("raw", key);
const shareUrl = `https://ejemplo.com/d/${fileId}#k=${base64url(keyBytes)}`;

El servidor ve bytes de aspecto aleatorio, un ID de archivo y nada más. La clave existe solo en la memoria del navegador del usuario y en el fragmento de URL.

Por qué supera al cifrado del lado del servidor

El cifrado del lado del servidor significa que el proveedor descifra a petición: para generar miniaturas, ejecutar análisis antivirus, procesar consultas de búsqueda o responder a demandas legales. Una revelación de Apple de 2023 mostró que las copias de seguridad de iCloud (que no estaban cifradas de extremo a extremo hasta el lanzamiento de Advanced Data Protection) eran accesibles para Apple y por tanto para las fuerzas del orden estadounidenses con solicitudes válidas.

El cifrado del lado del cliente invierte esto. Como la clave nunca llega al proveedor:

Los empleados malintencionados no ven nada. El ingeniero con acceso a la base de datos obtiene texto cifrado.
Las órdenes judiciales producen texto cifrado. El proveedor puede cumplir con las órdenes entregando el blob cifrado, que es inútil sin la clave.
Las brechas filtran texto cifrado. El incidente de LastPass de 2021 mostró que esto importa: las bóvedas robadas estaban cifradas, y solo los usuarios con contraseñas maestras débiles se enfrentaron a un riesgo real.
Las caídas del proveedor no comprometen los datos. Aunque la empresa desaparezca, tu copia local (la URL) sigue descifrando el archivo.

Lo que el servidor aún puede ver

El cifrado del lado del cliente protege el contenido del archivo pero no todo. El servidor típicamente observa:

Tamaño del archivo — la longitud del texto cifrado aproxima la del texto plano (AES-GCM añade 16 bytes de sobrecarga por cifrado, más el IV de 12 bytes).
Direcciones IP de subida y descarga con marcas de tiempo.
Metadatos de sesión de los handshakes TLS, incluida la huella digital TLS del cliente.
Nombres de archivo cifrados — a menos que los nombres de archivo se incluyan en la carga cifrada, pueden filtrarse.

Los buenos servicios del lado del cliente cifran los nombres de archivo como parte de la cabecera del texto cifrado y rellenan a tamaños de cubo (1 MB, 10 MB, 100 MB) para ocultar el tamaño. Tresorit y Proton Drive documentan explícitamente su exposición de metadatos.

Cifrado del lado del cliente protegido por contraseña

Muchos servicios permiten a los usuarios añadir una contraseña además del fragmento de URL. El flujo:

El navegador genera una salt aleatoria de 128 bits y deriva una clave usando PBKDF2-HMAC-SHA-256 con 600.000 iteraciones (recomendación OWASP 2023) o Argon2id con memory=64 MB, iterations=3.
El archivo se cifra con la clave derivada.
La salt va en el fragmento de URL; la contraseña se comunica fuera de banda.
El destinatario escribe la contraseña, que deriva la clave localmente.

Esto convierte una compartición de un solo canal (la URL es suficiente) en dos factores: el atacante necesita tanto el enlace como la contraseña. PBKDF2 con 600.000 iteraciones hace que la fuerza bruta offline cueste aproximadamente 10 segundos por intento en una GPU moderna, por lo que las contraseñas necesitan más de 40 bits de entropía para resistir atacantes decididos: piensa en 10+ caracteres de un alfabeto variado.

El cambio de confianza: del servicio al código del cliente

El cifrado del lado del cliente desplaza el límite de confianza. Antes, confiabas en que el servicio manejara bien tu texto plano. Ahora, confías en el JavaScript que el servicio envía a tu navegador en cada carga de página. Una actualización maliciosa podría exfiltrar la clave antes o durante el cifrado.

Existen tres mitigaciones, con diferente rigor:

Subresource Integrity (SRI) para las etiquetas de script garantiza que el hash del JS coincide con un valor conocido.
Auditorías de código por empresas como Cure53, NCC Group o Trail of Bits verifican que la lógica de cifrado es correcta.
Builds reproducibles permiten a partes independientes confirmar que el código distribuido coincide con el código fuente publicado.
Cabeceras Content Security Policy (CSP) bloquean scripts de terceros que podrían manipular el cifrado.

El enfoque más estricto, usado por pmcrypto de Proton Mail y algunos clientes basados en Electron, distribuye binarios firmados en lugar de JavaScript nuevo en cada visita. Los servicios basados en navegador intercambian algo de este rigor por la comodidad de no requerir instalación.

Casos de uso donde el lado del cliente destaca

Algunos escenarios donde el cifrado del lado del cliente vale la pena la primera carga ligeramente más lenta:

Documentos legales y médicos. HIPAA 45 CFR § 164.312 y el secreto profesional entre abogado y cliente se benefician enormemente de las arquitecturas ciegas al proveedor.
Periodismo y protección de fuentes. Envío de documentos sin redactar donde incluso la exposición de metadatos conlleva riesgo.
Propiedad intelectual corporativa. Documentos de junta directiva, modelos financieros, materiales de M&A donde las amenazas internas en el proveedor de transferencia son una preocupación realista.
Registros personales. Declaraciones de impuestos, pasaportes, análisis médicos — archivos que te incomodaría ver en un titular de brecha del proveedor.

Para archivos de baja sensibilidad (una foto de reunión, una receta), el cifrado tradicional del lado del servidor es suficiente.

Cómo reconocer el cifrado real del lado del cliente

Cuatro señales de que un servicio realmente hace cifrado del lado del cliente:

Los fragmentos de URL llevan una clave. La URL de compartición tiene texto después de # que parece bytes aleatorios codificados en base64.
Las subidas son texto cifrado. Abre DevTools → Red durante la subida; el cuerpo de la solicitud debería parecer bytes aleatorios, no tu nombre de archivo.
Los archivos grandes siguen funcionando rápido. Un flujo real del lado del cliente transmite fragmentos; no reenvía a una pasarela de cifrado del lado del servidor.
La política de privacidad dice «no podemos descifrar tus archivos». Acompañada de un whitepaper técnico, no solo texto de marketing.

Servicios que pasan: el nivel E2EE de SwissTransfer, Tresorit Send, los enlaces compartidos de Proton Drive, Mega.nz y HexaTransfer. Servicios que no pasan: WeTransfer (estándar), Google Drive, los enlaces de compartición de Dropbox.

Probarlo ahora mismo

Si quieres probar el cifrado del lado del cliente hoy, abre DevTools y mira la pestaña Red mientras subes un archivo. Deberías ver un blob cifrado yendo al servidor y una clave en tu barra de URL que nunca aparece en ninguna solicitud. Esa es toda la promesa.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.