All articles

A practical path to post-quantum fleet security one node at a time

AGELAIOS

Engineering

AGELAIOS signature suites and a fleet progressing from classical to hybrid post-quantum protection one node at a time.

A cryptographic migration is simple on a whiteboard. Choose new algorithms, update every system and retire the old ones. A deployed C2 fleet does not offer that luxury.

Some nodes are connected every day. Others operate through constrained links, remain isolated for weeks or return from deployment long after the rest of the fleet has changed. If security depends on every node switching at the same moment, the migration plan is already fragile.

AGELAIOS takes a different approach. It protects mesh confidentiality with a hybrid post-quantum key exchange today, while self-described signature suites and local verification policies let operators harden artifact verification node by node. The result is not a promise of instant quantum immunity. It is a controlled migration path designed for the operational reality of heterogeneous fleets.

The risk starts before a quantum computer exists

No publicly known quantum computer can currently break the asymmetric cryptography used in modern operational systems. That fact does not remove the immediate risk.

In a harvest now, decrypt later attack, an adversary records encrypted traffic, stores it and waits. If a cryptographically relevant quantum computer becomes available later, traffic protected only by vulnerable public-key mechanisms may then be exposed. CISA, NSA and NIST explicitly identify this scenario and recommend preparing migrations before such a machine exists [6].

For C2 systems, the useful life of the information sets the clock. A position history, an operational order or a frequency plan may remain sensitive long after transmission. Waiting for a confirmed quantum breakthrough would therefore mean starting after potentially valuable traffic had already been collected.

This also gives the migration a clear order of priority. Long-term confidentiality comes first because recorded exchanges can be attacked later. Artifact signatures must evolve because system images and modules may be verified years after they are produced. Live session authentication presents a different risk because an attacker would need quantum capability at the time of the connection to impersonate a peer.

AGELAIOS uses that distinction to invest first where the exposure begins first.

Hybrid confidentiality on the mesh

AGELAIOS establishes mesh sessions with X25519MLKEM768. This TLS 1.3 hybrid key agreement combines X25519 with ML-KEM-768, the post-quantum key encapsulation mechanism standardized by NIST in FIPS 203 [2]. The combination is specified by the IETF TLS working group [5].

The two components serve complementary purposes. X25519 retains the assurance and interoperability of a widely deployed classical mechanism. ML-KEM-768 adds protection against the class of quantum attacks that threatens elliptic-curve key exchange. The TLS shared secret incorporates material from both.

Consider a field node transmitting an operational picture today. An observer may capture the encrypted session in full. Under the security construction of the hybrid exchange, recovering that session later requires defeating both components rather than waiting for X25519 alone to become vulnerable. This is the practical value of hybridization. It adds post-quantum protection without discarding the confidence built around established classical cryptography.

The claim has a precise boundary. Hybrid key exchange protects the confidentiality of mesh sessions against deferred decryption, provided the protocol and its implementations behave as specified and at least one component remains secure. It does not make every cryptographic function in the product post-quantum.

Signature agility without an all-fleet cutover

Confidentiality is only one part of the transition. AGELAIOS also verifies system images, modules and update-repository metadata. These artifacts need signatures that remain understandable throughout a migration that may span several deployment cycles.

The signature format therefore identifies the suite used to produce each signature. A verifier does not have to infer the algorithm from context or rely on an out-of-band agreement. It reads the suite identifier, applies the corresponding verification procedure and then enforces its local acceptance policy.

Three suites are represented:

  1. Ed25519 provides the compact classical option defined by RFC 8032 [7].
  2. ML-DSA-65 provides a post-quantum signature standardized in FIPS 204 [1].
  3. The hybrid suite applies both Ed25519 and ML-DSA-65 to the same content and requires both signatures to verify.

This self-description separates compatibility from policy. A node can understand several suites without being required to accept all of them. That distinction is essential in a fleet where software versions, mission constraints and connectivity differ from one node to another.

Hybrid signatures also avoid replacing one concentration of risk with another. Ed25519 has extensive deployment experience but is not resistant to a sufficiently capable quantum computer. ML-DSA-65 addresses that threat, although the algorithm and its implementations have less operational history. Requiring both signatures during the transition preserves the classical assurance while adding the post-quantum component. This approach is consistent with ANSSI guidance, which strongly recommends hybridization for post-quantum deployments in the short and medium term [4].

What node-by-node migration looks like

Imagine a fleet with three different operating conditions. A headquarters node is continuously connected. A vehicle returns to base once a week. A remote node may remain unreachable for a month.

With a simultaneous cutover, the last node dictates the schedule for everyone. Tightening policy too early can strand it. Waiting for it keeps the rest of the fleet on the older posture. Neither option is attractive.

AGELAIOS lets each node enforce a local verification threshold. During the compatibility phase, a node can accept Ed25519, ML-DSA-65 and hybrid signatures. Once its software and artifact supply are ready, its policy can require a post-quantum component, which excludes Ed25519-only artifacts. Operators can then retain hybrid verification during the transition or move to an approved post-quantum-only policy when their assurance framework permits it.

Publishing hybrid-signed artifacts early creates the bridge between these states. Nodes still in compatibility mode can verify them, and nodes with a post-quantum requirement can accept them as well. The fleet can therefore advance without scheduling a universal cryptographic D-day.

This model delivers three operational benefits:

  1. Continuity. Temporarily isolated nodes do not force a fleet-wide security freeze.
  2. Control. A hardened node fails closed when an artifact falls below its configured requirement.
  3. Visibility. The accepted suites and the policy applied by each node can be inspected instead of inferred from a nominal migration plan.

The point is not to make migration effortless. Key management, software distribution, rollback planning and assurance work still have to be done. The value is that these tasks become staged, observable and reversible at fleet scale.

A deliberate boundary around TLS authentication

AGELAIOS currently keeps mesh TLS certificates and handshake signatures on classical Ed25519 or ECDSA authentication. This limitation is documented in PQC_MIGRATION.md.

The decision reflects a risk and cost trade-off. The hybrid key agreement already addresses the immediate harvest now, decrypt later exposure for session confidentiality. By contrast, exploiting a future break of the classical authentication key would not retroactively decrypt a previously recorded hybrid session. The more relevant residual threat is real-time impersonation once an attacker has access to a capable quantum computer.

There is also a concrete link cost. A raw ML-DSA-65 signature is 3,309 bytes, compared with 64 bytes for Ed25519 [1] [7]. Certificate chains and protocol encoding add further overhead. On radio links where every byte and retransmission matters, changing handshake authentication deserves measurement against representative bearers rather than an assumption based on data-center networks.

This does not remove TLS authentication from the roadmap. It identifies it as an open migration area while the post-quantum certificate and protocol ecosystem matures. Buyers and evaluators can assess that boundary directly instead of discovering it after deployment.

Standards guide the design without replacing evidence

AGELAIOS bases its choices on public standards and states where those choices differ from a specific external profile.

FIPS 203 standardizes ML-KEM, including ML-KEM-768 [2]. FIPS 204 standardizes ML-DSA, including ML-DSA-65 [1]. The IETF specification for hybrid ECDHE and ML-KEM key agreement defines X25519MLKEM768 for TLS 1.3 [5].

ANSSI recommends hybrid post-quantum protection during the transition so that newer algorithms do not introduce a regression against established classical security [4]. The AGELAIOS hybrid KEM and signature suite follow that design principle.

CNSA 2.0 confirms the strategic direction toward ML-KEM and ML-DSA for United States National Security Systems [3]. It selects the higher ML-DSA-87 parameter set for its profile. AGELAIOS uses ML-DSA-65, NIST security category 3, to balance security margin and signature size on constrained links. This is an explicit design choice, not a claim of CNSA 2.0 compliance.

Standards alignment matters, but names on a feature list are not proof. The relevant questions are which parameter set is used, where it is used, what remains classical and how policy is enforced. Those answers must be visible in the implementation.

Evaluate the migration path before buying the promise

The reference repository documents the three signature suites, the identifier carried by each signature, the verification policies and the remaining work on TLS authentication in PQC_MIGRATION.md. It is published under Apache-2.0 and reports approximately 930 automated tests passing.

A meaningful evaluation can therefore go beyond a presentation. Review the migration document. Inspect the policy checks. Sign the same artifact with each suite. Verify it under each acceptance mode. Confirm that an Ed25519-only artifact is rejected when a post-quantum component is required. Then test the hybrid TLS exchange on links representative of the intended deployment.

That is the AGELAIOS proposition in practical terms. Post-quantum preparation becomes a sequence of verifiable operating decisions, not a fleet-wide leap of faith.

Sources

  1. NIST, “FIPS 204 Module-Lattice-Based Digital Signature Standard”, 2024, https://csrc.nist.gov/pubs/fips/204/final
  2. NIST, “FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard”, 2024, https://csrc.nist.gov/pubs/fips/203/final
  3. NSA, “Announcing the Commercial National Security Algorithm Suite 2.0”, 2022, https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
  4. ANSSI, “ANSSI views on the Post-Quantum Cryptography transition”, 2022, updated in 2023, https://messervices.cyber.gouv.fr/documents-guides/follow_up_position_paper_on_post_quantum_cryptography.pdf
  5. IETF TLS Working Group, “Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3”, 2026, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
  6. CISA, NSA and NIST, “Quantum-Readiness Migration to Post-Quantum Cryptography”, 2023, https://media.defense.gov/2023/Aug/21/2003284212/-1/-1/0/CSI-QUANTUM-READINESS.PDF
  7. IETF, “RFC 8032 Edwards-Curve Digital Signature Algorithm”, 2017, https://datatracker.ietf.org/doc/html/rfc8032