Main claim: ECC key refresh gives every threshold peer a new share of the same key, so an attacker who compromised fewer than
tpeers loses the collected shares as a path toward the threshold.
A stolen share gives an attacker control over one part of a threshold key. The attacker still needs t shares from the same generation to reach the signing threshold. Refresh lets the peers jointly replace their shares after a partial compromise while keeping the public key. This article explains what changes, why the compromise stays contained, and when rotation becomes necessary.
What does a partial peer compromise expose?
A partial compromise exposes the shares stored by the affected peers.
Assume a 3-of-5 signing identity. An attacker compromises peers A and B and steals two shares. The attacker remains below the threshold because signing requires three shares from that generation.
The other three peers retain enough capacity to protect the identity and participate in recovery. The private key never needs to appear on one machine.
What happens during key refresh?
The peers run a distributed protocol that creates a fresh share for every participant.
Each new share represents the same elliptic-curve private key. The peers move from one share generation to another without reconstructing the private key.
After the new generation becomes active, signing uses its shares and commitments. The stolen shares from the previous generation stay outside the active threshold set.
The result has two properties:
- every peer holds a new share
- the aggregate public key stays the same
These properties let the system recover from a below-threshold share compromise without changing its public identity.
Why does refresh contain the compromise?
Refresh removes the attacker's progress toward the active threshold.
Return to the 3-of-5 example. The attacker stole two shares from generation 6. The team cleans or replaces the affected peers and refreshes the key.
All five peers now hold generation 7 shares. The two stolen generation 6 shares cannot join a generation 7 signing session or combine with generation 7 shares to reach its threshold.
The attacker must compromise three generation 7 peers to regain the same position. Refresh has reset the share-collection attack after the original compromise stayed below t.
Why does the public key stay the same?
Refresh changes how peers hold the private key while preserving the key itself.
The public key derives from the aggregate private key. Because the aggregate key stays fixed, existing verifiers continue to accept the same public key.
This continuity matters when the key identifies:
- an AI agent across several backends
- a blockchain account
- a deployment signer
- a certificate subject
Those systems can keep their current trust configuration after refresh.
Which keys support cryptographic refresh?
Cryptographic share refresh in TKeeper applies to threshold elliptic-curve keys.
Threshold ECC REFRESH creates new peer shares for the same public key. This includes the elliptic-curve identities used by the supported threshold signing protocols.
ML-DSA REFRESH advances the generation while carrying the existing shares and public key forward. Fresh ML-DSA material requires ROTATE or a new distributed key generation.
Mono REFRESH also advances the generation while keeping the same full private key. Mono mode has no distributed shares to replace.
When should you refresh the key?
Use refresh after a confirmed or suspected compromise of fewer than t threshold ECC peers.
Refresh also fits planned peer replacement and periodic share renewal. Both cases move the active identity to fresh shares while preserving the public key.
The operation should follow containment:
- Identify the peers and credentials exposed by the incident.
- Confirm that the possible share exposure stayed below
t. - Remove attacker access and rebuild affected peers from a trusted base.
- Run ECC refresh with enough healthy peers.
- Confirm that the public key stayed unchanged.
- Complete a signing test with the new generation.
- Handle old generations and backups under the recovery policy.
Running refresh while the attacker still controls a peer gives the attacker access to that peer's new share.
When must you rotate instead?
Rotate when the incident may have exposed enough material to control the existing key.
Rotation creates a new private key and public key. Downstream systems must then trust the new public key and stop accepting the old one for new actions.
Use rotation when:
tshares from one generation may be compromised- a complete mono private key may be compromised
- unsafe signing state may expose the aggregate key
- the algorithm or curve must change
- ML-DSA needs fresh key material
Refresh preserves the current key, so it cannot recover a key that the attacker may already control.
What can weaken the recovery?
A compromised host can leak its refreshed share again. Rebuild the host and its administrative path before trusting the new generation.
Backups can preserve enough old shares to reconstruct an earlier generation. Keep peer backups and their unseal dependencies in separate failure domains.
Cross-peer generation disagreement can stop signing. Confirm that a quorum agrees on the active generation before returning the identity to service.
Broad lifecycle permissions can let an attacker refresh, rotate, or disrupt key state. Keep lifecycle authority narrower than routine signing authority.
What should you do next?
For each threshold ECC identity, record t, the active generation, peer failure domains, and the recovery owner. If fewer than t peers are compromised, contain them and refresh; if exposure may reach t, rotate the key and retire the old public identity.
Read How MPC Distributes AI Agent Signing Risk Across Multiple Nodes for threshold design and The Byzantine Generals Problem in Threshold Signing for faulty-peer behavior.