Recovery and rotation

Two different problems, two different answers.

• Rotation is for a key you still have and no longer want. The old key signs the handoff.
• Recovery is for a key that is gone. Keys you named in advance sign the handoff instead.

Both change the signing key. Neither one involves a login, a support ticket, or us. There is no third path, and adding one would mean somebody other than you could sign as you.

Rotation

You generate a new key, and your old key signs a statement authorizing exactly that new key at exactly that point in your history. The new manifest carries both: it is signed by the new key, and it contains the old key’s authorization.

That is what makes it a handoff rather than a stranger appearing. Anyone who had pinned the old key sees an authorization the old key produced, and follows it forward. Somebody who has only stolen the new key cannot produce that authorization.

The server checks four things before it accepts the change:

1. The manifest verifies under the key that signed it.
2. Its position in your history matches the one we actually hold. The authorization is bound to a position, so it cannot be saved up and replayed later.
3. The named previous key is the one currently registered to you.
4. The old key’s signature covers exactly this key change, byte for byte.

Two things break on purpose when you rotate

Your anchor drops back to unchecked. The file hosted on your domain was signed by the retired key, so it is no longer proof of anything. Re-host and re-verify. Leaving a green badge on a file that no longer verifies would be a lie. See Anchoring.

Your old encrypted backup stops unlocking this identity. It still opens, and it still contains the old key, which is now the wrong key. Take a fresh backup, which the flow requires before it lets you finish.

Recovery

A recovery key is a key you designate in advance, inside your published manifest, and it is the only thing that can take an identity back when the signing key is gone.

Signup asks you to save exactly one thing for this: your recovery code. Set up later and it is still the same mechanism, just later.

The policy has a threshold. One printed recovery code is a threshold of one. Recovery contacts, meaning other people’s keys, are the same shape with a higher threshold, which is why this is a policy rather than a single field.

Caution

A designated recovery key is as powerful as your signing key. Whoever holds enough of them can take the identity. The threshold is the only dial that makes that harder, so treat a printed recovery code exactly like the key itself.

The rule that makes recovery safe

The policy that counts is the one published before the recovery, never the one the recovering entry declares about itself. Otherwise an attacker could simply arrive naming a fresh set of recovery keys and approve the takeover with them.

Every time you re-sign, the current policy is carried forward automatically, so an ordinary publish never quietly strips a recovery key you set up months ago.

If you never published a policy, there is nothing to recover with, and a lost key is final. That is the honest consequence of having no reset link.

Recovery contacts

The threshold mechanism is built and tested, so “three of my five friends can bring me back” already works at the protocol level. What is missing is the interface for inviting people and collecting the keys. Until that ships, use a printed recovery code.

What this actually guarantees

Guaranteed. Anyone reading your full history can tell an authorized key change from an unauthorized one. Both a rotation and a recovery leave a signed record inside the chain, and neither can be forged by somebody holding only the new key. We cannot forge one either, because we never hold a key that can sign the statement.

Not guaranteed. A verifier who has only ever seen your latest manifest pins whatever key signed it, and cannot tell whether that key arrived legitimately. Catching an unauthorized swap requires the history, which is why every version is kept and served. See Reading the history.

Also not guaranteed: that a recovery key stays in the right hands. The protocol enforces that the holder was designated by you. It cannot know who is holding it now.

In the Android app

Neither one is in the app. This is the page with the biggest gap between the two, and the Keys tab says so rather than hiding it: a Rotation & recovery button there opens realhandles.com, and the reason is one line under it.

Both actions turn on a signature the app is not in a position to produce cleanly. A rotation needs the outgoing key to sign the handoff at the moment a new key is being made, and a recovery needs keys designated in advance, which are by definition not the key sitting on the phone you are holding. Doing either badly is how somebody ends up locked out of an identity for good, so the app sends you to the website instead of offering a shortcut.

What the app does show is the result. The signed history under Identity > Data names a rotation or a recovery on the version that carried it, and says whether the handoff was authorized. See Reading the history.