TL;DR
- The server cannot read your data. Files are encrypted on your device with a key that never leaves your devices. The relay holds opaque ciphertext, opaque identifiers, and hashed tokens — nothing else.
- Compromising the relay (or a malicious operator, or a subpoena) yields ciphertext only.
- No plaintext, no file names/paths, no encryption keys ever reach the server.
Cryptography
| Element | Design |
|---|---|
| Workspace root key | 32 bytes, generated on the first device. Never transmitted to the relay. Shared to your other devices only inside the pairing code, out-of-band. |
| Subkey derivation | SHA-512 domain separation from the root key (enc, path subkeys). |
| File encryption | XSalsa20-Poly1305 (NaCl secretbox), convergent SIV-style nonce (keyed MAC of the plaintext) so identical content deduplicates. Authenticated — tampered ciphertext is rejected. |
| Large files | Chunked into ~48 MB sealed blobs plus a sealed manifest — the relay sees only opaque parts. |
| Auditability | Zero-content server audit trail, op-log integrity high-water marks, self-healing clients with local logs. |
| Path identifiers | HMAC-SHA-256 keyed by a path subkey, so the relay sees opaque IDs, never real file paths. |
| In transit | TLS 1.2+ (Let's Encrypt). |
| At rest (server) | Already ciphertext; the host volume can additionally be disk-encrypted. |
Key loss = data loss, by design. If you lose every device and the pairing code, the encrypted data on the relay is unrecoverable. Neither we nor the operator can recover it. This is the cost of zero-knowledge.
What the relay can and cannot see
Stores: encrypted blobs {nonce, ciphertext} addressed by content hash; an append-only op-log of {opaque-path-id, blob-hash, deleted, timestamp, device-id}; hashed device/join tokens; per-workspace and total byte counters.
Never sees: file contents, file names or paths, directory structure, the root key, or your identity.
Authentication & access control
- Per-device bearer tokens, stored only as SHA-256 hashes on the server. A leaked server DB does not yield usable tokens.
- Signup keys gate workspace creation. Multiple keys are supported so one can be issued per customer and revoked individually.
- Join tokens (in the pairing code) authorize adding a device; the pairing code also carries the root key, so it must be treated as a secret and shared only over a private channel.
Multi-tenant isolation & abuse resistance
- Each workspace is stored separately and reachable only with that workspace's device token.
- Per-workspace storage quota, per-blob size cap, and a relay-wide storage budget bound disk use.
- Per-IP rate limits on workspace creation and writes mitigate abuse/DoS.
- Workspace count cap bounds tenancy.
Operational security
- Host access is SSH-key-only (no passwords); the relay listens on localhost and is reachable only through the TLS reverse proxy.
- Daily encrypted-at-source backups with rotation; restore is a tar -xzf of ciphertext.
- Admin metrics endpoint (key-gated) for usage vs. quota monitoring — exposes counts only, never data.
Threat model (summary)
| Threat | Outcome |
|---|---|
| Relay server fully compromised | Attacker gets ciphertext + opaque metadata. Cannot read files without the client-side root key. |
| Malicious/compelled operator | Same — operator has no key material and cannot decrypt. |
| Network attacker (MITM) | Blocked by TLS; blobs are also independently authenticated-encrypted. |
| Leaked server database | Tokens are hashed; blobs are ciphertext. No plaintext exposure. |
| Leaked pairing code | Holder can join the workspace and decrypt. Treat the pairing code as a password. |
| Lost all devices + pairing code | Data is unrecoverable (by design). |
Honest current limitations
- The desktop installer is not yet code-signed (Windows SmartScreen warns on first run).
- No formal SOC 2 yet — the zero-knowledge design intentionally minimizes the data-handling surface a SOC 2 would cover; a formal report can be pursued when a customer requires it.
- Relay currently runs in a single region on one host; horizontal redundancy is planned.
- Rate-limiting is per-IP and in-memory (per relay node).
Contact
Security questions or disclosures: alexislancysavino@gmail.com.