Patents Wiki
Back to briefings
PaperCryptography

The 9,521-Byte Handshake: What a New 6G Paper Reveals About Post-Quantum Cryptography

Imagine sending a letter whose envelope weighs five times as much as the letter itself. The words inside are the same, but postage, handling, and shelf space all balloon. That is roughly the situation 6G networks face as they begin adopting post-quantum cryptography, the discipline of designing encryption and authentication algorithms that remain secure even against large quantum computers. NIST has finally standardized such algorithms. Swapping them into real protocols, however, produces handshakes that are not just a little larger. They are dramatically larger. A new experimental paper from Toshiba Europe quantifies exactly how much larger, and where the pain lands.

The research, led by Ananya Kudaloor and Adnan Aijaz at Toshiba's Bristol Research and Innovation Laboratory, is not a theoretical advance in lattice geometry. It is a deployment reality check. The authors take NIST's finalized algorithms, ML-KEM and ML-DSA. They run them through standard TLS 1.3 handshakes on a high-end Intel Core i7 and on a constrained Raspberry Pi 4. Then they ask a systems-level question: can these primitives power a quantum-safe 6G network without choking its edge? Their answer is cautiously optimistic, but laced with specific warnings about bandwidth, latency, and standards that still need to be written.

For anyone tracking the long migration from classical to quantum-safe infrastructure, this paper matters because it moves the conversation from "is the math secure?" to "can the network afford it?" That shift is where standards either get adopted or get delayed for another decade.

The paper at a glance

  • Publication: arXiv:2605.06881 [cs.NI], submitted 7 May 2026; accepted for publication in IEEE Communications Standards Magazine.
  • Authors: Ananya Kudaloor and Adnan Aijaz, Bristol Research and Innovation Laboratory, Toshiba Europe Ltd.
  • Core question: How do NIST-standardized post-quantum cryptographic schemes perform when integrated into 6G-relevant TLS 1.3 workflows?
  • Algorithms tested: ML-KEM-512/768/1024, ML-DSA, Falcon, with classical baselines X25519, ED25519, ED448, and RSA.
  • Test platforms: Intel Core i7 workstation and Raspberry Pi 4, using OpenSSL 3.5.2 and the Open Quantum Safe provider.
  • Key headline: A hybrid PQC TLS 1.3 handshake can carry roughly 9,521 bytes of transport payload, about five times the 1,893 bytes of a classical X25519 + RSA handshake.

When Shor's algorithm turns RSA and ECC into glass

To understand why this research exists, start with the threat. Today, nearly every secure connection relies on one of two mathematical problems. Integer factorization protects RSA. The discrete logarithm problem on elliptic curves protects ECDSA, ECDH, and modern relatives such as X25519. These problems are hard for classical computers. They are not hard for a sufficiently large quantum computer running Shor's algorithm.

Shor's algorithm, published in 1994, factors integers and solves discrete logarithms in polynomial time on a quantum computer. A future fault-tolerant machine with millions of physical qubits and thousands of logical qubits could retrospectively decrypt traffic recorded today. That possibility created the "harvest now, decrypt later" scenario: an adversary can store encrypted data today and wait for the hardware to catch up. The urgency is real enough that NIST ran a multi-year competition to find replacements that quantum computers cannot easily break.

The winning replacements fall into different mathematical families. ML-KEM, formerly known as Kyber, is a key encapsulation mechanism, a protocol step that lets two parties agree on a shared secret key without ever sending the key itself across the network. ML-DSA, formerly Dilithium, is a digital signature scheme, a method for proving that a message genuinely came from a particular sender and was not altered in transit. Falcon is another signature scheme in the same family, with smaller signatures but more complex floating-point arithmetic. All three rely on problems related to finding short vectors in high-dimensional lattices, a task for which no efficient quantum algorithm is known.

The paper's problem framing is subtle but important. NIST's job was to prove the algorithms are cryptographically sound. It was not to prove they fit inside every protocol. A 6G network is a particularly unforgiving environment because it spans three very different worlds: high-performance cloud cores, latency-sensitive edge nodes, and resource-constrained IoT devices. What works in a data center may be painful at the edge, and what is merely annoying at the edge may be prohibitive on a battery-powered sensor.

Lattice keys are the new steel beams: strong, but heavier

The paper's central idea is to treat post-quantum security as a systems engineering problem, not just a mathematics problem. Kudaloor and Aijaz build a cross-layer evaluation pipeline that connects the raw cryptographic primitives to the protocol layer, and then to the transport layer where bytes actually move across a network.

Think of a TLS handshake as the opening negotiation of a secure conversation. When your phone or laptop connects to a server, the two sides agree on a cipher suite, authenticate each other with certificates and signatures, and establish session keys. The total number of bytes exchanged during that negotiation is the handshake size. In classical TLS, that negotiation is compact because RSA and elliptic-curve public keys are small: an X25519 public key is only 32 bytes, and an RSA-2048 public key is 256 bytes.

Post-quantum keys and signatures are larger because the underlying lattice structures need more information to be secure. Lattice-based cryptography hides secrets inside noisy grids of points in high-dimensional space. Recovering a secret means distinguishing a structured point from random noise. That problem is believed to resist both classical and quantum attacks. ML-KEM public keys and ciphertexts are measured in hundreds or thousands of bytes, not tens. ML-DSA signatures are measured in thousands of bytes. The result is that a single PQC handshake carries far more payload than its classical equivalent.

The paper focuses on three configurations: classical-only, PQC-only, and hybrid. A hybrid key exchange is a transitional design that performs both a classical key agreement and a post-quantum key agreement in the same handshake, then combines their outputs. If either mechanism is later broken, the other still protects the session. Hybrid is the mode most operators are expected to deploy first, but it is also the heaviest, because you pay the cost of both.

How the authors measured the bloat

The authors use a four-stage measurement workflow, shown in the diagram below, to connect algorithm-level performance to real protocol behavior.

Core Architecture/Flow

At the algorithm level, they run the Open Quantum Safe project's liboqs benchmarking utilities. speed_kem repeatedly performs key generation, encapsulation, and decapsulation for key encapsulation mechanisms, while speed_sig does the same for signing and verification. They also use openssl speed to measure the same operations through OpenSSL's native API, which gives a second independent view.

At the protocol level, they configure an OpenSSL 3.5.2 server with the OQS provider and run full TLS 1.3 handshakes without session resumption. They measure completed connections per second using openssl s_time. They measure end-to-end handshake rate using openssl s_client loops. Primitive benchmarks measure only the cryptographic math. TLS benchmarks add certificate parsing, message formatting, and round-trip behavior.

At the transport level, they capture packet traces and sum the tcp.len field for every data packet sent during handshake establishment. This gives the actual number of bytes on the wire, which is what matters for bandwidth planning and radio resource allocation.

To quantify algorithmic overhead, they define the ciphertext expansion rate (CER), a ratio that measures how many bits must be transmitted to deliver one bit of usable shared secret. For ML-KEM, the transmitted ciphertext bit length is:

Bct=k⋅n⋅du+n⋅dvB_{ct} = k \cdot n \cdot d_u + n \cdot d_v

In this formula, kk is a module-rank security parameter, nn is the polynomial dimension, and dud_u and dvd_v are compression parameters that control how many bits are used to represent each coefficient. The CER is then:

CER=BctKCER = \frac{B_{ct}}{K}

where KK is the number of encapsulated information bits. For ML-KEM-768 at its standard compression settings, the CER is 48, meaning it sends 48 bits of ciphertext for every 1 bit of key material. That is the lattice tax in its purest form.

What the numbers actually say

The results fall into three buckets: primitive speed, handshake throughput, and connection setup size.

On an Intel Core i7, ML-KEM key generation throughput is comparable to classical X25519. ML-KEM-512 and ML-KEM-768 keep up well; ML-KEM-1024 is slower because its polynomial dimensions and arithmetic grow with the security parameter. This is good news for data-center and core-network deployments, where modern CPUs have vector units and memory bandwidth to spare.

On a Raspberry Pi 4, the picture changes. Classical X25519 retains a clear throughput advantage over ML-KEM. The Pi has weaker vector support and a less aggressive compiler optimization path, so the same lattice arithmetic takes a bigger relative hit. The gap is not catastrophic, but it is a reminder that IoT-grade hardware cannot be assumed to handle PQC as gracefully as server hardware.

When the authors measure TLS 1.3 handshakes in connections per second, the ordering is consistent across platforms: classical signatures such as ED25519 and ED448 are fastest, PQC signatures such as ML-DSA and Falcon are slower, and hybrid key exchange is slowest. Falcon is especially slow in software because it relies on floating-point lattice sampling, which is harder to implement both efficiently and in constant time.

The handshake payload numbers are the paper's most concrete finding. In Table II, the authors report TCP payload bytes per handshake:

SchemeHandshake payload (bytes)
X25519 + RSA1,893
X25519 + ML-DSA-447,257
X25519+ML-KEM-768 + RSA4,157
X25519+ML-KEM-768 + ML-DSA-449,521
ML-KEM-768 + ML-DSA-449,457
ML-KEM-1024 + ML-DSA-4410,321

The jump from 1,893 bytes to 9,521 bytes is the difference between a brief greeting and a small file download every time a device connects. Network impairment magnifies the cost. Under artificial 50 ms delay introduced with Linux tc netem, Falcon-512 handshake throughput collapsed from 5,600 connections in the measurement window down to 34. A larger handshake means more bytes in flight. Each retransmission or delayed packet hurts more.

Energy also rises. The authors measured X25519 at 25.17 mJ per connection and X25519+ML-KEM-768 at 34.33 mJ per connection. That is a roughly 36% increase in energy per connection setup on the client side. For a phone, that may be acceptable. For a sensor that wakes once an hour to send a few bytes, it matters a great deal.

The 6G deployment map where bigger is not better

The impact of these findings depends entirely on where in the network you are standing.

In the core cloud, with long-lived sessions and abundant CPU, a 9,500-byte handshake is a manageable cost. Major operators such as Cloudflare, Google Cloud, and AWS have already shown that hybrid PQC TLS can run at Internet scale, and the paper's measurements confirm that core infrastructure can absorb the overhead.

At the edge, the equation changes. Edge nodes are expected to handle ultra-reliable low-latency communication, frequent mobility events, and re-authentication. A larger handshake means more radio time spent on setup rather than data, and every extra millisecond competes with the latency budgets that 6G promises.

For IoT and constrained devices, represented in the paper by the Raspberry Pi 4, the combination of larger payloads and slower processors is the tightest constraint. A low-power sensor on a narrowband link may find that a PQC handshake consumes a noticeable fraction of its daily energy budget and a noticeable fraction of its available bandwidth.

The paper also highlights standards work that is still unfinished. 3GPP must define how PQC is negotiated in cellular authentication and key agreement procedures. ETSI must produce migration frameworks and hybrid profiles. GSMA must translate those standards into operational guidelines for roaming and certificate management. NIST and IETF provide the cryptographic primitives, but telecom-specific integration is still a patchwork.

The gaps that could still slow the migration

Kudaloor and Aijaz are careful not to overclaim. They list five open challenges that remain after their evaluation. Their list spans standards, energy, interoperability, wireless reliability, and testbeds.

First, there are no 6G-specific deployment profiles that map PQC parameter sets to service classes. We do not yet have agreed bandwidth or latency thresholds that say, for example, "URLLC control-plane messages must stay below this many bytes."

Second, energy-aware evaluation is still limited. The paper gives one energy measurement for key exchange, but battery-powered edge and IoT devices need much broader characterization across sleep cycles, wake times, and multiple authentication events.

Third, interoperability is complex. Hybrid operation requires careful negotiation between classical, PQC, and eventually quantum-key-distribution mechanisms. A mistake in negotiation logic can leave connections insecure or simply broken.

Fourth, reliability under wireless conditions is not fully understood. The authors show that delay and loss devastate handshake throughput for larger signatures, but fading, retransmissions, and non-standard compression parameters need more study.

Fifth, there is a lack of mature 6G testbeds that span the full stack from cryptographic primitive to radio-layer signaling. Until those exist, cross-layer claims remain partial.

Sources

This briefing curates and summarizes publicly available research with original commentary. All facts are drawn from the selected paper and its cited sources as of June 15, 2026.