Pre-Rotation: How KERI Commits to Future Keys Before You Need Them

Most key rotation schemes share a subtle vulnerability. When you rotate a compromised key, you use the compromised key to authorise the rotation, signing a statement that says "from now on, trust this new key instead." If an attacker has your current private key, they can issue that same statement, rotating your identity to a key they control. The window between compromise and detection is the attack surface, and the rotation mechanism itself becomes the exploit vector.

KERI's pre-rotation closes this window through a cryptographic commitment made before any compromise has occurred.

The Commitment Mechanism

When you create a KERI identity, or perform any rotation, you do two things simultaneously. You establish the current authoritative key set that will sign events from this moment. And you include a cryptographic commitment to your next key set: the digest of the next set of public keys.

The next keys themselves remain secret. They've been generated, but they haven't been published, transmitted, or used for any operation. No one, not your witnesses, not your verifiers, not an attacker observing the network, knows what those keys are. The only thing on the public record is their hash.

When you eventually rotate, you publish a rotation event that reveals the actual next key set and simultaneously commits to the next-next key set. Every verifier applies two checks: that the rotation event is signed by the current authoritative keys, and that the revealed keys hash to the digest committed in the previous event. Both conditions must hold. If either fails, the event is rejected by every compliant verifier.

The chain of commitments is continuous. Every state of the identity includes a commitment to its successor. There is never a moment where the identity exists without a pre-committed next state.

Why This Changes the Attack

Consider an attacker who compromises your current private key. In a standard rotation scheme, they can sign a valid rotation event transferring control to a key they control. Your identity is captured.

With pre-rotation, they cannot. They have your current key, which is sufficient to sign interaction events, but any rotation event they produce will fail the commitment check. They can't produce keys that hash to the digest committed in the previous event, because that digest was computed from keys they've never seen. The valid rotation is the one that reveals the pre-committed keys, and only the legitimate controller holds those.

Key compromise no longer immediately implies identity capture. The attacker can sign interaction events with the compromised key, which is serious and may need to be addressed. But they cannot transfer control of the identity to themselves. The controller's ability to recover is preserved as long as the pre-rotation keys are intact, and they should be, because they've never been exposed to a networked system.

Hot Keys and Cold Keys

Pre-rotation creates a natural operational separation. The current authoritative keys are hot, online, accessible, actively used to sign events. The pre-rotation keys are cold, generated, secured, and never exposed until the moment of rotation.

This separation is not a recommended practice layered on top of the protocol. It is what the protocol mechanically enforces. You cannot rotate without revealing the pre-rotation keys, which means they only ever touch a live system for one event, the rotation that consumes them and simultaneously establishes new commitments. After rotating, you generate the next pre-rotation key set, commit to its digest in the rotation event, and move those keys back to cold storage.

The pattern mirrors hardware security module practices and the cold/hot wallet discipline familiar in production cryptographic infrastructure. KERI formalises it at the protocol level rather than leaving it as operational guidance that teams may or may not follow. The protocol makes the secure practice the only practice.

Forward Security Without a Trusted Third Party

What makes pre-rotation elegant is that it achieves forward security, the property that compromise of current keys does not grant the attacker authority over future states, without requiring any external infrastructure to enforce it. No timestamp authority. No certificate revocation list. No trusted intermediary.

The constraint is self-enforcing through the commitment chain in the key event log. A verifier checking a rotation event doesn't need to consult anything external to determine whether the rotation is valid, the commitment digest from the previous event is right there in the log, and the revealed keys either match it or they don't. The verification is local, deterministic, and independent of any external service's availability.

This is consistent with KERI's broader design philosophy: cryptographic structure should provide the guarantees that institutions and intermediaries typically provide. Pre-rotation isn't a feature for security-conscious users. It's the only way rotation works in KERI. The protocol doesn't offer an insecure alternative.