Cómo funciona el cifrado de extremo a extremo en transferencias
Comprende cómo el cifrado de extremo a extremo protege tus archivos durante la transferencia: análisis técnico de los protocolos criptográficos y su implementación.
El cifrado de extremo a extremo en la transferencia de archivos significa que los bytes que salen de tu dispositivo están cifrados con una clave que nunca toca el servidor, y solo tu destinatario previsto puede descifrarlos. El servidor almacena texto cifrado, no ve nada significativo y podría sufrir una brecha sin exponer el contenido de tu archivo. La receta criptográfica casi siempre combina un cifrado simétrico como AES-256-GCM o XChaCha20-Poly1305 para el archivo en sí, envuelto con un intercambio de claves como X25519 ECDH o RSA-OAEP 2048/4096 para el material de claves. Así es exactamente cómo funciona en la práctica.
El modelo de amenaza que el cifrado de extremo a extremo realmente defiende
El cifrado de extremo a extremo defiende específicamente contra: que el proveedor de transferencia sea hackeado, reciba una orden judicial o actúe de mala fe; que atacantes de red intercepten el tráfico descifrado de TLS en proxies; que capturas de instantáneas del bucket de almacenamiento caigan en manos equivocadas; y que empleados del servicio accedan internamente. No defiende contra malware en el dispositivo del emisor o del receptor, phishing que capture el enlace de descifrado, ni cuentas comprometidas del destinatario. Comprender el modelo importa, porque "cifrado" se usa a menudo de forma incorrecta para referirse a "TLS en tránsito más AES en reposo en el servidor", lo que deja al proveedor con las claves.
Cifrado simétrico para el payload del archivo
Los archivos se cifran con un algoritmo simétrico porque la criptografía de clave pública es demasiado lenta para datos masivos. La elección moderna es AES-256-GCM, definido en NIST SP 800-38D, que proporciona confidencialidad e integridad autenticada en un único paso. Una clave aleatoria de 256 bits y un nonce único de 96 bits —nunca reutilizado con la misma clave— protegen cada archivo. XChaCha20-Poly1305, definido en RFC 8439 y RFC 8103, es una alternativa que suele ser más rápida en dispositivos sin aceleración hardware AES-NI, como procesadores ARM más antiguos. Ambos producen un texto cifrado más una etiqueta de autenticación de 128 bits que detecta cualquier manipulación.
Derivación de claves a partir de contraseñas
Cuando el cifrado de extremo a extremo usa una contraseña, la contraseña en sí nunca es la clave de cifrado: sería demasiado débil frente a la fuerza bruta. En su lugar, una función de derivación de claves como PBKDF2-HMAC-SHA256 con 600.000 iteraciones o más (directrices OWASP 2025), Argon2id con m=19 MiB y t=2 (RFC 9106), o scrypt (RFC 7914) convierte la contraseña en una clave robusta. Un salt aleatorio de 128 o 256 bits previene los ataques de tabla arco iris. La clave resultante cifra el archivo. El salt y el número de iteraciones se almacenan junto al texto cifrado para que el destinatario pueda reconstruir la clave al introducir la contraseña.
Envoltorio de clave pública para transferencias con cuentas
Cuando los destinatarios tienen cuentas con claves públicas publicadas, no es necesario introducir una contraseña. El emisor genera una clave de cifrado de archivo (FEK) aleatoria, cifra el archivo con AES-256-GCM usando la FEK y luego cifra la FEK hacia la clave pública de cada destinatario mediante el acuerdo de claves X25519 ECDH según RFC 7748, combinado con HKDF-SHA256 según RFC 5869 para derivar una clave de envoltorio, o RSA-OAEP según PKCS#1 v2.2 con SHA-256. La FEK envuelta queda junto al texto cifrado. Solo el titular de la clave privada del destinatario puede desenvolver la FEK y descifrar el archivo. Este es el modelo de Signal y WhatsApp para mensajes, adaptado para archivos.
Cifrado de extremo a extremo basado en enlace mediante fragmentos de URL
Un truco ingenioso en la transferencia basada en navegador consiste en almacenar la clave de descifrado en el fragmento de URL (la parte después de #). Los fragmentos nunca se envían al servidor en una petición HTTP. Un enlace como https://example.com/d/abc123#k=B9kZtR... lleva el ID del archivo en el lado del servidor y la clave en el lado del cliente. El navegador descarga el texto cifrado, lee el fragmento en JavaScript y descifra localmente. El servicio nunca ve la clave. La advertencia es que si el enlace se filtra en cualquier lugar —registros, capturas de pantalla, previsualizaciones de aplicaciones de mensajería— la clave se filtra con él.
Integridad con AEAD y hashes
Los modos de Cifrado Autenticado con Datos Asociados (AEAD) como GCM y ChaCha20-Poly1305 previenen la manipulación. Un solo bit invertido en el texto cifrado hace que la validación de la etiqueta de autenticación falle, y la función de descifrado devuelve un error en lugar de texto plano corrupto. Además del AEAD, muchas implementaciones calculan un hash SHA-256 o BLAKE3 del texto plano como entrada de manifiesto para que el destinatario pueda verificar tras el descifrado que el archivo coincide con lo que el emisor pretendía. Esto importa para archivos grandes transferidos en chunks, donde una entrega parcial podría de otro modo tener éxito en algunas partes y fallar silenciosamente en las finales.
Cifrado fragmentado para archivos grandes
Cifrar un archivo de 10 GB en una sola operación AES-GCM requiere mantener 10 GB de estado, lo que es impracticable en navegadores. Las implementaciones reales dividen el archivo en chunks, típicamente de 1 a 16 MB cada uno, y cifran cada chunk de forma independiente con una subclave derivada y un nonce basado en contador. La herramienta de cifrado age, definida en age-encryption.org, usa chunks de 64 KB con ChaCha20-Poly1305. Los límites de chunk también permiten a los navegadores transmitir el descifrado mediante la API de Streams, iniciando la descarga a disco antes de que llegue el archivo completo, y soportan subidas reanudables mediante el protocolo tus.io cuando se producen interrupciones de red.
Seguridad de transporte además del cifrado de extremo a extremo
TLS 1.3, definido en RFC 8446, sigue siendo relevante sobre el cifrado de extremo a extremo, no para la confidencialidad del payload —que ya está cifrado— sino para la privacidad de los metadatos: nombres de archivo, tamaños y temporización. TLS 1.3 con intercambio de claves de secreto perfecto hacia adelante como X25519 significa que incluso si la clave a largo plazo del servidor se compromete posteriormente, las sesiones grabadas no pueden descifrarse. La fijación de certificados o la precarga de HSTS previene los ataques de degradación. Juntos, el cifrado de extremo a extremo más TLS 1.3 protegen tanto el contenido del archivo como el patrón operativo de quién envía qué a quién.
Errores de implementación frecuentes
Tres errores se repiten. Primero, reutilizar nonces con la misma clave en AES-GCM rompe catastróficamente la confidencialidad: usa siempre un nonce aleatorio nuevo o un contador que nunca se repita. Segundo, implementar criptografía con rutinas caseras en lugar de bibliotecas auditadas como libsodium, la Web Crypto API (SubtleCrypto) o BoringSSL; las operaciones en tiempo constante son esenciales para prevenir ataques de temporización. Tercero, no autenticar los metadatos del archivo junto al contenido; si la identidad del emisor, el nombre de archivo o la lista de destinatarios no forman parte de los Datos Asociados Autenticados (AAD), un atacante puede sustituir los metadatos sin que se detecte. HexaTransfer aborda estos problemas usando primitivas estándar de Web Crypto en el lado del cliente con patrones revisados.
Cómo verificar que un servicio realmente hace cifrado de extremo a extremo
Lee las afirmaciones de marketing con escepticismo. El verdadero cifrado de extremo a extremo significa que el proveedor no puede descifrar los archivos ni siquiera ante una orden judicial. Busca documentación técnica publicada que describa los algoritmos exactos (AES-256-GCM, X25519, HKDF, recuentos de iteraciones de PBKDF2), código de cliente de código abierto que pueda auditarse y un modelo de amenaza que reconozca qué defiende y qué no defiende el cifrado de extremo a extremo. Los servicios que ofrecen recuperación de contraseña en el servidor para archivos cifrados no están haciendo verdadero cifrado de extremo a extremo: ellos tienen las claves. Los servicios que reivindican "conocimiento cero" deben respaldarlo con una descripción del protocolo criptográfico, no solo con un eslogan de marketing.
Pruébalo en https://hexatransfer.com — gratuito, sin cuenta, hasta 10 GB. AES-256-GCM del lado del cliente, TLS 1.3 en tránsito y derivación de claves con PBKDF2 sin que el servidor vea nunca el archivo sin cifrar.
Envía archivos grandes de forma segura con cifrado de extremo a extremo
Transfiere archivos de hasta 10 GB gratis con cifrado de extremo a extremo. Sin necesidad de cuenta. Tus archivos se cifran en tu navegador antes de subirlos: nadie más puede leerlos.
Enviar un archivo