This document describes the delivery path as implemented: how a production is sealed, how a recipient opens it, what each party can read at each step, and what is and is not logged. It is written to be checked, not taken on trust — every algorithm named is a published standard, and the verification step at the end can be run by the recipient without us.
1. Cryptographic primitives
| Function | Algorithm | Parameters |
|---|---|---|
| Content encryption | AES-256-GCM | 256-bit key, 96-bit IV unique per object, 128-bit authentication tag |
| Key derivation | PBKDF2-HMAC-SHA256 | 310,000 iterations, 128-bit random salt per seal |
| Integrity | SHA-256 | Computed per object before encryption, recorded in the sealed manifest |
| Transport | TLS 1.3 | Certificates issued by Let's Encrypt; HSTS enforced |
AES is specified in FIPS 197 and GCM mode in NIST SP 800-38D. PBKDF2 is specified in NIST SP 800-132 and RFC 8018. Approval of AES-256 for use on national security systems is set out in the applicable CNSS and NSA standards — CNSSP-15 and the Commercial National Security Algorithm Suite — not by NIST, which specifies the algorithm rather than its classification-level approvals.
No proprietary or in-house cryptography is used anywhere in the path. All operations in the recipient's browser are performed by the platform's SubtleCrypto implementation, not by our own code.
2. Where the key exists
The access token is the key material. It is generated at seal time, displayed once to the producing party, and issued to the recipient out of band. It is never transmitted to the server by the release page, and it is never stored server-side in any form.
When a recipient enters the token, the key is derived inside their browser and held only in page memory for the life of the tab. Closing or reloading the page discards it.
- The server stores ciphertext, a random salt, per-object IVs, and an encrypted manifest.
- The server does not store the token, a password hash, a key-encrypting key, or a recovery key.
- There is no administrative override, because there is nothing on the server to override with.
The practical consequence, stated plainly: if the token is lost, the production cannot be recovered by us. A new vault has to be sealed. That is the cost of the design, and firms evaluating it should price that in rather than be surprised by it later.
3. What a sealed vault discloses
Before a valid token is entered, an observer with the URL can determine the following and nothing more: that a vault exists, how many objects it contains, the total ciphertext size, the cipher and KDF parameters, and the descriptive matter details the producing party chose to display on the gate.
Filenames, labels, digests and the document set itself live in an encrypted manifest under the same key as the content. A sealed vault does not disclose what it contains.
Because the gate does display matter and case identifiers, the vault URL itself is treated as a secret: each vault is published under a random 14-character path. The link and the token are two separate secrets and are intended to travel by two separate channels.
4. Authentication and failure behaviour
There is no password comparison to bypass. A supplied token either derives a key that authenticates the manifest's GCM tag or it does not. An incorrect token produces an authentication failure and no plaintext of any kind.
The release page limits attempts within a session. This is a usability guard, not a security control: it is client-side, and a reload resets it. The actual protection is the key space: a 30-character token drawn from a 32-character alphabet is 150 bits of entropy, and every guess costs a 310,000-iteration derivation. The token is the only secret protecting the key, so it is sized well above the 128-bit line rather than merely above the plausible-attack line.
5. Integrity verification
Each object's SHA-256 digest is computed at ingest, before encryption, and sealed into the manifest. On release, the recipient's browser recomputes the digest of every decrypted object and compares it to the sealed value. A mismatch stops the release; it is not reported as a warning and worked around.
Verification without us
The archive offered by the release page contains a SHA256SUMS.txt in the standard format. A recipient can verify the production on their own machine, against their own tools, with no dependency on this service:
sha256sum -c SHA256SUMS.txt
This is the point of the design. An integrity claim a recipient can only confirm by asking the vendor is not an integrity claim.
6. Delivery surface
- Static files only. No application server, no database, and no server-side execution in the delivery path.
- HTTPS is required. Browsers do not expose the Web Crypto API in a non-secure context, so the page cannot decrypt over plain HTTP and says so rather than failing quietly.
- Response headers set HSTS, X-Content-Type-Options, X-Frame-Options: DENY, Referrer-Policy: no-referrer and a Content-Security-Policy restricted to same-origin plus the webfont origins.
- no-referrer is deliberate: it prevents a token carried in a URL fragment from reaching any third party through a Referer header.
- Release pages are marked noindex and excluded in robots.txt.
- Third-party origins in the page: webfonts only. No analytics, no tag managers, no trackers, no third-party JavaScript of any kind.
7. What is logged, and what is not
The delivery path is static files. There is no application server, so the only events that can be recorded are the ones the web server observes: HTTP requests.
Recorded, server-side
- Each request for a release page, with timestamp, source address and user agent.
- Each request for an encrypted object, the same way — so a retrieval of a production is visible as the set of object requests that served it.
- Certificate issuance and renewal, and TLS termination events.
Not recorded, and not claimed to be
- Failed token attempts. The token never leaves the browser, so an incorrect one produces no request and no log entry. Nothing anywhere counts how many times a recipient tried.
- Whether a decryption succeeded. The object request looks identical either way.
- Anything the recipient does with a file afterwards — opening, copying, forwarding, printing. That is outside any system's reach and is not asserted to be inside ours.
- Previews, in-page navigation, or any other browser-side interaction.
Stated plainly because the distinction matters to a reviewer: this is access logging at the delivery layer, not an application audit trail. A design that recorded browser-side events would have to send them somewhere, and that channel would be a place for the token or its metadata to leak. The absence of it is the trade being made, not an omission.
Retention of these logs, and who can read them, is covered in the privacy and retention document.
8. Expiry and takedown
Each vault displays an access window. That countdown is a display, not an enforcement mechanism, and no browser-side timer could be one — a recipient who has downloaded the ciphertext holds it regardless of what a page later shows.
Actual expiry is removal: deleting the objects from the server. After removal the link resolves to nothing and a correct token opens nothing. Any firm relying on a retention deadline should treat removal, not the countdown, as the control that satisfies it.
9. Known limitations
Stated here rather than left for a reviewer to find:
- Token loss is unrecoverable, by design.
- The attempt limit is client-side and resets on reload.
- Failed token attempts are not recorded anywhere, because they never reach a server.
- The expiry countdown is informational; only deletion is enforcement.
- Once released, a decrypted document is an ordinary file on the recipient's machine. Nothing in this or any comparable system controls it after that point, and no such claim is made.
- Webfonts are loaded from a third-party origin. No vault content is exposed to it, and referrers are suppressed, but a firm requiring zero third-party requests should tell us — the fonts can be self-hosted for that deployment.
- This document covers the delivery path. It is not a penetration-test report and does not claim any third-party audit or certification. None is currently held.
10. Reporting a vulnerability
Email security@l-vault.com. Please include enough detail to reproduce. We will confirm receipt and tell you what we intend to do about it. Researchers acting in good faith will not be pursued.