Quantum-safe data centre replication encryption explained

Quantum-safe data centre replication encryption means protecting storage replication, database log shipping and backup traffic between your own data centres with a key exchange that holds up against quantum attacks, usually hybrid ML-KEM combined with classical ECDH. Strong symmetric ciphers then carry the data, so copied data stays confidential for as long as it is kept.

For operators of OT and critical infrastructure, these links carry historian archives, SCADA and DCS configuration backups, engineering project files and identity databases. This article explains why these links deserve priority, how to add post-quantum key exchange without hurting throughput, how MACsec compares with IPsec, how often to rotate keys and where AES-256 fits in.

Why are replication and backup links between data centres a prime target for harvest now, decrypt later?

Replication links send a complete, constantly refreshed copy of an organisation’s most valuable data over a predictable path. Anyone who records that traffic today and breaks the key exchange later gets everything at once.

Most traffic is fragmented and short-lived. Replication is different in several ways:

• It is complete. One captured stream holds whole volumes, database transaction logs or full backup sets, not scattered sessions.
• It is predictable. The endpoints are fixed, the link is always on and the traffic often leaves the building over leased wavelengths or carrier circuits where passive capture leaves no trace.
• It lasts. Backups are often kept for years, and OT asset lifecycles run for decades. A network diagram or safety system configuration copied today may still describe the plant in 2040.
• It is set once and left alone. Replication tunnels are often configured during commissioning and seldom reviewed, so classical-only key exchange can stay in place for a long time.

Michele Mosca’s risk model puts this into a simple test: if the number of years your data must stay secret plus the years you need to migrate is greater than the years until a cryptographically relevant quantum computer (CRQC) exists, you are already exposed. Expert opinion makes that test hard to pass for long-retention data:

Statistic: In a survey of 32 leading science and industry experts in the field, approximately two-thirds estimated a 50% or greater likelihood of the arrival of a cryptographically relevant quantum computer within the next 15 years (Mosca and Piani, 2024, cited by the OECD).

US policy sets a similar horizon. National Security Memorandum 10 calls for a transition to quantum-resistant cryptography “with the goal of mitigating as much of the quantum risk as is feasible by 2035”.

Is AES-256 on its own enough to protect replicated data against quantum computers?

AES-256 as specified in NIST FIPS 197 is not the weak point. The risk sits in how the AES key is agreed. If ECDH or RSA delivers that key, recorded traffic becomes readable once the key exchange is broken, however strong the cipher is.

Grover’s algorithm gives a quantum computer only a square-root speedup against symmetric ciphers, so AES-256 keeps roughly 128-bit strength. NIST says that symmetric-key crypto (AES, SHA) would also be affected (by Grover’s algorithm), but less dramatically. Dustin Moody of NIST’s Cryptographic Technology Group adds that “NIST-approved symmetric primitives providing at least 128 bits of classical security continue to be approved”. NSA CNSA 2.0 also keeps AES-256 as its symmetric algorithm.

Shor’s algorithm is the real problem. It breaks the public-key methods that IPsec and TLS use to derive session keys. NIST has set dates for phasing them out:

Statistic: Under NIST IR 8547 (initial public draft, November 2024), quantum-vulnerable algorithms at 112-bit security strength are deprecated after 2030, disallowed after 2035, and 128-bit and higher are disallowed after 2035.

So the practical answer is to keep a 256-bit symmetric cipher and replace or supplement the key agreement. Any 256-bit AEAD will do. Quantum Network’s QPN gateway, for example, pairs a hybrid ML-KEM key agreement with ChaCha20-Poly1305 for the payload. The cipher choice matters less than whether the key behind it came from a classical-only exchange. One alternative is mixing in a symmetric post-quantum pre-shared key (RFC 8784). It works, but distributing and rotating those keys by hand across many sites is an operational burden.

How do you encrypt high-throughput replication traffic with hybrid ML-KEM without losing bandwidth?

ML-KEM only runs during handshakes and rekeys, not per packet, so it barely affects bulk throughput. Bandwidth losses on replication links almost always come from fragmentation, packet overhead and single-flow bottlenecks, not from the post-quantum algorithm.

Keep the handshake standard and hybrid

For IPsec, RFC 9370 is the standard mechanism. This method allows integration of PQC in IKEv2, while maintaining backward compatibility, to derive a set of IKE keys that is resistant to quantum-computer attacks. The classical exchange runs in IKE_SA_INIT, and the ML-KEM exchange follows in IKE_INTERMEDIATE messages, where IKEv2 fragmentation (RFC 7383) can handle the larger keys. Because both secrets feed the session key, an attacker would have to break both exchanges to recover it.

Statistic: NIST standardized ML-KEM as FIPS 203 in August 2024, and FIPS 203 specifies three parameter sets; ML-KEM-512, ML-KEM-768 and ML-KEM-1024.

Statistic: RFC 9370 does not attempt to address key exchanges with KE payloads longer than 64 KB; the current IKE payload format does not allow such a possibility. All ML-KEM parameter sets fit well within that limit.

Since the KEM cost is paid once per handshake, choosing ML-KEM-1024 (the parameter set CNSA 2.0 specifies) instead of ML-KEM-768 costs almost nothing on a replication link.

Tune the data plane, not the KEM

• MTU and MSS: Replication networks often use jumbo frames. Tunnel encapsulation adds headers, so either raise the MTU of the underlying path or clamp TCP MSS. Fragmented packets cut throughput far more than encryption does.
• Parallelism: A single tunnel carrying one large flow may be handled on a single CPU core. Spread the replication streams across several tunnels, security associations or gateways so they run in parallel.
• Latency budget: Synchronous replication waits for every write to be acknowledged, so added per-packet latency directly affects application performance. Asynchronous replication and backup tolerate much more.
• Realistic testing: Benchmark with the real replication engine and representative write patterns, including the moment of a rekey, not just synthetic bulk transfers.

Is MACsec or IPsec better suited for quantum-safe links between your own data centres?

MACsec (IEEE 802.1AE) suits links where you control a Layer 2 path and need line-rate encryption. IPsec with RFC 9370 suits routed paths, the public internet and cloud. It also currently offers a standardised way to add ML-KEM to the key exchange.

The deciding difference is key agreement. MACsec relies on the MACsec Key Agreement protocol from IEEE 802.1X, which derives keys from a pre-shared or EAP-derived connectivity association key. No standardised ML-KEM exchange is defined for it, so any quantum resistance comes from symmetric pre-shared keys and 256-bit cipher suites. IPsec, by contrast, has RFC 9370 for hybrid exchanges, and NSA has published a base profile for IPsec for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite as an Internet-Draft.

Some operators combine the two: MACsec on owned fibre for line-rate protection, and a Layer 3 hybrid tunnel on top for the post-quantum key exchange. If you rely on MACsec alone, check first that your carrier service actually passes 802.1AE frames end to end.

How often should keys be rotated on long-running replication tunnels?

Session keys should rotate often, triggered by both time and data volume, and every rekey must include a fresh post-quantum exchange. Long-term authentication credentials follow a separate, slower cycle.

The most common mistake is rekeying without a new key exchange. In IKEv2, a Child SA rekey without perfect forward secrecy just derives new keys from the existing IKE SA. If that one secret is ever broken, every later key falls with it. RFC 9370 handles this explicitly: it also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. Check that your configuration actually negotiates the additional ML-KEM exchange on rekeys, not only at initial setup.

Short intervals limit how much data any one key exposes and are easy to run once automated. For example, the QPN gateway renews both its classical and its post-quantum handshake every two minutes. Whatever interval you choose, make sure rekeys are make-before-break so replication does not stall, and set alerts on rekey failures. A tunnel should stop passing traffic rather than fall back to a weaker state.

Where should OT and critical infrastructure operators start?

Start with an inventory of every replication and backup flow, ranked by how long its data must stay confidential. Then move the longest-lived flows to hybrid key exchange first.

Map each flow’s source, destination, transport (owned fibre, carrier circuit, internet, cloud) and current key exchange. Ask your teams for retention periods for historian data, backups and configuration archives, because those periods decide urgency. Pick solutions that support crypto agility, so the post-quantum algorithm can be swapped if cryptanalysis moves on. An NSA presentation at NIST put the reason to start now plainly: “We know from past experience that transitions take time, so we need to start planning now”. NIST’s position is just as direct: “With the release of the first three final PQC standards, organizations should begin migrating their systems to quantum-resistant cryptography.”