The threat model, in one page
Who we defend your documents against, who we do not, and the residual risks we would rather state than hide. The whole model on one page, for a reviewer with ten minutes.
Every security claim is a claim against someone. Saying a product is “secure” means nothing until you say what it is secure against, and what it is not. This page is that statement for Sapherbox, written to be read in ten minutes and checked against the longer documents. The whitepaper has the mechanisms; this has the boundaries.
What is being protected
Three things, in order of importance: the content of your files, the names of files and folders, and the keys that open them. All three exist in plain text only on your devices. The server stores ciphertext, sealed keys and public keys. A fourth category, metadata, is protected less, and the honest part of this page is saying exactly how much less.
Adversaries we defend against
Our own servers, and whoever controls them. This is the adversary the architecture is built for. Assume the tenant server, its database, the object storage and the backups are all in an attacker’s hands, whether through a breach, a hosting-provider insider, a legal order, or a dishonest employee of ours. They obtain ciphertext, sealed key envelopes, public keys and metadata. There is no key on any server that opens any file, and there is no code path in which the server handles plain text, so what they obtain stays closed. What our servers can and cannot see lists the exact split.
A server that lies. A compromised server could try to hand a share to the wrong person by presenting a substituted public key. Grants are signed by the person who made them with their own key, and every recipient’s key is pinned after first contact, so a later substitution fails with a visible mismatch rather than silently. The limits of this are in the residual risks below.
The network. Every connection is TLS 1.3 with current cipher policy, and everything that travels is already encrypted end to end, so a broken connection yields ciphertext and metadata, not content.
Other customers. Each customer runs in a tenant of their own: its own virtual machine, database, object storage bucket, secrets and certificate. There is no shared database in which a bug in access control could leak one customer’s rows to another.
A former collaborator. Removing a person from a folder re-keys the folder, so the files are sealed under keys the removed person never had. The server cannot un-share, because it never had the keys; the device of the person doing the removing does the work. Revocation means changing the locks explains the cost and the one gap, below.
A stolen credential. A password alone is not enough to open an account from a new device when a second factor or a passkey is set, and a stolen API key cannot decrypt anything without the service account’s private keys, which the server never holds.
Someone editing history. The audit log is HMAC-chained with a key the database never sees, the application role cannot alter entries, and a verifier recomputes the whole chain on demand. An audit trail that cannot be quietly edited is the design.
Malicious documents. Files are cleaned or rejected on the uploading device before encryption, because the server could not inspect them afterwards. Content disarm and reconstruction describes the formats covered and the ones that are not.
A future quantum computer. Every key wrap uses RSA-4096 and ML-KEM-768 together, so ciphertext recorded today cannot be opened later by breaking RSA alone. The hybrid wrap is explained for non-cryptographers.
Adversaries we do not defend against
Whoever controls your device. Malware, a keylogger, a browser extension with page access, or a person at an unlocked screen acts as you. Plain text exists on your device by design, and nothing on our side can tell a thief with your session from you. Idle lock, session limits and the ability to revoke sessions reduce the window; they do not close it.
Whoever you share with. A recipient who downloads a file has it. Revocation stops future access; it cannot recall a copy.
A weak or reused password. Argon2id makes guessing expensive, and the server never sees the password, but a password that is already in a breach corpus is still the weakest link in the chain.
The code we deliver. The web client is JavaScript served from the tenant. A malicious operator, or an attacker who controlled the tenant, could serve a modified client that exfiltrates keys. A strict content security policy with no third-party scripts narrows the attack to our own origin; it does not remove the trust you place in the bundle we ship. Signed builds and a transparency log for client releases are on the roadmap, and until then this is the largest item of trust in the model. The desktop clients are installed once and updated when you choose, so their exposure is at install time rather than on every visit.
Residual risks, stated
These are the gaps we know about, as documented in the whitepaper’s limitations section.
- Metadata. File sizes, timestamps, folder structure, who has access to what, who accessed what and when, and the blinded search index, which reveals that the same token occurs in several files and which files a query matched. This is traffic-analysis material. It is visible to the server by design, because the server has to enforce access and answer queries.
- First contact. Key pinning is trust-on-first-use: the very first share to a new person accepts the key the server presents. A substitution at that moment is caught by nothing stronger than the two people comparing fingerprints. Every later change is blocked and shown.
- Old versions. After a file is revoked from someone, earlier versions they already downloaded keep their previous key. The re-key protects what they did not yet have.
- Transport is classical. The TLS key exchange on the tenant hosts is not yet post-quantum. A recorded TLS session, broken in the future, would expose the metadata layer, never content or keys, which are protected end to end. The hybrid exchange follows when the server’s TLS library supports it.
- Cleaning is client-asserted. The server cannot verify that an uploaded file was really cleaned, because it cannot read it. A modified client could mark an unclean file as clean. Endpoint protection on the reading device remains necessary.
- Rules are plain. Workflow definitions, triggers, recipients and webhook addresses are stored in plain text, because the server evaluates them.
How to use this page
If you are assessing the product, map your own threats onto the two lists. Anything in the first list is covered by the architecture and can be verified from the whitepaper and, where you have one, your own tenant. Anything in the second list is yours to cover with device management, identity policy and user training, as it would be with any product. Anything in the residual list is a conversation we are happy to have, with the roadmap item next to it where one exists.
Questions?
If your reviewer wants the mechanisms behind a line on this page, or a threat you do not see here, write to hello@sapherbox.com.