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: protected content is sealed on one endpoint and stays sealed until another authorized endpoint opens it. NDEVR OWL applies this model to client-side-decrypted (CSD) resource and chat content — not to every OWL mode or surface.

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 stores protected content without possessing a usable key to read it. It holds ciphertext.
The key rule
Content keys are generated and kept at authorized endpoints. They never reach the service in usable form on the covered path.
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 for a defined class of content: it has no usable key for that plaintext. It can store and deliver encrypted files, manage accounts, and enforce sharing while being cryptographically unable to open the covered payload. The practical boundary looks like this:

For content inside that boundary, a server breach or disclosure yields ciphertext rather than plaintext. Account, routing, sharing and resource metadata can still be available to the provider. Content confidentiality rests on cryptography rather than solely on provider policy.

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 password verifiers (bcrypt) and validates tokens; these authentication records are separate from the CSD content keys.

Because future access lives in server authorization and wrapped-key delivery, a grant or revocation can take effect without re-uploading the file. Revocation prevents later retrieval and key fanout; it cannot erase plaintext, a Content Key or ciphertext that an authorized recipient already retained.

The Honest Trade-offs

★

If only your endpoints hold usable keys, only those endpoints can recover content

In a provider-blind path, the provider cannot reset access by reading the protected payload. A recovery key you hold yourself can preserve that property. Provider-held escrow is different: when you opt into OWL account recovery, the operator can recover your account private key and then content keys wrapped to that account. Recovery is therefore an explicit provider-trust choice, not part of the zero-knowledge boundary.

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.

Content encryption also does not hide every fact about using a service. Account identity, resource and sharing metadata, recipients, routing and timing remain outside OWL's content-confidentiality claim. Public authored Sites are deliberately published as plaintext web pages, not stored as zero-knowledge resources.

NDEVR OWL in Practice

NDEVR OWL applies this model to CSD resource and chat content when provider-held recovery is disabled: payloads are sealed before upload, recipient keys are wrapped with ECIES, and the server stores and routes ciphertext without a usable content key. In server-side decryption (SSD), the client sends the Link Key and the server decrypts the requested content; provider-held recovery can recover the account private key and account-wrapped content keys. Both are explicit provider-trust modes outside the zero-knowledge boundary. For the full step-by-step flow, see OWL Encryption.

References & Further Reading