How File Request encryption works

When you first create a request, your browser derives a long-lived identity — a hybrid of ML-KEM-1024 and X25519, combined with HKDF-SHA-256 — from your unlocked account. The public half is served with the request link; the secret half is wrapped by your account key and stored so only you can recover it.

When a client uploads a file, their browser seals it to that public identity using the open-source @shieldfive/crypto core. Larger files are encrypted with an ephemeral content key that is itself sealed to your identity, so big uploads stay chunked but only you can open them. Only ciphertext is sent to ShieldFive. The post-quantum half (ML-KEM) is always on — it is not a paid tier.

We are honest about the limits of any hosted, browser-delivered tool. The server can see: the size of each ciphertext, the times a request was created, opened, and uploaded to, and the IP address that connected (hashed for abuse-prevention, never stored raw). It also holds a verifier for the request PIN — never the PIN itself — and the encrypted metadata blobs (title, checklist labels, filenames), which it cannot read. And it delivers the JavaScript that runs the encryption.

What the server cannot see: the file contents, the filenames, your checklist text, or your secret keys. Those stay on the devices of your client and you.

Because the encryption code — and the public key your clients seal to — are served by us each time the page loads, a compromise of ShieldFive could in principle serve malicious code or a substituted key. We reduce that risk with a strict Content-Security-Policy and no third-party scripts on the upload and inbox pages, and the crypto core is open source so it can be reviewed independently. This is the honest ceiling of any web-delivered end-to-end tool. Our claim is “encrypted in the browser, ciphertext at rest” — not that no server could ever be subverted. For the highest-assurance cases, verify the key fingerprint out of band.

A request link is a bearer capability, so it is defended like one. Each link carries a PIN (checked against a stored verifier with a lockout ladder), per-request file-count and byte caps enforced atomically in the database, an expiry (up to 7 days on the free plan; 30 or 90 days, or none, on Firm seats) plus revocation at any time, and per-IP and per-link rate limits. A shared link cannot be brute-forced or turned into an open upload endpoint.

On a paid seat, your firm’s decryption identity is sealed to each member’s account keys, so colleagues share one inbox without ever sharing personal keys. One honest limit: removing a member blocks new access, but a member who already cached the firm key can still read documents received before removal until the firm identity is rotated — and rotation does not re-encrypt already-received files.

Ciphertext and metadata are stored in the EU, and a GDPR data-processing agreement is included on every seat. There is no third-party tracking on the upload or inbox pages. For the full company security posture, see /security.