Post-quantum without a big bang: migrating a fleet node by node

A fleet of C2 (command and control) nodes cannot be migrated like a server farm. Nodes are deployed, sometimes isolated, sometimes out of network reach for weeks. Forcing a simultaneous cryptographic cutover of the whole fleet creates a window of fragility that nobody can schedule. OC2-Edge handles the post-quantum migration differently: self-described signature suites, a per-node requirement policy and a hybrid key exchange already active on the mesh. This article describes the mechanism, the stated limit and the normative alignment.

The real threat: capture today, decrypt tomorrow

The mechanism of the quantum threat is known; only its timeline is not. A cryptographically relevant quantum computer, or CRQC, would solve the mathematical problems underlying today’s asymmetric cryptography: factoring for RSA, the discrete logarithm for elliptic curves. No publicly known machine reaches that threshold today.

The attack does not wait for the machine, however. In the “harvest now, decrypt later” scenario, an adversary records interesting encrypted traffic today, stores it, and decrypts it the day a CRQC exists. CISA (Cybersecurity and Infrastructure Security Agency), the NSA (National Security Agency) and NIST (National Institute of Standards and Technology) describe this scenario in their joint quantum-readiness factsheet and recommend starting the migration without waiting for the machine [6].

This scenario targets long-term confidentiality. A position, an operation order or a frequency plan captured today can retain value for years: the lifetime of the secret defines the urgency, not the arrival date of the CRQC. The scenario does not target retroactive authentication. A signature verified today, during the session, authenticates that session at the moment it takes place. An adversary who breaks the key in ten years will be able to forge new signatures at that point; it will not be able to go back and alter what has already been verified. This asymmetry orders the migration: key exchange first, signatures according to key lifetime, session authentication last.

Three self-described signature suites

OC2-Edge signs its system images, its modules and the metadata of its update repository. The signature format does not assume a single algorithm. Three suites coexist in the code:

1. Ed25519 alone: the classical suite, specified by RFC 8032 [7], compact and proven;
2. ML-DSA-65 alone: the post-quantum suite, standardized by NIST in FIPS 204 [1];
3. hybrid Ed25519 + ML-DSA-65: two signatures over the same content, with verification requiring both to be valid.

Every signature carries the identifier of its suite. The verifier reads this identifier before any cryptographic operation: it knows which suite produced the signature, without prior negotiation or out-of-band convention. We call this property self-description. It makes artifacts durable: a module signed at the start of the migration remains verifiable at the end of the migration, whatever suite was used at signing time, as long as the verifying node’s policy accepts it.

The hybrid suite covers two symmetric risks. ML-DSA-65 rests on lattice assumptions more recent than those of Ed25519, and its implementations are young. Ed25519, conversely, will fall to a CRQC. A hybrid signature remains secure as long as either of the two components holds. ANSSI (the French national agency for the security of information systems) recommends this hybridization for the entire transition period [4].

A graduated policy: hardening node by node

Coexisting suites do not mean the absence of requirements. Each node applies a local policy that defines which suites are accepted at verification time. The policy hardens in steps:

1. accept all three suites: the initial state, compatible with everything already deployed;
2. require a post-quantum component: the node rejects an Ed25519-only signature, accepts the hybrid and ML-DSA-65 alone;
3. reject any purely classical suite: the node only accepts the hybrid or ML-DSA-65 alone, depending on configuration.

Moving from one step to the next is decided and deployed node by node. A hardened node rejects artifacts below its threshold and keeps verifying those above it. Signers publish hybrid signatures as early as possible: their artifacts satisfy every step at once. There is therefore no D-day, no window in which the whole fleet would have to be re-signed simultaneously, and no intermediate state in which a node could no longer verify its peers. A heterogeneous fleet, with recent nodes and isolated nodes updated late, remains operable throughout the transition. This is what we mean by migration without a big bang.

The hybrid X25519MLKEM768 KEM on the mesh

Confidentiality, the direct target of “harvest now, decrypt later”, cannot wait for the signature steps. On the mesh, OC2-Edge establishes its sessions with the hybrid KEM (key encapsulation mechanism) X25519MLKEM768: a classical X25519 exchange and an ML-KEM-768 encapsulation, standardized in FIPS 203 [2], combined for TLS (Transport Layer Security) 1.3 as specified by the IETF draft [5]. The session secret derives from both exchanges. An adversary recording traffic today will have to break both X25519 and ML-KEM-768 to decrypt it tomorrow. Protection against deferred capture is therefore effective now, regardless of how far the fleet’s signature steps have progressed.

The stated limit: TLS session authentication remains classical

The authentication of mesh TLS sessions, certificates and handshake signature, remains classical: Ed25519 or ECDSA. This is a documented choice, not a blind spot, and it is rational today for three reasons.

1. The deferred threat does not apply to this function. Authentication is a property of the moment of the session: a future CRQC does not retroactively forge a handshake that has already been verified. The confidentiality of those same sessions is already protected by the hybrid KEM.
2. The cost is immediate and measurable. An ML-DSA-65 signature occupies 3309 bytes, against 64 bytes for Ed25519 [1] [7]. On constrained radio links, making every handshake heavier is paid for at every session establishment.
3. The post-quantum certificate ecosystem is not yet stable. The day it is, the machinery already exists: certificates will join the same scheme of self-described suites and policy steps as artifact signatures.

The residual risk is bounded: it concerns an adversary holding a CRQC at the very moment of the session, able to impersonate an identity in real time, a scenario later than deferred capture. This point is tracked as an open point in PQC_MIGRATION.md.

Alignment: FIPS 204, FIPS 203, CNSA 2.0, ANSSI

The choices made in OC2-Edge rest on public references.

• FIPS 204 standardizes ML-DSA, the selected signature scheme [1]. FIPS 203 standardizes ML-KEM, the post-quantum component of the KEM [2].
• CNSA 2.0, the algorithm suite mandated by the NSA for United States national security systems, prescribes the post-quantum transition with a timeline extending to the exclusive use of post-quantum algorithms in 2033 [3]. CNSA 2.0 selects ML-DSA-87; OC2-Edge selects ML-DSA-65, NIST security category 3 [1], a trade-off between security margin and signature size on constrained links. The difference is acknowledged and documented.
• ANSSI recommends systematic hybridization during the transition and asks organizations to inventory their cryptographic usage before migrating [4]. The graduated policy provides that inventory in practice: each node declares its step, and the fleet’s migration state can be read instead of estimated.

Verify in the repository

The PQC_MIGRATION.md document in the repository describes the three suites, the suite identifier carried by every signature, the policy steps and the open points, including TLS authentication. The public repository, under the Apache-2.0 license, counts ~930 automated tests passing. Reading the document, then the code, is enough to confront this article with what is actually implemented.

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, “Avis de l’ANSSI sur la migration vers la cryptographie post-quantique”, 2022, supplemented in 2023, https://cyber.gouv.fr/publications/avis-de-lanssi-sur-la-migration-vers-la-cryptographie-post-quantique-0
5. IETF, TLS working group, “Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3”, draft-ietf-tls-ecdhe-mlkem, 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 (EdDSA)”, 2017, https://datatracker.ietf.org/doc/html/rfc8032