Métodos de cifrado para transferencias de archivos: comparativa detallada
Comparativa técnica de métodos de cifrado de archivos: AES-256, RSA, ChaCha20 y enfoques de cifrado de extremo a extremo frente a cifrado en servidor.
Los servicios de transferencia de archivos usan cinco enfoques de cifrado principales en 2026: solo TLS (datos cifrados en tránsito pero en texto plano en el servidor), AES-256 en servidor y en reposo (el proveedor guarda las claves), AES-256-GCM en el cliente mediante la Web Crypto API (E2EE, clave en fragmento de URL), cifrado de flujo XChaCha20-Poly1305 (nonce extendido, usado por libsodium y Tresorit) y cifrado híbrido OpenPGP (ECC Curve25519 + claves de sesión AES-256, usado por Proton). La elección correcta depende del modelo de amenaza, las restricciones de rendimiento y los requisitos normativos. Esta comparativa explica qué hace cada uno y dónde falla cada uno.
Los cinco modelos de cifrado
Modelo uno: solo TLS 1.3. El archivo se cifra durante el tránsito por la red y luego reside en el servidor como texto plano. Ejemplos: FTP básico sobre TLS (FTPS), cualquier subida HTTP POST sin cifrado en reposo. Protege frente a la escucha pasiva en la red, no protege frente a nada más.
Modelo dos: TLS + en reposo en servidor. AES-256 cifra el archivo almacenado; el proveedor guarda la clave maestra (a menudo en AWS KMS, GCP Cloud KMS o equivalente). Ejemplos: WeTransfer, SwissTransfer, Dropbox. Protege frente al robo de almacenamiento en frío, no protege frente al acceso interno, citaciones judiciales ni compromisos del servidor en vivo.
Modelo tres: E2EE en el cliente con clave simétrica. El navegador o cliente deriva una clave de 256 bits, cifra con AES-256-GCM y coloca la clave en un fragmento de URL o canal fuera de banda. Ejemplos: HexaTransfer, descendientes del protocolo Firefox Send. El servidor solo ve texto cifrado y no puede descifrar en ninguna circunstancia.
Modelo cuatro: cifrados de flujo autenticados. XChaCha20-Poly1305 usa nonces de 24 bytes (frente a los 12 bytes de ChaCha20-Poly1305), haciendo que las colisiones por birthday bound sean inviables en archivos muy grandes. Ejemplos: libsodium secretbox (Internxt), Tresorit Send. Se elige cuando la aceleración hardware AES-NI no es universal (dispositivos Android más antiguos, IoT) porque ChaCha20 es rápido en software.
Modelo cinco: clave pública híbrida + simétrica. OpenPGP (RFC 9580, revisión 2024) usa ECC Curve25519 o RSA-4096 para cifrar una clave de sesión AES-256 por archivo. Ejemplos: Proton Drive, cifrado GPG tradicional de archivos. Permite gestión asimétrica de claves; no se necesita secreto compartido entre remitente y destinatario si tienes la clave pública del destinatario.
AES-256 frente a ChaCha20: qué diferencia hay realmente
Ambos son cifrados simétricos de 256 bits. AES-256 es el estándar NIST (FIPS 197) y tiene aceleración hardware (AES-NI en x86, ARM Cryptography Extensions en móvil). En hardware moderno, AES-256-GCM funciona a 2-4 GB/s por núcleo. ChaCha20-Poly1305 funciona a 1-2 GB/s por núcleo en software puro, más rápido que AES en hardware sin AES-NI. Para un escritorio cifrando un archivo de 4 GB, ambos terminan en menos de dos segundos; la red es el cuello de botella. Criptográficamente, ambos se consideran igualmente seguros en 2026.
RSA está prácticamente muerto en la transferencia de archivos
RSA-4096 cifra 512 bytes de texto plano por operación. Usar RSA directamente para cifrar un archivo de 1 GB es absurdo; habría que fragmentarlo en millones de bloques de 512 bytes. El patrón es siempre híbrido: RSA envuelve una clave de sesión AES-256 por archivo, AES cifra el contenido. ECC Curve25519 ha reemplazado a RSA en la mayoría de los diseños nuevos porque es más rápido, las claves son más pequeñas (256 bits ECC equivale a 3072 bits RSA en seguridad) y es resistente a ataques de temporización. OpenPGP en 2024 recomienda ahora Curve25519 (X25519 para intercambio de claves) sobre RSA. Seguirás viendo RSA en despliegues SFTP heredados.
Por qué las claves en el fragmento de URL son importantes
HexaTransfer y el linaje del protocolo Firefox Send colocan la clave de cifrado en el fragmento de URL (la parte tras el #). Los navegadores están especificados (RFC 3986) para no transmitir nunca los fragmentos en la petición HTTP. Eso significa que el servidor recibe una petición como GET /file/abc123 pero nunca ve el fragmento que contiene la clave. Cuando el usuario pega o hace clic en la URL completa, el fragmento permanece en la memoria del navegador y alimenta el descifrado en el cliente. Esta es la forma arquitectónicamente elegante de entregar un enlace E2EE compartible sin un canal paralelo.
E2EE frente a cifrado en servidor: la prueba del modelo de amenaza
El cifrado en servidor protege frente a una sola cosa: el robo físico del dispositivo de almacenamiento. Si el disco es robado, el cifrado AES-256 en reposo mantiene los datos opacos hasta que alguien comprometa el KMS. El cifrado de extremo a extremo protege frente a todo lo que el servidor podría hacer: citación judicial, acceso interno, ransomware que alcance datos en vivo o coerción a nivel estatal. Si tu modelo de amenaza es "el disco se roba de un centro de datos", el cifrado en servidor es suficiente. Si es "el gobierno, un adversario o un competidor obliga al servicio a entregar los datos", solo el E2EE te protege.
El cifrado autenticado no es opcional
AES-CBC simple sin MAC permite ataques de padding oracle (BEAST, Lucky13) que pueden descifrar texto cifrado con consultas de texto cifrado elegido. La transferencia de archivos moderna debe usar AEAD: AES-256-GCM (NIST SP 800-38D) o ChaCha20-Poly1305 (RFC 8439). La etiqueta Poly1305 o GCM autentica el texto cifrado y cualquier dato asociado (tamaño de archivo, nonce, cabecera de nombre de archivo). Si un bit se corrompe en tránsito, el descifrado falla de forma visible. Quien siga usando AES-CBC en 2026 sin una capa HMAC está viviendo en 2010.
Derivación de claves para transferencias protegidas con contraseña
Cuando un usuario escribe una contraseña para proteger una transferencia, no puedes usar la contraseña directamente como clave AES. Tiene baja entropía y es vulnerable a fuerza bruta. Derivación de claves moderna: PBKDF2-SHA-256 con 600.000 iteraciones (recomendación OWASP 2023), scrypt con N=2^17, o Argon2id con 19 MiB de memoria y 2 iteraciones. HexaTransfer usa PBKDF2 con 600.000 iteraciones. Tresorit usa Argon2id. Ambos resisten el cracking de contraseñas acelerado por GPU. Los proveedores que aún usan PBKDF2 con 10.000 iteraciones (guía de 2015) están en infraseguridad.
Tabla comparativa
| Método | Confidencialidad | Autenticación | El servidor ve texto plano | Riesgo cuántico | |---|---|---|---|---| | Solo TLS 1.3 | En tránsito | Sí (MAC en suite de cifrado) | Sí | Intercambio de claves en riesgo | | AES-256 en servidor | En reposo + en tránsito | Sí | Sí (tiene la clave) | Bajo | | AES-256-GCM en cliente | Ruta completa | Sí (etiqueta GCM) | No | Bajo | | XChaCha20-Poly1305 | Ruta completa | Sí (etiqueta Poly1305) | No | Bajo | | OpenPGP (Curve25519 + AES-256) | Ruta completa | Sí (MDC/OCB) | No | Curve25519 en riesgo |
Consideraciones post-cuánticas
El algoritmo de Shor amenaza a Curve25519 y RSA cuando existan ordenadores cuánticos grandes. Los cifrados simétricos (AES-256, ChaCha20) se debilitan pero no se rompen con el algoritmo de Grover; las claves de 256 bits conservan una fortaleza post-cuántica de 128 bits, todavía inviable. NIST estandarizó ML-KEM (Kyber) en 2024 para encapsulación de claves post-cuántica. Signal migró a PQXDH en 2023. Los servicios de transferencia de archivos aún no han adoptado ampliamente el post-cuántico, pero la ventana de riesgo ("recopilar ahora, descifrar después") significa que los archivos con retención prolongada deberían usar cifrado simétrico de 256 bits hoy.
Elegir un método
Transferencia sensible puntual con retención corta: AES-256-GCM en el cliente con claves en fragmento de URL. HexaTransfer es la implementación de referencia. Flujos de trabajo regulados continuos: XChaCha20-Poly1305 con registros de auditoría (Tresorit). Múltiples destinatarios con gestión de claves: OpenPGP (Proton Drive, GPG). Distribución descentralizada a gran escala: libsodium secretbox más erasure coding (Internxt sobre Storj). Alto volumen no sensible: TLS + en reposo es aceptable.
Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.
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