VuVault VuVault Blueprint
Open standards · Client-side cryptography · Zero knowledge

The architectural blueprint.
Math, not obscurity.

This page describes the shape of the system: what runs where, which published standards it is built on, and what each layer is designed to survive. It is deliberately complete on principles and deliberately silent on implementation internals — a security model that depends on you not reading this page would not be a security model.

§ 01 — Invariants

Five non-negotiable invariants.

Every layer is checked against these five before it ships. If a feature breaks one, it does not ship — even if a competitor offers it, even if it's convenient.

P1
Server cannot read user data.
Mathematical, not policy. The wire only ever carries opaque ciphertext; decryption keys exist solely on the device.
Shipped
P2
Server cannot infer user data.
Metadata is treated as data. The shape, count, and cadence of what you store should reveal nothing.
In design
P3
Resistant to harvest-now-decrypt-later.
Hybrid post-quantum encryption from day one. Traffic recorded today must stay sealed against future quantum computers.
Shipped
P4
Verifiable by anyone.
Open source, signed releases in a public transparency log, verifiable in the page itself. No trust required.
Shipped
P5
No silent updates.
The code you run is the code that was published. The bundle hash is visible at unlock and checked against the release manifest.
Shipped
§ 02 — Architecture

Six layers, all in your browser.

Each layer is built on an open, published standard — the same primitives anyone can read, audit, and reimplement. The composition is the architecture; none of it relies on a secret.

A1 OPAQUE · RFC 9807

Authentication

Login uses an augmented PAKE. Your master secret never leaves the device — not at registration, not at login, not hashed, not at all. The server ends up with a verifier it cannot reverse and cannot reuse, so there is no password database to steal.

Server-side credential theftPhishing-resistant loginCredential stuffing
A2 WebAuthn PRF · HKDF

Key hierarchy

Vault keys are derived on-device from hardware-backed authenticator output, expanded through a one-way key schedule with strict domain separation. Every derived key has exactly one job; compromise of one context never cascades into another.

Master secret compromiseCross-context key reuseKey exfiltration
A3 Hybrid KEM · FIPS 203 · AEAD

Encryption envelopes

Every record is sealed in an authenticated envelope keyed by a hybrid of elliptic-curve and ML-KEM-1024 post-quantum key encapsulation. Breaking the envelope requires breaking both. Known-answer tests pin the cryptography to published test vectors on every build.

Harvest-now-decrypt-laterCipher downgradeCiphertext tampering
A4 Local-first · ciphertext-only sync

Storage model

The vault lives on your device and is usable with zero network access. When sync is enabled, the server stores opaque encrypted blobs — it cannot distinguish a password from a passport, and the end-to-end test suite asserts no plaintext ever crosses the boundary.

Server breachSubpoena of stored dataInsider access
A5 Same-origin · zero third parties

Transport & origin

The application is served from a single origin with no third-party hosts, no analytics tags, and no embedded trackers. All cryptography executes in your browser; what leaves the device is ciphertext addressed to our own endpoints, nothing else.

Third-party script compromiseTraffic analysis surfaceTracking
A6 Reproducible builds · Sigstore + Rekor

Supply chain integrity

Releases are built reproducibly, signed keylessly, and recorded in a public append-only transparency log. The running page can verify its own bundle hash against the published manifest, so a tampered or targeted build is detectable by the person it targets.

Build-system compromiseTargeted backdoorSilent substitution
§ 03 — Threat model

Assume the worst. Then check the math.

The design question for every adversary is the same: with everything they can take, what do they actually get?

Our own servers, fully compromised
Reads every byte we store and every request we receive
Obtains ciphertext and an irreversible authentication verifier. No keys, no plaintext.
Network observer
Records all traffic between you and us, indefinitely
Sees encrypted envelopes on a single origin. Hybrid post-quantum sealing keeps recordings worthless even against a future quantum computer.
Malicious or coerced release
Attempts to ship you altered code
Must forge a reproducible build and a public transparency-log entry, and still defeats the in-page bundle-hash check. Tampering is evident, not silent.
Thief with your locked device
Full physical access to the hardware
Faces hardware-backed unlock and memory-hard key derivation. The vault does not open without you.
Court order served on us
Compels us to hand over everything we have
We comply — and hand over ciphertext we are mathematically unable to read. That is the point.
§ 04 — What this page omits

Deliberately.

You will not find release schedules, internal milestones, infrastructure topology, or dependency selections here. Those change; the invariants do not. What we do publish is stronger than any of it: the source, a software bill of materials, signed reproducible releases in a public transparency log, and a verifier that runs in the page you are reading. Verify, don't trust.