File sharing is one of the oldest internet use cases and one of the least well-understood from a security perspective. "Send me the file" can mean a dozen different things, with security properties ranging from fully transparent to robustly encrypted, and most of the difference is invisible to the person clicking "attach."
The Chain of Custody Problem
A file's security is only as good as the weakest point in its journey from sender to recipient. That journey typically involves more stops than people realize:
- The sending device and its local storage
- The sending application's processing of the file (resizing, compression, thumbnail generation)
- The service's servers — where the file is uploaded, stored, and served from
- The network path the file travels over
- The receiving application's processing
- The receiving device and where it stores the downloaded file
End-to-end encryption, when correctly implemented, addresses the middle three: the service's servers hold ciphertext, and the network sees ciphertext. It does not address the endpoints — what your application does before encrypting, and where the file lands after decryption.
Encryption in Transit vs. Encryption at Rest
These two properties are distinct and frequently confused:
Encryption in transit means the file is encrypted while traveling over the network. HTTPS provides this for web transfers. Almost every file-sharing service does this. It protects against network interception but says nothing about how the file is stored at the destination.
Encryption at rest means the file is encrypted while stored on a server or device. It protects against someone who gains access to the storage medium without going through the normal authentication path. Again, almost every cloud storage service provides some form of server-side encryption at rest. The key question is who holds the decryption key.
End-to-end encryption is the combination where the file is encrypted before it leaves your device, using a key that the intermediary service does not have. Even if the service's servers are compromised, or the service receives a legal demand, the file content is inaccessible without the key held only by the sender and recipient.
Can the file-sharing service send you a password reset and restore access to your files? If yes, they hold your decryption keys — which means a court order or data breach can expose your file contents. If your files become permanently inaccessible when you forget your passphrase, you hold the keys. The first model is convenient; the second is secure.
Tools for Genuinely Secure File Sharing
Several tools offer meaningful end-to-end file encryption with different design trade-offs:
| Tool | E2E Encryption | Requires Account | File Persistence | Best For |
|---|---|---|---|---|
| OnionShare | Yes (Tor + AES) | No | Ephemeral (served from sender's machine) | High-sensitivity one-off transfers; no third-party servers |
| magic-wormhole | Yes (PAKE key exchange) | No | Ephemeral (direct transfer) | Simple CLI-driven encrypted transfers between known parties |
| Signal | Yes (Signal Protocol) | Phone number | Stored on Signal servers briefly; deleted after delivery | Everyday file sharing with Signal contacts |
| age (CLI) | Yes (X25519 / Scrypt) | No | You manage storage | Encrypting files for static storage or email attachment |
| Cryptomator + cloud drive | Yes (AES-SIV + AES-CTR) | Cloud provider account | Persistent in encrypted vault | Sharing folders of files ongoing with a trusted recipient |
| WeTransfer / Google Drive (standard) | No (server-side only) | Varies | Persistent, provider-readable | Non-sensitive file sharing where convenience matters most |
OnionShare takes a fundamentally different architectural approach: your computer becomes the server. Files are served over a Tor hidden service directly from your machine. There are no third-party servers involved, no file uploaded anywhere, no account needed. The recipient gets a .onion URL and downloads the file directly from you. The connection is end-to-end encrypted by Tor's layered encryption. The limitation is that both parties need to be online simultaneously for the transfer.
magic-wormhole uses a password-authenticated key exchange (PAKE) to establish a shared secret between two parties. You run wormhole send file.pdf, receive a short code phrase (like "7-guitarist-revenge"), share it with the recipient out-of-band, and they run wormhole receive 7-guitarist-revenge. The relay server facilitates the handshake but never sees the file content. This is elegant for command-line users who want a quick, authenticated transfer without managing keys.
age is a modern file encryption tool designed as an alternative to GPG for static file encryption. You encrypt a file to a recipient's X25519 public key (or to a passphrase using Scrypt). The result is a self-contained encrypted file you can send over any channel — email attachment, cloud storage link, USB drive. age does not handle key discovery or delivery; it handles only the encryption. That is a feature, not a limitation — it does one thing and does it correctly.
What Cloud Storage Providers Actually Encrypt
Dropbox, Google Drive, Box, and OneDrive all encrypt files in transit and at rest. All of them use server-side encryption with keys they manage. All of them can comply with legal demands to produce file contents. All of them have the technical capability to scan file contents for policy violations (CSAM detection, for example), which confirms they can access plaintext.
This does not make them bad products. For most non-sensitive file sharing, server-side encryption is entirely appropriate. The problem arises when users assume "encrypted" means their cloud provider cannot read the files. It does not.
"Encrypted at rest" from a cloud provider usually means: encrypted using a key the provider manages, so that someone who steals the physical storage hardware cannot read your files. It does not mean encrypted from the provider.
The Metadata That Survives
Even with strong content encryption, file transfers generate metadata that is often not encrypted and can be highly informative:
- Filename — often transmitted in the clear or inferrable from request patterns, even when file contents are encrypted
- File size — reveals approximate content volume; can be used to identify files by matching against known-size databases
- Transfer timing — when you send a file and to whom reveals relationship patterns
- EXIF and document metadata — photos carry GPS coordinates, camera model, and creation timestamps embedded in the file itself; Word documents carry author name, revision history, and printer information. These survive content encryption because they are part of the content.
EXIF stripping is a step that should happen before sensitive file sharing. On Linux, exiftool -all= file.jpg removes all EXIF data. Signal strips EXIF from photos before sending. Most other services do not. Document metadata can be removed with tools like mat2 (Linux) or LibreOffice's document sanitization tools.
After the Download: The Endpoint Problem
A file shared over an end-to-end encrypted channel arrives at the recipient's device decrypted. What happens to it then is outside the scope of the E2E encryption guarantee.
On iOS, a file received via Signal may be saved to the unencrypted Photos library or Files app. On Android, downloads often land in a world-readable downloads folder. On macOS, files saved to the Desktop or Downloads folder are indexed by Spotlight, synced by iCloud, and backed up unencrypted unless Advanced Data Protection is enabled.
This is not a failure of the file-sharing tool. It is an inherent limitation of end-to-end encryption: the endpoint is the point where trust assumptions end. Securing the transport is necessary but not sufficient; the file's life after delivery is the sender's and recipient's joint responsibility.
This connects to the broader encryption picture covered in what end-to-end encryption actually protects. The short version: E2E encryption protects your data from the service provider and from interception in transit. It does not protect your data from someone who compromises your endpoint, from forensic examination of a device in custody, or from a recipient who chooses to share what they received.