Skip to content

Back to the catalog

K-LMS: Design, Implementation, and Evaluation of Leighton–Micali Signatures with Korean Cryptographic Primitives
eprint.iacr.orgpaper

K-LMS: Design, Implementation, and Evaluation of Leighton–Micali Signatures with Korean Cryptographic Primitives

An IACR ePrint paper presenting K-LMS, an experimental variant of the NIST-standardized LMS hash-based post-quantum signature scheme in which the underlying hash is swapped for Korean primitives: the LSH-256 hash function (reference and vectorized) and a Tandem-DM double-block-length construction built from the CHAM, LEA, and ARIA block ciphers. The authors implement a non-invasive backend-swapping bridge over the reference LMS code and benchmark keygen/sign/verify latency, key/signature sizes, memory, and parameter sweeps, finding that hash substitution doesn't change key/signature sizes but that two measurement pitfalls (hash dispatch overhead, and software vs. hardware-accelerated SHA-256 baselines) can shift performance comparisons by an order of magnitude or 6x respectively. They report LSH-256 K-LMS signing on par with SHA-256 LMS in software, and 3.3-3.9x faster than a prior K-XMSS implementation because LMS needs fewer hash calls per Winternitz step than XMSS.

TL;DR New Korean-primitive variant of the NIST LMS post-quantum signature scheme (LSH-256 + CHAM/LEA/ARIA Tandem-DM), with benchmarks and two documented pitfalls that can skew hash-based signature performance comparisons.
Open original ↗
Document

What it is

K-LMS is an experimental backend swap for NIST's standardized LMS hash-based post-quantum signature scheme, replacing the hash function with Korean primitives: LSH-256 (reference and vectorized) and a Tandem-DM double-block-length construction over the CHAM, LEA, and ARIA block ciphers. It's implemented as a non-invasive bridge over the reference LMS code, giving eight interchangeable hash backends without modifying the reference implementation itself.

How it works

The paper profiles where LMS actually spends time: 94% of all hash calls are 55-byte one-shot digests, not long messages. This matters because it means scheme-level performance ranking cannot be extrapolated from standard long-message hash benchmarks — the hash's short-input performance is what dominates. The authors also identify two specific measurement pitfalls: a vectorized-backend dispatch wrapper that re-runs its CPU capability check on every single digest call (not once at startup), and the common practice of benchmarking against hardware-accelerated SHA-256 rather than a software baseline.

Preconditions / Affected

Relevant to anyone benchmarking or comparing hash-based PQC signature schemes (LMS, XMSS, SPHINCS+) across different hash backends, and to implementers evaluating Korean cryptographic primitives (LSH-256, CHAM, LEA, ARIA) for PQC use.

What to do

When benchmarking hash-substituted signature schemes:

  • Check whether any vectorized/dispatch wrapper re-checks CPU capabilities per-call rather than caching the check once — the paper measured this costing an order of magnitude on their virtualized host.
  • Be explicit about whether the SHA-256 baseline is software or hardware-accelerated: the choice shifts any LSH-vs-SHA-2 conclusion by roughly 6x.
  • Don't rely on long-message hash throughput numbers to predict LMS/XMSS signing performance — benchmark short (~55-byte) one-shot digest performance instead, since that's what dominates actual calls.

Caveats

Numbers (order-of-magnitude dispatch penalty, ~6x hardware-acceleration shift, 0.84x software signing ratio, 3.6x hardware advantage, 3.3–3.9x speedup over K-XMSS) are from the authors' specific host and are stated as observed on that setup, not as guaranteed general ratios. This is a preprint (received 2026-10-06, approved 2026-10-08), not yet peer-reviewed.

Technologies named here

Techniques named here

  • Hash substitution in LMS
  • Non-invasive backend bridge
  • Parameter sweep evaluation
  • Hash-call profiling
  • Vectorized LSH-256 implementation

Related in other