Zero-Knowledge SDK

The Everabyte Zero-Knowledge SDK is the client-side encryption library for Everabyte integrations. It encrypts file contents and file names on your machine, before any network call. For files processed through this SDK, Everabyte’s servers store opaque ciphertext and never receive the keys that open it — there is no server-side decryption path and no key escrow. This is the same protocol (evb-e2ee-v1) executed by the Everabyte web, desktop and mobile apps. The SDK is a byte-exact, cross-language implementation of that wire format: a file encrypted with one binding decrypts with every other, and compatibility is enforced in CI through a shared frozen test-vector grid plus the official test vectors of the underlying standards.

Which language, which mechanism

Repository: everabyte/crypto-sdk. PHP, Java, C# and Go all speak the same stable C ABI (reference) — any other language with a C FFI can integrate identically.

How a zero-knowledge file flows

Every step below runs client-side except the two network calls, which only carry ciphertext, opaque aliases and wrapped keys:

1. Enroll once. Generate the account key (UMK: X25519 secret 32 B + ML-KEM-768 seed 64 B) and a 12-word BIP-39 recovery phrase. Register the public keys and the wrapped copies: POST /e2ee/keys/register.
2. Per file, generate a data key (DEK, 32 random bytes) — it is never persisted anywhere.
3. Encrypt the content locally: AES-256-GCM in authenticated 64 KiB chunks (EVB1 wire format).
4. Name substitution: the upload filename becomes a deterministic opaque alias (evb-<hex64>); the real name travels only as an AES-256-GCM blob under the DEK.
5. Wrap the DEK to the account key with HPKE (RFC 9180, mode PSK carrying the ML-KEM-768 shared secret), upload the ciphertext, and attach the envelope: POST /e2ee/files/by-path/envelope.
6. Download = fetch envelope + ciphertext, unwrap the DEK, decrypt locally. The restored file is byte-identical to the original.

If attaching the envelope fails, the file is not usable as a zero-knowledge file. On a timeout, reconcile the result using the returned file identifier and GET /e2ee/files/{fileId}/envelope before taking action. After a confirmed attach failure, the E2EE upload contract requires deleting the orphaned ciphertext row. Resolve its identifier from the bucket listing if necessary, confirm no envelope is attached, then hard-delete it through the file API; retention policy may prevent deletion and must be handled explicitly.

Mandatory for new accounts

Accounts created on or after 2026-11-13 are zero-knowledge by default (zkRequired). For these accounts:

• uploads must be client-encrypted — files that arrive unencrypted are refused on download (403) and swept after a grace window;
• the Everabyte apps enforce this natively; custom integrations enforce it by following the quickstarts above;
• legacy accounts keep the opt-in path — client-side encryption is optional and existing files migrate through the in-app controls (migration).

Standards conformance

The HPKE key schedule is byte-exact against RFC 9180 §A.1.1/A.1.2 (both sender and receiver side); the GCM/HKDF constructions match the official published vectors. Compliance tests run in the SDK repository and fail the build on any drift.

What the SDK does — and what stays in your application

The split is deliberate: your key custody model stays yours. The SDK never opens a network connection and never logs key material. Browser code must not contain an Everabyte secret API key; route authenticated REST calls through your own backend. That backend can relay ciphertext and wrapped envelope data without receiving the UMK, DEK or recovery phrase.

What the model protects — and what it does not

Protected: the content and the names of zero-knowledge files, against Everabyte’s services, operators and infrastructure providers. No operator console, maintenance job or database read can produce their plaintext. No escrow: with every enrolled device and the recovery phrase lost, the data is unreadable by anyone — including Everabyte. Not protected:

• Technical metadata the product requires: file/folder sizes, timestamps, the folder tree, the sharing graph, quotas and access logs. Visible to the service in both encryption models.
• Deliberate sharing. A share recipient — or anyone holding a public link — holds the decryption key material for that file, by design.
• A compromised device, or a tampered client on it. Encryption happens where the SDK runs; protect the host.
• The web app delivering its own code — native bindings (this SDK) remove that dependency for custom integrations.
• Recovery failure. No enrolled device + no recovery phrase = no recovery. There is nothing for support to reset.

Where to go next