How recovery works

This page explains the math behind the recovery flow. You do not need to read it to use Clavitor. Read it if you want to understand what is actually keeping you safe.

The split

Your hardware key produces a 32-byte secret called P3 — short for "PRF output, layer 3." Clavitor's servers never see P3. It exists only on the device that did the biometric tap.

P3 is what unwraps the actual encryption key for your vault. If you lose P3, your vault is mathematically unreachable. Recovery exists because hardware keys get lost.

When you generate a recovery code:

1. The browser produces P3 with a hardware tap.

2. The browser generates RA, a fresh random 32 bytes — the recovery anchor.

3. The browser computes P3 XOR RA — 32 bytes that reveal nothing about P3 without RA, and nothing about RA without P3.

4. The browser appends a 4-byte CRC32-IEEE over the 32 XOR bytes for typo detection (legacy codes with a zero tail still open).

5. The 36 bytes are encoded as 48 base64 characters and displayed as your recovery code (RC).

6. The browser uploads RA to Clavitor's central server, paired with your account email.

7. The browser shows you RC and asks you to confirm you have saved it.

At rest:

You hold RC: 48 characters, on paper or in storage of your choice.
Clavitor holds RA: 32 random bytes, in the central database.
No one holds the unwrapping key. It only exists when both halves are combined.

Why a 256-bit split is unbreakable

Suppose an attacker steals your printed recovery code. They have RC, which is P3 XOR RA plus a checksum. To recover P3, they need RA. RA is 32 bytes of true randomness — 256 bits, the same key size used by AES-256 to encrypt the world's banking traffic. Brute-forcing 256 bits is not impractical; it is energetically impossible with the physics of our universe.

Conversely, suppose an attacker breaches Clavitor and steals every RA in the database. Each RA alone reveals nothing — without the matching RC, it is 32 random bytes. The attacker would still need to compromise each customer's storage of their RC individually to make any use of the breach.

The whole construction relies on the property that XOR of two 256-bit random values produces output indistinguishable from random.

The recovery transaction

During recovery:

1. You enter the session code. The browser POSTs {session_code} to Clavitor — no email, no sign-in. The server checks the code (single use, 10-minute TTL, and only the newest code issued for that email address), deletes it, and returns RA together with a 10-minute grant to register one new device of that vault.

2. You enter RC. In the browser, the page's WebAssembly checks and strips the checksum and computes P3 = (RC minus checksum) XOR RA.

3. The browser derives P1, a public 8-byte value, from P3 and sends only P1. The server returns the wrapped vault key of the device P1 belongs to (or 410 Gone if that device was removed from the vault, 404 if P1 matches nothing).

4. The browser uses P3 to unwrap your vault's encryption key.

5. The browser registers your new hardware key with the grant and wraps the vault key to it. The server uses the grant up.

6. With Remove the vault's other devices ticked (the default), the server revokes every other device of the vault in the same database transaction that writes the new one: both or neither. Each revocation is pushed to the vault's servers, and the vault's audit log records the new device and each removed one.

The server never receives P3. It releases RA once, to whoever presents the session code, and deletes the code immediately. Even a hostile insider with database access and packet captures cannot read P3 — at no point is P3 in transit or at rest on our side.

What an attacker would need

To decrypt one user's vault through the recovery channel, an attacker needs all four:

1. The user's recovery code — paper, email, cloud, wherever the user stored it.

2. The user's verification material, or the ability to socially engineer a Clavitor operator into accepting their answer.

3. A scheduled Zoom call with a Clavitor operator during business hours.

4. The ability to receive a verbal session code on that call and use it within 10 minutes.

Each step has its own defenses. Step 1 is the user's storage discipline. Steps 2–3 are the human gate, staffed deliberately to be slow rather than convenient. Step 4 is a short TTL: a session code works once, for 10 minutes, and a new code for the same email address cancels the old one. Clavitor's server logs every code an operator issues and who issued it, every release of RA, and every refused code (unknown, already used, or expired); the vault's own audit log records the devices a recovery added and removed.

Going deeper

The full design rationale — including the dead ends we explored and rejected (BIP39 mnemonics, entropy blobs with PINs, server-side scattering, physical-interaction gates) — sits behind our security writeups. If you find a hole in this design, email security@clavitor.ai. We pay for valid reports.