Crypto Agility and Migration

No algorithm is hard-coded; every key, certificate, and protocol carries an algorithm identifier so schemes can be rotated without redesigning the plant.

Assume today's algorithms will be retired

Cryptographic history is a history of deprecations. A plant that hard-codes a cipher will one day need surgery to replace it. Kronos designs for agility: algorithms are named in metadata, negotiated at connection time, and swappable behind stable interfaces. When a scheme weakens - classical or post-quantum - it can be phased out through configuration and re-issuance rather than a rebuild.

Mechanisms of agility

• Algorithm identifiers on every artifact (certs, signatures, encapsulations) so verifiers know what to run.
• Negotiated suites with a policy-driven minimum, so weak options can be disabled centrally.
• Hybrid modes (classical + PQC) as the default during transition - see ML-KEM hybrid.
• Short credential lifetimes so a policy change propagates in hours via re-issuance - see zero-trust identity.

# Verifier dispatches by declared algorithm and enforces a floor
def verify(artifact):
    alg = artifact.alg_id
    if alg not in policy.allowed or policy.strength(alg) < policy.floor:
        return REJECT               # deprecated schemes fail policy, not code
    return REGISTRY[alg].verify(artifact)

Migration without downtime

Because control availability matters, migrations are staged: introduce the new algorithm alongside the old, require both (hybrid), then raise the policy floor to retire the old one once every node presents the new. The audit log records the transition so verification of historical artifacts still resolves the algorithm they were signed with.

Design status

The algorithm registry, negotiation, and policy-floor enforcement are implemented in the twin. The migration playbook is exercised in simulation by rotating a suite end to end; it has not yet been run against live reactor hardware, which begins with the FOAK build.