Revisiting the Constant-Sum Winternitz One-Time Signature with Applications to $\text {SPHINCS}^+$ and XMSS

Abstract

Hash-based signatures offer a conservative alternative to post-quantum signatures with arguably better-understood security than other post-quantum candidates. As a core building block of hash-based signatures, the efficiency of one-time signature (OTS) largely dominates that of hash-based signatures. The WOTS$^{+}$ signature scheme (Africacrypt 2013) is the current state-of-the-art OTS adopted by the signature schemes standardized by NIST—XMSS, LMS, and SPHINCS$^+$.

A natural question is whether there is (and how much) room left for improving one-time signatures (and thus standard hash-based signatures). In this paper, we show that WOTS$^{+}$ one-time signature, when adopting the constant-sum encoding scheme (Bos and Chaum, Crypto 1992), is size-optimal not only under Winternitz’s OTS framework, but also among all tree-based OTS designs. Moreover, we point out a flaw in the DAG-based OTS design previously shown to be size-optimal at Asiacrypt 1996, which makes the constant-sum WOTS$^{+}$ the most size-efficient OTS to the best of our knowledge. Finally, we evaluate the performance of constant-sum WOTS$^{+}$ integrated into the SPHINCS$^+$ (CCS 2019) and XMSS (PQC 2011) signature schemes which exhibit certain degrees of improvement in both signing time and signature size.

Appendices

A An Example of Constant-Sum $\text {WOTS}^{+}$

In this section, we present a concrete example of constant-sum $\text {WOTS}^{+}$, including counting, encoding algorithm, and the optimality proof. In this example, we choose parameter $l=3$ and $w=4$, therefore the size of $\mathcal {C}$ is maximum when the constant-sum is $\lfloor l(w-1)/2\rfloor =4$. This example can be also generated from a Python code, which is open-sourced at  [20].

Counting the Size. Recall that

$$ D_{l,s}= |\{{\boldsymbol{c}}\in [w]^l : \sum _{i=1}^{l} c_i = s \}| , $$

with their initial values

$$\begin{aligned} D_{0,0}&= 1 , \\ D_{0,s}&= 0 , \text{ for } s\in \{1,2,\dots ,w-1\} \\ D_{l,s}&= 0 , \text{ for } 1\le l \in \mathbb {Z}, s \in \mathbb {Z^-} , \end{aligned}$$

and recurrence relation

$$ D_{l,s} = \sum _{i=0}^{w-1} D_{l-1,s-i} , 2 \le l \in \mathbb {Z},s\in \{0,1,\dots ,l(w-1)\} .$$

We can compute the table of D, Table 6.

Table 6. The table of D

The value of $D_{3,4}$ tells us that we have 12 different vectors such that the length of each is 3 and the sum of each is 4.

The Encoding Algorithm. Since we $D_{3,4}=12$, we can encode at most 12 different messages, represented by $\{0,1,\dots ,11\}$. We show how to encode $x=4$ to a constant-sum vector. Recall that for each loop, we determine $v_{l-i}=j$ by seeking which j satisfies $x\in [\sum _{k<j}D_{l-1,s-k},\sum _{k\le j}D_{l-1,s-k})$.

• Initialization. Initially, we have $x=4$ and $s=4$.

• Loop 1. $D_{l,s}=D_{3,4}=12=2+3+4+3=D_{2,1}+D_{2,2}+D_{2,3}+D_{2,4}$ and $D_{2,4}\le x=4<D_{2,3}+D_{2,4}$. So we have $j=1$. Update the variables to $v_1=1,s=3,x=1$.

• Loop 2. $D_{l,s}=D_{2,3}=4=1+1+1+1=D_{1,0}+D_{1,1}+D_{1,2}+D_{1,3}$ and $D_{1,3}\le x=1<D_{1,2}+D_{1,3}$. So we have $j=1$. Update the variables to $v_2=1,s=2,x=0$.

• Loop 3. $D_{l,s}=D_{1,2}=1=1+0+0=D_{0,0}+D_{0,1}+D_{0,2}$ and $D_{0,1}+D_{0,2}+\le x=0<D_{0,0}+D_{0,1}+D_{0,2}$. So we have $j=2$. Update the variables to $v_3=2,s=0,x=0$.

• Finally. We get $v=(1,1,2)$.

By executing the encoding algorithm, We can list those 12 vectors (in order):

$\{(0, 1, 3)$, (0, 2, 2), (0, 3, 1), (1, 0, 3), (1, 1, 2), (1, 2, 1), (1, 3, 0), (2, 0, 2), (2, 1, 1), (2, 2, 0), (3, 0, 1), $(3, 1, 0)\}$.

Optimality Proof

By Dilworth’s theorem, the proof of optimality is also a construction of chain decomposition. We present an example here, which is computed in the way of the proof of Theorem 4.

• $l=1$. This is a trivial case. We have only one chain $(0)\le (1) \le (2) \le (3)$.

• $l=2$. We have 4 chains, they are:

  • 1. $(0, 0)\le (1, 0)\le (2, 0)\le (3, 0)\le (3, 1)\le (3, 2)\le (3, 3)$.

  • 2. $(0, 1)\le (1, 1)\le (2, 1)\le (2, 2)\le (2, 3)$.

  • 3. $(0, 2)\le (1, 2)\le (1, 3)$.

  • 4. (0, 3).

• $l=3$. We have 12 chains, they are:

  • 1. $(0, 0, 0)\le (1, 0, 0)\le (2, 0, 0)\le (3, 0, 0)\le (3, 1, 0)\le (3, 2, 0)\le (3, 3, 0)\le (3, 3, 1)\le (3, 3, 2)\le (3, 3, 3)$

  • 2. $(0, 0, 1)\le (1, 0, 1)\le (2, 0, 1)\le (3, 0, 1)\le (3, 1, 1)\le (3, 2, 1)\le (3, 2, 2)\le (3, 2, 3)$

  • 3. $(0, 0, 2)\le (1, 0, 2)\le (2, 0, 2)\le (3, 0, 2)\le (3, 1, 2)\le (3, 1, 3)$

  • 4. $(0, 0, 3)\le (1, 0, 3)\le (2, 0, 3)\le (3, 0, 3)$

  • 5. $(0, 1, 0)\le (1, 1, 0)\le (2, 1, 0)\le (2, 2, 0)\le (2, 3, 0)\le (2, 3, 1)\le (2, 3, 2)\le (2, 3, 3)$

  • 6. $(0, 1, 1)\le (1, 1, 1)\le (2, 1, 1)\le (2, 2, 1)\le (2, 2, 2)\le (2, 2, 3)$

  • 7. $(0, 1, 2)\le (1, 1, 2)\le (2, 1, 2)\le (2, 1, 3)$

  • 8. $(0, 1, 3)\le (1, 1, 3)$

  • 9. $(0, 2, 0)\le (1, 2, 0)\le (1, 3, 0)\le (1, 3, 1)\le (1, 3, 2)\le (1, 3, 3)$

  • 10. $(0, 2, 1)\le (1, 2, 1)\le (1, 2, 2)\le (1, 2, 3)$

  • 11. $(0, 2, 2)\le (0, 2, 3)$

  • 12. $(0, 3, 0)\le (0, 3, 1)\le (0, 3, 2)\le (0, 3, 3)$

The size of this chain decomposition meets the size of antichain $\mathcal {C}$. According to Dilworth’s theorem, the antichain $\mathcal {C}$ is maximum.

B On the Best Known Graph

We first correct a minor fault in the design of the weight function of  [13]. The old weight function was $wt(p)=\sum _{i=0}^{w-1}(w+1-r_i)$. Since we know $r_i\in \{0,\dots ,w\}$, the range of the old weight function is $[w, w(w+1)]$. When $w=2$, this range can not be fitted into $\{0,\dots ,|\mathcal S |-1\}$. Thus we make it into $wt(p)=\sum _{i=0}^{w-1}(w-r_i)\in [0,w^2]$, which is a more suitable choice.

For $l=l'=1,w=2$, we can have a correct construction if we reorder the mapping $\{\mathcal S _i\}$ to (0, 0), (1, 0), (0, 1), (1, 1), (2, 0), (0, 2). ([13] does not specify the order that mapping integers to signature patterns.) This does not mean we fixed this construction. The key problem is we can not prove the pairs of the message and checksum (m, c) form an antichain in this graph. There may exist forgery attacks for larger $l,l',w$ parameters.

There is a way to fix it by using “separate representation function encoding”, purposed in [7], which can be viewed as a generalized checksum method. However, even if we use this new encoding, the performance of this graph-based is clearly worst than $\text {WOTS}^{+}$ (with checksum). Both two constructions require encoding checksum separately. For $w=3$, the $\text {WOTS}^{+}$ fully utilized $(w+1)^w=64$ message space while the graph-based has only $|\mathcal S |=51$ choices.

C More Detailed Comparisons

1.1 C.1 Comparison Between Original and Improved $\text {SPHINCS}^+$

We benchmarked the performance of the improved $\text {SPHINCS}^+$ under 24 parameter settings ($\{\textrm{shake256, sha256}\} \times \{128,192,256\} \times \{\text {fast},\text {small}\} \times \{\text {ref},\text {avx2}\}$). To facilitate a fair comparison, we tested our implementation (adapted from the $\text {SPHINCS}^+$ codes) along with the original $\text {SPHINCS}^+$. The test results are reported in Table 7 and Table 8 with a comparison in Table 9.

Table 7. Runtime benchmarks for $\text {SPHINCS}^+$. Key generation, signing, and verification time are in the number of cpu cycles; the public key, secret key, and signature size are in bytes. All cycle counts are the median of 100 runs.

Table 8. Runtime benchmarks for $\text {SPHINCS-}{\alpha }$. Key generation, signing, and verification time are in the number of cpu cycles; the public key, secret key, and signature size are in bytes. All cycle counts are the median of 100 runs.

Table 9. Performance comparison between the original and improved $\text {SPHINCS}^+$ in terms of relative changes.

1.2 C.2 Comparison Between Original and Improved XMSS

We benchmarked the performance of the improved XMSS under selected parameter settings. To facilitate a fair comparison, we tested our implementation (adapted from the official repository) along with the original XMSS. The test results are reported in Table 10 and Table 11 with a comparison in Table 12.

Table 10. Runtime benchmarks for XMSSMT. Key generation, signing and verification time are in the number of cpu cycles; public key, secret key and signature size are in bytes. All cycle counts are the median of 16 runs.

Table 11. Runtime benchmarks for improved XMSSMT. Key generation, signing and verification time are in the number of cpu cycles; public key, secret key and signature size are in bytes. All cycle counts are the median of 16 runs.

Table 12. Performance comparison between the original and improved XMSS in terms of relative changes.