The problem shows up the moment a privacy-focused service tries to be usable. People forget passphrases. They lose phones. A 24-word recovery seed is mathematically excellent and behaviorally fragile, because most people will not store it correctly. So designers reach for the thing humans actually remember: a four to six digit PIN. The catch is obvious. A six-digit PIN has only a million possibilities, and a server holding the encrypted data could try all of them in seconds. The whole design problem is making that brute force impossible for the one party best positioned to attempt it.
Why You Cannot Just Stretch the PIN
The first instinct is to slow the attacker down with key stretching. Run the PIN through Argon2 or a similar memory-hard function so each guess costs real time and memory. This helps against a weak attacker, but it does not solve the problem. A six-digit PIN has so little entropy that even an expensive hash function only buys you a modest factor. A server with the encrypted blob and unlimited attempts will still get through, because the math of a million guesses against any per-guess cost it can afford is not in your favor.
The real insight is that the defense cannot be the cost per guess. It has to be a hard limit on the number of guesses, enforced by someone who genuinely cannot be talked into raising it. That is the move Secure Value Recovery, or SVR, is built around. It was developed by the Signal team to back up their account registration data and contact information, and the design has been documented publicly and audited.
Do not try to make each PIN guess expensive. Make the total number of guesses small and unbypassable, enforced by hardware the operator cannot override, so an attacker gets ten tries instead of a million.
The Enclave Does the Counting
SVR stores the encrypted secret on a server, but the guess-counting and key derivation happen inside a hardware secure enclave, originally Intel SGX and later other trusted execution environments. The enclave runs a specific, attested piece of code that the operator cannot modify without the modification being detectable. When you set up recovery, here is roughly what happens:
- Your device generates a strong random master key and uses it to encrypt your real backup.
- The master key is combined with your PIN and handed to the enclave, which stores a stretched, salted representation along with a guess counter set to a small limit, often around ten.
- When you need to recover, you send your PIN to the enclave. It checks it, decrements the counter on every attempt, and returns the master key only on a correct guess.
- If the counter hits zero, the enclave destroys the stored data permanently. There is no reset, because a reset the operator could perform is exactly the hole the design exists to close.
The user verifies, through remote attestation, that the enclave is running the expected published code before trusting it with a PIN. That attestation step is what turns "trust the company" into "trust this specific audited program, and verify it cryptographically."
Splitting Trust Across Multiple Enclaves
A single enclave is a single point of failure. If a side-channel attack breaks SGX, and several have, the guess limit could be defeated. Later versions of SVR address this by splitting the secret across multiple enclaves running on different hardware, using secret sharing. The master key is reconstructed only if a threshold of the enclaves agree, so an attacker would need to break several independent trusted environments at once rather than just one.
The security does not come from the PIN being strong. It comes from the PIN only getting ten chances, enforced by hardware the operator has provably tied its own hands against.
What This Buys, and What It Costs
| Recovery model | Strength | Trade-off |
|---|---|---|
| Provider-held key | Easy reset, never locked out | Provider can read or be compelled to hand over data |
| Recovery seed phrase | Provider holds nothing, strongest secrecy | Lose the phrase, lose everything; high user-error rate |
| Secure Value Recovery | Short PIN, provider cannot brute-force | Trusts enclave hardware; wrong PIN too many times wipes it |
The honest weakness of SVR is its dependence on the security of the enclave hardware. Trusted execution environments have a track record of side-channel vulnerabilities, and each new break is a research event that the whole design must survive. The multi-enclave, threshold approach is a direct response to that fragility, but it does not eliminate the underlying assumption: you are trusting that a specific class of processor feature keeps its promises. For most users protecting most data, that is a reasonable trade. For someone whose adversary is a nation-state with hardware-attack budgets, the assumption deserves harder scrutiny.
Where Self-Recovery Fits Instead
SVR is the right tool when you want convenience without giving the operator readable access. A different and equally valid choice is to keep the operator entirely out of recovery. That is the model behind a user-held recovery design, where a generated seed phrase is the only path back into the account and no server-side component, enclave or otherwise, can restore it.
Haven takes the second path. Account recovery runs on a 24-word seed phrase that you control, with no operator-held reset and no enclave we ask you to trust. The reasoning is simple: the strongest statement we can make about your data is that there is no recovery mechanism on our side to compromise, subpoena, or misconfigure. That puts more responsibility on you to store the phrase safely, which is a real cost, and we think it is the right one for the people Haven is built for. SVR and seed-phrase recovery are both legitimate answers to the same hard question; they just draw the trust boundary in different places.
If you want the wider context on how recovery interacts with the rest of an account's security, our piece on encrypted backups covers the storage side, and the account recovery security guide covers the trade-offs in choosing a model.