Encryption architecture

Everabyte uses a layered encryption architecture. Files are encrypted by Everabyte’s application services before they are written to storage, and Everabyte’s storage infrastructure applies an additional, independent layer of encryption at rest. Objects are therefore protected through their whole lifecycle: in transit over TLS, in the application layer, and at rest. Decryption operations are governed by account-owner authorization. No Everabyte service can retrieve or use an account-owner-controlled decryption key, or access decrypted file content, without a corresponding operation authorized by the account owner. Authorized operations, including file downloads and version restoration, are processed through controlled workflows with appropriate authentication and access permissions. This page describes the model as implemented. It is deliberately precise about what the encryption model does and does not protect against, because the difference matters for your own security review.

​

The encryption pipeline

At a high level, for every file version:

1. A per-file AES key is derived from a hybrid key encapsulation step.
2. The file is encrypted with AES-256-GCM in streaming mode, in 64 KB chunks.
3. Each chunk is authenticated as it is written; tags are verified as it is read.
4. The encrypted file and its per-file key envelope are stored.
5. The AES key itself is never persisted. It is recomputed on demand from the envelope and the owning key chain.
6. Once written, the stored object is additionally protected by the storage infrastructure’s independent encryption-at-rest layer.

Because encryption is streaming, the server does not buffer a whole object in memory to process it. This is what makes large uploads and range downloads work without weakening the encryption.

​

Key hierarchy

Master keys wrap the user key chains; the user key chains wrap the per-file envelopes; the envelopes wrap the per-file AES keys. Each level is distinct and must not be described interchangeably. The hybrid-e2ee-v1 string you may see in internal metadata is a key-derivation label that is part of the on-disk format. It is a protocol identifier, not a product claim. Renaming it would break decryption of existing objects.

​

Hybrid post-quantum key encapsulation

Per-file keys are wrapped using two mechanisms together:

• X25519, a widely deployed elliptic-curve Diffie-Hellman function.
• ML-KEM-768, a post-quantum key encapsulation mechanism.

The file key is derived from both shared secrets, so an attacker would need to break both to recover a file key from an envelope. The hybrid design pairs a classical mechanism with a post-quantum one; it is not an absolute quantum-safety guarantee. It also does not change who is authorized to request a decryption.

​

The recovery phrase

Users can hold a BIP39 recovery phrase that wraps their private key in the browser. The mnemonic never reaches the backend; the platform stores only the wrapped key material, a derivation salt, and a fingerprint of the phrase. Its function is specific:

• The recovery phrase restores your key chain through the platform’s recovery flow, verified with a proof derived from the phrase.
• It is distinct from the master keys, from the per-file keys, and from the decryption key it protects. It is not a second copy of your files.
• An ordinary password reset by email does not disturb the key chain, so file access continues afterwards.
• The phrase must still be treated as a high-value secret by the user.

​

Encryption in transit

Traffic between clients and Everabyte is served over TLS. Do not terminate TLS with an untrusted certificate or downgrade clients; the API expects HTTPS. Requests between the platform’s internal services are authenticated with service credentials and request signing.

​

Integrity verification

The platform runs a scheduled integrity process that re-reads stored objects, decrypts them inside the platform’s controlled services, and compares the result against a plaintext SHA-256 recorded at write time. Every AES-GCM authentication tag is verified as the object is read. This detects silent corruption introduced below the application layer. Verification runs in budgeted passes rather than covering every object every day. On a mismatch, the platform alerts the account owner, records the event in the audit trail, and exposes status through compliance-gated views; corrupt objects are reported, not silently removed. Restore testing follows the same idea: a sample from a restore point is decrypted and verified server-side, and backup jobs can additionally schedule verification tests that the desktop agent performs locally, restoring a sampled set into an isolated directory. Combined with version history, this is how the platform demonstrates that backups are usable, rather than merely present.

​

What the model protects against — and what it does not

​

CDN delivery

On enterprise plans, file delivery can optionally go through a CDN. When enabled, the platform streams decrypted bytes to the edge over a token-protected origin path, and the edge serves the object through signed URLs. Signed-URL validity is configurable per company — 5 minutes to 30 days, 6 hours by default — and edge caches hold the object for up to 30 days under versioned cache keys. Hard deletes and access revocations purge the edge cache. That is a real trade-off: it improves latency, and it means decrypted content exists at the edge for as long as it is cached. If your threat model excludes that, use the origin stream route and keep CDN delivery disabled for those buckets.

​

Design guidance for integrations

• Treat fileId and versionId as the authoritative identifiers. Filenames are display metadata.
• Do not assume the platform validates a client-supplied checksum. If you need integrity assurance on your side, hash the plaintext yourself and compare after download.
• Do not store encryption key material you obtain from the platform in logs, analytics, or error reports.
• Remember that scopes and bucket restrictions, not encryption, are what limit blast radius from a leaked key.

​

Related