Evidence boundary: Contemporary key-management guidance, cryptographic-transition practice, and post-quantum standards address present security horizons. They do not validate an algorithm, key store, identity institution, or archive for centuries. NIST standardized ML-KEM, ML-DSA, and SLH-DSA in 2024; standardization does not mean they are eternal, implementation-proof, or already integrated into safety-critical space systems. This lesson is a civil-and-defensive design synthesis, not cryptographic certification. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. High-consequence cryptographic, identity, and dual-use decisions require two-person review.
Plain-language summary
Cryptography helps a community answer questions such as:
- Did this command come from an authorized role?
- Has this medical or engineering record changed?
- May this device join the control network?
- Is this software release the one that reviewers approved?
- Can only the intended people read this private information?
The mathematics is only part of the system. Keys must be generated, stored, used, recovered, revoked, and eventually destroyed. Devices and people need identities. Clocks and event sequences must remain interpretable. Old records must still be readable after algorithms and institutions change.
A generation ship cannot assume that Earth will issue a replacement certificate, recover a lost key, publish a new cryptographic library, or resolve a disputed signature. The ship needs crypto agility: a measured ability to discover where cryptography is used, replace algorithms and implementations, migrate protected material, and keep essential service operating through the transition. Agility does not mean making every choice configurable by anyone.
Inventory before migration
An algorithm inventory should record more than the word “encryption.” For each use, capture:
- purpose: confidentiality, integrity, authentication, key establishment, commitment, timestamping, or random generation;
- algorithm, parameters, mode, protocol, library, hardware, and version;
- keys, certificates, trust anchors, owners, custodians, and authorized uses;
- protected data and required protection lifetime;
- dependent devices, software, records, and recovery paths;
- clock, sequence, revocation, and network assumptions;
- migration and rollback capability;
- known compatibility constraints; and
- evidence that implementation behaves as intended.
The inventory must include hidden uses: boot verification, factory controllers, medical instruments, backup formats, database checksums, wireless links, access badges, archived legal signatures, AI-model provenance, and spare hardware sealed for later use. A migration that finds only central servers can strand the machines that sustain life.
NIST’s 2025 crypto-agility guidance defines agility as the capability to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. That is a present practice goal, not evidence of multigenerational success.
Separate purpose from mechanism
Design interfaces around required security properties and explicit policy, while keeping implementations replaceable. A record should say what kind of assurance it needs, for whom, and for how long—not merely that it uses one named algorithm.
However, abstraction can conceal important differences. New algorithms may have larger keys or signatures, different failure modes, stronger randomness requirements, higher compute or memory demand, and incompatible hardware acceleration. A controller with small memory or a low-bandwidth conduit may not accept a simple library swap.
Therefore agility needs:
- multiple implementation paths where consequence justifies them;
- test vectors and known-answer tests preserved offline;
- capacity margins for larger keys, signatures, and protocol messages;
- versioned formats that identify algorithms and parameters;
- negotiation policies that prevent silent downgrade;
- hardware-independent fallback for essential verification where feasible;
- source, build tools, specifications, and readable reference implementations; and
- representative migration exercises on old hardware.
Algorithm diversity can reduce common-mode risk, but unnecessary variants increase complexity. The objective is planned transition, not cryptographic abundance.
Keys are governed material
NIST SP 800-57 covers key generation, storage, use, backup, recovery, compromise, revocation, archival, and destruction. On a ship, these functions become local civic institutions.
No single person should hold a universal key to identity, life support, archives, manufacturing, and recovery. High-consequence authority can use threshold control: several independently selected custodians must cooperate. Custodians should rotate, train successors, declare conflicts, and work under observable procedure.
Threshold schemes do not solve governance by themselves. A coalition can collude; shares can be lost together; a rule can exclude disabled residents; emergency access can become permanent. Recovery design should specify:
- how many independent shares exist and what failures they tolerate;
- physical and institutional separation;
- accessibility and succession;
- activation conditions and time limits;
- evidence recorded without exposing secret material;
- appeal and retrospective review;
- response when compromise is suspected; and
- a path to replace the recovery system itself.
Backup keys are dangerous because they preserve access. No backups are dangerous because loss can become irreversible. The correct balance depends on the consequence and protection lifetime.
Identity without a permanent Earth authority
People are born, mature, change roles, lose capabilities, and die. Devices are manufactured, repaired, combined, reassigned, and retired. Institutions change legitimacy. Identity must represent that lifecycle without turning ancestry, occupation, or political status into an immutable hierarchy.
Distinguish:
- a person or device;
- an identifier;
- a credential binding an identifier to evidence;
- a role granting bounded authority;
- an authorization decision at a particular time; and
- an audit record that may itself be contested.
A credential validly issued under an old constitution may no longer authorize current action. A device may hold an intact key after its sensors become untrustworthy. A signed maintenance command can be authentic and unsafe. Cryptography supports policy; it does not decide legitimate policy or physical fitness.
Emergency credentials should be scoped, expire, and trigger independent review. Identity services must preserve access to basic life and due process during partition or recovery. They must not become an unappealable social score.
Time, sequence, revocation, and partition
Many security decisions ask whether a credential or message is still valid. That requires time or a reliable sequence. Yet clocks drift, timing hardware fails, zones partition, and delayed messages arrive later.
The design should separate:
- physical mission time and its uncertainty;
- local monotonic event sequence;
- civil calendars and institutional terms;
- cryptographic validity intervals;
- evidence receipt time; and
- claims about when an event actually happened.
During partition, a zone may not receive revocation information. A strict refusal policy can halt care or control; unconditional acceptance can preserve compromised authority. Predeclared degraded modes should limit privilege, duration, and affected resources while recording evidence for reconciliation. No universal rule resolves every trade; safety and rights reviewers must examine each use.
Archives outlive algorithms
A signature verifies under a particular algorithm, key, policy, and evidence context. Decades later, the algorithm may be deprecated, the key destroyed, the signer dead, the certificate authority reorganized, and the file format obscure.
Archival preservation should retain:
- original bytes and format documentation;
- signature, certificate chain, policy, revocation evidence, and validation time;
- contextual records explaining the signer’s authority;
- independent hashes and replicated storage;
- migration history and custodial actions;
- periodic validation before algorithms weaken; and
- renewed attestations that bind old evidence to new mechanisms without erasing the original.
Migration is not permission to rewrite history. Preserve originals, explain transformations, and allow contested interpretations. Important constitutional, medical, scientific, and maintenance records may need different confidentiality and availability periods.
Post-quantum standards are a transition, not an ending
NIST FIPS 203 defines ML-KEM for key establishment; FIPS 204 defines ML-DSA; FIPS 205 defines SLH-DSA. These standards provide present alternatives intended to resist known quantum attacks. They should be evaluated for protocol fit, implementation quality, performance, side-channel behavior, storage, bandwidth, and recovery.
A generation-spanning design should expect further cryptanalysis and new standards. Hybrid transitions may preserve assurance from different assumptions, but add complexity and can fail if composed poorly. The correct claim is not “post-quantum forever.” It is “maintain an inventory, monitor evidence, test alternatives, migrate deliberately, and preserve fallback.”
LLMs are not roots of trust
An offline LLM could locate cryptographic uses in source code, explain an old certificate policy, compare inventories, or draft a migration checklist. It can also hallucinate an algorithm identifier, misunderstand a validity rule, leak sensitive context into logs, or be influenced by poisoned documentation.
The model must cite controlled local sources, distinguish retrieved fact from inference, and never receive secret keys merely to answer a question. It cannot generate production keys, approve identity, authorize revocation, interpret a constitutional dispute, or certify a migration. Model weights and retrieval data require provenance and poisoning checks. Human operators must avoid overreliance, retain non-AI procedures, and confirm critical outputs with deterministic tools and two qualified reviewers.
A migration exercise
A meaningful test starts with an intentionally old but representative island. Inventory every cryptographic dependency. Announce deprecation of one algorithm and compromise of one authority. Partition the island from central identity. Replace a controller with locally available hardware. Migrate active communications, firmware verification, private records, and archival signatures while preserving minimum safe service.
Then test loss of a key custodian, clock disagreement, delayed revocation, corrupt backup, a poisoned AI explanation, and rollback pressure. Independent observers should verify not just message success, but authority, rights, record continuity, physical safety, and recovery.
Evidence ledger
- L11-04-A — Present key-management and crypto-agility guidance covers inventories, lifecycle controls, transition planning, and operational continuity. Basis: observed. Readiness: operational in current institutions; major scale-up for permanent local autonomy. Confidence: strong.
- L11-04-B — NIST standardized ML-KEM, ML-DSA, and SLH-DSA in 2024. Basis: observed. Readiness: operational standards with implementation and integration work continuing. Confidence: strong.
- L11-04-C — Standardization does not establish century security, correct implementation, safe integration, or archival continuity. Basis: normative evidence boundary. Readiness: no known demonstrated century path. Confidence: strong.
- L11-04-D — Trust anchors, identity, secure time, revocation, threshold recovery, migration, and archival interpretation must operate locally after Earth is unavailable. Basis: proposed requirement. Readiness: early research as an integrated system. Confidence: supported.
- L11-04-E — Cryptography cannot by itself establish physical truth, competence, legitimacy, or justice. Basis: normative systems boundary. Readiness: operational as a design principle. Confidence: strong.
- L11-04-F — Crypto agility and toolchain preservation have Earthside value for long-lived medical, energy, transport, and public systems. Basis: proposed extrapolation from current transition problems. Readiness: operational to major scale-up by sector. Confidence: supported.
Linked corpus claims: claim-12-02, claim-12-04, claim-12-05, claim-12-06, claim-12-09, and claim-12-10. See the claim registry for each record's current evidence grade and independent-review state.
Assumptions and limits
- No current algorithm is assumed secure for the full mission.
- NIST standards are present reference points, not generation-ship certification or universal law.
- “Crypto agility” includes people, policy, hardware, formats, archives, and recovery—not only software interfaces.
- Threshold custody does not eliminate coercion, collusion, exclusion, or institutional failure.
- Archival renewal can preserve evidence chains but cannot recreate missing social context.
- LLMs remain offline-capable, evidence-linked, non-authoritative, logged, and excluded from secrets and trust-anchor decisions.
- This lesson contains no exploit procedure, offensive operation, or weapon integration.
What would change this conclusion?
Confidence would increase after public, repeatable migrations across old hardware, partitioned identity, disputed time, lost custodians, revoked authorities, archival evidence, and locally rebuilt toolchains—without loss of minimum safe service or due process. Discovery of a practical long-duration primitive would change the migration cadence, not remove the need for inventory and governance. Inability to locate cryptographic dependencies, rotate root authority, interpret old records, or recover after compromise is a wait/do-not-launch condition.
Sources and locators
- S01 — NIST CSWP 39 Update 1, Considerations for Achieving Crypto Agility (opens external site in a new tab). Locator: definition, inventory and discovery, transition strategies, protocol and application considerations, operational trade-offs, and future work; December 2025 with updates through 2026-06-29; accessed 2026-07-25.
- S02 — NIST SP 800-57 Part 1 Revision 5, Recommendation for Key Management (opens external site in a new tab). Locator: sections 5–8 on security services, algorithms, key lifecycle, protection, compromise, backup, recovery, archival, and destruction; May 2020; accessed 2026-07-25.
- S03 — NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (opens external site in a new tab). Locator: sections 1–7, approved ML-KEM parameter sets and implementation requirements; August 2024, errata noted by NIST; accessed 2026-07-25.
- S04 — NIST FIPS 204, Module-Lattice-Based Digital Signature Standard (opens external site in a new tab). Locator: sections 1–7 and ML-DSA parameter sets; August 2024; accessed 2026-07-25.
- S05 — NIST FIPS 205, Stateless Hash-Based Digital Signature Standard (opens external site in a new tab). Locator: sections 1–7 and SLH-DSA parameter sets; August 2024; accessed 2026-07-25.
- S06 — NIST SP 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths (opens external site in a new tab). Locator: transition status categories and guidance for algorithms and key lengths; March 2019; accessed 2026-07-25.
- S07 — NIST SP 800-130, A Framework for Designing Cryptographic Key Management Systems (opens external site in a new tab). Locator: goals, policies, roles, lifecycle functions, compromise recovery, and design documentation; August 2013; accessed 2026-07-25.
- S08 — NIST AI 600-1, Generative Artificial Intelligence Profile (opens external site in a new tab). Locator: confabulation, data privacy, information integrity, human-AI configuration, and value-chain risk sections; July 2024; accessed 2026-07-25.
Editorial record
- Prepared by: GShips Project
- Last edited: 2026-07-25
- Status: Substantive editorial draft
- Independent domain review: Pending; high-consequence cryptographic, identity, governance, and dual-use claims require explicit two-person review before publication
- Required review: cryptography, key management, identity, archival science, safety engineering, governance, and software assurance
- Reviewer: No independent reviewer assigned
- Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
- Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NIST or any named organization
- Scope boundary: Civil and defensive resilience only; offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
- Corrections: Suggest a correction