Recover with your Recovery Key

This is the good case. Your key pair does not change, so every environment you had access to is still yours afterwards.

You need: access to your email, and the Recovery Key (RK1-…) from your Recovery Kit.

The steps

1. Start recovery and enter your email. A one-time code is sent to you.
2. Enter the code. It is single-use and expires in 15 minutes.
3. Enter your Recovery Key. Your device fetches the encrypted backup of your account keys and decrypts it locally, with the Recovery Key. The server never sees the key and cannot decrypt the blob it just handed you.
4. Set a new master password. Your private key is re-encrypted under a key derived from the new password, and uploaded — still as ciphertext.
5. You’re back in, logged in but locked. Unlock with your new password.

What survives

Your key pair is unchanged, which means:

• Every environment grant still works. Nobody has to re-share anything with you.
• Your history is intact.
• Your teammates do nothing and notice nothing.

That is the whole reason to keep the Recovery Key somewhere you’ll find it. The other path is considerably more disruptive.

Your old Recovery Key stops working

A used recovery code is burned, and your client generates and uploads a fresh recovery backup immediately.

Write down the new one

The old Recovery Key no longer works. You now have a new one, and it is the only one. Store it before you close the window.

If you get key_mismatch

Stop. This is not a typo error.

key_mismatch means the key your credentials derive does not match what the server served — a wrong Recovery Key produces a different, uniform failure instead. A mismatch means what you were handed disagrees with what you can prove, and the right response is to verify out of band, not to retry.

Email security@cendarum.com.

A mistyped Recovery Key, by contrast, is usually caught before anything runs: the Kit format is checksummed, so a wrong character fails locally and immediately rather than after a 64 MiB key derivation.

If your email is compromised

Someone with your email can drive this flow. What that gets them is bounded, and worth stating precisely:

They can set a password they choose and gain the account API surface — over ciphertext only. They cannot read any secret. The recovery path never changes your public_key, so they cannot produce a valid bundle for your existing key pair or swap in their own.

What they can do is deny you access, and make that denial persistent by overwriting the recovery backup with the password they now know.

This is the inherent property of any email-verified recovery, and it is why the threat model lists email control as a root. Protect the mailbox that can reset things.

What if you have neither factor

If you are on a team, there is admin-assisted recovery.

If you are not, there is nothing. See what is unrecoverable.