Post-Quantum Session Establishment for Matter over Thread: Message Size, Transport, and Protocol Options

Post-Quantum Session Establishment for Matter over Thread: Message Size, Transport, and Protocol Options Daniel Commey

arXiv:2610.13026v1 [cs.CR] 9 Oct 2026

TIDES Lab, Department of Computer Engineering and Computer Science California State University, Long Beach, Long Beach, CA 90840, USA daniel.commey@csulb.edu Abstract—Matter’s first post-quantum change protects device attestation with ML-DSA, but its operational handshake, CASE, still derives session keys from P-256 ECDH, so recorded traffic can be decrypted once a quantum computer exists. We quantify the cost of moving CASE to ML-KEM and post-quantum signatures over Thread, where frames carry at most 127 bytes and a Matter message at most 1178 bytes. A byte-exact model of the CASE messages shows that a drop-in ML-KEM-768/ML-DSA-44 handshake grows from 1.6 kB to 22.8 kB and that no fully postquantum configuration built from FIPS 203/204/205 algorithms fits the message limit. A Monte Carlo model of multi-hop Thread, calibrated to OpenThread and Matter source constants, shows that sending these messages as fragmented IPv6 datagrams causes spurious retransmissions whenever a message and its reply outlast Matter’s retransmission timer. At three to four hops the drop-in handshake then takes 1.8 to 2.6 times longer than with a selective-repeat block transfer, with or without interference, and up to 33% of handshakes with sleepy devices fail; raising the timers does not remove the effect. Caching certificate chains and authenticating the device with a pre-distributed ML-KEM key reduce the handshake to 6.1 kB and 44 ms of device computation. As a first step, hybrid P-256+ML-KEM-512 key exchange with a cached device chain protects session keys against harvest-now, decrypt-later attacks while every message still fits the current limit. Index Terms—Post-quantum cryptography, Matter, Thread, IEEE 802.15.4, ML-KEM, ML-DSA, authenticated key exchange, IoT.

I. I NTRODUCTION Matter [1] is the IP-based application standard for smarthome devices. Battery-powered Matter devices usually run over Thread, an IPv6 mesh on IEEE 802.15.4 radios with 127-byte frames and 250 kb/s. Matter devices authenticate each other with operational certificates, and every operational session starts with Certificate Authenticated Session Establishment (CASE), a SIGMA-I handshake [2] over ephemeral P256 ECDH with ECDSA-signed node operational certificates (NOCs). A cryptographically relevant quantum computer would break both primitives. For key exchange the threat is already present: an adversary who records CASE traffic today can recover the session keys later and decrypt everything sent under them [3]. Smart-home traffic includes door-lock commands, occupancy, and camera control, and devices stay in service for a decade or more, so the window is long. In September 2026

the Matter reference implementation merged its first postquantum change, PQC Phase 1 [4]. It adds ML-DSA to the device-attestation chain used during commissioning and carries the larger attestation certificates in 600-byte applicationlayer segments. CASE, the operational certificates, and the session keys are unchanged. Migrating CASE is harder than swapping primitives because of Thread. ML-KEM-768 public keys are 1184 B and MLDSA-44 signatures 2420 B [5], [6]. Matter caps a message at 1178 B so that it fits one 1280-byte IPv6 packet, and OpenThread disables IPv6 fragmentation by default [7]. A larger message needs a new transport mechanism, and on a multi-hop 802.15.4 mesh the choice of mechanism interacts with Matter’s retransmission timers. This paper quantifies those costs and evaluates protocol options. Our contributions are: A byte-exact size model of CASE for 15 representative configurations and 3780 design points, built on a Matter TLV codec that round-trips all 19 certificate test vectors of the reference implementation (§IV, §V). • The result that no fully post-quantum CASE built from FIPS 203/204/205 algorithms fits a Matter message, so migration requires a transport change, together with a configuration that gives harvest-now, decrypt-later protection without one (§V). • A Monte Carlo model of CASE over multi-hop Thread, with link, mesh, sleepy-device, and retransmission parameters taken from OpenThread and Matter source code, and the identification of a timer pathology that makes fragmented IPv6 transport 1.8 to 2.6 times slower than a block transfer at three or more hops (§VI). • Sensitivity analyses over interference burst length and occupancy, Matter retransmission timers, and segment size (§VII), and a discussion of the security of the proposed protocol changes (§IX). •

All results are from models and simulation. We have not yet measured them on hardware; §IX-C states what this implies for each result.

II. BACKGROUND

III. T HREAT M ODEL AND D ESIGN S PACE

A. CASE CASE has three messages and a status report. Sigma1 (initiator to responder) carries a 32-byte random, a session identifier, a destination identifier derived from the target’s fabric and node identity, the initiator’s ephemeral public key, and session parameters. Sigma2 returns the responder’s ephemeral key and an encrypted block containing the responder’s NOC, an optional intermediate CA certificate (ICAC), a signature over both ephemeral keys, and a resumption identifier. Sigma3 carries the initiator’s encrypted NOC, ICAC, and signature. The responder answers with a status report. Each party verifies the peer’s chain up to the fabric’s root CA certificate (RCAC), which both store. Matter encodes certificates in a compact TLV form; the reference test vectors have a 269-byte NOC and a 252-byte ICAC. In a typical deployment the initiator is a controller (a phone, hub, or border router) and the responder is the Thread device. Session resumption replaces Sigma2 and Sigma3 with a short Sigma2Resume authenticated by a key derived from the previous session.

We consider a passive adversary that records CASE exchanges now and later gains a quantum computer (harvestnow, decrypt-later), and an active quantum adversary in the future. The first requires a post-quantum key exchange in every CASE handshake performed today. The second requires postquantum signatures, or another post-quantum authentication mechanism, before such a computer exists. Authentication can therefore migrate later than key exchange, but certificates issued now remain valid for years. We vary five dimensions. Key exchange: P-256 (today), MLKEM-512 or ML-KEM-768 [5], or a hybrid that concatenates a P-256 share with an ML-KEM encapsulation key, as in hybrid TLS [11]. Signature per chain position: NOC, ICAC, and RCAC may each use ECDSA, ML-DSA-44 [6], Falcon-512, SLH-DSA-128s [12], or one of the second-round additional signatures MAYO, SNOVA, or UOV [13]. CA keys sign offline, so slow signing is acceptable there; the NOC key signs during every handshake. Chain structure: with or without an ICAC. Responder authentication: a signature as in SIGMA; a static ML-KEM key in the responder’s NOC, to which the initiator encapsulates in Sigma3 (KEM authentication, as in KEMTLS [14]); or, if the initiator already holds that key, encapsulation in Sigma1 and a key-confirmation MAC in Sigma2 (KEM-PDK, as in KEMTLS-PDK [15]). Cached chains: if a party already holds the peer’s NOC and ICAC, the peer sends an 8-byte reference instead [16]. In Matter this is common: the controller that commissioned a device issued its NOC. Table I lists the 15 configurations used throughout. The design-space study in §VIII enumerates all 3780 combinations of 3 key exchanges, 5 NOC signatures, 6 ICAC options, 7 RCAC signatures, and 6 authentication and caching modes.

B. Message size limit Over UDP, a Matter message payload may not exceed 1280 − 48 − 38 − 16 = 1178 B: the IPv6 minimum MTU minus uncompressed IPv6 and UDP headers, a reserve for Matter headers, and the message integrity code (kMaxAppMessageLen in [8]). Matter defines a TCP transport for large payloads, but Thread devices do not normally support it. C. Thread Thread carries IPv6 over 802.15.4 using 6LoWPAN header compression and fragmentation [9], [10]. With MAC security and short addresses, a 127-byte fragment frame carries 96 to 101 B of the IPv6 packet, so a 1232-byte UDP payload occupies 13 frames. Routers forward fragments hop by hop. OpenThread retransmits a unicast frame up to 15 times, discards a partially reassembled packet after 2 s, and, for sleepy end devices (SEDs), holds frames at the parent until the SED polls for them [7]. D. Matter reliable messaging The Message Reliability Protocol (MRP) acknowledges each reliable message, either piggybacked on the next application message or, if none is sent within 200 ms, as a standalone acknowledgement. A sender retransmits the whole message after Tn = I · 1.1 · 1.6max(0,n−1) (1 + 0.25 U ) + Tboost ,

(1)

where I is the active retry interval advertised by the receiver, n counts previous transmissions, and U ∼ U (0, 1). A message is sent at most five times. On OpenThread builds a device advertises I = 2000 ms and adds Tboost = 1500 ms to its own timers; a controller on Wi-Fi or Ethernet advertises I = 300 ms [8]. The timer starts when the message is handed to the transport.

IV. M ETHODOLOGY A. Message size model We implemented the Matter TLV encoding and decode the certificate test vectors of the reference implementation [8]; all 19 re-encode to identical bytes. Post-quantum certificates are built from the real NOC, ICAC, and RCAC templates by replacing the public key and signature fields and dropping the elliptic-curve identifier; all other fields, including extensions, are unchanged. A hybrid (composite) certificate carries its second key and signature under two new context tags. Matter has not specified post-quantum operational certificates, so these encodings are our assumption; they add only TLV length bytes beyond the raw key and signature sizes. The CASE messages follow the field layout of CASESession.cpp, including session parameters. Fields we introduce (KEM ciphertexts, certificate references, key-confirmation MACs) use new context tags. Algorithm sizes are from the standards and were checked against liboqs 0.16. B. Computation model Device computation counts the post-quantum operations on the responder: encapsulation and signing before Sigma2,

TABLE I C ONFIGURATIONS . C HAIN LISTS NOC/ICAC/RCAC SIGNATURE ALGORITHMS : E = ECDSA P-256, F = FALCON -512, M = ML-DSA-44, Y = MAYO-2, U = UOV-I S - PKC . C ACHED : PEER ALREADY HOLDS THE RESPONDER (R) OR BOTH (R+I) CHAINS . PAYLOAD SIZES IN BOLD EXCEED THE 1178- BYTE LIMIT; T OTAL INCLUDES THE STATUS REPORT. D EVICE PQ: POST- QUANTUM COMPUTATION ON THE RESPONDER AT 64 MH Z FROM PQM 4 CYCLE COUNTS ( CLASSICAL ECC EXCLUDED ). T IME : MEDIAN COMPLETION WITH BLOCK TRANSFER , 1 HOP WITHOUT INTERFERENCE AND 3 HOPS UNDER HEAVY W I -F I INTERFERENCE . Payload bytes ID

KEM

Chain

B P-256 E/E/E Drop-in replacements D1 P-256+K768 E/E/E D2 P-256+K768 F/F/F D3 K768 M/M/M D4 P-256+K768 E+M/E+M/E+M Structural changes S1 K768 M/–/M S2 K768 M/–/Y S3 K768 M/–/U S4 K768 M/M/M S5 K768 M/–/M Prior knowledge of peer credentials C1 P-256+K512 E/E/E C2 K768 M/M/M C3 K768 M/M/M C4 K768 M/–/M C5 K768 M/–/M

Auth.

Cached

sig

Device

Time [s]

Sigma1

Sigma2

Sigma3

Total

PQ [ms]

1 hop

3 hops

–

174

775

619

1,576

–

0.12

0.7

sig sig sig sig

– – – –

1,359 1,359 1,294 1,359

1,864 5,334 11,361 11,760

619 4,089 10,181 10,515

3,850 10,790 22,844 23,642

10 380 139 139

0.29 1.14 1.71 1.76

1.6 4.8 9.3 9.7

sig sig sig KEM KEM

– – – – –

1,294 1,294 1,294 1,294 1,294

7,503 5,268 5,178 8,809 4,951

6,323 4,088 3,998 11,273 7,415

15,128 10,658 10,478 21,403 13,687

116 188 94 88 66

1.17 0.94 0.83 1.56 1.02

6.3 4.6 4.4 8.7 5.7

sig sig sig KEM-PDK KEM-PDK

R R R+I – R+I

975 1,294 1,294 2,386 2,386

1,026 3,639 3,639 1,222 1,222

619 10,181 2,459 6,323 2,459

2,628 15,122 7,400 9,939 6,075

6 139 94 66 44

0.19 1.19 0.63 0.77 0.49

1.0 6.2 3.1 4.1 2.6

decapsulation and verification after Sigma3. We use the fastest Cortex-M4 cycle counts in pqm4 [17] (measured at 24 MHz with zero wait states) and scale to 64 MHz, the clock of the nRF52840. We exclude classical ECC from all configurations, because its cost depends on the hardware accelerator, so the classical baseline is slightly optimistic. The controller is assigned 5 ms per message. C. Transport simulation The simulator follows each 802.15.4 frame on each hop. Per frame it models the unslotted CSMA-CA initial backoff, airtime at 32 µs per byte including the synchronization header, turnaround, the immediate acknowledgement or acknowledgement wait, and up to 15 retransmissions with OpenThread’s retransmission backoff. Frames carry 6LoWPAN fragmentation and, beyond one hop, a mesh header; a datagram is lost if any fragment exhausts its retries or reassembly exceeds 2 s. For SEDs the parent delivers each frame after a data poll; a frame-pending bit lets the device poll again immediately for consecutive frames, and each frame has four indirect attempts. Hops are traversed store-and-forward on a single shared channel without spatial reuse. This lengthens multi-hop transfers relative to a pipelined mesh and therefore favors the timer effect in §VI; we return to this point there. MRP is modeled with Eq. (1), five transmissions, piggybacked and standalone acknowledgements, and duplicate transmissions that occupy the channel. Table II lists the parameters and their sources. Channel loss follows a time-based Gilbert–Elliott model [18], [19]: the channel alternates between a good state with loss probability pg and a bad state with loss probability 0.9, with exponentially distributed durations. This reproduces the bursty loss that 802.15.4 links experience under Wi-Fi

TABLE II M ODEL PARAMETERS . S OURCE : CONNECTEDHOMEIP @8982 F 4 D (CHIP), O PEN T HREAD @75 BF 129 (OT). Parameter

Source

Max. Matter payload (kMaxAppMessageLen) IPv6 MTU, IPv6 fragmentation MAC header + security + FCS Direct frame retransmissions Indirect (SED) attempts per frame 6LoWPAN reassembly timeout MRP active interval, device / controller MRP sender boost, Thread device MRP standalone-ACK timeout MRP transmissions SED poll interval during CASE Device clock / controller per message

CHIP 1178 B OT 1280 B, off 802.15.4 21 B OT 15 OT 4 OT 2s CHIP 2000 / 300 ms CHIP 1500 ms CHIP 200 ms CHIP 5 assumed 200 ms assumed 64 MHz / 5 ms

Value

interference [20], [21]. We use four scenarios: no interference; light Wi-Fi (pg = 1%, 10% of time in 10-ms bursts); heavy Wi-Fi (pg = 2%, 30% in 30-ms bursts); and an i.i.d. lossy link (pg = 15%). These values are illustrative rather than measured, and §VII varies them. Transports. Messages that fit are sent as one datagram. For larger messages we compare three mechanisms. IPv6 fragmentation sends the message as ⌈s/1232⌉ IPv6 datagrams; this requires enabling IPv6 fragmentation, and a lost datagram loses the message, which MRP then resends in full. Pull segmentation follows PQC Phase 1: the receiver requests each segment, and each request–segment pair is an MRP exchange. Block transfer is our proposal, similar in spirit to CoAP’s QBlock option [22]: the sender transmits all segments back to back, the receiver returns a bitmap of received segments, and the sender resends only the missing ones. If the bitmap is

1178 B limit

total kB

B

1.6

D1

3.9

D2

10.8

D3

22.8

D4

23.6

S1

15.1

S2

10.7

S3

10.5

S4

21.4

S5

13.7

C1

2.6

C2

15.1

C3 C4 C5

7.4

Sigma1 Sigma2 Sigma3 200

9.9 6.1 500

1000

2000

5000

10000

Message payload [bytes] Fig. 1. Payload of each Sigma message per configuration (Table I), log scale. Messages right of the dashed line exceed Matter’s 1178-byte limit; numbers on the right give the handshake total.

lost, the sender retransmits unconfirmed segments after the MRP timer. Segments carry 1024 payload bytes and a 12-byte header unless stated otherwise. Metrics. Handshake time runs from the controller sending Sigma1 until the status report reaches the controller, when both parties hold the session; it excludes the 200-ms wait before the final standalone acknowledgement. We also record failures (any message exhausting MRP), retransmissions, and the device’s radio transmit and receive time. Each scenario is run 300 times with independent seeds; we report medians with percentile-bootstrap 95% confidence intervals and the 90th percentile. The full grid has 15 configurations, 1 to 4 hops, 4 interference scenarios, always-on and sleepy devices, and 3 transports, for 432,000 handshakes. Piggybacked acknowledgements. The arrival time of a piggybacked acknowledgement is estimated as the loss-free delivery time of the first unit (whole message, or first segment) of the reply. Under loss the real arrival is later, so this approximation underestimates spurious retransmissions, which works against our finding in §VI. V. M ESSAGE S IZES Fig. 1 and Table I give the message sizes. Today’s handshake (B) is 1576 B in 20 frames at one hop, and its largest message, Sigma2, is 775 B. Adding ML-KEM-768 to the key exchange (D1) already breaks the limit twice: the hybrid share makes Sigma1 1359 B, and the ciphertext makes Sigma2 1864 B. A drop-in post-quantum handshake with ML-KEM-768 and an all-ML-DSA-44 chain (D3) is 22.8 kB in 244 frames, 14

times the classical size. Composite hybrid certificates (D4) add another 0.8 kB. Structural changes help but do not reach the limit. Removing the ICAC (S1) saves 7.7 kB. A short-signature root (MAYO-2, S2, or UOV, S3) shrinks each NOC because the NOC carries the issuer’s signature, but places a 4.9 kB or 66 kB root key in device storage. KEM authentication replaces the responder’s 2420-byte signature with a 1088-byte ciphertext (S4, S5) but moves the ciphertext into Sigma3. Prior knowledge of credentials has the largest effect. Caching both chains (C3) removes 15.4 kB from D3. With the device’s ML-KEM key pre-distributed and both chains cached (C5), the handshake is 6.1 kB, and the device performs one encapsulation, one decapsulation, and one MLDSA verification: 44 ms instead of 139 ms. Its largest message, Sigma3 at 2459 B, is dominated by the controller’s ML-DSA44 signature. No fully post-quantum configuration fits. Across all 3780 design points, the smallest largest message using only FIPS 203/204/205 algorithms is 2459 B (ML-KEM with KEMPDK and both chains cached). Allowing Falcon-512, whose standard (FIPS 206) is not final, lowers it to 1565 B. The only points where every message fits use ML-KEM-512, both chains cached, and a MAYO or SNOVA NOC key, schemes still under evaluation. A post-quantum handshake therefore needs a way to carry messages above 1178 B. Key exchange alone can fit. The harvest-now, decrypt-later threat only requires a post-quantum key exchange. A hybrid P-256+ML-KEM-512 share with classical certificates and a cached responder chain (C1) yields messages of 975, 1026, and 619 B, all within the limit, for a 2.6 kB handshake. MLKEM-512 targets NIST security category 1, comparable to the 128-bit classical security of P-256, and the hybrid keeps P-256. C1 needs only a certificate-reference field in Sigma2 and the hybrid share; it does not need a new transport. Some national guidance recommends ML-KEM-768 or stronger for general use. With ML-KEM-768 the cached-chain Sigma2 is 1346 B and does not fit, so a deployment that follows that guidance needs the transport changes of §VI even for key exchange alone. Resumption. The reference implementation requires the ephemeral key in every Sigma1, including resumption attempts. With an ML-KEM-768 share this makes a resumption Sigma1 1332 B, above the limit. The share is used only if resumption fails and the responder falls back to a full Sigma2 (CASESession.cpp returns before reading it when resumption succeeds). Making it optional reduces a postquantum resumption to 226 B in total, below today’s 294 B, at the cost of an extra round trip when resumption fails. VI. T RANSPORT FOR L ARGE M ESSAGES Fig. 2 compares the three transports. At one hop, IPv6 fragmentation is the fastest: for D3 it completes in a median 1.58 s without interference, against 1.71 s for block transfer and 1.82 s for pull segmentation, because it sends no segment headers or bitmaps. From two hops on it is the slowest.

Classical (B)

IPv6 fragmentation

Pull segmentation

(b) C5: KEM auth., chains cached

(c) D3 with IPv6 fragmentation Spurious retransmissions

Handshake time [s]

(a) D3: drop-in ML-KEM + ML-DSA

Block transfer

10

1

0.1

No interference Light Wi-Fi Heavy Wi-Fi 15% i.i.d. loss

4 3 2 1 0

1

2

3

4

1

2

Thread hops

3

Thread hops

4

1

2

3

4

Thread hops

Fig. 2. Handshake time under heavy Wi-Fi interference for (a) the drop-in configuration D3 and (b) the smallest post-quantum configuration C5, by transport. Markers show medians (95% bootstrap confidence intervals are smaller than the markers); vertical bars extend to the 90th percentile. (c) Mean spurious retransmissions per D3 handshake with IPv6 fragmentation, by interference scenario. Always-on device, 300 runs per point.

MRP timer T0

ACK received

Device Sigma2 Sigma3 + ACK Controller Sigma2 resent Fig. 3. Spurious retransmission with IPv6 fragmentation. The device’s MRP timer for Sigma2 starts when Sigma2 is handed to the network and expires before the acknowledgement, piggybacked on the fully reassembled Sigma3, arrives. The device resends all of Sigma2, which competes for the channel with Sigma3.

At three hops without interference D3 takes 8.8 s with IPv6 fragmentation and 4.9 s with block transfer; at four hops under heavy interference, 32.3 s and 13.1 s. The cause is the interaction shown in Fig. 3. The device sends Sigma2 and starts a timer of T0 = 300 · 1.1 · (1 + 0.25U ) + 1500 ≈ 1.83–1.91 s. The acknowledgement rides on Sigma3, and with IPv6 fragmentation the controller’s stack delivers Sigma3, and with it the acknowledgement, only after the last fragment arrives. A spurious retransmission occurs when Ttx (Sigma2) + tctrl + Ttx (Sigma3) > T0 .

(2)

Loss-free, Sigma2 and Sigma3 of D3 need about 0.71 s and 0.64 s per hop on a mesh path, so the condition holds from two hops on even without loss. The retransmitted 11-kB Sigma2 then delays Sigma3 further, and the next timer, 1.6 times longer, can expire again. Fig. 2c shows 1.0 spurious retransmissions per handshake at two hops and 3.8 at four hops without interference, nearly the MRP maximum of four. Interference adds losses, but the retransmissions themselves are caused by timing. The same holds in the other direction: Sigma3 travels with the controller’s timer of at least 2.2 s, which it can also exceed at four hops.

With pull segmentation and block transfer the acknowledgement for Sigma2 is piggybacked on the first segment of Sigma3, so no message waits for a large reply. Across the 416 scenarios where a segmented transport is used, pull segmentation has a median handshake time 5.9% longer than block transfer (range −4.5% to +37%); it was faster in 9 scenarios. The largest differences occur with SEDs, where every segment request waits for a poll. For the smallest configuration C5 the largest message is 2.4 kB, the timer condition never holds, and IPv6 fragmentation is 7 to 9% faster than block transfer at all hop counts (Fig. 2b). Spurious retransmissions are thus specific to large handshakes. Sleepy devices. SEDs receive each frame only after polling. With a 200-ms poll interval and heavy interference, IPv6 fragmentation lost handshakes in 28 of the 52 sleepy-device scenarios with oversized messages, up to 33% of them (S4 at four hops) and 24% for D3. All of these failures occurred in Sigma3, the large message toward the device: each 1232byte datagram needs 13 consecutive indirect frames, and four failed attempts on any of them discard the whole message. (Two always-on scenarios at four hops also lost one handshake each.) Over the oversized configurations, block transfer completed all 124,800 handshakes it was used for, and pull segmentation all but one. Radio time. At one hop without interference the device’s radio transmits or receives for 85 ms in a classical handshake, 1.15 s for D3, 318 ms for C5, and 133 ms for C1. For sleepy devices, whose radio is otherwise off, handshake energy scales roughly with this time, so caching and KEM authentication reduce it in proportion to the handshake size. Always-on Thread routers keep their receiver on regardless, so for them the saving is smaller. VII. S ENSITIVITY Interference model. Fig. 4a varies the fraction of time in a bad state from 5% to 40% and the mean burst length from 5

(b) Pull segmentation / block, 3 hops

(c) MRP interval / Thread boost

40

2.50

2.49

2.43

2.65*

2.07*

1.05

1.05

1.16

1.56

1.97*

30

2.52

2.50

2.44

2.82*

2.43*

1.05

1.05

1.05

1.48

1.95*

20

2.40

2.52

2.52

2.45*

2.66*

1.05

1.05

1.09

1.31

1.66

10

2.22

2.23

2.24

2.42

2.48

1.06

1.06

1.06

1.12

1.37

5

2.23

2.22

2.21

2.17

2.21

1.05

1.06

1.05

1.05

1.09

5

10

30

60

100

5

10

30

60

100

Mean burst length [ms]

3.5

Median time ratio to block

Time in interference burst [%]

(a) IPv6 fragmentation / block, 3 hops

300 ms / 1.5 s (default) 300 ms / none 2 s / 1.5 s 2s/3s

3.0 2.5 2.0 1.5 1.0 0.5 1

Mean burst length [ms]

2

3

4

Thread hops

Fig. 4. Sensitivity of the transport comparison for D3. (a, b) Ratio of median handshake time to block transfer at three hops as a function of interference occupancy and mean burst length; an asterisk marks success below 99.5%. (c) Ratio of IPv6 fragmentation to block transfer under heavy interference for combinations of the controller’s advertised active interval and the Thread device’s sender boost. 200 runs per cell.

VIII. D ESIGN -S PACE T RADE - OFFS Fig. 6 plots handshake size against device computation. With FIPS 203/204/205 algorithms only, a single configuration is Pareto-optimal: C5 with ML-KEM-512 (5.4 kB, 39 ms). With Falcon-512 two more appear: a KEM-PDK variant in which the controller’s NOC carries a Falcon-512 key (3.6 kB, 23 ms) and a signature-based one with Falcon NOCs (3.2 kB, 363 ms). In the first, only the controller signs, so the device merely verifies Falcon signatures. In the second the device signs with Falcon, which needs double-precision floating point that the Cortex-M4F lacks and must emulate; it trades 0.4 kB for about 340 ms of device computation and depends on FIPS 206, which is not yet final. Most points with MAYO, SNOVA, or UOV are dominated: they shorten signatures but

1.5

Time relative to 1150 B

to 100 ms at three hops. IPv6 fragmentation is 2.1 to 2.8 times slower than block transfer in all 25 settings, and with bursts of 60 ms or more it also loses up to 98% of handshakes. Pull segmentation (Fig. 4b) stays within 16% of block transfer for bursts up to 30 ms but becomes 1.3 to 2.0 times slower when bursts of 60 to 100 ms occupy 20% or more of the time. A long burst destroys several consecutive segments; block transfer reports all of them in one bitmap, while pull segmentation recovers each with a separate MRP timeout of at least 2.2 s. Retransmission timers. An implementer could raise the timers to avoid spurious retransmissions. Fig. 4c varies the controller’s advertised interval (300 ms to 2 s) and the device’s boost (none to 3 s). A 2-s interval with a 3-s boost removes the effect at two hops, but at three and four hops IPv6 fragmentation remains 2.0 to 2.5 times slower than block transfer for all nine settings we tested. Longer timers also delay recovery from real losses. Segment size. PQC Phase 1 allows segments down to 600 B. Fig. 5 shows that segment size matters more than the choice between pull and block. Relative to 1150-byte segments, 300byte segments are 27 to 41% slower and 600-byte segments 3 to 12% slower, because every segment adds a request, an MRP exchange, and a partially filled final frame. Segments should be as large as the 1178-byte limit allows.

D3, 3 hops, heavy Wi-Fi D3, 1 hop, no interference C5, 3 hops, heavy Wi-Fi C5, 1 hop, no interference

1.4 1.3 1.2 1.1 1.0

Phase 1 minimum

300

450

600

800

1024

1150

Segment size [bytes] Fig. 5. Median handshake time with pull segmentation, relative to 1150-byte segments, as a function of segment size. 200 runs per point.

cost seconds of signing or verification on the device, or very large public keys. IX. D ISCUSSION A. Security of the protocol options We give an informal analysis; a formal treatment is future work. Hybrid key exchange. Concatenating P-256 and ML-KEM shares and deriving the session key from both secrets keeps the session secure if either problem remains hard [11]. C1 keeps classical authentication, so it protects against recording now and decrypting later, but not against an active quantum adversary. KEM authentication. In S4 and S5 the responder proves possession of its static KEM key by decapsulating the initiator’s ciphertext and confirming the derived key, as in KEMTLS [14]. The ephemeral ML-KEM exchange still provides forward secrecy. Responder authentication becomes implicit and is confirmed one message later, and this weakens identity protection. SIGMA-I reveals the initiator’s identity only after the responder has authenticated. In S4 and S5, Sigma2 carries no signature, so an active attacker can relay the device’s public certificate, complete the ephemeral exchange itself, and

25

number of segments in flight should be bounded by a window so that senders and routers with small buffer pools are not overrun. (3) Specify post-quantum NOCs together with chain references and KEM-PDK device authentication, which keeps a fully post-quantum handshake near 6 kB and the device’s computation below 50 ms. (4) Make the ephemeral share in resumption Sigma1 optional.

20

C. Limitations

15

All results come from models. The message sizes are exact for the stated encodings, but post-quantum certificate formats are not yet specified. The latency results depend on the simulator: it serializes transmissions on one channel, ignores spatial reuse and other traffic, and estimates piggybacked acknowledgement times without loss. Ignoring spatial reuse overstates multi-hop transfer times, which favors the timer effect at three or more hops; at two hops, where neighboring links interfere and pipelining gains little, the effect already appears without loss. The simulator also does not model memory. OpenThread’s default build has 44 message buffers of 128 B, about 5.6 kB, which cannot hold a 10-kB Sigma message at once. Larger pools are a build option, but IPv6 fragmentation and an unwindowed block transfer both need the whole message buffered, whereas pull segmentation needs one segment, so default buffer sizes may favor pull segmentation. We have not evaluated Matter’s TCP transport: Thread devices rarely implement it, and it adds a connection setup and perconnection state before CASE begins, but TCP over Thread can perform well [23] and is a natural baseline for future work. Absolute times should therefore be read as estimates; the ratios between transports and their sensitivity to parameters are the more robust results, since they hold across all settings in §VII. Device computation uses Cortex-M4 cycle counts and excludes classical ECC; other cores (for example RISC-V) and hardware accelerators will differ. The interference scenarios are illustrative. Validating frame counts, latency, and energy on nRF52840 and ESP32-H2 devices with a sniffer and power analyzer is our next step.

Uses MAYO, SNOVA or UOV Adds Falcon-512

FIPS 203/204/205 only

Handshake bytes [kB]

35 30

10 5 0

b

a

c 100

1000

Responder PQ computation [ms at 64 MHz] Fig. 6. Total handshake bytes against post-quantum computation on the device for 3780 design points. Black outlines mark the Pareto-optimal points: (a) C5 with ML-KEM-512, the only one using FIPS 203/204/205 algorithms alone (5.4 kB, 39 ms); with Falcon-512 allowed, (b) KEM-PDK with a Falcon512 key in the controller’s NOC and both chains cached (3.6 kB, 23 ms) and (c) signature-based with Falcon-512 NOCs and both chains cached (3.2 kB, 363 ms). Points with identical size and computation overlap.

decrypt Sigma3, which contains the controller’s certificate. The attacker cannot complete the handshake, but it learns who the initiator is. With KEM-PDK (C4, C5) the initiator encapsulates to the responder’s known key in Sigma1, so only the intended responder can complete Sigma2, and the initiator verifies Sigma2’s key confirmation before sending its own certificate in Sigma3, which preserves SIGMA-I’s identity protection. The initiator must obtain the responder’s key authentically, which in Matter is natural because the controller issued the device’s NOC. We therefore recommend KEM-PDK rather than plain KEM authentication. Certificate references. A reference is sent inside the encrypted part of Sigma2 or Sigma3, so it reveals no more about identity than the certificate it replaces. If the receiver lacks the referenced chain, the handshake must fall back to sending it, which costs a round trip but no security. Resumption without a KEM share. The resumption keys derive from the previous session’s shared secret and fresh randoms, so omitting the share does not change the security of a successful resumption. As today, resumption does not add forward secrecy beyond the original session. B. Recommendations Our results suggest a staged migration. (1) Deploy hybrid P-256+ML-KEM-512 with a certificate reference for the device chain (C1): it closes the harvest-now, decrypt-later gap without a new transport and costs 70 ms at one hop. Where policy requires ML-KEM-768, this step needs the transport of step (2). (2) Specify a block transfer for secure-channel messages instead of relying on IPv6 fragmentation, and reuse it for the attestation certificates of PQC Phase 1. Segments should be as large as the message limit allows, and the

X. R ELATED W ORK Post-quantum Matter. PQC Phase 1 [4] is, to our knowledge, the only post-quantum work in Matter, and it covers device attestation only. Measurement studies of Matter over Thread, such as [24], address application performance rather than security handshakes. Constrained key exchange. EDHOC [25] is the IETF’s lightweight authenticated key exchange for constrained devices. Post-quantum cipher suites for it [26] and a KEM-based authentication method [27] have been proposed; neither studies the transport of large messages over an 802.15.4 mesh. Our results on message size and transport apply to them as well. Post-quantum TLS. KEMTLS [14] and KEMTLS-PDK [15] replace handshake signatures with KEM operations, and we adapt both to CASE. Sikeridis et al. [28] and Paquin et al. [29] measured how post-quantum signatures and key exchange affect TLS latency under packet loss and found that larger

handshakes suffer disproportionately on lossy links, consistent with our results. Bürstinghaus-Steinbach et al. [30] integrated Kyber and SPHINCS+ into mbed TLS on embedded platforms. Certificate caching [16] and compression [31] reduce TLS handshake size. Our earlier benchmark [32] measured postquantum primitives on consumer-electronics platforms. Large transfers on low-power networks. CoAP block-wise transfer [33] and its Q-Block extension [22] move large payloads over lossy constrained networks, the latter with selective retransmission similar to our block transfer. TCPlp [23] showed that TCP can perform well over Thread. XI. C ONCLUSION The main cost of moving Matter’s CASE handshake to post-quantum cryptography is communication on Thread; device computation is secondary. A drop-in ML-KEM/ML-DSA handshake is 14 times larger than today’s, and no fully postquantum configuration using FIPS 203/204/205 algorithms fits Matter’s 1178-byte message. Simply allowing fragmented IPv6 datagrams is not an adequate fix on multi-hop networks: large messages and their replies outlast Matter’s retransmission timers, causing spurious retransmissions that make the handshake up to 2.6 times slower, and sleepy devices fail up to a third of handshakes. A block transfer avoids both effects. Caching chains and authenticating the device with a predistributed ML-KEM key reduce a post-quantum handshake to 6.1 kB, and a hybrid ML-KEM-512 key exchange with a cached device chain protects against recorded traffic today without changing the transport. Hardware measurements will test the latency estimates and quantify energy. A RTIFACT AVAILABILITY The TLV codec, size model, simulator, and the scripts that produce every table and figure in this paper will be released as open source. R EFERENCES [1] Connectivity Standards Alliance, Matter Specification, Version 1.4, Connectivity Standards Alliance, 2024. [2] H. Krawczyk, “SIGMA: The ‘SIGn-and-MAc’ approach to authenticated Diffie-Hellman and its use in the IKE protocols,” in Advances in Cryptology – CRYPTO 2003, ser. LNCS, vol. 2729. Springer, 2003, pp. 400–425. [3] M. Mosca, “Cybersecurity in an era with quantum computers: Will we be ready?” IEEE Security & Privacy, vol. 16, no. 5, pp. 38–41, 2018. [4] Project CHIP Authors, “PQC phase 1: Crypto, commissionee and commissioner support,” connectedhomeip pull requests 73853, 73854, 73855, https://github.com/project-chip/connectedhomeip/pull/ 73853, 2026, merged Sept. 2026. [5] National Institute of Standards and Technology, “Module-lattice-based key-encapsulation mechanism standard,” NIST, FIPS 203, 2024. [6] ——, “Module-lattice-based digital signature standard,” NIST, FIPS 204, 2024. [7] OpenThread Authors, “OpenThread: An open-source implementation of Thread,” https://github.com/openthread/openthread, 2026, commit 75bf129, Sept. 2026. [8] Project CHIP Authors, “connectedhomeip: Matter reference implementation,” https://github.com/project-chip/connectedhomeip, 2026, commit 8982f4d, Sept. 2026. [9] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, “Transmission of IPv6 packets over IEEE 802.15.4 networks,” RFC 4944, 2007. [10] J. Hui and P. Thubert, “Compression format for IPv6 datagrams over IEEE 802.15.4-based networks,” RFC 6282, 2011.

[11] D. Stebila, S. Fluhrer, and S. Gueron, “Hybrid key exchange in TLS 1.3,” IETF Internet-Draft draft-ietf-tls-hybrid-design, 2025. [12] National Institute of Standards and Technology, “Stateless hash-based digital signature standard,” NIST, FIPS 205, 2024. [13] ——, “Post-quantum cryptography: Additional digital signature schemes,” https://csrc.nist.gov/projects/pqc-dig-sig, 2024. [14] P. Schwabe, D. Stebila, and T. Wiggers, “Post-quantum TLS without handshake signatures,” in Proc. ACM Conf. Computer and Communications Security (CCS), 2020, pp. 1461–1480. [15] ——, “More efficient post-quantum KEMTLS with pre-distributed public keys,” in Computer Security – ESORICS 2021, ser. LNCS. Springer, 2021. [16] S. Santesson and H. Tschofenig, “Transport layer security (TLS) cached information extension,” RFC 7924, 2016. [17] M. J. Kannwischer, J. Rijneveld, P. Schwabe, and K. Stoffelen, “pqm4: Testing and benchmarking NIST PQC on ARM Cortex-M4,” in Second PQC Standardization Conference, 2019, benchmarks from https://github. com/mupq/pqm4, commit 5e5cc76, Sept. 2026. [18] E. N. Gilbert, “Capacity of a burst-noise channel,” Bell System Technical Journal, vol. 39, no. 5, pp. 1253–1265, 1960. [19] E. O. Elliott, “Estimates of error rates for codes on burst-noise channels,” Bell System Technical Journal, vol. 42, no. 5, pp. 1977–1997, 1963. [20] C.-J. M. Liang, N. B. Priyantha, J. Liu, and A. Terzis, “Surviving WiFi interference in low power ZigBee networks,” in Proc. ACM Conf. Embedded Networked Sensor Systems (SenSys), 2010. [21] K. Srinivasan, M. A. Kazandjieva, S. Agarwal, and P. Levis, “The β-factor: Measuring wireless link burstiness,” in Proc. ACM Conf. Embedded Networked Sensor Systems (SenSys), 2008. [22] M. Boucadair and J. Shallow, “Constrained application protocol (CoAP) block-wise transfer options supporting robust transmission,” RFC 9177, 2022. [23] S. Kumar, M. P. Andersen, H.-S. Kim, and D. E. Culler, “Performant TCP for low-power wireless networks,” in Proc. USENIX Symp. Networked Systems Design and Implementation (NSDI), 2020. [24] M. Nobile, F. Palmese, A. Boiano, A. E. C. Redondi, and M. Cesana, “Zigbee vs. Matter over Thread: Understanding IoT protocol performance in practice,” arXiv:2603.04221, 2026. [25] G. Selander, J. Preuß Mattsson, and F. Palombini, “Ephemeral DiffieHellman over COSE (EDHOC),” RFC 9528, 2024. [26] G. Selander, J. Preuß Mattsson, and C. Papon, “Quantum-resistant cipher suites for LAKE,” IETF Internet-Draft draft-ietf-lake-pqsuites-01, Sep. 2026. [27] L. Pocero Fraile, C. Koulamas, A. P. Fournaris, and E. Haleplidis, “KEM-based authentication for EDHOC,” IETF Internet-Draft draftlake-pocero-authkem-edhoc-00, Oct. 2025. [28] D. Sikeridis, P. Kampanakis, and M. Devetsikiotis, “Post-quantum authentication in TLS 1.3: A performance study,” in Proc. Network and Distributed System Security Symp. (NDSS), 2020. [29] C. Paquin, D. Stebila, and G. Tamvada, “Benchmarking post-quantum cryptography in TLS,” in Post-Quantum Cryptography (PQCrypto 2020), ser. LNCS. Springer, 2020. [30] K. Bürstinghaus-Steinbach, C. Krauß, R. Niederhagen, and M. Schneider, “Post-quantum TLS on embedded systems: Integrating and evaluating Kyber and SPHINCS+ with mbed TLS,” in Proc. ACM Asia Conf. Computer and Communications Security (ASIACCS), 2020, pp. 841–852. [31] A. Ghedini and V. Vasiliev, “TLS certificate compression,” RFC 8879, 2020. [32] D. Commey, B. Appiah, G. S. Klogo, W. Bagyl-Bac, J. D. Gadze, Y. Alsenani, and G. V. Crosby, “Performance analysis and deployment considerations of post-quantum cryptography for consumer electronics,” arXiv:2505.02239, 2025. [33] C. Bormann and Z. Shelby, “Block-wise transfers in the constrained application protocol (CoAP),” RFC 7959, 2016.

Related documents

• Post-Quantum Session Establishment for Matter over Thread: Message Size, Transport, and Protocol Options#1297378
• Quantum Workload Privacy Beyond Data Confidentiality#924218
• Quantum Workload Privacy Beyond Data Confidentiality#919987
• Secure Quantum Metasurfaces for Direct Quantum Key Distribution Measurements#1037629
• Leakage benchmarking with decohering subgroups in the presence of preparation and measurement errors#1345127