A signature key should not silently break because a server was rolled back or copied. XMSS and XMSSMT track signing state, but counter mistakes can reuse a one-time signature and enable forgery. SPHINCS+ removes that state requirement while retaining a hash-based design. section 14.2.3
SPHINCS+ adapts XMSSMT in three main ways:
- Derives the hypertree path deterministically from the private key and message, so signing the same message twice produces the same signature. section 14.2.3
- Uses many more one-time-signature locations, reducing the probability that pseudorandom path selection reuses one. section 14.2.3
- Replaces the final one-time signature with a few-time signature, so path reuse across different messages does not directly break the scheme. section 14.2.3
Figure 14.6 The XMSSMT stateful hash-based signature scheme uses multiple trees to increase the amount of signatures supported by the scheme while reducing the work at key generation and signing time. Each tree is deterministically generated only when they are used in the path to the final leaf that contains the OTS used to sign a message.
The XMSSMT multi-tree structure supplies the hypertree foundation that SPHINCS+ modifies to avoid state tracking. section 14.2.3
A safer operational interface
If the same message is signed twice, SPHINCS+ deterministically selects the same path and produces the same signature. Unlike stateful XMSSMT, copying a signing key between servers or restoring an old filesystem state does not require maintaining a shared counter. section 14.2.3
