← Blog
Collaboration5 min read

Secure collaboration without compromise

You can share files with confidence without giving your provider a copy of the plaintext. Here is how recipient-keyed sharing actually works.

Try it in one click.

Three private surfaces. Same zero-knowledge architecture.

The collaboration paradox Most cloud sharing models work by giving the provider's server enough access to mediate the exchange — server-readable URLs, permission tables tied to plaintext, previews generated on the server. That makes sharing easy. It also makes the provider a participant in every conversation.

Secure collaboration means designing sharing so the provider is a transport, not a participant.

How recipient-keyed sharing works When you share a file with another DRIVUNO user, your client wraps the per-file key under that user's public key (X25519 sealed box). The server transports the wrapped key from your device to theirs — but cannot decrypt it.

The result: - Only the intended recipient can decrypt. - The server sees ciphertext on the way in and ciphertext on the way out. - Revoking access is a key-rotation event, not a permission flip.

What this changes day to day - No public link that anyone with the URL can follow. - No silent server-side previews of shared documents. - No "anyone at the company" sharing tier that quietly widens the audience. - Clear, auditable records of who was granted access.

DRIVUNO's collaboration model DRIVUNO is designed so that collaboration does not require lowering the confidentiality bar. The same architecture that protects a private file protects a shared one.

The traditional trade-off Collaboration tools usually require the provider to read your data — for previews, comments, search, AI summaries. That is convenient and it is also why most "encrypted" collaboration is not actually end-to-end.

How DRIVUNO threads the needle Files are encrypted with a per-file symmetric key. Sharing wraps that key for each recipient's public key. Each collaborator decrypts locally; the server still sees only ciphertext. Comments and annotations follow the same model: encrypted client-side, opaque server-side.

What collaboration looks like in practice Invite a counterparty by email, their client receives a wrapped key, they read and respond — the provider mediates the transport, not the content. Revoke access and their wrapped key disappears. Cryptographic, not policy-based.

Try it in one click.

Three private surfaces. Same zero-knowledge architecture.

Encrypted on your device · upload in 1 click
Upload