One-Round Threshold XMSS and SPHINCS+ from Fully Homomorphic Encryption

What it is

A threshold signing protocol for XMSS (RFC 8391) and SPHINCS+ (FIPS 205), built by Jung Hee Cheon, Kevin Choi, Hyeoncheol Joo, and Taeseong Kim (IACR ePrint 2026/2360). It is specifically a one-round protocol: any t-of-n key holders produce a valid signature in a single round of interaction, rather than the multi-round exchanges general MPC would require for these hash-based schemes.

How it works

The secret key is secret-shared across the t-of-n parties. Signing is evaluated homomorphically using threshold fully homomorphic encryption (FHE) over discrete CKKS, so each party only performs a threshold decryption step at the end to recover the plaintext signature — hence one round. The core technical contribution is an efficient homomorphic evaluation of SHAKE (the hash function underlying XMSS/SPHINCS+) under CKKS at varying batch sizes, combined with homomorphic lookup tables to handle the data-dependent selections in the signing algorithm, plus batching for the parallel hash computations inherent to the Merkle-tree structure of both schemes.

Preconditions / Affected

Applies to deployments of XMSS or SPHINCS+ wanting distributed/threshold key custody (e.g., multiple signers, HSM quorum, or distributed CA-style setups) without modifying verifiers. Output signatures are verified by unmodified RFC 8391 / FIPS 205 verifiers — no downstream compatibility changes needed.

What to do

No code, library, or reproduction commands are given on the page itself (preprint, no artifact link listed) — this is a construction/implementation paper, not a tool release. For engineers evaluating feasibility, the actionable numbers are the benchmarks:

• Amortized homomorphic SHAKE256/256 evaluation: 3.4 ms per hash
• Online threshold XMSS signing: 0.69 s
• Threshold SPHINCS+ signing latency: roughly two orders of magnitude higher than XMSS (i.e., tens to ~100 s range implied, not stated exactly), but SPHINCS+ setup latency is over an order of magnitude lower than XMSS's

These numbers are the basis for deciding whether threshold XMSS (fast signing, slower setup) or threshold SPHINCS+ (slow signing, fast setup) fits a given deployment's latency budget.

Caveats

The paper states the SPHINCS+/XMSS latency tradeoff only in relative terms ("two orders of magnitude higher," "an order of magnitude lower") rather than giving an absolute SPHINCS+ signing time — so absolute feasibility for SPHINCS+ in latency-sensitive settings can't be assessed from the abstract alone. No details on t/n scaling behavior, network assumptions, or hardware used for the benchmarks are given in the fetched text.