How a vault that never knows your password works

In the previous essay we argued that the middleman became unnecessary for a growing number of functions. Here we show how that turns into engineering at TAIVA Vault, without heavy math, with the protocol names where they matter.

The classic problem of password storage

You create an account. The server needs to store something that proves, on the next login, it is you. History has three progressive answers:

1. Plain text: store the password as is. Almost nobody does this anymore, but leaks prove it still happens.
2. Simple hash (sha256 without salt): better, but vulnerable to rainbow tables.
3. Hash with salt and a costly function (bcrypt, Argon2id, scrypt): state of the art for a decade.

In all three solutions, the server receives your password in plain text at login time. It applies the function, compares with what is stored, and either grants or denies access. The window where the password exists in server memory can be milliseconds, but it exists. If there is malware on the host, a memory dump, an accidental logger, or an active debugger, the password leaks.

The industry always justified this by saying "we trust the server". There was a practical reason. There was no other way to do it.

PAKE: the mathematical way out

PAKE stands for Password Authenticated Key Exchange. It is a family of protocols where two parties (client and server) prove they know the same password without transmitting it.

Analogy. Imagine two people who want to confirm they know the same address without saying the address. Each calculates the distance from their house to point X, then X to Y, then Y back. They exchange only the final number. If the numbers match, they started from the same place. If not, they diverged at the first step and neither learned the other's house.

OPAQUE-3DH (RFC 9497) is the state of the art of this family in 2026. Standardized by the IETF, reviewed by dozens of cryptographers, implemented by Cloudflare in the @cloudflare/opaque-ts library that TAIVA Vault uses in production.

The simplified flow:

1. You type the password in the browser.
2. The client does a local operation with the password (OPRF blinding), generates a ke1, and sends it to the server.
3. The server cannot reverse ke1 to the password (OPRF property).
4. The server responds with ke2 based on its own parameters plus ke1.
5. The client combines ke1, ke2, and the local password to generate ke3.
6. Both arrive at an identical 32-byte export_key, if the password was correct. If not, they diverge mathematically and nobody learns anything useful.

At no point in the protocol does the plain text password leave the browser. The server receives derived math, operates on it, returns derived math. If the handshake closes, both know both knew the password. If it does not close, silent failure.

The post-quantum hybrid wrap

OPAQUE proves you know the password. But the vault has another function: storing your encrypted data without the server knowing what is inside.

For that, we derive an encryption key (DEK, Data Encryption Key) from the export_key. This DEK never leaves the browser in plain text. It is used locally to encrypt each credential before uploading to the server.

This solves the "server reads my data" problem, but opens another one: what if in 15 or 20 years quantum computers manage to break current cryptography? The concern is real and documented by NIST, the NSA, and the academic community. It is not tomorrow. But it is within the retention horizon of your data.

The modern standard answer is to hybridize: combine classical cryptography (P-256, AES-256) with post-quantum cryptography (ML-KEM). If one of the two mathematical foundations falls in the future, the other still holds.

At TAIVA Vault, we use ML-KEM-1024 (FIPS 203, NIST security category 5, standardized in August 2024) in hybrid mode with the classical export_key via HKDF-SHA256.

The flow:

1. The server keeps a long-lived ML-KEM-1024 key pair (seed stored in an isolated secret vault).
2. The client fetches the server's pubkey, encapsulates a random secret against it, generates an mlKemCt (ciphertext) and a shared secret.
3. The client computes hybridKEK = HKDF(export_key || shared_secret, "taiva-opaque-pq-v1").
4. hybridKEK encrypts the DEK before upload.
5. On the next login, the cycle repeats: the client sends mlKemCt, the server decapsulates with its private key, returns the same shared secret, and the client reconstructs hybridKEK.

Even if one of the math foundations falls, the other has to fall too for the encrypted material to be revealed. A strategy known as cryptographic defense in depth.

MPC 2-of-3: no single point of failure

OPAQUE plus hybrid wrap takes care of content. But another question: what if our server gets breached?

If the entire DEK lived on a single server (encrypted, but intact), that server would be a single point of failure. Even encrypted, storing everything in one place is unnecessary fragility.

The solution is Multi-Party Computation (MPC). We divide the DEK into pieces called shares, which sit on different servers in different jurisdictions. To reconstruct the key, you need at least N out of M shares (threshold).

TAIVA Vault uses a hybrid scheme:

1. The client does an XOR-split of the DEK into share1 and share2, each 32 bytes.
2. share1 is encrypted with hybridKEK (the key derived from PAKE+ML-KEM) and stored on the main server as opaqueWrappedDek.
3. share2 is distributed server-side via Shamir Secret Sharing 2-of-3 across three independent MPC nodes in three different geographic jurisdictions.

To reconstruct the DEK, the client needs to:

• Prove the password via OPAQUE (recovers export_key).
• Decrypt share1 via hybridKEK (recovers the first share of the DEK).
• Recover share2 from at least two of the three MPC nodes.
• Combine share1 XOR share2 to obtain the final DEK.

If one MPC node goes down, two continue serving (availability preserved). If two go down, the third alone cannot reconstruct share2 (threshold not met). If one node is legally compromised, the attacker needs simultaneous cooperation from at least one more node in another jurisdiction.

This eliminates the single point of failure and also the single point of legal compromise. It is not an absolute vault. It is architecture that multiplies the cost of an attack.

Audit chain anchored to Bitcoin

Everything above protects content. But one question remains: how do you know that we are being honest about what happened in the past?

Each relevant operation (login, credential creation, export, privacy law deletion request) generates a log entry chained by hash. Each entry contains the hash of the previous entry, forming a Merkle chain. Modifying an old entry changes all subsequent hashes in cascade.

Still, in theory, we could rewrite the entire chain if we wanted.

To prevent this, we anchor the head of the chain in Bitcoin via OpenTimestamps every 6 hours. The hash of the current state gets recorded in a public Bitcoin block, with a timestamp verifiable by any external observer. The cost of rewriting history after that would be rewriting the Bitcoin ledger from that block, meaning redoing all the proof of work since then, which nobody can do.

Practical result: you can independently audit, with the ots verify open source tool, whether our claims about the state of your account on a date X match what was anchored to Bitcoin on that date.

Post-quantum TLS on transport

Finally, transport. Even if everything above is well done, if the TLS channel between your browser and the server is broken retroactively, an attacker who recorded today's traffic can replay everything tomorrow.

We use TLS 1.3 with the hybrid curve X25519MLKEM768 (RFC draft adopted by Chrome, Cloudflare, and others in 2024). Even if X25519 falls in twenty years (classical break unlikely), ML-KEM-768 holds. Even if ML-KEM falls (post-quantum cryptanalysis unlikely), X25519 holds.

Configured at the edge (Caddy and Traefik) with minimum TLS 1.3, strong ciphers, no weak fallback.

What we still see

No system is an absolute vault. Technical honesty matters. What TAIVA Vault still observes, by design:

• Registered email. Without it, there is no OTP recovery.
• Operation timestamps. Login logs with IP masked after N days.
• Encrypted volume. We know how many credentials you have, what size the blobs are. Content, no.
• Approximate origin. Coarse geolocation by IP, retained for a short period to investigate fraud.

What we mathematically do not see:

• Your master password (OPAQUE prevents it).
• The content of credentials (encrypted with DEK derived client-side).
• The content of secure notes (same encryption).
• The DEK itself (exists only in your browser's memory during use).

This boundary is the point. What it needs to see to work, it sees. What it can hide and still work, it hides. The line is documented in the public whitepaper, versioned in Git, anchored to Bitcoin.

Back to the essay

In the previous post we said the middleman became unnecessary through engineering, not activism. OPAQUE-3DH, ML-KEM-1024 hybrid, MPC 2-of-3, and the Bitcoin-anchored audit chain are the concrete names of these tools in our stack.

We invented none of them. We standardized the integration, tested against known attack scenarios, deployed to production, and documented honestly what falls outside the scope.

The question stops being "what can TAIVA do with your data?". It becomes "what is mathematically out of our reach, even if we wanted to?".

The bigger that second list, the more sovereign you are.

Also read:

• Digital sovereignty: why the middleman became unnecessary: the broader argument that motivates this design.
• Recovery without losing sovereignty: 3 independent envelopes: how to recover access when you lose the master password, without handing over the vault.
• What changed in NIST FIPS 203 and why it matters to you: the post-quantum cryptography the vault uses, explained from scratch.

TAIVA Vault: personal digital vault with OPAQUE-3DH, ML-KEM-1024 hybrid, MPC 2-of-3 across three independent servers, Bitcoin-anchored audit chain. Create a free account →