Salt escrow (Plan B)

Who this is for

Premium users enabling cloud sync who want new devices to fetch KDF salt and public Key DID material from NT² without manually transferring salt—while still entering the master password locally for every unlock.

What you need

Steps

Plan A vs Plan B

Most users start on Plan A; first sync enable migrates to Plan B without generating a new salt.

Upload salt (first sync enable)

1. Open Settings → Vault & sync → Cloud sync and choose Enable cloud sync.
2. After Key DID authentication, registerUser sends your existing vault_meta.saltHex, password verifier (when present), and public Key DID fields.
3. NT² rejects a conflicting salt for the same Key DID (409)—one canonical salt per vault.

Fetch salt on a new device

1. On a cold device, start vault setup or replica handoff (setup QR / recovery kit flow).
2. Client calls GET /api/vault/bootstrap?keyDid= (public, no session) for salt, verifier, and public signing keys.
3. Enter your master password; PBKDF2 (100k iterations, SHA-256) runs in the browser to derive the vault key.
4. Wrong password fails via verifier—same as local-only unlock.

Session salt fetch

1. Authenticated devices may use GET /api/salt?keyDid= with a sync session token matching the Key DID.
2. Response includes salt and optional verifier ciphertext—still no master password transit.

Tips and common mistakes

• Salt is not secret—it slows offline guessing; security comes from your master password strength.
• Plan B does not escrow private signing keys in current client builds—threshold unlock still uses local Shamir material after bootstrap.
• Local-only vaults never need Plan B; recovery kit + backup remain sufficient.
• Disabling sync does not delete the D1 row; salt may remain for future re-enable unless account data is removed through support.

Related

• Cloud sync
• Security settings — Vault identity
• Create and unlock a vault
• Help: How it works