Skip to main content
Alongside the layered server-side encryption described in Encryption architecture, Everabyte offers a client-side encryption model in which file content and file names are encrypted on your device, before any network call. For files in this model, Everabyte’s servers store opaque ciphertext and never receive the keys that open it. This is the model the Everabyte web, desktop and mobile apps execute natively, and the one the Zero-Knowledge SDK exposes to custom integrations.

How it works

  1. Your device generates an account key (X25519 + ML-KEM-768, FIPS 203) and shows you a 12-word recovery phrase (BIP-39). Only the public keys and wrapped copies of the account key are registered; the phrase and the private material stay with you.
  2. Every file gets a fresh data key. The file is encrypted with AES-256-GCM in authenticated 64 KB chunks (NIST SP 800-38D), on your device.
  3. The data key is wrapped to your account key using HPKE in PSK mode (RFC 9180 — X25519 with an ML-KEM-768 secret), and only then uploaded together with the ciphertext.
  4. The file’s name is replaced in transit by a deterministic opaque alias; the real name travels only as an encrypted blob.
  5. On download, your device unwraps the data key and decrypts locally. Decryption of zero-knowledge files happens exclusively on devices holding the account key.
Everabyte’s servers never perform a decryption step for these files. There is no escrow: if you lose every enrolled device and the recovery phrase, the files are unreadable by anyone — including Everabyte. This is a property of the model, not a recoverable defect.

Who gets it by default

  • Accounts created on or after 2026-11-13 are zero-knowledge by default: the apps require an activated key chain before uploading and do not fall back to server-side encryption for them. Everabyte apps prompt enrollment on first use; custom integrations use the Zero-Knowledge SDK.
  • Earlier accounts adopt it deliberately: enroll in Settings → Security, then use the migration controls on the same page (see Migrating legacy files).

What Everabyte stores for a zero-knowledge file

What the model protects — and what it does not

Stated plainly, the same way the server-side model is stated: It protects the content and the names of zero-knowledge files against Everabyte’s own services, operators, and infrastructure providers: no operator console, maintenance job, or database read can produce their plaintext. It does not protect:
  • Technical metadata that the product requires to function: file and folder sizes, timestamps, the folder tree, the sharing graph, quotas and access logs. This is visible to the service in both models.
  • People you share with, by design. A recipient of a shared file, or anyone holding a public link, holds the decryption key material in that share or link.
  • A compromised device. Encryption happens on your machine; if the machine or an installed application is compromised at the moment of encryption or decryption, that local session is exposed. The web app executes code delivered by the server — native apps and the SDK remove that specific dependency for custom integrations.
  • Recovery failures. Zero-knowledge files are not recoverable from Everabyte without an enrolled device or the recovery phrase. Account-level recovery cannot restore what the account no longer holds.
These limits follow from the client-side key custody model described on this page. Product behavior can differ between providers; this page makes no claim that another provider has identical limits.

Working with zero-knowledge files

  • Apps: upload, download, preview, share and restore work transparently once the key chain is activated and unlocked for the session.
  • Custom integrations: the Zero-Knowledge SDK provides the identical wire protocol in Rust, TypeScript/WASM and Dart.
  • Migrating existing files: see Migrating legacy files.
  • Wire format: fully specified in the protocol reference — validated byte-for-byte against the official RFC 9180 / NIST / RFC 5869 test vectors and a cross-language vector grid shared by every client.