Architecture7 min read•
Secure file sharing architecture: how a link can be safe by design
Most "secure" sharing is access control on readable files. Here is the architecture of a share link that stays confidential even from the provider hosting it.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.
Two very different meanings of "secure sharing" The common one: the file sits readable on a server, and a permission table decides who may fetch it. Security equals correct configuration, forever, by everyone.
The architectural one: the file is ciphertext everywhere, and sharing means delivering a key to a specific person. A misconfiguration then exposes bytes nobody can read.
The components of a zero-knowledge sharing model - **Per-file keys.** Every file gets a fresh symmetric key (XChaCha20-Poly1305), so sharing one file never exposes another. - **Key envelopes.** For a named recipient, the file key is sealed to their public key (X25519). Only their device can open it. - **Fragment-carried keys for public links.** For a link recipient who has no account, the key travels in the URL fragment — the portion browsers never send to a server — so the host never receives it. - **A passphrase layer.** The fragment key is additionally protected by a passphrase stretched with Argon2id, so an intercepted link alone is not enough. - **Short expiry by default.** Every public link stops working quickly, because an eternal link is an eventual leak. - **Rotation on revocation.** Removing a member re-wraps the remaining keys, so the copy they held stops matching.
What the server is allowed to know Ciphertext, sealed key envelopes, sizes, timestamps and the blind-index tags your device produced for search. Not filenames in the clear, not contents, not the key.
Why folder-level sharing is harder than file-level A shared folder must let new files inherit access without re-inviting anyone. DRIVUNO handles this with a folder key sealed once per member: new files are wrapped to the folder key, and removing a member rotates it. That keeps membership changes cryptographic rather than administrative.
Threats this design actually addresses - A leaked or over-shared link, because the key is not on the server. - An insider or compelled disclosure at the provider, because there is nothing readable to disclose. - A stolen backup, because snapshots are encrypted before leaving the platform. - Silent expansion of access, because access is a key envelope, not a row in a table someone can edit.
The trade-off, stated plainly You cannot ask us to reset your password and still see your files, and we cannot preview your documents for you server-side. Those missing capabilities are the proof the model is real.
Try it in one click.
Three private surfaces. Same zero-knowledge architecture.