What is zero-knowledge encryption?

A design where the service provider has no technical ability to read user content. Keys never reach the server in usable form; only encrypted data does.

Is end-to-end encryption the same as zero-knowledge?

Related but not identical. End-to-end describes a transport guarantee (sender to recipient, no readable middle). Zero-knowledge describes a storage and architectural guarantee (the server has no knowledge of keys or content).

Why can't DRIVUNO reset my password?

Because your password derives the master key that wraps your file keys. If we could reset it into a working vault, we would have either escrowed your key or weakened the encryption. We do neither.

Educational

Encryption Explained

A guide for people who don't write cryptography for a living. Read this once and you'll understand exactly what DRIVUNO is doing — and why it matters.

1 · The two models

Most clouds use server-side encryption: the provider encrypts your files on their servers using keys they manage. It's better than nothing, but the provider holds both the lock and the key.

DRIVUNO uses client-side encryption: your device encrypts files before they leave it, with keys derived from a password only you know. The provider only ever sees scrambled bytes.

Capability

Server-side encryption (typical cloud)

Client-side / zero-knowledge (DRIVUNO)

Where keys live

On the provider's servers

On your device only

Provider staff can read

Yes, with operator access

No — they hold ciphertext

If the database leaks

Files may be exposed

Files remain encrypted

If the provider is compelled

Plaintext can be produced

Only ciphertext can be produced

Password reset by support

Possible

Architecturally impossible

2 · What “zero-knowledge” really means

Zero-knowledge is a property of the system, not a marketing word. It means we have no technical way to read user content, even with full administrative access to our own infrastructure. Not “we promise not to look” — “we built it so we cannot look.”

3 · Why encryption before upload matters

A leak becomes a non-event

If our database is exfiltrated, the attacker holds the same encrypted bytes we hold. Without your password, those bytes are useless.

Compelled disclosure is bounded

We can only produce what we have. With ciphertext-only storage, even a court-ordered handover yields encrypted bytes the requester still cannot read.

Operator risk is eliminated

A rogue DBA, a misconfigured backup, a leaked admin token — none of these expose plaintext, because plaintext is not on our servers in the first place.

The product gets simpler

We don't run AI on your files, content moderation, or analytics on what you upload — architecturally we can't, so we don't.

4 · Recovery keys, and why they matter

Because we cannot read your password, we cannot reset it. To prevent permanent lockout, you can set up recovery factors: a Recovery Key (a string you write down), a secondary email, and SMS. Each factor independently wraps your master key on your device — never on our server.

The honest part

If you lose your password and all your recovery factors, your vault is unrecoverable. That is the cost of the architecture. We strongly recommend setting at least two factors.

5 · The cryptographic primitives

Argon2id — turns your password into a strong key, slowly enough to defeat brute force.
XChaCha20-Poly1305 — encrypts your file bytes and detects any tampering.
X25519 — lets us seal a file key for a specific recipient, including future shares.
Ed25519 — signs share manifests so a tampered link is detected, not silently followed.
SHA-256 — fingerprints the ciphertext, so we verify before decrypting.

All standard, peer-reviewed primitives. No homebrew cryptography.

Want the implementation detail? Read the architecture page or the whitepaper.