Recovery without losing sovereignty: why 3 independent envelopes change everything

Zero-knowledge vaults have a classic problem: if the server mathematically cannot see your passwords, it also cannot give them back to you when you forget the master password. The privacy guarantee becomes a recovery trap.

Almost every password vault solves this by breaking privacy at recovery time. You answer security questions, provide a document, talk to support, and the company releases access. At that moment, it had to be able to identify you and give back your material. Which means it could, and could have done the same for another request, under other circumstances.

There is a different way. Newer, more elegant, and one that sustains the zero-knowledge promise even during recovery. It is called multiple OPAQUE envelopes with domain separation. This text explains how it works, without heavy math.

What an OPAQUE envelope is

OPAQUE-3DH (RFC 9497) is the protocol that lets client and server agree on a shared key derived from a password, without the server seeing the password. Each time you create an account, the client and server execute register, which produces two artifacts:

1. An envelope, opaque, that stays on the server (encrypted with your password, but the server has no decryption key).
2. An export_key of 32 bytes that stays on the client (deterministically derived from your password, server salt, and internal parameters).

You forget the export_key (no need to remember it) because it gets derived from the password every time you log in. But it is the material that encrypts your vault keys. Therefore, if you know the master password, you derive the export_key, decrypt the envelope, unlock the vault. If you do not know, nothing.

The envelope is the key point. It is specific to that password. Change the password, the envelope changes. There is no way to discover the password from the envelope alone (even with unlimited computational power, it is theoretically opaque).

The idea: 3 envelopes, 3 different passwords

What if you created not one, but three envelopes at the same time? Each encrypted with a different password? Each capable of decrypting the same vault key?

That is what TAIVA Vault does at sign-up. You do not see three envelopes in the interface. You see:

1. Master password that you memorize and use every day.
2. Backup password that you write down somewhere else (physical manager, paper in a safe, second family member).
3. Recovery key of 24 words that you print or copy to an offline place.

Internally, each of these three inputs becomes the password of an independent OPAQUE envelope. The three envelopes encrypt the same vault DEK (Data Encryption Key). Any one of the three decrypts the entire vault.

The crucial mathematical property: the three envelopes cannot be correlated. Even with the server looking at the three encrypted blobs it has stored, it cannot say if they came from the same account nor if they encrypt the same content. This is called domain separation: each envelope is treated as a separate cryptographic identity, with its own salt, derivation, and parameters.

The recovery flow in practice

Typical scenario. You forget the master password. You try to log in, try again, realize it is not coming back. You go to the "forgot password" option.

The interface asks: "use your recovery key (24 words) or your backup password".

You choose the recovery key, open the physical envelope where it is, type the 24 words.

The client:

1. Derives an export_key from the 24 words (same function, different salt).
2. Tries to decrypt the recovery OPAQUE envelope (not the primary).
3. If the words were right, it opens. If wrong, it fails without revealing anything.
4. Once the envelope is decrypted, extracts the DEK.
5. Vault unlocked.

At no point did the server see your recovery words. It did not see your master password. It did not see your backup password. The server only did its protocol part (responding to the OPAQUE handshake) and delivered the opaque envelope.

After unlocking via recovery, the interface forces you to define a new master password. This generates a new primary envelope (replaces the old one). Your recovery words remain valid (they do not change). Your backup password remains valid. You just swapped one of the three rings without the server seeing any of them.

Why 3 and not 1 or 5

The choice is not arbitrary. It is calibrated for three typical access loss scenarios:

Scenario 1: you forgot the master password.

Frequent, low impact. Resolves with the recovery key. The backup password does not even come into play.

Scenario 2: you forgot the master password AND lost the recovery key.

Less frequent, medium impact. Generally happens when you lost access to a place where you kept physical material (fire, move, change of family safe). Resolves with the backup password, which lives in a different head (spouse, adult child, trusted friend).

Scenario 3: you lost everything.

Rare, high impact. You forgot the master password, lost the recovery key, and lost access to the backup password. Then the vault is unrecoverable. And that is a feature, not a defect. It means that neither the service, nor a government, nor an attacker can force access. The price is that you also cannot, if you reached that point.

That is why 3. One alone (master password) is too fragile (any forgetting loses everything). Two is still few (scenario 2 is reasonably common). Three covers almost everything without inflating complexity. Five or more would increase the surface area without covering much more real-world scenario.

Research in digital vault UX (Apple, Google, 1Password have published studies) converges on the number three as the optimal point between robustness and usability.

The detail nobody sees: domain separation

Back to the important technical property. The three envelopes must not reveal they belong to the same account.

This seems like a detail, but it has real consequence. Imagine the server is hacked and all stored OPAQUE envelopes leak. Without domain separation, someone looking at the leak could group "primary, backup, and recovery" from the same user, and attack all three simultaneously. Breaking the weakest one delivers vault access.

With domain separation, each envelope looks like an independent registration. Attacking one of them is statistically equal to attacking any other unrelated account. To attack "your account" specifically, the attacker needs to know WHICH three envelopes belong to you, and that the server does not store even in metadata.

Internally, TAIVA Vault implements domain separation with a distinct credentialId for each envelope. The credentialId is derived from userId + path where path is "primary", "backup", or "recovery". Since userId is internal (not published in leaks), the three envelopes stay decorrelated at the visible level (and at the normal cryptanalysis level).

What can go wrong

Technical honesty also matters in describing the limits. Things that can go wrong, and how we mitigate:

You write the recovery key in the cloud. Then it becomes custodied by the same class of risk as the vault. Recommendation: print and store physically. Some people tattoo (no exaggeration, it is real practice in technical families).

You set the backup password equal to the master password. Technically possible, defeats the benefit. The interface warns, but if you insist, the system allows. Obvious recommendation: make them different.

You give the recovery key to someone who later turns hostile. That person can enter your vault. Cryptography does not solve human relationships. The recovery key is access power. Treat it as such.

You forget all three. The vault is unrecoverable. There is no backdoor. That is the price of sovereignty. If there were a backdoor, it would exist for an attacker too.

Where this fits in the bigger design

Recovery via 3 envelopes is part of the real zero-knowledge promise. Back to the principle: the server cannot grant access because it does not have access. You are the only possible locus of recovery.

But real life is chaotic. Passwords are forgotten. Papers are lost. People move. Family migrates. 3 envelopes calibrate that chaos without giving margin for the server to be called a "gentle guardian" and end up handing the vault to someone who should not have it.

The next generation of vaults will also bring options like social sharing of recovery (Shamir among confidants), recovery by hardware device (YubiKey), recovery by local biometrics (without the server seeing). Each one reduces friction more without trading away sovereignty.

The direction is clear. The model "ask support and they resolve" is being replaced by "you always had the power to resolve, distributed in the ways that make sense to you".

Also read:

• How a vault that never knows your password works: the overall architecture of which recovery is part.
• Custody vs possession: the distinction nobody teaches: why classic recovery (via company support) is disguised custody.
• What changed in NIST FIPS 203 and why it matters to you: the post-quantum algorithm that encrypts the envelopes against future threats.

TAIVA Vault: digital vault with 3 independent OPAQUE envelopes. Forgot the master password? Recovery via physical key or backup password, without the server seeing any of the three. Create a free account →