Encryption5 min read•
Encryption before upload: the real difference
Almost every cloud claims to be 'encrypted'. The architectural question is whether encryption happens before your file leaves your device.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.
Three timings of encryption A file can be encrypted at three different moments. The timing decides who can read it.
- **At rest, on the server.** The provider stores files on encrypted disks. Protects against stolen hardware. Does nothing against the provider itself.
- **In transit.** TLS protects the upload from network eavesdroppers. Does nothing once the file lands.
- **Before upload, on the device.** The file is sealed locally. What leaves your device is already ciphertext.
Only the third model removes the provider from the trust chain.
Why "before upload" changes everything If encryption happens after upload, the provider's systems necessarily see plaintext at some point — to encrypt it, to preview it, to index it, to run AI features. If encryption happens before upload, that window does not exist. The provider receives ciphertext and only ever holds ciphertext.
What the server actually receives - An opaque ciphertext blob. - A wrapped per-file key, encrypted under your master key. - Minimal metadata — size, timestamp, account id — needed to deliver the service.
Nothing else. No filenames as plaintext in the envelope, no thumbnails generated server-side, no content indexing.
The DRIVUNO model DRIVUNO encrypts every file on your device before it touches the network. The master key is derived from your password using Argon2id and never leaves your device. The upload is ciphertext from byte one. Encryption is not a server feature in DRIVUNO — it is a property of the file by the time the cloud sees it.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.