Post-quantum encryption low bandwidth links: will it work?

Post-quantum encryption on low bandwidth links means protecting traffic over cellular, satellite, radio or metered connections with key exchange that resists quantum computers, typically ML-KEM from FIPS 203 combined with a classical algorithm. The bulk data is still encrypted symmetrically, so the extra cost sits mostly in the handshake rather than in every packet.

For operators of substations, pumping stations, pipeline valves and wind parks, the question is practical. These sites often hang off a 4G router with a monthly data cap or a satellite terminal with high round-trip times. This article explains what changes on the wire when you add ML-KEM, how often that change happens, and how to keep remote tunnels running when the link is poor.

Does post-quantum key exchange work over slow cellular or satellite links?

Yes. ML-KEM handshakes complete over slow cellular and satellite links. The engineering problems are message size and fragmentation, not raw throughput or processing power.

NIST finalised ML-KEM in FIPS 203 in August 2024. The standard defines three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, ordered by increasing security strength and decreasing performance. Even the middle set has keys of just over a kilobyte. That is large next to classical elliptic-curve keys, but small next to a single firmware download or a historian backfill.

In practice, what fails on constrained links is the handshake packet, not the cryptography. A message carrying an ML-KEM public key plus headers can exceed the effective MTU of a cellular bearer or a satellite modem that adds its own encapsulation. When an intermediate device drops IP fragments, the handshake stalls and keeps retrying. The draft specification for ML-KEM in IKEv2 says this plainly: ML-KEM keys and ciphertexts may not fit common packet sizes, so the messages that carry them may be fragmented according to RFC 7383.

Why RFC 7383 matters for remote OT sites

RFC 7383 defines fragmentation inside IKEv2 itself, so large key-exchange messages no longer depend on IP fragmentation. Each fragment travels as a complete UDP datagram, which helps on networks where carrier-grade NAT or firewalls discard IP fragments. RFC 9242 adds that an initiator may first send a message unfragmented and resend it fragmented if it gets no response, and that peers may try different fragment sizes as a simple form of path MTU discovery. Whichever tunnel protocol you use, the lesson is the same: large post-quantum key material must be split at the application or tunnel layer, not left to the IP stack.

How much extra data does an ML-KEM handshake add compared with classical key exchange?

A hybrid X25519 plus ML-KEM-768 exchange carries about 2.3 KB of key-share data. A classical X25519 exchange carries 64 bytes. The difference, roughly 2.2 KB per handshake, is the core overhead.

The sizes below come from the published specifications. Real handshakes also carry nonces, identities, authentication data and transport headers, so treat these as the cryptographic payload rather than total bytes on the wire.

• Statistic: In the hybrid X25519 plus ML-KEM-768 construction, the client share is 1216 bytes and the server share is 1120 bytes (IETF draft-kwiatkowski-tls-ecdhe-mlkem-01, 2024).
• Statistic: X25519 public values are 32-byte strings (IETF RFC 7748, 2016).

To see what this means on a slow link, convert bytes to time. About 2,336 bytes is roughly 18,700 bits. On a 9.6 kbit/s radio channel that takes close to two seconds of serialisation. On a 64 kbit/s channel it takes about a third of a second. On ordinary 4G it is negligible. For the slowest legacy links, check that the handshake fits inside the tunnel’s own retransmission timers before you worry about anything else.

How does rekeying frequency affect bandwidth on metered remote OT links?

Rekeying cost grows linearly: handshake size multiplied by handshakes per period. Even aggressive rekeying with hybrid ML-KEM usually adds tens of megabytes per month at most, which is visible on a small data plan but rarely decisive.

The worked example below multiplies the hybrid key-share payload (2,336 bytes) by the number of rekeys. It is arithmetic based on the specification sizes above, not a measurement. Your real figure will be higher once headers and authentication are included, so verify it with interface counters on a test link.

Three practical points follow. First, short rekey intervals limit how much traffic any single session key protects, which is useful for long-lived OT tunnels that may stay up for months. Second, on metered links, keepalives and dead-peer detection often use more data than rekeying, because they run every few seconds. Third, if a data cap really is tight, it usually makes more sense to review SCADA polling design (for example, DNP3 report-by-exception instead of fixed-rate integrity polls) than to stretch key renewal.

As one reference point, Quantum Network’s QPN gateway uses hybrid key agreement that combines a classical part with ML-KEM into one session key, and renews both handshakes every two minutes. That puts it in the top row of the table. Use the numbers to budget data at sites on capped plans.

What latency does post-quantum encryption add to SCADA polling over remote links?

Post-quantum key exchange adds nothing to individual polls. ML-KEM runs only when keys are agreed, and each IEC 60870-5-104 or DNP3 (IEEE 1815) request and response is protected with symmetric encryption, as in a classical tunnel.

Latency on a remote SCADA link comes from three places, and only one of them is cryptographic:

• Propagation and bearer latency. Satellite and congested cellular links add hundreds of milliseconds per round trip. Encryption does not change this.
• Per-packet processing. The gateway encrypts each packet and checks its authentication tag. With symmetric ciphers on current x86 hardware this is small compared with WAN latency. For example, QPN states a typical latency overhead of about 1 ms, which varies with load and distance.
• Handshake bursts. During a rekey, a few kilobytes compete with polling traffic for a moment. On very narrow channels this can delay one poll cycle slightly.

The interaction that matters is between tunnel recovery and protocol timers. IEC 60870-5-104 runs over TCP and supervises the connection with its t1 (acknowledgement) and t3 (idle test frame) timers. If the tunnel needs longer to re-establish after a dropout than those timers allow, the master closes the TCP session and reports the outstation as lost, even though the cryptography worked. DNP3 masters have the same issue with application and link-layer confirm timeouts. Set the tunnel’s retry behaviour and the SCADA timers together, not separately.

Where IEC 62351 fits

IEC 62351 is the security series for power-system protocols, including IEC 60870-5-104 and DNP3. It protects at the protocol or session level, while a site-to-site tunnel protects everything above Layer 3 between two locations. Many installed RTUs cannot implement IEC 62351, so network-layer encryption between sites is often the realistic route to encrypting legacy telecontrol traffic. The two approaches can coexist.

How do you keep tunnels stable on unreliable connections to remote substations and pumping stations?

Stability comes from four things: handshakes that fit the path, automatic recovery that never falls back to plaintext, timers aligned with the SCADA protocol, and monitoring that tells link failures apart from crypto failures.

Design choices that hold up in the field

• Fix MTU and MSS deliberately. Set the tunnel MTU below the smallest bearer MTU and clamp TCP MSS for IEC 104 sessions, so data packets never fragment, as well as handshakes.
• Fail closed. A tunnel that drops to unencrypted traffic when the handshake fails defeats its own purpose. QPN, for example, never falls back to unencrypted traffic and retries automatically after a line failure, with no user action needed.
• Keep NAT mappings alive. Cellular carriers age out idle UDP mappings quickly. Keepalive intervals must be shorter than the carrier’s NAT timeout, and that has to be balanced against data caps.
• Avoid outbound-only blind spots. Sites behind carrier-grade NAT cannot accept inbound connections. Let the remote side start the tunnel, and make sure the control centre end can always be reached.
• Separate the alarms. Log handshake failures apart from link-down events. A run of handshake timeouts on one bearer type usually points to MTU or fragmentation, not to the algorithm.

Why start now rather than wait for better links?

Remote OT links are replaced slowly, and traffic recorded today could be decrypted later, so the standards bodies advise starting the migration now.

• Statistic: NIST released its first three finalized post-quantum standards, including FIPS 203, on 13 August 2024 (NIST, 2024-08-13).
• Statistic: Under the NIST IR 8547 timeline, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035 (NIST CSRC, 2024).

“We encourage system administrators to start integrating them into their systems immediately, because full integration will take time,” said Dustin Moody, the NIST mathematician who leads the PQC standardization project. NIST Director Laurie E. Locascio described the finalised standards as “the capstone of NIST’s efforts to safeguard our confidential electronic information.”

NIST has also picked HQC as a backup key-encapsulation algorithm, and Moody has said it is not meant to replace ML-KEM, which remains the recommended choice for general encryption. For remote OT links, that means two things. Build on ML-KEM today. Make sure the gateway or tunnel can switch algorithms later without new hardware at every substation, because a site visit to a remote pumping station costs far more than the bandwidth any handshake will ever use.