File Transfer Encryption Methods Compared in Detail
Technical comparison of file transfer encryption methods including AES-256, RSA, ChaCha20, and end-to-end vs server-side encryption approaches.
File transfer services use five main encryption approaches in 2026: TLS-only (data encrypted in transit but plaintext on the server), server-side AES-256 at rest (provider holds the keys), client-side AES-256-GCM via Web Crypto API (end-to-end, key in URL fragment), XChaCha20-Poly1305 stream encryption (extended-nonce, used by libsodium and Tresorit), and OpenPGP hybrid encryption (Curve25519 ECC + AES-256 session keys, used by Proton). The right choice depends on threat model, performance constraints, and regulatory requirements. This comparison explains what each does and where each fails.
The Five Encryption Models
Model one: TLS 1.3 only. The file encrypts during network transit and then sits on the server as plaintext. Examples: basic FTP over TLS (FTPS), any HTTP POST upload without at-rest encryption. Protects against passive network eavesdropping, protects against nothing else.
Model two: TLS + server-side at-rest. AES-256 encrypts the stored file; the provider holds the master key (often in AWS KMS, GCP Cloud KMS, or equivalent). Examples: WeTransfer, SwissTransfer, Dropbox. Protects against cold-storage theft, doesn't protect against insider access, subpoena, or live server compromise.
Model three: Client-side E2EE with symmetric key. The browser or client derives a 256-bit key, encrypts with AES-256-GCM, and places the key in a URL fragment or out-of-band channel. Examples: HexaTransfer, Send (Firefox Send protocol descendants). The server sees only ciphertext and cannot decrypt under any circumstance.
Model four: Authenticated stream ciphers. XChaCha20-Poly1305 uses 24-byte nonces (vs 12-byte in ChaCha20-Poly1305), making birthday-bound collisions infeasible across very large files. Examples: libsodium secretbox (Internxt), Tresorit Send. Chosen when AES-NI hardware acceleration isn't universal (older Android devices, IoT) because ChaCha20 runs fast in software.
Model five: Hybrid public-key + symmetric. OpenPGP (RFC 9580, 2024 revision) uses ECC Curve25519 or RSA-4096 to encrypt a per-file AES-256 session key. Examples: Proton Drive, traditional GPG file encryption. Enables asymmetric key management; no shared secret needed between sender and recipient if you have the recipient's public key.
AES-256 vs ChaCha20: What Actually Differs
Both are 256-bit symmetric ciphers. AES-256 is the NIST standard (FIPS 197) and has hardware acceleration (AES-NI on x86, ARM Cryptography Extensions on mobile). On modern hardware, AES-256-GCM runs at 2-4 GB/s per core. ChaCha20-Poly1305 runs at 1-2 GB/s per core in pure software, faster than AES on hardware without AES-NI. For a desktop encrypting a 4 GB file, both finish in under two seconds; the network is the bottleneck. Cryptographically, both are considered equally secure in 2026.
RSA Is Mostly Dead in File Transfer
RSA-4096 encrypts a 512-byte plaintext per operation. Using RSA directly to encrypt a 1 GB file is absurd; you'd fragment into millions of 512-byte blocks. The pattern is always hybrid: RSA wraps a per-file AES-256 session key, AES encrypts the content. ECC Curve25519 has replaced RSA in most new designs because it's faster, smaller keys (256-bit ECC equals 3072-bit RSA security), and resistant to timing attacks. OpenPGP in 2024 now recommends Curve25519 (X25519 for key exchange) over RSA. You'll still see RSA in legacy SFTP deployments.
Why URL-Fragment Keys Matter
HexaTransfer and the Firefox Send protocol lineage place the encryption key in the URL fragment (the part after #). Browsers are specified (RFC 3986) to never transmit fragments in the HTTP request. That means the server receives a request like GET /file/abc123 but never sees the fragment containing the key. When the user pastes or clicks the full URL, the fragment stays in the browser's memory and powers client-side decryption. This is the architecturally elegant way to deliver a shareable E2EE link without a sidecar channel.
End-to-End vs Server-Side: The Threat Model Test
Server-side encryption protects against one thing: a physical theft of the storage device. If the disk is stolen, the AES-256 at-rest encryption keeps data opaque until someone compromises the KMS. End-to-end encryption protects against everything the server could do: subpoena, insider access, ransomware reaching live data, or state-level coercion. If your threat model is "drive gets stolen from a data center," server-side is fine. If it's "government, adversary, or competitor compels the service to hand over data," only E2EE protects you.
Authenticated Encryption Is Not Optional
Plain AES-CBC without a MAC allows padding oracle attacks (BEAST, Lucky13) that can decrypt ciphertext with chosen-ciphertext queries. Modern file transfer must use AEAD: AES-256-GCM (NIST SP 800-38D) or ChaCha20-Poly1305 (RFC 8439). The Poly1305 tag or GCM tag authenticates the ciphertext and any associated data (file size, nonce, filename header). If a bit flips in transit, decryption fails loudly. Anyone still shipping AES-CBC in 2026 without an HMAC wrapper is living in 2010.
Key Derivation for Password-Protected Transfers
When a user types a password to protect a transfer, you cannot use the password as an AES key directly. It's low-entropy and vulnerable to brute force. Modern key derivation: PBKDF2-SHA-256 with 600,000 iterations (OWASP 2023 recommendation), scrypt with N=2^17, or Argon2id with 19 MiB memory and 2 iterations. HexaTransfer uses PBKDF2 with 600,000 iterations. Tresorit uses Argon2id. Both resist GPU-accelerated password cracking. Providers still using PBKDF2 with 10,000 iterations (2015 guidance) are undersecured.
Comparison Table
| Method | Confidentiality | Authentication | Server Sees Plaintext | Quantum Concern | |---|---|---|---|---| | TLS 1.3 only | In transit | Yes (MAC in cipher suite) | Yes | Key exchange at risk | | Server-side AES-256 | At rest + in transit | Yes | Yes (has key) | Low | | Client-side AES-256-GCM | Full path | Yes (GCM tag) | No | Low | | XChaCha20-Poly1305 | Full path | Yes (Poly1305 tag) | No | Low | | OpenPGP (Curve25519 + AES-256) | Full path | Yes (MDC/OCB) | No | Curve25519 at risk |
Post-Quantum Considerations
Shor's algorithm threatens Curve25519 and RSA once large quantum computers exist. Symmetric ciphers (AES-256, ChaCha20) are weakened but not broken by Grover's algorithm; 256-bit keys retain 128-bit post-quantum strength, still infeasible. NIST standardized ML-KEM (Kyber) in 2024 for post-quantum key encapsulation. Signal migrated to PQXDH in 2023. File transfer services haven't broadly adopted post-quantum yet, but the risk window ("harvest now, decrypt later") means long-retention archives should use 256-bit symmetric encryption today.
Picking a Method
One-off sensitive transfer, short retention: client-side AES-256-GCM with URL fragment keys. HexaTransfer is the implementation. Ongoing compliance-regulated workflows: XChaCha20-Poly1305 with audit logs (Tresorit). Multi-recipient with key management: OpenPGP (Proton Drive, GPG). Large decentralized distribution: libsodium secretbox plus erasure coding (Internxt on Storj). Non-sensitive high-volume: TLS + at-rest is acceptable.
Try it at hexatransfer.com — free, no account, 10 GB max.
Send large files securely with end-to-end encryption
Transfer files up to 10 GB for free with end-to-end encryption. No account required. Your files are encrypted in your browser before upload — no one else can read them.
Send a file