Encryption & Security

End-to-End & Zero-Knowledge Encryption

Most cloud services encrypt your files — but they also hold the keys, which means they can read your data, and so can anyone who compromises them. End-to-end and zero-knowledge encryption flip that around: the data is sealed on your device and stays sealed, so the service stores your files without ever being able to open them. This is the model NDEVR OWL is built on.

End-to-end (E2EE)
Data is encrypted on the sender's device and only decrypted on the recipient's — never readable in between.
Zero-knowledge
The service can prove it stores your data without ever being able to read it. It holds only ciphertext.
The key rule
Encryption keys are generated and kept on your devices. They never reach the server in usable form.
Built from
AES + public keys + ECIES + hashing & KDFs.

What "End-to-End" Means

End-to-end encryption (E2EE) means data is encrypted at one endpoint — your device — and can only be decrypted at another authorized endpoint. At no point in between, including on the servers that route or store it, is the data readable. Compare this with ordinary “encryption in transit” (HTTPS) and “encryption at rest,” which protect the data on the wire and on disk but leave the provider holding the keys — so the provider, and anyone who breaches it, can still read everything.

What "Zero-Knowledge" Means

Zero-knowledge describes the service's position: it has zero knowledge of your plaintext. It faithfully stores and delivers your encrypted files, manages accounts, and enforces sharing — all while being mathematically unable to read what it holds, because the keys never leave your control. The practical upshot is powerful:

If the server is breached, attackers get only scrambled bytes. If served a subpoena, the provider can hand over only ciphertext it cannot decrypt. Privacy is guaranteed by mathematics, not by a promise.

How the Pieces Combine

Zero-knowledge isn't one algorithm — it's how the standard building blocks fit together:

  1. Each file is sealed on your device with a fast, strong AES-256 key.
  2. Every account has a public/private key pair; the public half is shared, the private half stays on your device, encrypted with a key derived from your password via PBKDF2.
  3. To share a file, its AES key is ECIES-sealed to each recipient's public key — so only their private key can unwrap it.
  4. Hashing protects passwords (bcrypt) and verifies tokens, so the server never stores anything that could unlock your data.

Because access lives in these wrapped keys rather than in the file, you can grant or revoke a person's access instantly — without re-uploading or deleting anything.

The Honest Trade-offs

★

If only you hold the keys, only you can recover them

True zero-knowledge means the provider cannot reset your access by reading your data — there's no back door, by design. Systems handle this with optional recovery keys you store yourself, or escrow you explicitly opt into. It's the deliberate cost of a provider that genuinely cannot read your files: you, not a help desk, are the ultimate key-holder.

There's also a spectrum. Browser-based access can be weaker than a native app, because code delivered fresh by a server is harder to trust than installed software. Strong systems are transparent about where each mode sits — and steer the most sensitive operations toward the most trustworthy endpoint.

NDEVR OWL in Practice

NDEVR OWL applies this model to file storage and sharing: files are AES-256-sealed before upload, keys are ECIES-wrapped per recipient, and the server holds only ciphertext. OWL even lets you choose, per share, between server-side and client-side decryption depending on whether you trust the provider or your collaborators more — with neither side ever gaining the other's key. For the full step-by-step flow, including how OWL links are minted and read, see OWL Encryption.

References & Further Reading