PaperlayerView exact revision on arXiv

Source-linked AI summary

Efficient TCitH-Based Alternatives to SLH-DSA: Cross-Layer ASIC Design of Mirath

Hiandra Tomasi, Maximilian Schöffel, Johannes Feldmann, Norbert Wehn

arXiv:2609.35053v1cs.CRcs.AR

TL;DR

Resource-intensive MPCitH implementations pose challenges for resource-constrained devices, and this paper presents a cross-layer RISC-V ASIC implementation of Mirath. The authors report lower signing latency than considered SPHINCS+/SLH-DSA ASIC implementations.

  • Problem

    Reference MPCitH implementations are computationally and memory intensive, leading to high latency, memory use, and energy consumption on resource-constrained devices.

    Source: §I · p. 1

  • Method

    The authors combine algorithmic memory optimization with hardware/software co-design and dedicated accelerators in a RISC-V-based ASIC implementation of Mirath.

    Source: §I · p. 1, §IV · p. 2, §V · p. 3

  • Results

    The implementation achieves lower signing latency than all considered SoA SPHINCS+/SLH-DSA ASIC implementations, with less area and substantially lower verification energy than an ASIC at the same technology node.

    Source: §VIII · p. 6

  • Takeaways & Limitations

    The results support the feasibility of TCitH-based signatures as viable alternatives from an implementation perspective.

    Source: §VII · p. 6

    Energy comparisons are limited because only one considered work reports operation-level power and energy, and only for Verify.

    Source: §VII · p. 6

Abstract

from arXiv · show

To address the security risks posed by quantum computers, the U.S. National Institute of Standards and Technology (NIST) has standardized the post-quantum signature schemes ML-DSA, FN-DSA, and SLH-DSA. While ML-DSA and FN-DSA are lattice-based, SLH-DSA relies on hash-based assumptions. To support cryptographic agility against future vulnerabilities, NIST is evaluating non-lattice candidates as alternatives to SLH-DSA. Among these, TCitH-based schemes are particularly promising due to their compact keys and small signatures. However, their high computational complexity and memory footprint pose significant challenges for efficient implementations on resource-constrained embedded platforms. They remain largely unexplored in this context, particularly in ASIC implementations. To address this gap, we use a cross-layer methodology combining algorithmic and hardware layers to present, to the best of our knowledge, the first ASIC implementation of Mirath, a TCitH-based signature scheme, in a RISC-V-based system. The design is implemented in a 22nm FD-SOI technology node. Compared with an SLH-DSA ASIC implemented in the same technology node, the proposed architecture achieves 17.8x lower signing latency while requiring 58% less total cell area, showing the potential of TCitH-based signatures as efficient non-lattice alternatives from an implementation perspective.

I. INTRODUCTION

The introduction motivates non-lattice signature alternatives for crypto-agility, while identifying implementation cost and limited ASIC exploration as barriers. It presents a RISC-V hardware/software co-design of Mirath to investigate those bottlenecks.

I. INTRODUCTION

  • NIST’s additional signature process aims to strengthen crypto-agility, the ability to replace algorithms if vulnerabilities emerge.The introduction says non-lattice candidates must offer a significant performance advantage over SPHINCS+, the scheme underlying SLH-DSA.Source: §I · p. 1
  • TCitH schemes combine small public keys and compact signatures with security assumptions distinct from standardized schemes.The TCitH framework significantly reduces signature sizes relative to earlier corresponding MPCitH-based designs.Source: §I · p. 1
  • Reference implementations of MPCitH schemes are computationally and memory intensive, causing high latency, memory use, and energy consumption on resource-constrained devices.Source: §I · p. 1
  • ASIC implementations of candidates from the additional NIST signature process remain largely unexplored, while prior work mainly covers embedded software and FPGA implementations.Some candidates were eliminated before optimized implementation baselines were established.Source: §I · p. 1
  • The work presents what the authors describe as the first ASIC implementation of a TCitH-based signature scheme, combining algorithmic and hardware optimizations.The design is implemented in 22 nm FD-SOI and is intended to challenge the perception that MPCitH signatures are inherently inefficient.Source: §I · p. 1

II. BACKGROUND

Mirath is a TCitH-based signature scheme grounded in the MinRank Syndrome Problem. Its signing and verification procedures use commitments, seed-tree openings, and recomputed proof values.

II. BACKGROUND

  • TCitH replaces additive secret sharing with packed Shamir secret sharing to reduce opening data; Mirath uses this framework.Mirath did not advance to the third round of the NIST process due to similarities with other candidates, while its security claims remain unaffected.Source: §II · p. 2
  • Mirath is based on the MinRank Syndrome Problem, and its key generation derives secret and public-key values from seeds.The supplied passage identifies the problem basis and key-generation inputs, but does not provide the complete problem statement.Source: §II · p. 2
  • During signing, GGM trees derive leaf seeds, commitments bind to the digest hcom, and the resulting values feed polynomial-proof values.Source: §II · p. 2
  • The BAVC opening reveals enough seed-tree information to reconstruct non-challenged parties while keeping challenged leaf seeds hidden; verification recomputes commitments, shares, and proof values.AES supports seed-tree expansion, pseudorandom-share generation, and leaf-seed commitments; FIPS 202 supports matrix and seed expansion, transcript hashing, and challenge generation.Source: §II · p. 2

III. DESIGN OBJECTIVES

The design targets Mirath’s memory requirements and execution latency, using algorithmic memory reduction followed by hardware/software acceleration. The evaluation uses Mirath-1a-fast and the reference C implementation as its baseline.

III. DESIGN OBJECTIVES

  • The evaluation uses Mirath-1a-fast and the reference C implementation, PRef, with 33-byte test-vector messages as the baseline.Source: §III · p. 2
  • Table I compares latency and memory for the reference and algorithmically optimized implementations at 500 MHz.Source: Table I · p. 2
  • The design objectives are to reduce Mirath’s memory requirements through algorithmic optimization and then reduce execution latency by accelerating dominant computational bottlenecks.The reference implementation’s Sign and Verify operations require substantial data memory, while long execution times create prohibitive latency for general applications.Source: §III · p. 2

IV. ALGORITHMIC OPTIMIZATION

The algorithmic optimization reduces Sign and Verify memory by deriving tree leaves and commitments on demand. It trades memory savings for additional AES evaluations and latency, which motivates hardware acceleration.

IV. ALGORITHMIC OPTIMIZATION

  • The memory bottleneck is pre-computing round inputs: the complete GGM tree and leaf commitments each require approximately 139 kB, and duplicated leaf seeds add 70 kB to a 377 kB data-memory footprint.Source: §IV · p. 2
  • Instead, leaves and commitments are derived on demand from the root along the corresponding path, used, and discarded as commitments are incrementally absorbed into hcom.Verify applies the same strategy to visible leaves reconstructed from sibling seeds in πBAVC.Source: §IV · pp. 2–3
  • The compact Mirath-1a-fast GGM tree has 4352 leaves across two depths, and its illustrated path ends at node 8702.Each parent seed serves as an AES-128 key; branch-specific plaintexts are derived from the salt, node index, and branch bit to produce child seeds.Source: Figure 2 · p. 3
  • The optimization replaces full tree and commitment arrays with a 224 B path and a 32 B commitment, reducing Sign/Verify data memory by approximately 90%.Repeated tree traversals increase AES evaluations and latency by up to 273%.Source: §IV · p. 3

V. HW/SW CO-DESIGN

The design pairs a RISC-V processor with TCitH accelerators and local storage, using progressively coarser offload. AES and GGM-tree traversal are specifically accelerated for Sign and Verify.

V. HW/SW CO-DESIGN

  • The processor communicates with the TCitH accelerator over AXI4-Lite, with two 8 kB local memories for operands, intermediate values, and results.Where possible, intermediate values move directly between accelerators; the memory-mapped interface avoids custom RISC-V instructions for kernels with multiple wide operands.Source: §V · p. 3, Figure 3 · p. 3

A. AES IP

  • AES-128 encryption accelerates GGM seed derivation, leaf-seed commitments, and pseudorandom-share generation during Sign and Verify, but is unused during KeyGen.The AES IP also retains AES-128/256 encryption and decryption modes for broader application contexts.Source: A. AES IP · p. 3

B. GGM Tree Accelerator

  • The GGM Tree module derives only the requested path from a root seed, salt, and node or leaf index, without generating both children or materializing the full tree.Local memories retain the preceding path so consecutive traversals with a common prefix can resume at the first differing level; verification uses disclosed sibling-path seeds and this mode is integrated only with the Accumulator.Source: B. GGM Tree Accelerator · pp. 3–4

C. FIPS 202 Accelerator

The FIPS 202 module offloads selected hash operations while leaving incremental context and protocol-specific input handling in software. The Accumulator handles party reconstruction and accumulation, with distinct signing and verification flows.

C. FIPS 202 Accelerator

  • The FIPS 202 module executes KECCAK permutations and aligned 64-bit absorb and squeeze portions, while software retains context, fragments, padding, byte extraction, and hash-input construction.When paired with the Accumulator, it can receive 32-byte party commitments directly through a 64-bit ready/valid interface, avoiding a processor round trip.Source: C. FIPS 202 Accelerator · p. 4
  • FIPS 202 supports matrix expansion, commitment and transcript digests, and protocol-challenge derivation.Source: C. FIPS 202 Accelerator · p. 4

D. Accumulator

  • During Sign, the Accumulator processes one repetition per command, deriving party seeds and commitments, expanding shares, and computing accumulations and auxiliary values.AES seed generation overlaps with share processing, and the resulting values remain in local memories for direct use by MPC-Emulation when enabled.Source: D. Accumulator · p. 4
  • During Verify, the Accumulator uses disclosed sibling seeds to reconstruct visible parties, expand their shares, and regenerate commitments; hidden-party values come from the signature.When direct commitment streaming is enabled, hidden commitments enter the FIPS 202 stream at their corresponding position.Source: D. Accumulator · p. 4

E. MPC-Emulation Accelerator

The MPC-Emulation accelerator reuses the Accumulator’s multiplier lanes for algebraic proof computations. The evaluated partition configurations combine accelerator modules in different sets.

E. MPC-Emulation Accelerator

  • MPC-Emulation uses a multi-phase state machine and reuses the Accumulator’s eight F28 multiplier lanes; its early-exit mode computes y for KeyGen syndrome computation and Sign reconstruction.The accelerator is not used during KeyGen for polynomial-proof values; those values are used during Sign and Verify.Source: E. MPC-Emulation Accelerator · p. 4, P10 AES IP, GGM Tree, FIPS 202,… · p. 4

P4 AES IP, GGM Tree

F. Partitionings

The partition results show that accelerator benefits depend on the operation and remaining software bottlenecks. AES yields large latency reductions, while later accelerators provide additional gains once dominant workloads are addressed.

F. Partitionings

  • Fourteen distinct HW/SW partitions are considered, with KeyGen limited to P2, P3, and P5, Sign supporting all partitions, and Verify excluding P4.ASIC timing uses worst-case PVT conditions at 125 °C and 0.72 V; power uses nominal conditions at 25 °C and 0.8 V.Source: F. Partitionings · p. 4, §VI · p. 4

A. Impact of the different partitions on the overall runtime

  • KeyGen latency falls from 3.07 ms in P0 to 2.67 ms, 0.60 ms, and 0.20 ms in P2, P3, and P5, respectively.All partitions were validated against PRef, and accelerator effectiveness depends on the targeted operation and remaining software bottlenecks.Source: A. Impact of the different partitions… · p. 4
  • 99.61% and 99.70% lower P0 latency for Sign and Verify, respectively, result from introducing standalone AES IP in P1.FIPS 202 or MPC-Emulation alone provides negligible benefit for Sign and Verify, leaving the system 197–273% slower than PRef; AES IP accounts for 4.75% of total P12 cell area.Source: A. Impact of the different partitions… · pp. 4–5
  • Approximately 22.1% lower signing latency than P1 results from adding the GGM Tree accelerator in P4.Its smaller marginal gain removes another seed-tree computation component and enables larger gains from Accumulator and MPC-Emulation.Source: A. Impact of the different partitions… · p. 5
  • 82.7% and 87.1% fewer signing and verification cycles, respectively, result from adding FIPS 202 to P11 to form fully accelerated P12.The results are reported for the considered HW/SW partitions in Table IV.Source: A. Impact of the different partitions… · p. 5, Table IV · p. 5

B. Area, Power, and Energy

The P12 implementation reduces area and memory requirements relative to PRef, while its additional accelerator logic slightly increases power; shorter execution time yields substantially lower energy consumption.

B. Area, Power, and Energy

  • PRef and fully accelerated P12 are the two design-space endpoints compared for area and energy characteristics.The area breakdown is reported in Table V; Table VII summarizes power and energy.Source: B. Area, Power, and Energy · p. 5, Table VII · p. 6
  • 0.51 mm2 (PRef) versus 0.24 mm2 (P12) total cell area; P12 also reduces data SRAM from six 64 kB macros to one.Both designs were implemented and simulated at 500 MHz.Source: B. Area, Power, and Energy · p. 5
  • 14×, 5,929×, and 10,569× lower energy consumption for KeyGen, Sign, and Verify, respectively, are reported for P12 relative to PRef.P12 has slightly higher power consumption, attributed to its additional accelerator logic, but the execution-time reduction outweighs this increase.Source: B. Area, Power, and Energy · pp. 5–6

VII. COMPARISON TO SOA

P12 is compared with ASIC implementations of standardized and pre-standardization schemes. The comparisons show lower signing latency than the considered SPHINCS+/SLH-DSA implementations, with qualifications for area and energy comparisons.

VII. COMPARISON TO SOA

  • Area comparisons are limited by technology-node and implementation-stage differences, and the compared works do not report PVT conditions.Source: §VII · p. 6
  • 6.6× to 95× lower signing latencies than the SPHINCS+/SLH-DSA implementations in –[20] are reported for P12.The same-technology-node implementation occupies 2.4× the area of P12, with full-system area accounting.Source: §VII · p. 6
  • P12 meets the stated non-lattice-candidate latency requirement when Sign and Verify are considered jointly, although Mirath did not advance to the third round.The authors identify this as a finding for TCitH schemes with similar computational structures.Source: §VII · p. 6
  • For Verify, P12 requires approximately 1.9× lower power and 135× lower energy than; energy comparison is limited to this work and operation.P12 also reports 2× and 11.7× lower area than and, respectively, while operating in their latency range.Source: §VII · p. 6

VIII. CONCLUSION

The paper presents a first ASIC implementation of a TCitH-based signature scheme and evaluates Mirath for resource-constrained systems. Its results support the implementation feasibility of TCitH-based signatures as embedded alternatives.

VIII. CONCLUSION

  • The authors present, to their knowledge, the first ASIC implementation of a TCitH-based signature scheme, combining algorithmic optimization with hardware accelerators.The implementation reduces signing and verification energy relative to the reference software implementation.Source: §VIII · p. 6
  • P12 achieves lower signing latency than all considered SoA SPHINCS+/SLH-DSA ASIC implementations and substantially lower verification energy at the same technology node.Source: §VIII · p. 6
  • Compared with lattice-based Dilithium/ML-DSA and Falcon implementations, Mirath supports the feasibility of TCitH-based signatures in embedded applications for computation time and required area.Source: §VIII · p. 6
Loading 2609.35053v1…