In this note, we discuss using parameter sets for SPHINCS+ which support a smaller number of signatures than the $2^{64}$ target. This includes a larger search through the SPHINCS+ parameter space, comparing it with the current parameter sets and providing data on how the security degrades if one exceeds the limits

Stefan Kölbl

In this note, we explore parameter sets for SPHINCS+ which support a smaller number of signatures than $2^{64}$, but are otherwise compatible with the SLH-DSA specification. In practice, use cases for which a low number of signatures per key pair suffice are common, and as we will show this allows a significant reduction in signature size and verification speed for SPHINCS+. For this we carry out a larger search through the SPHINCS+ parameter space, comparing it with the current parameter sets and further showing that for carefully chosen parameter the security degrades slowly if one exceeds the limits. Finally, we provide a case study for firmware signing on OpenTitan to demonstrate the efficiency of these alternative parameters

Jade Philipoom

Cryptology ePrint Archive

A note on SPHINCS+ parameter setsStefan Kölbl1Security Engineering Research, Googlekste@google.comKeywords: Hash-based signatures, post-quantum, SPHINCS+Abstract. In this note, we discuss using parameter sets for SPHINCS+which support a smaller number of signatures than the 264 target. Thisincludes a larger search through the SPHINCS+ parameter space, com-paring it with the current parameter sets and providing data on how thesecurity degrades if one exceeds the limits.1 IntroductionThe NIST call for post-quantum digital signature schemes had a requirementthat every scheme must maintain the full security level when a single key pairis used for up to 264 signatures. For most signature schemes this requirementcomes with little additional costs. However for hash-based signatures supportinga large number of signatures for a single key pair increases both signature sizeand computation time, as it requires choosing parameter which lead to largertree sizes.In practice, a limit of 264 seems very conservative for some applications.Consider for instance the limit of 250 signatures the original SPHINCS schemestargeted. This would allow issuing 1 million signatures per second for 30 yearswith a single key. There are many use cases in practice which will never need264 signatures, and could benefit greatly from parameter sets which are tailoredtowards those applications. To list a few:– Firmware signing: Only a small number of firmware versions will exists inthe lifetime of a key and a few thousand signatures would already be enoughin some cases.– Certificate signing: CAs sign a comparably small number of signatures com-pared to the 264 target. This is especially true for root CAs, which signintermediates. As today the certificate transparency log contains a total ofaround ≈ 233 certificates.In particular, in these use cases it is difficult for an adversary to trigger a largenumber of signatures being generated. For applications where this is possible,e.g. TLS handshakes, a conservative choice is preferable.There are significant risks of targeting a lower number of signatures, as en-forcing a query limit for a key in practice can be difficult. We therefore would notrecommend to place these schemes alongside signature schemes which provide avirtually unlimited number of signatures per key as this could lead to misuse.In some environments this might not be easier than for instance managing thestate in a stateful hash-based signature scheme.However, a stateless scheme like SPHINCS+ would still have several advan-tages:– Exceeding the limit is less severe. While stateful schemes fall quickly apart ifstate gets reused, the security of SPHINCS+ degrades much slower (see sub-section 2.1). If the parameters are chosen carefully, security degrades surpris-ingly slow. In practice this means that the limit can be exceeded by severalorder of magnitudes before it becomes a practical issue.– Backing up the key becomes much easier, as no state has to be synchronized.– Concurrently using the same key material in a distributed system is muchsimpler.We think it would be particular useful to have parameters, which targetthe same number of signatures as the existing stateful hash-based signaturestandards. These parameter sets then allow a direct comparison on how much itwould cost to get rid of the stateful property.2 Parameter searchIn the following we use q to denote the maximum number of signatures whichcan be used, while the targeted security level is still guaranteed. We used thesame approach as for the parameter search done on the original SPHINCS+parameter [BHK+19], sampling a large number of parameters from a reasonablespace in terms of signature size and expected signing costs.We collected a large set of parameters, sorted them by signature size firstand signing speed as a second criteria. These are then filtered to only includeparameters which are strictly better, i.e. a smaller signature size or faster signingspeed. The results of this search can be seen in Figure 1, Figure 2 and Figure 3.In this search we further include parameters with w = 256 for smaller q.While w = 256 can lead to parameters which are better in both signature sizeand signing speed, we expect the resulting verification speed to be significantlyworse. As verification speed is often critical in the applications which parameterwith small q would be used, we don’t think these offer a significant benefit.For estimating the signing speed, we simply count the number of hash oper-ations. This only provides a rough estimate of the real performance, as we treatthe costs for each hash operation the same. Depending on the platform andchoice of hash function there might be an asymmetry in the costs, and bettertrade-offs could be possible.In Table 1 we provide a comparison between the current SPHINCS+ pa-rameters, and a selection of q = 220 parameters, which seem well-suited for thepreviously mentioned use cases. In particular, they reduce signature size by morethan 50% and provide faster verification, while key generation and signing timeis slower.2048409681921638432768105 106 107 108Round 3 F parameter setRound 3 S parameter setSignatureSize,BytesHashes Performed During Signature Generation210 Signatures220 Signatures210 Signatures (w = 256)220 Signatures (w = 256)210 Signatures (100-bit sec for 220)220 Signatures (100-bit sec for 230)230 Signatures240 Signatures250 Signatures264 SignaturesFig. 1. Comparison of the size and signing speed for parameter sets providing 128-bitsecurity, for different target of max signatures.2.1 Security degradationIt’s important to point out that while SPHINCS+ security will degrade whenexceeding the maximum number of signatures, this happens slowly. Figure 4and Figure 5 shows how security degrades for some of the parameters we found.With moderate additional costs it is possible to find parameter which guaranteethat security does not drop below a certain level after exceeding the maximumnumber of signatures. In Figure 1, we explored parameter sets which:– Support 210 signatures, but security does not drop below 100 bits if one signsup to 220 signatures.– Support 220 signatures, but security does not drop below 100 bits if one signsup to 230 signatures.These have been included in Figure 1 and can provide a more conservative ap-proach, having a larger buffer before security would be affected in practice.ReferencesBHK+19. Daniel J. Bernstein, Andreas Hülsing, Stefan Kölbl, Ruben Niederhagen,Joost Rijneveld, and Peter Schwabe. The sphincs+ signature framework.In CCS, pages 2129–2146. ACM, 2019.40968192163843276865536105 106 107 108Round 3 F parameter setRound 3 S parameter setSignatureSize,BytesHashes Performed During Signature Generation210 Signatures220 Signatures210 Signatures (w = 256)220 Signatures (w = 256)230 Signatures240 Signatures250 Signatures264 SignaturesFig. 2. Comparison of the size and signing speed for parameter sets providing 192-bitsecurity, for different target of max signatures.Table 1. Comparison of parameters for q = 220 with the round 3 SPHINCS+ parame-ters.n h d log(t) k w bitsec sec level sig bytesSPHINCS+-128s 16 63 7 12 14 16 133 1 7,856SPHINCS+-128s (q = 220) 16 17 1 20 8 16 132 1 3,424SPHINCS+-192s 24 63 7 14 17 16 193 3 16,224SPHINCS+-192s (q = 220) 24 26 2 16 12 16 192 3 7,992SPHINCS+-256s 32 64 8 14 22 16 255 5 29,792SPHINCS+-256s (q = 220) 32 24 2 16 17 16 257 5 14,3368192163843276865536105 106 107 108Round 3 F parameter setRound 3 S parameter setSignatureSize,BytesHashes Performed During Signature Generation210 Signatures220 Signatures230 Signatures240 Signatures250 Signatures264 Signatures210 Signatures (w = 256)220 Signatures (w = 256)Fig. 3. Comparison of the size and signing speed for parameter sets providing 256-bitsecurity, for different target of max signatures.02040608010012014010 15 20 25 30SecurityinbitsNumber of signatures (log2)h = 14, d = 1, log(t) = 16, k = 8h = 12, d = 1, log(t) = 22, k = 6h = 16, d = 1, log(t) = 21, k = 6Fig. 4. Plot showing how the security degrades for different parameters targeting 210signatures with 128-bit security.02040608010012014020 25 30 35 40SecurityinbitsNumber of signatures (log2)h = 17, d = 1, log(t) = 20, k = 8h = 24, d = 2, log(t) = 21, k = 6h = 26, d = 2, log(t) = 18, k = 7Fig. 5. Plot showing how the security degrades for different parameters targeting 220signatures with 128-bit security.

A note on SPHINCS+ parameter sets

Abstract

Similar works

Full text

Available Versions

Cryptology ePrint Archive