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, stored payloads are ciphertext. That does not make every server compromise harmless: stolen authentication secrets can enable password guessing, and malicious client code can capture unlocked keys. The OPAQUE security boundaries explain that distinction. Account, routing, sharing and resource metadata can still be available to the provider.

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 is stored in an encrypted envelope and opened on your device. OWL’s OWPK v2 envelope is protected by a key derived from the client-only export key produced by OPAQUE.
  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. OPAQUE authenticates password sign-in, while account policy and required multi-factor authentication control session issuance. That login layer is separate from the AES keys used to encrypt files.

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. OWL recovery uses that user-held model: your device encrypts the account private key under a recovery key you save. The operator stores only the encrypted envelope, so enabling recovery preserves 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 usable decryption keys stay on authorized devices: 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; user-held recovery keeps the account private key encrypted under a key you control. SSD is outside the zero-knowledge boundary; user-held recovery stays inside it. For the full step-by-step flow, see OWL Encryption.

References & Further Reading