Encryption at Rest vs in Transit: Both Matter for Security

Encryption in transit protects data moving between two points — your browser and a server, for instance — using TLS 1.3 with AES-256-GCM or ChaCha20-Poly1305. Encryption at rest protects data sitting on disk, typically with AES-256-XTS for full-disk encryption or AES-256-GCM for per-file. Neither alone is enough. TLS protects against network snooping but decrypts at the server; at-rest encryption protects stored data but is useless if the keys live next to the ciphertext. Real security comes from layering both, ideally alongside client-side (end-to-end) encryption so the server never sees plaintext at all.

Two different threats, two different controls

The threats look different depending on where your data lives:

In transit (network path): a coffee-shop attacker running a packet sniffer, a compromised ISP router, a nation-state intercepting undersea cables. The 2013 Snowden documents revealed NSA's MUSCULAR program tapping internal Google fiber links. Defense: TLS 1.3, preferably with certificate pinning for apps.

At rest (storage): a stolen laptop, a leaked backup tape, a misconfigured S3 bucket, a rogue datacenter employee with disk access. The 2017 Equifax breach exposed 147 million records partly because data sat unencrypted. Defense: LUKS, BitLocker, FileVault for disks; AES-256-GCM or AES-256-XTS for per-file or per-block.

The mistake is treating one as a substitute for the other. TLS doesn't protect a database dump. Disk encryption doesn't stop a man-in-the-middle attack.

How TLS 1.3 protects data in transit

TLS 1.3, standardized in RFC 8446 (2018), is the modern default. It uses:

• Forward secrecy by default via ephemeral ECDHE key exchange. Even if a server's long-term key leaks, past sessions stay protected.
• AEAD ciphers only — AES-128-GCM, AES-256-GCM, or ChaCha20-Poly1305. Old CBC modes and RC4 are gone.
• Single round-trip handshake (1-RTT), or zero round-trip (0-RTT) for resumption.
• Encrypted handshake so passive observers can't see the certificate chain.

Every reputable file transfer service — WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer — runs TLS 1.3 with HSTS headers enforcing HTTPS for at least 12 months. You can verify at SSL Labs' testssl tool; anything scoring below A- has configuration issues.

How at-rest encryption works on the server

Once files arrive and TLS terminates, at-rest encryption takes over. There are several layers:

• Block-level (full-disk): AES-256-XTS on LUKS (Linux), BitLocker (Windows), FileVault (macOS), or cloud-provider equivalents like AWS EBS encryption. Protects against stolen disks.
• Filesystem-level: eCryptfs, Fscrypt on ext4/F2FS. Each user's files encrypted with separate keys.
• Object-storage level: AWS S3 SSE-KMS, Azure Blob with Storage Service Encryption, Google Cloud Storage with customer-managed keys. Each object encrypted with AES-256-GCM.
• Application-level: the service encrypts each file in its own code before writing to storage, with keys held in a KMS or HSM.

Application-level is strongest because the encryption happens before any storage system sees the data. AWS KMS charges $1/key/month plus $0.03 per 10,000 requests — cheap enough that serious services use it per file.

The "keys next to ciphertext" trap

Here's where at-rest encryption commonly fails. If the keys are stored on the same server as the ciphertext, an attacker who breaches the server gets both. The provider can technically tick the "encrypted at rest" box for compliance while offering zero real protection against server compromise.

Good architectures separate concerns:

• Ciphertext on S3 or similar object storage.
• Encryption keys in AWS KMS, Google Cloud KMS, Azure Key Vault, or a dedicated HSM.
• Access to keys gated by short-lived IAM credentials and audit logs.

Great architectures go further: the keys never exist on the server at all. Client-side encryption (E2EE) means the user's browser generates the key, encrypts the file, and keeps the key. The server stores ciphertext and has nothing to leak.

Where encryption gaps appear

Even with both controls in place, data is briefly plaintext in several places:

• In server memory during upload processing, virus scanning, or thumbnail generation. A memory dump during this window reveals plaintext.
• In access logs if filenames or content snippets get logged for debugging.
• In backup tapes if backups don't inherit the same encryption.
• During compression or transcoding where the service processes file contents.
• In browser cache after download if the user doesn't clear it.

These gaps are why zero-knowledge (client-side) encryption matters. When files are encrypted in the browser before upload, the server-side gaps become irrelevant — the server only ever sees ciphertext.

What the big services actually do

A rough classification based on public documentation:

• Google Drive, Dropbox, OneDrive: TLS 1.3 in transit, AES-256 at rest with provider-held keys. Not zero-knowledge — the provider can read your files.
• WeTransfer (free tier): TLS 1.3, AES-256 at rest on AWS S3. Provider holds keys.
• Box Enterprise: TLS 1.3, AES-256-GCM at rest, optional customer-managed keys (Box KeySafe).
• Tresorit, Proton Drive, SwissTransfer E2EE tier, HexaTransfer: TLS 1.3 in transit, AES-256-GCM at rest, but the per-file keys are client-generated and never reach the server. Effectively zero-knowledge.

For sensitive data, only the last category provides meaningful protection against insider threats and valid legal demands.

Compliance and the "defense in depth" mandate

Regulators explicitly require both:

• GDPR Article 32 mandates "pseudonymisation and encryption of personal data" with no restriction on which state the data is in.
• HIPAA Security Rule 45 CFR § 164.312(a)(2)(iv) and (e)(2)(ii) requires encryption for ePHI both in transit and at rest.
• PCI DSS 4.0 Requirement 3 and 4 separates "protect stored cardholder data" (at rest) from "protect cardholder data with strong cryptography during transmission" (in transit).
• FIPS 140-3 validation applies to cryptographic modules used in both contexts.

Providing only one is a compliance failure even before it becomes a security failure.

How to verify both are active

Five quick checks for any file transfer service:

1. Run testssl.sh https://provider.com to confirm TLS 1.3 with strong ciphers only.
2. Check for HSTS headers with max-age of at least 31,536,000 (one year).
3. Read the security whitepaper for explicit mention of AES-256-GCM or AES-256-XTS at rest.
4. Confirm keys are held in a KMS or HSM, not the application database.
5. Look for SOC 2 Type II or ISO 27001 certification — both require documented at-rest and in-transit controls.

Bonus: check if client-side encryption is available as an option. If yes, turn it on for anything sensitive.

Layering them correctly

The pattern that actually works:

1. Browser encrypts file with a random AES-256-GCM key (client-side).
2. Ciphertext travels over TLS 1.3 to the server (in transit).
3. Server stores ciphertext on AES-256 encrypted storage (at rest).
4. Decryption key lives only in the share URL fragment, never sent to the server.

Three independent layers. Break one, the others hold. This is the design HexaTransfer uses, along with Tresorit Send, Proton Drive share links, and SwissTransfer's E2EE mode.

Try it at hexatransfer.com — free, no account, 10 GB max.