PaperlayerView exact revision on arXiv

Source-linked AI summary

System-Level Optimization Beyond Cryptographic Kernels: An ML-KEM Case Study on Arm Cortex-M7

Mahmoud Abdelhafeez Sayed, Mostafa Taha, Gurp Nijjer

arXiv:2610.01960v1cs.CR

TL;DR

Embedded ML-KEM performance can remain limited by system behavior and work repeated across API calls after kernel optimization. The paper evaluates system-level choices around an optimized Cortex-M7 implementation across all three parameter sets. Profiles without auxiliary public state reduce cycles by up to approximately 2.5%, while public-data reuse yields larger encapsulation and decapsulation cycle reductions.

  • Problem

    After arithmetic-kernel optimization, embedded ML-KEM performance can still depend on memory placement, randomness, clock configuration, and repeatedly derived public data.

    Source: §1 · p. 2

  • Method

    The study evaluates memory placement, hardware integration, operating points, and deterministic public state around an optimized Cortex-M7 ML-KEM implementation across all three parameter sets.

    Source: §1 · pp. 2–3

  • Results

    Profiles without auxiliary public state reduce cycles by up to approximately 2.5%, while balanced AE-noD-noPK reduces encapsulation and decapsulation cycles by up to 74.6% and 58.8%, respectively.

    Source: §1 · p. 3, §7 · p. 21

  • Takeaways & Limitations

    The results show that additional gains remain possible after low-level arithmetic optimization, with evaluated profiles preserving standardized wire formats.

    Source: §1 · pp. 2–3

    The Cortex-M7 results demonstrate the methodology on one platform rather than establish a universal ranking of optimization classes.

    Source: §3.3 · p. 7

Abstract

from arXiv · show

Recent work on embedded post-quantum cryptography has focused primarily on instruction-level optimization, including arithmetic-kernel improvements, assembly tuning, register allocation, and instruction scheduling. Using the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) on an Arm Cortex-M7 as a case study, we examine the additional gains available from memory-hierarchy utilization, tightly coupled memory placement, peripheral integration, clock configuration, and deterministic public-data reuse. The evaluation starts from a state-of-the-art SLOTHY-optimized implementation and covers all three ML-KEM parameter sets. Without modifying the cryptographic algorithm or standardized wire formats, the evaluated profiles without auxiliary public state reduce cycles by up to 2.5%. A selected public-data-reuse profile reduces encapsulation and decapsulation cycles by up to 74.6% and 58.8%, respectively. These results demonstrate that substantial deployment gains remain after arithmetic-kernel optimization and motivate a two-stage methodology that also examines the surrounding execution system.

1 Introduction

Although instruction-level optimization has advanced embedded PQC implementations, execution-system behavior and repeated work across API calls can still limit performance. This study evaluates system-level choices around an optimized ML-KEM implementation and reports gains across all three parameter sets while preserving standardized formats.

1 Introduction

  • ML-KEM’s computation and memory demands, plus repeated derivation of public data, make embedded performance depend on more than arithmetic kernels.Relevant work includes polynomial arithmetic, NTTs, SHAKE-based expansion, hashing, rejection sampling, and matrix-vector operations.Source: §1 · p. 2
  • Prior Cortex-M work primarily reduces cryptographic-kernel cost through arithmetic improvements, assembly tuning, instruction scheduling, register allocation, and software pipelining.The study starts from the optimized implementation of Abdulrahman et al..Source: §1 · p. 2
  • The proposed two-stage methodology complements instruction-level tuning with evaluation of memory placement, hardware integration, operating points, and deterministic public state across operation and key lifecycles.It measures cycle counts, latency, memory consumption, and caller-managed auxiliary public state across all three ML-KEM parameter sets.Source: §1 · p. 2
  • The clock-scaling study measures ML-KEM across the platform’s full operating range because cycle counts vary with memory-system behavior and do not directly establish lowest execution latency.The cited baseline reports measurements at 24 MHz to eliminate Flash instruction-fetch wait states.Source: §1 · p. 2
  • Profiles without auxiliary public state reduce cycles by up to 2.5%, while the selected public-data-reuse profile reduces encapsulation and decapsulation cycles by up to 74.6% and 58.8%, respectively.The evaluation starts from a SLOTHY-optimized implementation and preserves standardized wire formats.Source: §1 · pp. 2–3

2 Related Work

Prior embedded PQC work largely improves arithmetic and assembly kernels, with a smaller body examining memory trade-offs and platform effects. This paper complements that work by organizing system-level choices around an optimized baseline and evaluating them together.

2 Related Work

  • PQM4 benchmarking and subsequent lattice-scheme implementations established a progression of embedded evaluation, with dominant costs including polynomial arithmetic, NTTs, hashing, sampling, and matrix-vector operations.The pqm4 project became a widely used baseline for embedded cryptographic evaluation.Source: §2 · p. 3
  • Most prior work improves kernel execution through NTT optimization, DSP features, arithmetic reductions, transform restructuring, and faster Keccak scheduling.Abdulrahman et al. optimized polynomial arithmetic and Barrett reductions, while Adomnicai optimized Keccak instruction scheduling and memory access.Source: §2 · pp. 3–4
  • SLOTHY-based migration reschedules and reallocates optimized Cortex-M4 assembly for Cortex-M7, providing the present study’s instruction-level baseline.Both processors implement Armv7E-M, but Cortex-M7 has a dual-issue pipeline with different scheduling constraints.Source: §2 · p. 4
  • A smaller literature studies memory trade-offs and Cortex-M7 microarchitectural effects, while this paper evaluates those system-level choices alongside public-data reuse, peripherals, and clock configuration.The paper does not propose new arithmetic kernels, transform structures, reductions, or assembly schedules.Source: §2 · p. 4

3 A Two-Stage View of Embedded Cryptographic Optimization

The framework separates local kernel-cost reduction from system-level execution and reuse, then groups recurring system-level choices and gives criteria for selecting them. Its questions transfer across embedded workloads, but measured gains and rankings remain platform-dependent.

3 A Two-Stage View of Embedded Cryptographic Optimization

  • Instruction-level optimization reduces local computational cost, while system-level optimization addresses kernel execution and reuse through placement, peripherals, operating points, and deterministic state across API calls.The stages identify where an optimization acts rather than imposing a strict algorithm-versus-platform division.Source: §3 · pp. 4–5

3.1 System-Level Optimization Classes

  • System-level classes include hot-code and hot-data placement, public-data reuse, hardware offloading, and clock or operating-point optimization.These respectively target fetch overhead, data-access latency, recomputation, software overhead, and execution time or energy efficiency.Source: §3.1 · p. 5

3.2 Optimization Selection Criteria

  • Select optimizations using code or data size, measured execution frequency, recomputation cost, and platform behavior rather than treating the classes as predictive performance models.Hot-code and hot-data choices also require profiling and accounting for fast-memory capacity, startup copying, and opportunity cost.Source: §3.2 · pp. 5–6
  • Public-data reuse is attractive when deterministic public information is costly to derive and repeatedly consumed, but preparation, storage, distribution, integrity, invalidation, and retention costs matter.Peripheral offloading must beat setup and integration costs; operating points must be validated for the deployment’s clock tree, memories, and peripheral timings.Source: §3.2 · pp. 6–7

3.3 Scope and Transferability

  • The framework’s questions transfer to other workloads, but Cortex-M7 results on one platform do not establish universal optimization rankings or unchanged gains.Available memory capacity, access behavior, hardware interfaces, and reusable public state differ across platforms and algorithms.Source: §3.3 · p. 7

4 ML-KEM System-Level Optimization on Cortex-M7

The study applies system-level optimization to ML-KEM on a SLOTHY-optimized Cortex-M7 baseline while preserving standardized key, ciphertext, and shared-secret formats. It evaluates memory placement, peripheral integration, clock configuration, and reuse of public-derived data.

4.1 Hot-Code Placement

  • ITCM offers lower, more predictable instruction-fetch latency than Flash, but limited capacity makes placement dependent on parameter set, clock, and whether A is regenerated or reused.Flash acceleration is effectively evaluated under the warm-cache benchmark conditions; the expected incremental benefit may be small when the instruction cache and ITCM cover the hot path.Source: ITCM Placement of Hot Code · pp. 8–9, Flash Acceleration and Prefetch… · p. 9

4.2 Hot-Data Placement

  • DTCM placement copies public NTT tables from Flash at startup, trading RAM and copy cost for removing those accesses from the Flash path.The tables are public; the benefit may be small if access-time savings do not justify the added RAM.Source: DTCM Placement of Public NTT Constants · p. 9

4.3 Hardware Offloading

  • The hardware-TRNG experiment measures STM32 peripheral integration cost against a deterministic software fallback, not against a deployment-quality software random-number generator.Entropy-source validation and peripheral error handling remain deployment responsibilities.Source: Hardware TRNG Integration · p. 10

4.4 Clock and Operating-Point Optimization

  • Clock configuration changes latency for a given cycle count rather than reducing executed instructions, and memory or peripheral behavior can also make cycle counts vary with frequency.The evaluation therefore treats clock selection as an operating-point choice and measures both cycle behavior and latency across configurations.Source: Clock Configuration · p. 10

4.5 Public-Data Reuse

  • Public-data reuse avoids repeated derivation or preparation by retaining cached A, H(pk), or parsed public-key state, trading RAM and possible communication for reduced repeated work.Cached A captures a multiplication-ready matrix during key generation; cached H(pk) can avoid rehashing during encapsulation, while parsed-key state avoids repeated decoding and preparation.Source: §4.5 · p. 11, Cached Public Matrix (A) · p. 11, Cached H(pk) · p. 11
  • The extra state is caller-managed and does not enlarge standardized ML-KEM keys; it must be associated with the correct public key and protected against stale or mismatched inputs.A remote encapsulator may need to receive, derive, or retain the auxiliary state, while a decapsulating key owner can retain state prepared during key generation.Source: §4.5 · p. 11, Parsed Public-Key Cache · p. 12

5 Implementation and Evaluation

The evaluation benchmarks a SLOTHY-optimized Cortex-M7 implementation across all three ML-KEM parameter sets, isolated system-level knobs, combined profiles, and clock settings. Public-data reuse yields the largest cycle reductions, while clock scaling and repeatability checks distinguish implementation work from deployment latency.

5.1 Experimental Platform and Baseline

  • The 384 benchmark cases use the strongest available repository baseline and cover all three FIPS 203 parameter sets, with 16 validated clock profiles in the composite evaluation.Operations are measured over 100 timed iterations after warm-up, with arithmetic mean cycles used for analysis; measurements report matching encapsulated and decapsulated shared secrets.Source: §5 · p. 12, §5.1 · p. 12

5.2 Evaluation of Individual Optimization Directions

  • Cached A cuts encapsulation cycles by 41.04–61.69% and decapsulation cycles by 37.76–58.41%; endpoint-selected ITCM cuts all three operations by 0.15–1.72% without auxiliary public state.Cached H(pk) reduces encapsulation cycles by 12.49–16.35% for 32 B, whereas parsed public-key caching saves at most 1.30% while requiring 2–4 KiB; Flash acceleration is effectively neutral under the warm-cache protocol.Source: Table 3 · p. 13, §5.2 · p. 14

5.1 Experimental Platform and Baseline

  • Across baseline measurements, cycle counts remain relatively stable as clock frequency rises while wall-clock latency scales approximately with processor frequency; cycles are not strictly frequency-invariant.The 24-to-216 MHz increase averages approximately 4.1k cycles and exceeds 5.2k in the worst case, so high-frequency latency cannot be inferred accurately by scaling low-frequency cycle measurements.Source: §5.1 · p. 13, Table 2 · p. 13

5.3 Evaluation of Combined Optimization Profiles

  • Profiles without public-data reuse reduce cycles by at most approximately 2.5% with no auxiliary public state, while reuse profiles yield larger encapsulation and decapsulation reductions at key-generation and storage cost.The selected AE-noD-noPK profile retains cached A and H(pk), hardware TRNG, Flash configuration, and path-specific ITCM placement; it omits DTCM constants and parsed public-key state.Source: Table 5 · p. 15, §5.3 · pp. 15–16
  • The selected profile's added key-generation cycles are smaller than the savings from one later encapsulation or decapsulation for every tested parameter set and endpoint; at 216 MHz, encapsulation is under 1 ms for all three sets.This comparison excludes external distribution and persistent-storage costs, and the profile assumes auxiliary public state can be retained or made available.Source: §5.3 · p. 16

5.4 Clock-Scaling Evaluation

  • For ML-KEM-768 encapsulation, latency falls from 4.808 ms at 24 MHz to 0.542 ms at 216 MHz; across all parameter sets, 24-to-216 MHz clock scaling reduces operation latency by approximately ninefold.In the same sweep, ML-KEM-768 key-generation and encapsulation cycles rise by approximately 0.8% and 1.4%, respectively.Source: §5.4 · p. 16, Figure 4 · p. 17

5.5 Measurement Dispersion and Repeatability

  • Within-run standard deviations were 0.29–1.01% for fixed-seed runs and 0.31–0.67% with TRNG inputs; across reboots, normalized standard deviations of means were at most 0.006% and 0.050–0.052%, respectively.For ML-KEM-768, ITCM savings were 0.40–0.45% at 24 MHz and 1.28–1.45% at 216 MHz, with every observed ITCM run mean below its corresponding baseline mean for all operations at both endpoints.Source: §5.5 · pp. 17–18

6 Deployment-Oriented Optimization Guidelines

Deployment choices depend on operation mix, key lifetime, memory, communication, and platform constraints; no profile dominates every objective. The recommendations distinguish communication-, memory-, and performance-constrained deployments, with public state needing a valid association to its key.

6 Deployment-Oriented Optimization Guidelines

  • No profile dominates every deployment objective; select among complete measured profiles at the intended clock and account for whether public state can be retained, derived once, or distributed with authenticated key association.The provisioned-sensor example amortizes state across a key lifecycle, but the cost of distributing or persistently storing that state was not measured.Source: §6 · pp. 18–19

6.1 Communication-Constrained Deployments

  • NC-noD is the preferred measured default when auxiliary public state cannot be retained or distributed, avoiding its communication, storage, and key-association requirements.It combines path-specific ITCM placement, hardware TRNG, and Flash configuration, while omitting DTCM constants that use 1792 B without measurable isolated benefit; public-data-reuse profiles raise key-generation cycles by 1.08–6.27%, with preparation costs potentially amortized over later operations.Source: §6.1 · pp. 19–20

6.2 Memory-Constrained Deployments

  • 12.49–16.35% fewer encapsulation cycles comes from 32 B of cached H(pk), a storage–performance option for memory-limited encapsulators.Combining the cache with selected ITCM placement is an evidence-based candidate, but the complete combination still requires measurement; parsed-key caching needs 2–4 KiB for at most a 1.30% isolated saving, while cached A requires 1.5–6 KiB for larger savings.Source: §6.2 · p. 20

6.3 Performance-Oriented Deployments

  • AE-noD-noPK is the balanced measured profile for repeated use, while AE or AC gives the lowest measured decapsulation time depending on the ML-KEM parameter set.At 216 MHz, AE is lowest for ML-KEM-512 and ML-KEM-768; AC is lowest for ML-KEM-1024. The faster-profile choice remains constrained by memory and auxiliary-state requirements, and the study does not measure power or energy.Source: §6.3 · p. 20

7 Conclusion

Starting from a SLOTHY-optimized Cortex-M7 implementation, the study evaluates system-level optimization across all three ML-KEM parameter sets while preserving standardized wire formats. Public-data reuse yields the largest reported cycle reductions, while profile rankings remain dependent on platform, workload, and lifecycle.

7 Conclusion

  • The balanced AE-noD-noPK profile reduces encapsulation and decapsulation cycles by up to 74.6% and 58.8%, respectively, while increasing key-generation cycles by 1.08–4.22%.At 216 MHz, its encapsulation latency is below 1 ms for every parameter set; profiles without auxiliary public state reduce cycles by up to approximately 2.5%.Source: §7 · p. 21
  • The study evaluates memory placement, Flash configuration, hardware randomness, operating frequency, and deterministic public-data reuse across all three ML-KEM parameter sets.It starts from a SLOTHY-optimized Cortex-M7 implementation and preserves standardized wire formats.Source: §7 · p. 21
  • The results support optimization beyond instruction-level kernels, but technique rankings and resulting profiles remain platform-, workload-, and lifecycle-dependent.On the evaluated platform, public-data reuse provides the largest gains, while selective ITCM placement is the most consistent improvement without auxiliary public state.Source: §7 · p. 21
Loading 2610.01960v1…