Skip to content

Back to the catalog

Shorter Few-Time Signatures from Hash Chains and Blockwise Forced Pruning
eprint.iacr.orgpaper

Shorter Few-Time Signatures from Hash Chains and Blockwise Forced Pruning

This IACR ePrint paper introduces BPORS-C+BFP, a new few-time signature construction that replaces FORS in SPHINCS+/SLH-DSA, combining short hash chains with a blockwise forced-pruning budget to shrink the bottom signature component. The authors derive a generating-function coverage bound and an exact counting method to safely tighten pruning per block, achieving 8.3%-18.1% smaller full SLH-DSA signatures across six standard parameter sets (versus 3.7%-13.4% for the prior BPORS+FP scheme), and up to 32.5%-36.5% reduction in limited-use settings.

TL;DR New hash-chain-based few-time signature scheme shrinks SLH-DSA (SPHINCS+) signatures by up to 18% via blockwise forced pruning.
Document

What it is

BPORS-C+BFP, a few-time signature (FTS) construction designed as a drop-in replacement for FORS, the bottom-layer few-time signature component in SPHINCS+/SLH-DSA. It's the direct successor to an earlier scheme called BPORS+FP, built by the same line of work.

How it works

FORS signatures reveal secret values at selected leaves of several independent Merkle trees. BPORS+FP improved on this with "forced pruning": a single shared budget limiting the total number of authentication nodes needed across all coordinates. BPORS-C+BFP goes further in two ways:

  1. Hash chains instead of fixed secrets — each leaf's secret is replaced by a short hash chain. A selected chain contributes one hash value to the signature, but the depth at which it's opened is an extra encoding choice (more information packed per revealed value).
  2. Blockwise budgets instead of one global budget — rather than one pruning budget shared across all coordinates, each block of coordinates gets its own separate authentication-node budget. This confines the pruning-induced dependencies to smaller groups, which is what makes exact (not just approximate) counting of safe pruning limits computationally practical.

To make this safe, the authors needed a way to bound how much an attacker could exploit repeated signing (since repeated use can disclose different depths on the same chain). They derive a generating-function upper bound on coverage, plus an exact counting method for individual blocks, to calibrate how aggressively each block can be pruned without weakening security.

Preconditions / Affected

Applies when BPORS-C+BFP is substituted for FORS inside SLH-DSA/SPHINCS+, with the hypertree layers and one-time signature (WOTS+) parameters held fixed — only the few-time signature layer changes. Results are reported across six standard SLH-DSA parameter sets, plus three additional "limited-use" settings (scenarios with a small cap on total signatures per key, where tighter pruning budgets are safer to apply).

What to do

This is a construction proposal, not a shipped patch — there's no code or integration guidance on the page. The actionable figures, for anyone evaluating it against BPORS+FP or FORS:

  • Full SLH-DSA signature size reduction: 8.3%–18.1% across the six standard parameter sets, vs. 3.7%–13.4% for BPORS+FP on the same sets.
  • In the three limited-use settings, reduction relative to plain FORS: 32.5%–36.5% for BPORS-C+BFP vs. 22.0%–26.0% for BPORS+FP.

Caveats

The paper is a preprint (received 2026-10-06, approved 2026-10-08) with no indication of third-party cryptanalysis or review yet. The security argument rests on the authors' own generating-function bound and exact counting method — no independent verification is mentioned on the page.

Technologies named here

Techniques named here

  • Forced pruning
  • Blockwise forced pruning
  • Hash chains for few-time signatures
  • Constant-sum constraint on depth tuples
  • Generating-function coverage bound and exact counting method