A document released through DocShare passes four trust boundaries. This page describes each of them, the primitives that guard them, and what an attacker would have to defeat to read a single page.
Design principles
Our architecture starts from the failures we consider likely rather than the ones that are convenient to defend against.
We assume an attacker reads the recipient's email. That is why the link carries no key, no password and no description of the contents — possessing it grants nothing.
We assume an attacker holds root on a DocShare application host. Master keys are unreachable from application code; unwrapping happens inside the HSM under a passphrase we do not possess.
We assume a DocShare employee will one day try to read customer content. Key ceremonies require dual control, administrative access is time-bound and session-recorded, and no single role can both reach ciphertext and request unwrapping.
Decrypted content lives in memory for the length of the session, is never written to browser storage, and the viewer sets no persistent identifier before the recipient acts.
Algorithms are declared per share in a signed manifest, so a document sealed in 2021 can be re-sealed under a stronger suite without re-issuing links. Hybrid post-quantum key encapsulation is already in limited release.
Every event is appended to a hash-chained log, sealed hourly with an eIDAS qualified timestamp. Records can be verified independently, including against us.
Envelope encryption
Every document gets a disposable key. Every tenant gets a durable key. The disposable key never leaves the document; the durable key never leaves the hardware.
AES-256-GCM using that key and a unique nonce.Ed25519 key.AES-KW under the tenant master key inside the HSM.Argon2id.encryptionId resolves to an encryption record — not to a key.Argon2id stretches it against the per-share salt to remove the outer seal.AES-256-GCM, 96-bit nonce, 128-bit tag, one key per document versionAES-KW (RFC 3394) under a non-exportable tenant master keyXChaCha20-Poly1305 keyed by the Argon2id outputArgon2id m=65536 KiB, t=3, p=4, 128-bit saltECDH P-384 with RSA-4096 fallback for legacy HSM partitionsEd25519 over canonicalised JSON (RFC 8785)SHA-256 per document, SHA-256 Merkle root per shareTLS 1.3 only · X25519 · HSTS preload · OCSP stapling · CAA pinnedX25519 + ML-KEM-768 key encapsulationPre-release verification
These execute before the passphrase field is enabled. If any one of them does not return green, the sequence halts and no key request is ever made — there is nothing to guess at, because nothing is listening.
The viewer confirms it is running over TLS 1.3 on the tenant's own subdomain, with a certificate matching the entry published in our Certificate Transparency monitor. A downgrade, a proxy or a lookalike domain fails here.
The share reference carries an Ed25519 signature from the sending tenant. This proves the link was minted by the organisation it claims to come from, and has not been edited in transit or reconstructed by an attacker.
The encryptionId is looked up. The record must exist, be within its validity window, and not already have been consumed. Revoked, expired and previously released shares stop here.
The SHA-256 digest of the stored ciphertext is compared against the signed manifest. Any divergence — storage corruption, or tampering — aborts the release rather than serving a damaged document.
Network reputation, geolocation consistency, automation signals and velocity are scored. A high score does not silently block: it halts the release, notifies the sender's security contact, and gives the recipient a reference to quote.
The HSM partition holding the tenant master key is asked whether it is available and holds the wrapped key for this record. Only after a positive answer does the passphrase field unlock.
Operations
Cryptography is rarely the weak point. Access management, patching discipline and key ceremonies are.
Limits
A security page that only lists strengths is a marketing page. These are real constraints of the design.