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 for typo detection. 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 RC and the session code in your browser. 2. Browser POSTs {email, session_code} to Clavitor. Server validates the code (single-use, 10-minute TTL), returns RA. 3. In the browser, JavaScript strips the checksum from RC and computes P3 = (RC minus checksum) XOR RA. 4. Browser uses P3 to unwrap your vault's encryption key. 5. Browser registers your new hardware key and writes a fresh authentication record. 6. If you marked the old key as stolen, browser writes an append-only revocation marker.

The server never receives P3. It releases RA over an authenticated session and forgets the session 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 with audit logging on every release.

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.