Efficient Implementation of Hash-based Signature Schemes

AuthorIng. AndreasSchöngruber, BSc.11725595

SubmissionInstitute ofComputationalPerception

Thesis Supervisora.Univ.-Prof. Dr. JosefScharinger

June 2021

JOHANNES KEPLERUNIVERSITY LINZAltenbergerstraße 694040 Linz, Austriawww.jku.atDVR 0093696

EfficientImplementation ofHash-based SignatureSchemes - LMS andHSS

Master Thesisto obtain the academic degree of

Diplom-Ingenieurin the Master’s Program

Computer Science

Acknowledgement

I want to thank my supervisor, Dr. Josef Scharinger, for providing guidance and feedbackthrough this thesis. Especially helpful for me was the very quick response to each mailand question which allowed me to keep up with my personal schedule. His feedback wasalways constructive and supportive. I also want to thank my friends for their distractionand support in such different times for young people as we currently have. I think it isalso important to mention the countless IT companies that provide several services thathelp students to finish their studies and also a big thank you to one of my favorites theBraucommune in Freistadt for their tasty beer that helps a lot in every life situation.

June 2021 Ing. Andreas Schöngruber, BSc. i/87

Abstract

The development of large-scale quantum computers progresses continuously. It is believedthat in the next few years large-scale quantum computers will be available and that thosecan break some of the current security standards. Therefore, new standards are needed forall different kinds of applications. One kind of quantum-safe algorithms are hash-basedsignature schemes. In this thesis, the Leighton-Micali hash-based signature scheme andits multi-tree variant the hierarchical signature system are implemented in Java and theperformance of the algorithm is compared to the Cisco C reference implementation ofRFC 8554.

Kurzfassung

Die Entwicklung von großen Quantencomputern schreitet kontinuierlich voran. Es wirdvermutet, dass diese Quantencomputer in den nächsten Jahren verfügbar sein werden undeinige der aktuellen Security Standards brechen können. Daher werden neue Standardsfür verschiedene Arten von Anwendungen benötigt. Eine Art von Quantensicheren Algo-rithmen sind Hash-basierte Signaturverfahren. In dieser Arbeit wird das Leighton-MicaliHash-basierte Signaturverfahren und die dazugehörige Multi-Baum Variante, das Hierar-chical Signature System, in Java implementiert. Die Implementierung wird abschließendmit der Cisco C Referenzimplementierung vom RFC 8554 verglichen.

June 2021 Ing. Andreas Schöngruber, BSc. ii/87

Contents

1 Introduction 11.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Theory 32.1 Post-Quantum Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Hash-based Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Parameter Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Leighton-Micali One-Time Signature . . . . . . . . . . . . . . . . . . 102.2.3 Leighton-Micali Signature Scheme . . . . . . . . . . . . . . . . . . . 162.2.4 Hierarchical Signature System . . . . . . . . . . . . . . . . . . . . . 21

2.3 Random Number Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.1 One-Time Signature Key Reuse . . . . . . . . . . . . . . . . . . . . . 252.4.2 Hash Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4.3 Key Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5 LMS Security Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Implementation 283.1 Used Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2 Common Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.1 Leighton-Micali One-Time Signature . . . . . . . . . . . . . . . . . . 363.3.2 Leighton-Micali Signature . . . . . . . . . . . . . . . . . . . . . . . . 403.3.3 Hierarchical Signature System . . . . . . . . . . . . . . . . . . . . . 47

3.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.5 Benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4 Existing Implementations 57

5 Results 595.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1.1 Leighton-Micali One-Time Signature Scheme . . . . . . . . . . . . . 60

June 2021 Ing. Andreas Schöngruber, BSc. iii/87

5.1.2 Leighton-Micali Signature Scheme . . . . . . . . . . . . . . . . . . . 615.1.3 Hierarchical Signature System . . . . . . . . . . . . . . . . . . . . . 61

5.2 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 Conclusion and Outlook 736.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Appendix 81

June 2021 Ing. Andreas Schöngruber, BSc. iv/87

List of Figures

2.1 LMS Tree with Signature Path [1] . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Unit Test Code Coverage Statistics . . . . . . . . . . . . . . . . . . . . . . . 52

5.1 LM-OTS Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.2 LMS Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3 HSS Key Generation - H5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.4 HSS Key Generation - H10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.5 HSS Key Generation - H15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.6 HSS Key Generation - H20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.7 HSS Key Generation - H25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.8 CPU Utilization - Key Generation . . . . . . . . . . . . . . . . . . . . . . . . 655.9 HSS Signature Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.10 LM-OTS Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.11 LM-OTS Key Sizes - Logarithmic scale . . . . . . . . . . . . . . . . . . . . . 685.12 LMS Key Sizes - Logarithmic Scale . . . . . . . . . . . . . . . . . . . . . . . 695.13 HSS Key Sizes Level 1 - Logarithmic Scale . . . . . . . . . . . . . . . . . . . 695.14 HSS Key Sizes Level 8 - Logarithmic Scale . . . . . . . . . . . . . . . . . . . 70

June 2021 Ing. Andreas Schöngruber, BSc. v/87

List of Tables

2.1 LM-OTS Parameter Sets [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 LMS Parameter Sets [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Supported Features of Existing Implementations . . . . . . . . . . . . . . . 58

5.1 LM-OTS Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.2 LMS Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.3 HSS Key Sizes - 1 Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.4 HSS Key Sizes - 8 Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

1 HSS Key Generation H5 - Benchmark Results . . . . . . . . . . . . . . . . . 812 HSS Key Generation H10 - Benchmark Results . . . . . . . . . . . . . . . . 813 HSS Key Generation H15 - Benchmark Results . . . . . . . . . . . . . . . . 824 HSS Key Generation H20 - Benchmark Results . . . . . . . . . . . . . . . . 825 HSS Key Generation H25 - Benchmark Results . . . . . . . . . . . . . . . . 826 HSS Signature Generation - Benchmark Results . . . . . . . . . . . . . . . . 837 HSS Signature Verification - Benchmark Results . . . . . . . . . . . . . . . 838 LM-OTS Parameter Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849 LMS Parameter Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

June 2021 Ing. Andreas Schöngruber, BSc. vi/87

Listings

2.1 Calculation of LM-OTS Parameters p and ls . . . . . . . . . . . . . . . . . . 72.2 LM-OTS Private Key Generation [1] . . . . . . . . . . . . . . . . . . . . . . 102.3 LM-OTS Public Key Generation [1] . . . . . . . . . . . . . . . . . . . . . . . 122.4 LM-OTS Signature Generation [1] . . . . . . . . . . . . . . . . . . . . . . . . 132.5 LM-OTS Coefficient Algorithm [1] . . . . . . . . . . . . . . . . . . . . . . . 132.6 LM-OTS Checksum [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 LM-OTS Signature Verification [1] . . . . . . . . . . . . . . . . . . . . . . . 142.8 LM-OTS Public Key Candidate Generation [1] . . . . . . . . . . . . . . . . 152.9 LMS Private Key Generation [1] . . . . . . . . . . . . . . . . . . . . . . . . . 162.10 LMS Signature Generation [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 182.11 LMS Signature Verification [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 192.12 LMS Public Key Candidate Generation [1] . . . . . . . . . . . . . . . . . . . 202.13 HSS Key Pair Generation [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.14 HSS Signature Generation [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 222.15 HSS Signature Verification [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Gradle Checkstyle Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Gradle Spotbugs Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 LM-OTS Private Key Generation . . . . . . . . . . . . . . . . . . . . . . . . 393.4 LM-OTS Public Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . 403.5 LM-OTS Signature Generation . . . . . . . . . . . . . . . . . . . . . . . . . 403.6 LM-OTS Signature Generation . . . . . . . . . . . . . . . . . . . . . . . . . 403.7 LMS Calculate Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.8 LMS Key Pair Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.9 LMS Signature Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.10 LMS Signature Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.11 HSS Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.12 HSS Signature Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.13 HSS Signature Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.14 LM-OTS Private Key Generation Test . . . . . . . . . . . . . . . . . . . . . . 523.15 HSS E2E Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.16 Parallel Unit Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.17 HSS Key Generation - Benchmark . . . . . . . . . . . . . . . . . . . . . . . 56

June 2021 Ing. Andreas Schöngruber, BSc. vii/87

Glossary

E2E End-to-End.

HSS Hierarchical Signature System.

JIT Just-In-Time Compiler.

JVM Java Virtual Machine.

LM-OTS Leighton-Micali One-time Signature.

LMS Leighton-Micali Hash-Based Signature.

NIST National Institute of Standards and Technology.

XMSS eXtended Merkle Signature Scheme.

XMSSMT Multi-Tree XMSS.

June 2021 Ing. Andreas Schöngruber, BSc. viii/87

1 Introduction

In this short first chapter of this thesis, the problem statement and the resulting motivationfor this thesis are explained. This chapter also contains an outline that shows what toexpect of all other chapters of this thesis.

1.1 Problem Statement

The progress in quantum computer research grows the need for quantum-resistant cryp-tographic algorithms because current standards might be not resistant against quantumattacks [2, 3, 4, 5]. Especially public-key cryptographic algorithms will be broken whenlarge-scale quantum computers become available. These algorithms are used in manydifferent applications and protocols in our daily life. Having no secure alternatives willresult in a very big security threat, which many cryptographers try to prevent.

1.2 Motivation

Hash-based signature schemes are believed to be quantum-resistant and their securityis already well understood [1, 6, 7, 8, 9, 10, 11]. Although stateful hash-based signatureschemes are no candidates for a new standard because they require careful state man-agement, they provide security against quantum attacks and can make sense in someapplications. The National Institute of Standards and Technology (NIST) approved twoof them, the Leighton-Micali Hash-Based Signature (LMS) and the EXtended MerkleSignature Scheme (XMSS), and their respective multi-tree variants, the Hierarchical Sig-nature System (HSS) and the Multi-Tree XMSS (XMSSMT). Currently, there are not manyimplementations of LMS and HSS available. Cisco’s C implementation [12] performs

June 2021 Ing. Andreas Schöngruber, BSc. 1/87

very well but does not support all parameter sets defined in the process by NIST [13].The motivation for this work is to have an efficient implementation of LMS and HSS thatsupports all defined parameter sets, with secure state management. Additionally, thesource code should be easy to read, to adapt, and reusable for future researchers.

1.3 Outline

This thesis continues with Chapter 2, the theory about hash-based signature schemes. Itcovers all essential knowledge that builds the foundation for this thesis. It begins withan explanation about post-quantum cryptography, goes over to the details about hash-based signature schemes and how the algorithms for LMS and HSS work. It contains alsoinformation about random number generation and ends with some security considera-tions for hash-based signature schemes and the LMS security proof. After the theory isexplained, the details about the implementation of the program in this thesis can be foundin Chapter 3. It covers the used technologies, the details about all source code files, andalso encountered problems and their respective solution. How unit testing was done isalso covered in this chapter, including a few examples of such unit tests and the overallcode coverage statistics of the project. It ends with details about the Java benchmarks donein this thesis. In Chapter 4, all relevant existing implementations of HSS are mentionedand compared in regards to their feature set. In Chapter 5, the only relevant existing andopen-source implementation, the C implementation from RFC 8554 [1], is compared tothe Java implementation from this work. Both programs are compared in regards to theirperformance of key generation, signature generation, and signature verification. Thischapter contains also information about the expected key sizes of the different parametersets. This thesis ends with a conclusion and open tasks in Chapter 6.


2 Theory

In this chapter, the required theory for this thesis will be explained. It starts with explain-ing the term Post-Quantum cryptography and why it is needed. Hash-based signatureschemes are explained and also the concrete algorithm LMS and its respective multi-treevariant HSS are described. The random number generation requirements and some ofthe security considerations are mentioned and it ends with an overview of LMS secu-rity proofs. All the information covered in this chapter is needed to understand variousimplementation details in the following chapter.

As the development of large-scale quantum computers progresses [14] it grows the needfor quantum-proof security algorithms. It is believed that large-scale quantum computerswill break most of the current public-key security standards e.g., RSA and DSA. PeterW. Shor [3, 4, 15] proved that quantum computers can solve the integer factorizationand the discrete logarithm problem in polynomial time and Lov K. Grover showed thatquantum computers can speed up brute-force attacks against symmetric key algorithmsexponentially [5, 15]. It is estimated that large-scale quantum computers can break a2048-bit RSA key in a matter of hours [2] where this takes trillions of years for classicalcomputers. To be ready for this when large-scale computers are available there aretwo possible solutions. Quantum cryptography and post-quantum cryptography [2].Quantum cryptography requires a quantum source, a transmission line and a quantumdetector which is not available to everyone [16]. The biggest disadvantage of quantumcryptography is that the existing infrastructure must be changed which would be amassive effort. The second possibility is to use post-quantum cryptography which usesquantum-proof algorithms on classical computers. The main advantage of this approachis that existing infrastructure and protocols only require small adaptions and can thenbe used with quantum-proof algorithms. This will make the transition from public-keycryptography to quantum-safe cryptography much easier and faster than introducingcompletely new protocols [17].


2.1 Post-Quantum Cryptography

Post-Quantum cryptography defines a set of algorithms that are quantum-safe but do notrequire a quantum computer. These algorithms can be used on classical computers. Themajor advantage of post-quantum cryptography is, therefore, that it is already possibleto use it and that most existing protocols do not need to be changed or require onlysmall adaptions because of the possible larger key sizes. Even if no large-scale quantumcomputers are available it is possible to introduce post-quantum cryptography in allkinds of protocols and the world will be ready for the future when large-scale quantumcomputers eventually become available. There are mainly five different types of post-quantum cryptographic algorithms defined [18]:

• Lattice-based cryptography

• Code-based cryptography

• Multivariate polynomial cryptography

• Hash-based signatures

• Secret-key cryptography

Lattice-based cryptography The security of lattice-based algorithms is based on worst-case hardness of lattice problems. Breaking an algorithm based on such lattice problemsis at least as hard as solving these lattice problems in the worst case. One such problemis the shortest vector problem (SVP) [19]. These algorithms are relatively efficient andsimple [19].

Code-based cryptography Code-based cryptographic algorithms are based on the hard-ness of decoding a linear code. The first known code-based cryptographic algorithm wasproposed by Robert J. McEliece [20] in 1978. Even with quantum computers, there are stillno known attacks against them. The biggest disadvantage of McEliece is the large publickey size [21].


Multivariate polynomial cryptography The security of multivariate public key cryptosys-tems is based on the problem of solving nonlinear equations over a finite field [22]. Thisproblem is NP-hard. These algorithms are similar to current public-key cryptographicalgorithms. In the last three decades, the development in this area has been intensive.Some algorithms believed to be secure turned out to be not secure but others are stillunbroken [22].

Hash-based signatures The security of hash-based signatures is well understood be-cause they were invented in the late 1970s by Ralph Merkle [23]. Their security depends onthe collision resistance of the underlying hash function [10]. One drawback of hash-basedsignatures is that the number of signatures that can be generated with one public/privatekey pair is limited.

Secret-key cryptography Secret-key cryptography or often also called "conventionalsystems" have been used for a long time. The idea of these algorithms is that two partiesshare one common key for encryption and decryption [24]. They are believed to be secureagainst quantum attacks but because of Grover’s algorithm [5] the size of the used keysshould be doubled to keep the systems secure. A table showing the strength dependingon their key size of currently used algorithms in comparison to conventional computingand quantum computing can be found in the ETSI Quantum Safe Cryptography Whitepa-per [17]. Secret-key algorithms like AES, have many advantages e.g., fast encryption anddecryption. The major drawback is the key agreement between two parties.

NIST has started a process to find one or more quantum-resistant public-key algo-rithms [25]. The goal of this public process is to define new standards for each typeof algorithm: public-key encryption, key-establishment algorithms, and digital signa-ture algorithms. This process is still in progress and might take some time before itgets finalized [25]. There was also a dedicated process for stateful hash-based signatureschemes, SP 800-208 [13], which was finalized in October 2020. The final candidates ofthe Recommendation for Stateful Hash-Based Signature Schemes are LMS, XMSS, andtheir multi-tree variants HSS and XMSSMT [1, 13, 26, 27]. These four algorithms areno candidates in the Post-Quantum Cryptography standardization process. NIST didnot allow stateful hash-based signature schemes to be submitted as candidates for thepost-quantum-cryptography standardization. The reason for this is that they do not meet


the NIST API requirements, most likely due to the fact that stateful hash-based signatureschemes require careful state management [28]. In the FAQs of NIST we can find thefollowing explanation [29]:

"What are NIST’s plans regarding stateful hash-based signatures? ...

NIST plans to coordinate with other standards organizations, such as the IETF,to develop standards for stateful hash-based signatures. As stateful hash-basedsignatures do not meet the API requested for signatures, this standardizationeffort will be a separate process from the one outlined in the call for proposals.It is expected that NIST will only approve a stateful hash-based signaturestandard for use in a limited range of signature applications, such as codesigning, where most implementations will be able to securely deal with therequirement to keep state."

2.2 Hash-based Signature Schemes

In this chapter the theoretical functionality of the hash-based signature scheme algorithmsLeighton-Micali One-time Signature (LM-OTS), LMS and HSS are explained. Also, alldefined parameter sets are contained in this section. All shown algorithms are taken fromRFC 8554 [1].

2.2.1 Parameter Sets

For each hash-based signature scheme algorithm exists a set of predefined parameters [1,13, 26]. Each parameter set has a name that gives a hint about the used hash algorithmand the used parameters.

LM-OTS supports two different hash functions, SHA-256 and SHAKE-256. Both hashfunctions are used either with an output length of 24 byte or 32 byte. Each parameter setshould have a numeric identifier defined by NIST but at the time of writing this thesis notall parameter sets got an identifier assigned. In such a case they have the value TBD.


As soon as those identifiers are assigned they can be found at https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml [13, 30].The LM-OTS parameters are explained in RFC 8554 [1] as follows:

• n: The number of bytes of the output of the hash function

• w: The width (in bits) of the Winternitz coefficients; that is, the number of bits fromthe hash or checksum that is used with a single Winternitz chain. It is a member ofthe set {1, 2, 4, 8}

• p: The number of n-byte string elements that make up the LM-OTS signature

• ls: The number of left-shift bits used in the checksum function

• H: A second-preimage-resistant cryptographic hash function that accepts byte stringsof any length and returns an n-byte string

The parameters p and ls can be calculated from the parameters n and w with the algorithmfrom appendix B of RFC 8554 [1], see Listing 2.1. The parameter ls has been removed fromthe final report [13] of NIST whereas the parameter p is still listed.

1 u = c e i l (8 * n / w)2 v = c e i l ( ( f l o o r ( lg ( ( 2 ^w − 1) * u ) ) + 1) / w)3 l s = 16 − ( v * w)4 p = u + v

Listing 2.1: Calculation of LM-OTS Parameters p and ls

The used parameters influence the key generation time and the signature length. Theparameters n and p influence the length of the signature and the length of the keys.Larger n and large p will result in larger key sizes. The parameter w influences theperformance of the key generation because it has a direct effect on the total number ofrequired hash computations. A larger w slows down the key generation significantlybut it also increases the security of the signature. The parameter H also influences theperformance because different hash algorithms require different computational effort.The number of hash computations for an LM-OTS public key can be calculated withthe formula: p ∗ (2w − 1) + 1 [1]. All defined LM-OTS parameter sets can be found inTable 2.1.


https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml


LM-OTS Parameter Sets Identifier H n w pLMOTS_SHA256_N32_W1 0x0000 0001 SHA-256 32 1 265LMOTS_SHA256_N32_W2 0x0000 0002 SHA-256 32 2 133LMOTS_SHA256_N32_W4 0x0000 0003 SHA-256 32 4 67LMOTS_SHA256_N32_W8 0x0000 0004 SHA-256 32 8 34LMOTS_SHA256_N24_W1 TBD SHA-256 24 1 200LMOTS_SHA256_N24_W2 TBD SHA-256 24 2 101LMOTS_SHA256_N24_W4 TBD SHA-256 24 4 51LMOTS_SHA256_N24_W8 TBD SHA-256 24 8 26LMOTS_SHAKE_N32_W1 TBD SHAKE-256 32 1 265LMOTS_SHAKE_N32_W2 TBD SHAKE-256 32 2 133LMOTS_SHAKE_N32_W4 TBD SHAKE-256 32 4 67LMOTS_SHAKE_N32_W8 TBD SHAKE-256 32 8 34LMOTS_SHAKE_N24_W1 TBD SHAKE-256 24 1 200LMOTS_SHAKE_N24_W2 TBD SHAKE-256 24 2 101LMOTS_SHAKE_N24_W4 TBD SHAKE-256 24 4 51LMOTS_SHAKE_N24_W8 TBD SHAKE-256 24 8 26

Table 2.1: LM-OTS Parameter Sets [13]

LMS supports 20 different parameter sets. Their naming is similar to the LM-OTS parame-ter sets and contains the used hash function, the output length, and the LMS tree height.It uses two hash functions, SHA-256 and SHAKE-256 which can have an output lengthof either 24 byte or 32 byte. Each parameter set has a numeric identifier but currently,not all parameter sets have one assigned. The missing identifiers are stated as TBD. Forthe LMS key generation, one LMS parameter set must be selected and also one LM-OTSparameter set. The combination can almost freely be chosen but it is required that bothparameter sets use the same hash function [13]. The LMS parameter sets are explained inRFC 8554 [1] as follows:

• h: The height of the tree

• m: The number of bytes associated with each node

• H: A second-preimage-resistant cryptographic hash function that accepts byte stringsof any length and returns an m-byte string.


LMS Parameter Sets Identifier H m hLMS_SHA256_M32_H5 0x0000 0005 SHA-256 32 5LMS_SHA256_M32_H10 0x0000 0006 SHA-256 32 10LMS_SHA256_M32_H15 0x0000 0007 SHA-256 32 15LMS_SHA256_M32_H20 0x0000 0008 SHA-256 32 20LMS_SHA256_M32_H25 0x0000 0009 SHA-256 32 25LMS_SHA256_M24_H5 TBD SHA-256 24 5LMS_SHA256_M24_H10 TBD SHA-256 24 10LMS_SHA256_M24_H15 TBD SHA-256 24 15LMS_SHA256_M24_H20 TBD SHA-256 24 20LMS_SHA256_M24_H25 TBD SHA-256 24 25LMS_SHAKE_M32_H5 TBD SHAKE-256 32 5LMS_SHAKE_M32_H10 TBD SHAKE-256 32 10LMS_SHAKE_M32_H15 TBD SHAKE-256 32 15LMS_SHAKE_M32_H20 TBD SHAKE-256 32 20LMS_SHAKE_M32_H25 TBD SHAKE-256 32 25LMS_SHAKE_M24_H5 TBD SHAKE-256 24 5LMS_SHAKE_M24_H10 TBD SHAKE-256 24 10LMS_SHAKE_M24_H15 TBD SHAKE-256 24 15LMS_SHAKE_M24_H20 TBD SHAKE-256 24 20LMS_SHAKE_M24_H25 TBD SHAKE-256 24 25

Table 2.2: LMS Parameter Sets [13]

The height of the LMS tree can have a big impact on the key generation performance andalso the private key size. The LMS tree height is a member of the set {5, 10, 15, 20, 25}. Theresulting LMS tree has then 2h nodes e.g., 210 = 1024 nodes. All defined parameter setsfor LMS can be found in Table 2.2.

For HSS there exists only one parameter, the number of LMS levels. This parameter is aninteger between 1 and 8 and defines how many levels of LMS trees are used. An HSS keywith only one level is basically the same as an LMS key. The more LMS levels are used themore signatures can be generated but it also increases the duration of the key generationand increases the private key size.


2.2.2 Leighton-Micali One-Time Signature

A One-Time Signature Scheme is a digital signature scheme and can be used to sign exactlyone message [9, 6, 1, 13, 11]. If more than one message needs to be signed a new OTSprivate key must be generated for each message or signing operation. The idea of One-Time Signatures was invented by Leslie Lamport and Michael Rabin already in 1979 [7,8, 31]. Hash-based one-time signature schemes are one kind of such one-time signatureschemes. Their security depends solely on the security of the used hash function. Oneconcrete example of such a hash-based one-time signature scheme is the Leighton-MicaliOne-Time Signature.

To sign a message with LM-OTS one party needs to generate a private/public key pair.The private key is the combination of p random n-byte strings, where n and p are definedin the LM-OTS parameter sets defined in the NIST recommendation [13, 1] which can befound in Section 2.2.1 of this thesis. Additionally to the random n-byte strings the privatekey also contains the used parameter set and two 16 byte identifiers q and I which areused in the LMS tree later. The generation of such an LM-OTS private key is rather fastbecause only random strings are constructed. The pseudocode of the LM-OTS private keygeneration can be seen in Listing 2.2.

1 1 . Re t r i eve the values of q and I ( the 16− byte i d e n t i f i e r of the LMS publ ic/p r i v a t e key pai r ) from the LMS t r e e t h a t t h i s LM−OTS p r i v a t e key w i l l be

used with2 2 . Set type to the typecode of the algorithm3 3 . Set n and p according to the typecode4 4 . Compute the array x as fo l lows :5 f o r ( i = 0 ; i < p ; i = i + 1 ) {6 s e t x [ i ] to a uniformly random n−byte s t r i n g7 }8 5 . Return u32s t r ( type ) || I || u32s t r ( q ) || x [ 0 ] || x [ 1 ] || . . . || x [ p−1]

Listing 2.2: LM-OTS Private Key Generation [1]

For the signature verification process, one needs an associated public key. The LM-OTSpublic key generation requires more computational effort than the private key generation.To generate an LM-OTS public key the previously generated private key is needed. Eachrandom n-byte string from the private key is hashed 2w − 1 times in a row. First the n-byte


string is stored in tmp which is then used in the hashing operation. The result of thatoperation is then again stored in tmp. After all 2w − 1 hashing operations are done theresult will be stored in y[p] where b is the index of the n-byte string of the private key.For the hashing operation also the identifiers I and q from the LMS tree, the index of then-byte string, and the hash counter are included:

tmp = H(I || u32str(q) || u16str(i) || u8str(j) || tmp)

Depending on the used parameter set this results in 1 up to 255 hash operations per n-bytestring. Therefore, the parameter w can also be called the security parameter because itdefines how often the keys are hashed. After all p n-byte strings ran through that processthe resulting hashes y[0] ... y[p-1] are then concatenated and hashed again to generate thefinal LM-OTS public key K. The last hash operation contains the identifiers q and I, andthe security string D_PBLC = 0x8080 [1]:

K = H(I || u32str(q) || u16str(D_PBLC) || y[0] || ... || y[p − 1])

The LM-OTS public key contains also the typecode of the used parameter set and theidentifiers I and q. It has the following format:

publicKey = u32str(type) || I || u32str(q) || K

The possible public key sizes can be found in Chapter 5.2 of this thesis. The generatedpublic key is then distributed so that other parties can verify signatures generated withits respective private key. The LM-OTS public key generation algorithm can be seen inListing 2.3 [1].

To sign a message with the Leighton-Micali One-Time Signature scheme the message isfirst hashed together with the identifiers I and q, the security string D_MESG = 0x8181 [1],and a random n-byte string C. The LM-OTS typecode and the identifiers I and q are takenfrom the private key:

Q = H(I || u32str(q) || u16str(D_MESG) || C || message)


The resulting hash is then used in several iterations in the signature generation process.First, a checksum of that hash is generated. The checksum is used to prevent any forgeryattempts on signatures. The algorithm to generate the checksum can be seen in Listing2.6 [1]. For each n-byte string of the LM-OTS private key the coefficient a is calculated.This coefficient determines how many hashing iterations need to be performed. Thealgorithm for the coefficient calculation can be seen in Listing 2.5. Each n-byte string fromthe private key is then hashed a-times including the identifiers I and q, and the key index,and the hash counter. First the n-byte string is stored in tmp which is then used in thehashing operation. The result of that operation is then again stored in tmp. This is similarto the public key generation:


1 1 . Set type to the typecode of the algorithm2 2 . Set the i n t e g e r s n , p , and w according to the typecode3 3 . Determine x , I , and q from the p r i v a t e key4 4 . Compute the s t r i n g K as fo l lows :5 f o r ( i = 0 ; i < p ; i = i + 1 ) {6 tmp = x [ i ]7 f o r ( j = 0 ; j < 2^w − 1 ; j = j + 1 ) {8 tmp = H( I || u32s t r ( q ) || u16s t r ( i ) || u8s t r ( j ) || tmp )9 }

10 y [ i ] = tmp11 }12 K = H( I || u32s t r ( q ) || u16s t r (D_PBLC) || y [ 0 ] || . . . || y [ p− 1] )13 5 . Return u32s t r ( type ) || I || u32s t r ( q ) || K

Listing 2.3: LM-OTS Public Key Generation [1]

After a hash iterations the resulting hashes, y[0] ... y[p-1], for each n-byte string of theprivate key are concatenated together to form the LM-OTS signature. The final LM-OTSsignature is the concatenation of the typecode, the random n-byte string C and the pconcatenated n-byte hashes:

signature = u32str(type); || C || y[0] || ... || y[p − 1]

The pseudocode for the signature generation can be seen in Listing 2.4 [1].


1 1 . Set type to the typecode of the algorithm2 2 . Set n , p , and w according to the typecode3 3 . Determine x , I , and q from the p r i v a t e key4 4 . Set C to a uniformly random n−byte s t r i n g5 5 . Compute the array y as fo l lows :6 Q = H( I || u32s t r ( q ) || u16s t r (D_MESG) || C || message )7 f o r ( i = 0 ; i < p ; i = i + 1 ) {8 a = coef (Q || Cksm(Q) , i , w)9 tmp = x [ i ]

10 f o r ( j = 0 ; j < a ; j = j + 1 ) {11 tmp = H( I || u32s t r ( q ) || u16s t r ( i ) || u8s t r ( j ) || tmp )12 }13 y [ i ] = tmp14 }15 6 . Return u32s t r ( type ) || C || y [ 0 ] || . . . || y [ p−1]

Listing 2.4: LM-OTS Signature Generation [1]

The coefficient algorithm retrieves the i-th bit sequence with a length of w bits of an inputS. The parameters w and i must be positive integer values. For example if the input stringS is 0x1234 = 0001 0010 0011 0100, then the result of coef(S, 7, 1) is 1, because the 7th bitfrom the left side is 1. Respectively the result of coef(S, 0, 4) is 1, because the first byte fromthe left is 1. This algorithm is shown in Listing 2.5.

1 coef ( S , i , w) =2 (2^w − 1) AND ( byte ( S , f l o o r ( i * w / 8) ) >> (8 − (w * ( i % (8 / w) ) + w) ) )

Listing 2.5: LM-OTS Coefficient Algorithm [1]

1 sum = 02 f o r ( i = 0 ; i < ( n*8/w) ; i = i + 1 ) {3 sum = sum + (2^w − 1) − coef ( S , i , w)4 }5 re turn (sum << l s )

Listing 2.6: LM-OTS Checksum [1]

To verify an LM-OTS signature one needs the signature, the public key, and the originalmessage. The first step in the signature verification process is to validate that the public


key is at least four bytes long. Then the typecode, I, q, and K are parsed from the publickey, where the first four bytes are the typecode. The next 16 bytes are the identifier I. Thenext four bytes are the identifier q, and the next n bytes are the public key K. With all thatinformation it is then possible to compute the public key candidate Kc. Computing thepublic key from the signature is possible because the signature is an intermediate value ofthe public key [1]. If the generated public key candidate Kc is equal to the given public keyK then the signature is valid. In all other cases, the signature is not valid. This algorithmis shown in Listing 2.7 [1].

1 1 . I f the publ ic key i s not a t l e a s t four bytes long , re turn INVALID .2 2 . Parse pubtype , I , q , and K from the publ ic key as fo l lows :3 a . pubtype = strTou32 ( f i r s t 4 bytes of publ ic key )4 b . Set n according to the pubkey and Table 1 ; i f the publ ic key i s not

e x a c t l y 24 + n bytes long , re turn INVALID .5 c . I = next 16 bytes of publ ic key6 d . q = strTou32 ( next 4 bytes of publ ic key )7 e . K = next n bytes of publ ic key8 3 . Compute the publ ic key candidate Kc from the signature , message , pubtype ,

and the i d e n t i f i e r s I and q obtained from the publ ic key , usingAlgorithm 4b ( L i s t i n g 2 . 8 in t h i s t h e s i s ) . I f Algorithm 4b re turnsINVALID , then return INVALID .

9 4 . I f Kc i s equal to K, re turn VALID ; otherwise , re turn INVALID .

Listing 2.7: LM-OTS Signature Verification [1]

The generation of the public key candidate Kc is done in general very similar to the publickey generation. First, all required information is parsed from the given signature e.g., thetypecode. The next step is to hash the identifiers I and q, the security string D_MESG =0x8181, the random string C, and the message:

Q = H(I || u32str(q) || u16str(D_MESG) || C || message)

Then a checksum is computed from the resulting hash. The checksum is appended tothe hash and used for the calculation of the coefficient a. This is the same process asdone during the signature generation. For each key from the signature the following hashoperation is done 2w − 1 − a times. First tmp will be set to the n-byte string from thesignature which will then be used for the hashing operation. The result of that operation


will then be stored again in tmp. After all hashing operations are done the result will bestored in z[p]:


All resulting hashes, z[0] ... z[p-1], from the signature keys are finally hashed togetherwith the identifiers I and q, and the security string D_PBLC = 0x8080 to get the key Kc:

Kc = H(I || u32str(q) || u16str(D_PBLC) || z[0] || z[1] || ... || z[p − 1])

The algorithm for calculating Kc can be seen in Listing 2.8 [1].

1 1 . I f the s ignature i s not a t l e a s t four bytes long , re turn INVALID .2 2 . Parse sigtype , C, and y from the s ignature as fo l lows :3 a . s ig type = strTou32 ( f i r s t 4 bytes of s ignature )4 b . I f s ig type i s not equal to pubtype , re turn INVALID .5 c . Se t n and p according to the pubtype ; i f the s ignature i s not e x a c t l y

4 + n * ( p+1) bytes long , re turn INVALID .6 d . C = next n bytes of s ignature7 e . y [ 0 ] = next n bytes of s ignature8 y [ 1 ] = next n bytes of s ignature9 . . .

10 y [ p−1] = next n bytes of s ignature11 3 . Compute the s t r i n g Kc as fo l lows :12 Q = H( I || u32s t r ( q ) || u16s t r (D_MESG) || C || message )13 f o r ( i = 0 ; i < p ; i = i + 1 ) {14 a = coef (Q || Cksm(Q) , i , w)15 tmp = y [ i ]16 f o r ( j = a ; j < 2^w − 1 ; j = j + 1 ) {17 tmp = H( I || u32s t r ( q ) || u16s t r ( i ) || u8s t r ( j ) || tmp )18 }19 z [ i ] = tmp20 }21 Kc = H( I || u32s t r ( q ) || u16s t r (D_PBLC) || z [ 0 ] || z [ 1 ] || . . . || z [ p− 1] )22 4 . Return Kc .

Listing 2.8: LM-OTS Public Key Candidate Generation [1]


2.2.3 Leighton-Micali Signature Scheme

The biggest drawback of one-time signatures is that they should only be used to sign onemessage because otherwise, it could weaken their security [13, 1]. Ralph Merkle addedthe ability to sign multiple messages with the invention of Merkle trees in 1979 [23]. Notonly allow Merkle trees to sign multiple messages but they also keep the public key veryshort.

For the Leighton-Micali Signature Scheme, several one-time signature key pairs are gen-erated. Each LM-OTS private key is then used for at most one signature generation.Therefore, the state of the LMS private key must be maintained.

To generate an LMS private key 2h LM-OTS private keys need to be generated wherethe identifier q gets incremented for every single key. This algorithm can be seen inListing 2.9 [1].

1 1 . Determine h and m from the typecode .2 2 . Set I to a uniformly random 16− byte s t r i n g .3 3 . Compute the array OTS_PRIV [ ] as fo l lows :4 f o r ( q = 0 ; q < 2^h ; q = q + 1) {5 OTS_PRIV [ q ] = LM−OTS p r i v a t e key with i d e n t i f i e r s I , q6 }7 4 . q = 0

Listing 2.9: LMS Private Key Generation [1]

An LMS public key is generated by computing the LM-OTS public keys for each LM-OTSprivate key of the LMS tree. The keys from the leaf nodes of the LMS tree are pairwisehashed together to form the previous level of the LMS tree. Therefore, the size of eachlevel of the LMS tree shrinks by the factor of two. This process continues until only onekey is available, the root of the LMS tree, T[1]. It forms the LMS public key which can laterbe used to verify all signatures that were generated with the respective LMS private key.A simple example of an LMS tree can be seen in Figure 2.1. The public key has followingformat:

publicKey = u32str(type) || u32str(otstype) || I || T[1]


Figure 2.1: LMS Tree with Signature Path [1]

An LMS signature consists of the LMS leaf identifier q, an LM-OTS signature, the LMStypecode, and the path from the leaf node to the root node in the LMS tree. The path array,path[0] ... path[h - 1], consists of h elements which represent the adjacent nodes from theroot path. This can be seen in Figure 2.1. The idea behind that is, that each node holds allthe information from all nodes that are below. Therefore, those h elements are enough toverify an LMS signature. This keeps the LMS signature as small as possible. The signaturehas following format:

signature = u32str(q) || lmots_signature || u32str(type) ||

path[0] || path[1] || path[2] || ... || path[h − 1]

Figure 2.1 shows a simple LMS tree with an height of 3. At the bottom of the figure, theleaf nodes are located. They represent the LM-OTS keys. At the top of the figure, the treeroot is shown. It represents the LMS public key. The figure also shows the signature pathfrom one leaf node to the root. The used LM-OTS key is marked with a green box. Theidentifier q for this key is 2, where the identifiers start with 0 at the most left leaf of the treeand end with 7 at the most right leaf as indicated in Figure 2.1. The path from the usedkey to the root is marked green. To be able to calculate this path with pairwise hashing thenodes marked in red need to be known. These nodes, leaf 3, T[4], and T[3] are the valuesthat are stored in the LMS signature path.


To generate an LMS signature of a message, first, an LM-OTS signature must be generated.This is done with the next unused LM-OTS private key in the LMS tree. To ensure thateach LM-OTS private key is used at most once, the q identifier in the LMS tree must beupdated before releasing the signature. More about One-Time Signature Key Reuse can beread in Section 2.4.1. The used identifier q, the LM-OTS signature, and the LMS typecodeare then stored in the LMS signature. The path to the root node of the LMS tree is thengenerated and also added to the signature.

There are mainly two different possible implementations to calculate the path to theroot: (1) Store all nodes of the tree in memory, (2) Calculate all path values on demand.Calculating the full tree once and keeping all nodes in memory is not very memoryefficient but it is the fastest possible way to compute the path from one LMS leaf to theroot. Depending on the used LMS parameter set this approach is not always possible,because it would require too much memory. With a tree height of 25 and an hash functionoutput length of 32 byte, the memory requirement would be 226 ∗ 32 byte ≈ 2.1 GB.Calculating all nodes on demand is much more memory efficient but it requires thiscomputation for each signature generation. A side-effect of this approach is that it makesthe implementation more secure because the internal nodes that should be kept private arenot stored in memory and make it harder for an attacker to gain access to them. It is alsopossible to use some kind of hybrid approach. Storing only a few pre-computed nodescan save computation time during the signature generation and also keep the consumedmemory rather low. It is possible to store the nodes of the first levels of the LMS tree.These nodes are needed every time and can slightly speed up the signature generation.A different approach, the Fractal Merkle Tree Traversal, was proposed by Jakobsson et.al. [32]. They introduce subtrees to the LMS tree and only need to update small parts ofthem when used. The worst-case computation effort of this approach is 2 log N / loglog Nhash computations and the total storage requirement is less than 1.5 log2 N / loglog N,where N is the number of leaves.

The algorithm for the LMS signature generation can be seen in Listing 2.10 [1].

1 1 . Set type to the typecode of the LMS algorithm .2 2 . E x t r a c t h from the typecode .3 3 . Create the LM−OTS s ignature f o r the message :4 o t s _ s i g n a t u r e = lmots_sign ( message , LMS_PRIV[ q ] )5 4 . Compute the array path as fo l lows :


6 i = 07 r = 2^h + q8 while ( i < h ) {9 temp = ( r / 2^ i ) xor 1

10 path [ i ] = T [ temp ]11 i = i + 112 }13 5 . S = u32s t r ( q ) || o t s _ s i g n a t u r e || u32s t r ( type ) || path [ 0 ] || path [ 1 ] ||

. . . || path [ h−1]14 6 . q = q + 115 7 . Return S .

Listing 2.10: LMS Signature Generation [1]

The first step of the signature verification process is to validate the given LMS public key.The public key must be at least four bytes long to be able to continue. The first four bytesof the public key are the LMS typecode. The next four bytes parsed from the public keygive the LM-OTS typecode. With that information, it is then possible to generate the LMSpublic key candidate Tc from the LMS signature. If this public key candidate Tc is equalto the given public key the signature is valid, otherwise, the signature is invalid. Thisalgorithm is shown in Listing 2.11 [1].

1 1 . I f the publ ic key i s not a t l e a s t e i g h t bytes long , re turn INVALID .2 2 . Parse pubtype , I , and T [ 1 ] from the publ ic key as fo l lows :3 a . pubtype = strTou32 ( f i r s t 4 bytes of publ ic key )4 b . ots_typecode = strTou32 ( next 4 bytes of publ ic key )5 c . Se t m according to pubtype .6 d . I f the publ ic key i s not e x a c t l y 24 + m bytes long , re turn INVALID .7 e . I = next 16 bytes of the publ ic key8 f . T [ 1 ] = next m bytes of the publ ic key9 3 . Compute the LMS Publ ic Key Candidate Tc from the signature , message ,

i d e n t i f i e r , pubtype , and ots_typecode , using Algorithm 6a ( L i s t i n g 2 . 1 2in t h i s t h e s i s ) .

10 4 . I f Tc i s equal to T [ 1 ] , re turn VALID ; otherwise , re turn INVALID .

Listing 2.11: LMS Signature Verification [1]

To calculate the public key candidate Tc the LM-OTS signature from the LMS signatureneeds to be parsed and the LM-OTS public key candidate Kc can then be computed


according to the algorithm shown in Listing 2.8 [1]. With the computed LM-OTS publickey candidate Kc the LMS public key candidate Tc can be computed. For this process, thepath from the LMS signature is required to calculate the LMS root which gives the publickey candidate Tc. The algorithm for calculating the public key candidate Tc can be seen inListing 2.12 [1].

1 1 . I f the s ignature i s not a t l e a s t e i g h t bytes long , re turn INVALID .2 2 . Parse sigtype , q , lmots_signature , and path from the s ignature as fo l lows

:3 a . q = strTou32 ( f i r s t 4 bytes of s ignature )4 b . o t s s i g t y p e = strTou32 ( next 4 bytes of s ignature )5 c . I f o t s s i g t y p e i s not the OTS typecode from the publ ic key , re turn

INVALID6 d . Set n , p according to o t s s i g t y p e ; i f the s ignature i s not a t l e a s t 12

+ n * ( p + 1) bytes long , re turn INVALID .7 e . lmots_s ignature = bytes 4 through 7 + n * ( p + 1) of s ignature8 f . s ig type = strTou32 ( bytes 8 + n * ( p + 1) ) through 11 + n * ( p + 1) of

s ignature )9 g . I f s ig type i s not the LM typecode from the publ ic key , re turn INVALID .

10 h . Set m, h according to s ig type .11 i . I f q >= 2^h or the s ignature i s not e x a c t l y 12 + n * ( p + 1) + m * h

bytes long , re turn INVALID .12 j . Se t path as fo l lows :13 path [ 0 ] = next m bytes of s ignature14 path [ 1 ] = next m bytes of s ignature15 . . .16 path [ h−1] = next m bytes of s ignature17 3 . Kc = candidate publ ic key computed by applying Algorithm 4b ( L i s t i n g 2 . 8

in t h i s t h e s i s ) to the s ignature lmots_signature , the message , and thei d e n t i f i e r s I , q

18 4 . Compute the candidate LMS root value Tc as fo l lows :19 node_num = 2^h + q20 tmp = H( I || u32s t r ( node_num ) || u16s t r (D_LEAF) || Kc )21 i = 022 while ( node_num > 1) {23 i f ( node_num i s odd ) :24 tmp = H( I ||u32s t r ( node_num/2)||u16s t r (D_INTR) ||path [ i ]||tmp )25 e l s e :26 tmp = H( I ||u32s t r ( node_num/2)||u16s t r (D_INTR) ||tmp||path [ i ] )27 node_num = node_num/228 i = i + 1


29 }30 Tc = tmp31 5 . Return Tc .

Listing 2.12: LMS Public Key Candidate Generation [1]

2.2.4 Hierarchical Signature System

The hierarchical signature system uses several layers of LMS. NIST defined that HSSsupports between 1 and 8 levels of LMS [13]. The idea is that each LMS leaf, the LM-OTSkeys, sign the root of the next LMS tree. This means that an HSS key pair with just onelevel is equivalent to LMS. If HSS is used with more than one level it can speed up the keygeneration process for higher levels and also increases the number of possible signaturesto generate with just one HSS private key without reusing any LM-OTS private key. Onlythe LMS trees of the last level of the HSS key are used to sign messages. All previouslevels are used to sign the LMS trees of the next levels. If one uses a large LMS tree inthe first level and smaller LMS trees in all other levels this will drastically reduce the keygeneration time of all other levels and increase the possible number of signatures that canbe generated with that HSS key. For example, if an HSS private key with two levels isused where the first level uses an LMS tree of height 25 and the second level uses LMStrees of height 10, then the HSS private key has 225 LMS trees with a height of 10 and cansign up to 225 ∗ 210 = 34, 359, 738, 368 messages. To speed up the key generation process,only the most left LMS trees are computed initially. Every time an LMS tree is exhaustedonly the next tree on this level and on the next levels must be computed. If small LMStrees are used in the higher levels then this process does not require much time comparedto the larger trees in the top levels.

The HSS key pair generation is done by generating LMS key pairs according to the HSSlevels. These keys are stored in the HSS key pair. Each tree root, the public key, of higherlevels is then signed with the previous private key. The number of levels, the LMS publickeys, the LMS private keys, and the LMS signatures are then used as the HSS key pair.This algorithm can be seen in Listing 2.13 [1]. Each level can use different parameter setsbut the parameter sets in the same level must not be different.


1 1 . Generate an LMS key pair , p lac ing the p r i v a t e key i n t o priv [ 0 ] , and thepubl ic key i n t o pub [ 0 ]

2 2 . For i = 1 to L−1 do {3 generate an LMS key pair , p lac ing the p r i v a t e key i n t o priv [ i ] and

the publ ic key i n t o pub [ i ]4 s i g [ i −1] = lms_signature ( pub [ i ] , pr iv [ i −1] )5 }6 3 . Return u32s t r ( L ) || pub [ 0 ] as the publ ic key and the priv [ ] , pub [ ] , and

s i g [ ] arrays as the p r i v a t e key

Listing 2.13: HSS Key Pair Generation [1]

When generating a signature first a check is performed if the current LMS tree of thehighest level is exhausted. If it is exhausted the next LMS tree of that level must becomputed. In case all LMS trees on the highest level are exhausted the next LMS tree ofthe previous level must be computed and also the first LMS tree of the highest level. Thisprocess is done until all LMS trees of all levels are exhausted which means that the HSSkey is exhausted and cannot be used for any further signature generations. A message isthen signed with the next free key from an LMS tree of the highest HSS level. The signingof the message is done with the LMS signature generation algorithm shown in Listing2.10. The number of signed public keys, Nspk, the first signed public key, and if morethan one level are used, the next signed public keys and their signatures are appended tothe HSS signature. The general format of the HSS signature is as follows:

u32str(Nspk) || signed_pub_key[0] || ... || signed_pub_key[Nspk − 1] || sig[Nspk]

The algorithm for the HSS signature generation can be seen in Listing 2.14 [1].

1 1 . I f the message−signing key prv [ L−1] i s exhausted , regenera te t h a t keypair , toge ther with any parent key p a i r s t h a t might be necessary .

2 I f the root key pai r i s exhausted , then the HSS key pai r i s exhausted andMUST NOT generate any more s i g n a t u r e s .

3 d = L4 while ( prv [ d − 1 ] . q == 2^( prv [ d − 1 ] . h ) ) {5 d = d − 16 i f ( d == 0)7 re turn FAILURE8 }


9 while ( d < L ) {10 c r e a t e lms key pai r pub [ d ] , prv [ d ]11 s i g [ d−1] = lms_signature ( pub [ d ] , prv [ d−1] )12 d = d + 113 }14 2 . Sign the message .15 s i g [ L−1] = lms_signature ( msg , prv [ L−1] )16 3 . Create the l i s t of signed publ ic keys .17 i = 0 ;18 while ( i < L−1) {19 signed_pub_key [ i ] = s i g [ i ] || pub [ i +1]20 i = i + 121 }22 4 . Return u32s t r ( L−1) || signed_pub_key [ 0 ] || . . . || signed_pub_key [ L−2] ||

s i g [ L−1]

Listing 2.14: HSS Signature Generation [1]

To verify an HSS signature it is first parsed into its components. The HSS signature consistsof a signature chain. The signature chain holds all signatures of the several LMS treesused. To verify an HSS signature each of its LMS signatures must be verified. Thus, allsignatures in the chain are verified, and then the final signature that signs the messageis verified. If all signatures in the chain are valid then the HSS signature is valid. Thealgorithm for the HSS signature validation is shown in Listing 2.15 [1].

1 Nspk = strTou32 ( f i r s t four bytes of S )2 i f Nspk+1 i s not equal to the number of l e v e l s L in pub :3 re turn INVALID4 f o r ( i = 0 ; i < Nspk ; i = i + 1) {5 s i g l i s t [ i ] = next LMS s ignature parsed from S6 p u b l i s t [ i ] = next LMS publ ic key parsed from S7 }8 s i g l i s t [ Nspk ] = next LMS s ignature parsed from S9

10 key = pub11 f o r ( i = 0 ; i < Nspk ; i = i + 1) {12 s i g = s i g l i s t [ i ]13 msg = p u b l i s t [ i ]14 i f ( lms_ver i fy (msg , key , s i g ) != VALID) :15 re turn INVALID


16 key = msg17 }18 re turn lms_ver i fy ( message , key , s i g l i s t [ Nspk ] )

Listing 2.15: HSS Signature Verification [1]

2.3 Random Number Generation

Hash-based signature schemes make use of random number generators during key gener-ation and signature generation [1, 13]. Random numbers are required for the LMS key pairidentifier I, the n-byte strings of the LM-OTS private key, and the n-byte string C of theLM-OTS signature. To generate the n-byte strings of the LM-OTS private key and the LMSkey pair identifier, an RNG SEED must be used. The SEED shall be generated using anapproved random bit generator. The approved random bit generators are defined in [33]and their respective approved entropy sources are defined in [34]. The instantiation of therandom bit generators must support at least 128 bits of security [13].

If more than one LMS tree is used then for each LMS tree a new SEED must be generated.The generation of the n-byte strings of the LM-OTS private key must be generated usingthe given SEED and the pseudorandom key generation method shown in Appendix A ofRFC 8554 [1, 13]. With this pseudorandom key generation method, it is possible to storeonly the SEED instead of all n-byte keys which is a major memory saving because themethod ensures that the keys are pseudorandom and therefore, no keys have the samevalue and it allows to compute the keys deterministically on demand. With this approach,the n-byte strings of the LM-OTS private key are computed as:

x_q[i] = H(I || u32str(q) || u16str(i) || u8str(0x f f ) || SEED)

This approach requires one hash operation for each n-byte string of the LM-OTS privatekey. It is possible to improve the pseudorandom key generation method by providing adifferent SEED for each LM-OTS private key. In that case, no hash needs to be computedduring the LM-OTS private key generation because the different SEEDs already ensuredifferent strings. The identifier q of each LM-OTS private key is appended to the initialSEED and this SEED is then used p-times to generate the n-byte strings of the LM-OTS


private key. This approach reduces the number of required hash operations for eachprivate key from P to 1 which results in slightly faster key generations but keeping allbenefits from the pseudorandom key generation method described in RFC 8554 [1]. TheSEED for each LM-OTS private key can be computed as:

SEED_q = H(SEED || q)

This pseudorandom key generation method was implemented in this thesis.

2.4 Security Considerations

To keep the LMS and HSS algorithm secure there are a few security considerations thatneed to be taken care of. These considerations are requirements for hash-based signatureschemes and are discussed in this section.

2.4.1 One-Time Signature Key Reuse

As mentioned in the theory of this thesis, Chapter 2.2.3, it must be ensured that no one-timesignature key is reused. Reusing such a key could weaken the security of the algorithmand make it feasible for an attacker to forge a signature [13, 35]. To ensure that no OTS keyis reused the state of the private key must be managed. This is where the stateful in theirname comes from. In the theory Chapter 2.2.2, it was mentioned that each OTS key hasone unique identifier q. The next identifier q of the next unused OTS key is stored in theLMS private key. This identifier is the state of the LMS private key. Every time a messageis signed the identifier q must be incremented so that it points to the next unused OTSkey [1]. If the private key is kept in volatile memory it must also be stored in non-volatilememory to keep the state even if the application exits or crashes. Otherwise, an attackercould intentionally try to crash the application and manage that the signer will reuse anOTS key. This requires also that every time the state of the private key changes, the keymust also be updated in non-volatile memory [35]. To reduce the number of such updatesone possible approach is to reserve a number of OTS keys before they can be used forsigning messages. When reserving such keys the future state of q needs to be written to


non-volatile memory. If then the application crashes and not all reserved keys were used,they are lost and can never be used again.

For example, if there are 32 keys available in an LMS tree. Before signing the first messagethe q identifier of the LMS tree is 0. The consumer then reserves 10 keys which willimmediately store the private key to non-volatile memory with its q identifier set to 10.Now the consumer signs 4 messages and then the application crashes for some reason.When the private key is loaded from non-volatile memory on the next application start, ithas its q identifier set to 10. Therefore, the keys with identifiers 4 to 9 will never be used.

Leon G. Bruinderink and Andreas Hülsing [9] show in their paper how the security ofOne-Time signature schemes degrades when reusing the same OTS key. How fast thesecurity degrades depends on the used OTS scheme. Lamport’s [7] scheme securitydegrades slowly with OTS key reuse whereas the security of the Winternitz OTS schemedegrades faster.

2.4.2 Hash Collisions

The security of hash-based signature schemes does not depend on any hard-to-solvemathematical problems but depends solely on the security of the used hash function [1, 13,6]. Therefore, it is important that those hash functions have a high collision resistance. Itmust be ensured that an attacker cannot find two distinct messages with the same messagedigest [13]. This could be done either by looking for a message that has the same messagedigest as an already signed message. This is a so-called second preimage [36] or by findingtwo distinct messages that result in the same message digest, a so-called generic collision,and letting the private key holder sign one of these messages. The security properties [13,37] of the recommended hash functions for LMS and HSS are very strong e.g., SHA-256and SHAKE-256. Their respective 192-bit counterparts are weaker but their securityproperties still make it very hard for an attacker to find a collision or second preimage.To find a collision an attacker needs up to 2128 inputs to find a collision for SHA-256 andonly 296 inputs for SHA-256/192. Besides the security properties of the underlying hashfunction, LMS uses randomized hashing to make it infeasible for an attacker to find ageneric collision. With randomized hashing, a random value is appended to the messagebefore signing.


2.4.3 Key Revocation

In case that the private key owner detects any potential problems with his private key itshould be possible to revoke that key [38]. In general, it must not be possible to reuse anyOTS keys but if there is a bug in the implementation this could still be possible and it isnot guaranteed that all implementations are bug-free. For such a case the implementationshould support the possibility to remediate the issue by allowing the key holder to revokeits key. In the example of LMS and HSS private keys, the key revocation could be done bysimply reserving all keys and reloading the updated key from non-volatile memory. Thekey will be exhausted after that and can not be used for any message signatures anymorewhen the state management of the keys is implemented correctly.

2.5 LMS Security Proof

In cryptography security proofs of algorithms are often done with the help of a random-oracle model [39]. The random-oracle model imitates the hash functions used in thealgorithms. Therefore, it can also be used to prove the security of LMS. Jonathan Katz [11]analyzed the LMS security and proved its security with the random-oracle model. Whenusing LMS in a post-quantum world then this proof is not sufficient anymore [6]. EdwardEaton proved the LMS security using the quantum random-oracle model. In the experi-ments with the random-oracle model, an attacker is given a set of strings with the hashtargets. The attacker then wants to find one or more strings with the same hash targets.In [11] an upper bound on the attacker’s ability to find such first or second preimages isproven. The same proofs are done in the quantum random-oracle model in [6]. Furtheranalysis of these proofs and the hash-based signature schemes were also done by ScottFluhrer [40].


3 Implementation

This chapter contains all details of the Java program implemented within this thesis. Itstarts with the used technologies and third-party libraries and continues with detailsabout LM-OTS and how it can be used, goes over to the LMS implementation details, andends with HSS implementation details. This chapter contains also various problems thatwere faced during implementing this application and also the found solutions to thoseproblems. It is also stated how the application was tested and how the program can beused from a consumer perspective.

The source code can be found on GitHub: https://github.com/AndiCover/lms_hss.

3.1 Used Technologies

In this section, the technologies that were used in the development process are mentioned.Some of the tools are required for the development itself and others are needed to ensurethat the source code stays clean and in a good shape. Also, the tools used for testing andbenchmarking are mentioned.

The program is written in Java with JDK 15 [41]. For building and dependency manage-ment the chosen tool is Gradle [42] because it is state-of-the-art and makes the managementof external dependencies very easy. It is not only used for building the project and manag-ing external dependencies but also to use several plugins to perform static code analysis onthe source code. In combination with GitHub workflows, this can be done automaticallyfor each push to the repository which provides instant feedback about the current qualitystate of the source code.

Following the list of used plugins and relevant external dependencies including theirversion:


https://github.com/AndiCover/lms_hss

• Checkstyle: 8.29

• Spotbugs: 4.7.0

• PMD: 6.33.0

• CPD: 6.6.0

• JaCoCo: 0.8.6

• keccakj: 1.1.0

• JUnit: 5.7.1

• JMH: 1.29

Checkstyle [43] is a tool to perform several static code analysis checks to maintain theformat and quality of the source code. It is used in many state-of-the-art projects and canreally improve the readability and the overall quality of the source code. When addingthe Checkstyle plugin to the project, Gradle will automatically create a Checkstyle task foreach source set e.g., main. In this project, those tasks were merged into one task with thefollowing code:

1 task c h e c k s t y l e {2 dependsOn ’ checkstyleMain ’3 dependsOn ’ checks ty leTes t ’4 dependsOn ’ checkstyleJmh ’5 }

Listing 3.1: Gradle Checkstyle Task

The resulting task will execute the three depending tasks and therefore, perform thequality checks on all source sets of the project. It is a good idea to have the same standardson test code as on the production code. The task can be run with Gradle as follows:

./gradlew checkstyle

If the task fails it provides information about the source code that does not meet therequirements with location and the violated Checkstyle rule.


Spotbugs [44] is a tool used to perform static code analysis on byte code level to findpotential bugs in Java applications. Using this tool can help to find bugs that were notthought of when implementing the program which improves the quality of the application.When adding the plugin to the project Gradle will automatically create a Spotbugs taskfor each source set. Those tasks were merged into one task identical to the Checkstyletasks but with one additional change that the Spotbugs task does not need to run for theJMH source set:

1 task spotbugs {2 dependsOn ’ spotbugsMain ’3 dependsOn ’ spotbugsTest ’4 dependsOn ’ spotbugsJmh ’5 }6 spotbugsJmh . o n l y I f { f a l s e }

Listing 3.2: Gradle Spotbugs Task

The reason for disabling Spotbugs for the JMH source set is that this source set containsthe Java benchmarks and consists of a lot of auto-generated code which results in a lot ofviolations. The tasks can be run with Gradle as follows:

./gradlew spotbugs

PMD [45] is a tool very similar to Spotbugs but the code analysis is performed on thesource code and not on the generated byte code. It is a great addition to Spotbugs and canalso help to find potential bugs in the application. Similar to the other plugins a Gradletask is added to the project when including the plugin. Those tasks are merged into onetask as done with the Checkstyle tasks.

CPD [46] is a tool to detect duplicate code in a project. This can make the source codeclearer and also reduce the likelihood to introduce new bugs if code is adapted becauseoften changes are only made on one part of the source code and are forgotten for itsduplicate sibling. When having no duplicates this is not possible.


JaCoCo [47] is a tool that measures the code coverage when running unit tests. Itprovides an HTML report that contains an overview of how much code or how manylines of the source code are covered by unit tests. The report even provides informationfor each line of source code and all possible branches. It is very helpful to figure out whatwas definitely not tested and can therefore help to increase the code coverage on relevantparts of the source code.

Keccakj [48] is a Java library that provides several cryptographic implementations e.g.,SHA3-256 and SHAKE-256. This library is used because the default Java Virtual Machine(JVM) security providers do not need to support SHAKE-256 [49].

JUnit [50] is the tool that is used for unit testing the application. It is very common andused in most Java applications for unit testing.

JMH [51] is used for building and running Java benchmarks. It handles all the prerequi-sites for Java benchmarking e.g., JVM warm-up. Warming up the JVM is a requirementto get comparable results for Java benchmarks because the Just-In-Time Compiler (JIT)adapts the bytecode during runtime to optimize the program. This process can takeseveral iterations and can be easily configured using JMH. The tool also allows to easilymeasure the runtimes in nanoseconds and provides a meaningful report at the end. Thebenchmarks can be executed with the following Gradle task:

./gradlew jmh

Note that running all benchmarks of this project will take several hours to complete.

3.2 Common Utilities

For the implementation of LM-OTS, LMS, and HSS there are two interfaces KeySize andStorable which are implemented by all private key, public key, and signature models. Thereare also several utility classes which are explained below.


KeySize This interface defines one common method int calculateSize() which returns thelength of the current key or signature.

Storable This interface defines two methods:

• byte[] getBytes(): Returns the key as byte array, which can then be used to store theobject to disk. This method might throw an OutOfMemory exception if the object isvery large e.g., LMS private key or HSS private key.

• void writeToPipedOutputStream(PipedOutputStream outputStream): This method is usedto write chunks of the object to an output stream which is concurrently written todisk (Producer-Consumer pattern). This allows it to store even large objects to disk.

Defaults This class contains all default settings for the entire application which are:

• int DEFAULT_KEY_RESERVE_COUNT = 20: Defines how many LM-OTS keysshould be reserved by default.

• RANDOM_NUMBER_ALGORITHM = "SHA1PRNG": Defines the default randomnumber generation algorithm. It must support deterministic random numbersdetermined by a given SEED [52].

• CACHE_TIMEOUT = 60_000: Defines the default timeout of message digest cacheentries in milliseconds.

• MAX_CACHE_ENTRIES: Defines the default limit of message digest entries in thecache.

• DEFAULT_OUTPUT_BUFFER = 16_384: Defines the size of the output buffer for theasynchronous writing to disk.

• STORED_TOP_LEVEL_NODES = 65_535: Defines how many of the pre-calculatedtop-level hashes of the LMS tree are kept in memory. Currently, these are the first 15levels that require about 2 MB of memory.

• THREAD_COUNT = 16: Defines how many threads are used in the thread pool.


To improve the overall LMS key generation performance, especially with multiple threads,a dedicated cache is used that stores MessageDigest instances for each thread. Thoseinstances are used when hashing arbitrary strings or byte arrays. This cache significantlyreduces the MessageDigest instance creations during any key generation. All relevantclasses are located in the digest package of the project.

CustomMessageDigest is an interface that contains the digest method and the fourdifferent hash algorithm identifiers:

• SHA_256 = "SHA-256";

• SHA_256_192 = "SHA-256/192";

• SHAKE_256 = "SHAKE256";

• SHAKE_256_192 = "SHAKE256/192";

The two classes CustomSha256Digest and CustomShakeDigest implement that interface.Both return either a 24 byte or a 32 byte hash string depending on the chosen algorithm.The difference is that CustomSha256Digest internally uses the SHA-256 implementationprovided by the JVM security provider and CustomShakeDigest uses the Shake256 spongefrom the keccakj library. Both classes are package-private because they are not intendedto be used directly. Internally there exists a factory CustomMessageDigestFactory whichcreates a new instance depending on the given algorithm. This factory is also not publiclyaccessible because it is only used by the cache and it ensures that all instances are createdthrough the cache.

MessageDigestCache This is the cache that provides the CustomMessageDigest instancesfor each thread. It is a simple cache that is implemented as a singleton to ensure that thereis only one cache available for the entire application. It has exactly one public method tofetch an instance from the cache getMessageDigest(String algorithm). The consumer simplyprovides the algorithm identifiers which are defined in CustomMessageDigest and receivesthe dedicated instance. If the cache already has the wanted instance available (cache-hit)it simply returns it and if it does not (cache-miss) it will create a new instance using the


CustomMessageDigestFactory. All stored instances are mapped to the requesting thread id.This allows us to have an equal instance for each thread but there are no synchronizationissues when using the instances to hash arbitrary strings with more than one thread. Thistechnique improves the performance significantly for LMS and HSS. All cache entrieshave a timeout of 60 seconds which is updated after each usage. The cache has a totallimit of 200 entries and the cache gets cleared if this limit is reached. The limit is just asoft limit because it does not perform any locking. It is therefore possible, that more than200 elements are in the cache but only for a very short time. It is also not expected thatthis limit is reached that often because in most applications the used algorithm will bethe same and also the threads won’t change that much. Should this become a problemanyway then it would make sense to increase the limit or implementing a different cacheclean-up strategy e.g., removing only outdated cache entries.

Commonly used methods are separated into so-called utility classes which provide one ormore methods that can be used from everywhere in the program. These six utility classesare described below:

• ByteUtil

• KeySizeUtil

• MathUtil

• PersistenceUtil

• SecurityString

• ThreadUtil

ByteUtil provides several methods to make handling with bytes easier and to improvethe performance. It contains methods to convert integer values to byte arrays with logicalshift operations and vice-versa. This is relevant for the hash operations where only stringsor byte arrays can be provided. The class contains also several methods to merge two ormore byte arrays in one large byte array containing both input arrays. These methods arealso used for the hash operations where always a byte array is expected.


KeySizeUtil provides methods that return the expected key size of a key or signature.This class does not generate the key and return its length but instead, it calculates the keysize. Some of these methods are used to allocate the correct array lengths when initializingobjects. Nevertheless, the class contains such a method for each key or signature type, andthey are used in unit tests and have the purpose to figure out the different key sizes whichcan be seen in Chapter 5.2 of this thesis.

MathUtil provides a method to calculate the n-th power of 2. It calculates it by using nleft shifts which is faster than calculating it using Math.pow(). In most cases, it does notmake a real difference because the JIT compiler improves the instructions after a shorttime but it slightly improves the first calls.

PersistenceUtil provides methods to load and store any key from and to disk. To store anobject on disk the consumer needs to provide the object and the filename. Storing is donewith two threads (Producer-Consumer pattern). One thread reads chunks (from 1 byte upto 16 Kb) of the object and writes it to a small buffer. The second thread continuously readsfrom that buffer and writes to the disk. This is much faster than writing those chunksdirectly to disk and reduces the memory overhead when storing objects drastically.

When loading a key from disk this process is done in reversed order. One thread reads thecontent of the file into a 16 Kb buffer and the second threads reads the required chunksfrom that buffer and constructs the objects.

SecurityString holds all the security strings provided in RFC 8554 Chapter 7.1 Securitystring [1]: D_PBLC, D_MESG, D_LEAF, and D_INTR.

ThreadUtil provides methods for handling thread pools. It allows to create a thread pooland also provides a method that takes care of shutting down the given thread pool. Bothmethods are used in different places of the application and therefore, extracting this codeinto a utility class reduces duplicate code.


3.3 Signature Schemes

3.3.1 Leighton-Micali One-Time Signature

The LM-OTS part is separated into an API package and an implementation package. TheAPI defines the interfaces of the private key, the public key, and the signature. Thoseinterfaces are visible to the consumer. The implementations of those interfaces are notvisible to the consumer and therefore, all implementation details are hidden. Additional tothose interfaces the API package contains the enum of the LM-OTS parameter sets whichthe consumer requires.

LMOTSPrivateKey is an interface that contains all methods that are required by eitherthe consumer or the LMS implementation. It extends the interfaces Storable and KeySizeand defines the following methods for the LM-OTS private key:

• byte[][] getKeys(): Returns all keys of the private key

• byte[] getIdentifier(): Returns the 16 byte identifier for the LMS public/private keypair

• int getQIdentifier(): Returns the leaf number q of the hash tree

• byte[] getSeed(): Returns the n-byte SEED for the random number generator

• LMOTSType getLmotsType(): Returns the used LM-OTS parameter set

LMOTSPublicKey is an interface that contains all methods that are required by either theconsumer or the LMS implementation. It extends the interfaces Storable and KeySize anddefines the following methods for the LM-OTS public key:

• byte[] getKey(): Return the public key K.





LMOTSSignature is an interface that contains all methods that are required by either theconsumer or the LMS implementation. It extends the interfaces Storable and KeySize anddefines the following methods for the LM-OTS signature:

• byte[][] getKeys(): Returns all keys of the signature

• byte[] getC(): Returns the n-byte randomizer that is included with the messagewhenever it is being hashed to improve security


LMOTSType is the enum that holds all LM-OTS parameter sets that are defined in Table2.1 in Chapter 2.2.1 of this thesis. Not all LM-OTS parameter sets have gotten a numericidentifier assigned by NIST. The used LM-OTS parameter set identifiers in this workmight not comply with the identifiers assigned by NIST in the future. For the undefinedidentifiers, the next free numbers were chosen in this work. The used identifiers can befound in the appendix of this thesis.

LMOTSPrivateKeyImpl is a class that implements the interface LMOTSPrivateKey andholds one LM-OTS private key. It has the following four members:

• LMOTSType lmotsType: The used LM-OTS parameter set

• byte[] identifier: The 16 byte identifier for the LMS public/private key pair

• int qIdentifier: The leaf number q of the hash tree

• byte[] seed: The n-byte SEED for the random number generator

This class contains almost no special logic because it acts as a model class. Though thegetKeys() method defined in its interface, this class calculates the private keys on-demandusing the stored SEED and a random number generator. This reduces the memoryfootprint of the LM-OTS private key object significantly because it needs the memoryonly when generating a signature. Depending on the used parameter set the memory


saving can be up to 8.480 byte per object. The resulting size of an LM-OTS private keyobject depends on the used LM-OTS parameter set and is either 48 byte or 56 byte plusthe JVM object overhead e.g., 16 byte [53]. The large LM-OTS private key size was onemajor problem in the first draft of this work because it did not allow larger LMS trees.One would need up to 285 GB for one large LMS private key.

Note: The memory savings are a requirement to be able to handle larger LMS trees but itrequires more computational effort when generating a signature.

LMOTSPublicKeyImpl is a class that implements the interface LMOTSPublicKey andholds one LM-OTS public key. It has the following four members:




• byte[] key: The n-byte public key K

This class does not contain any logic because it acts as a model class. The resulting size ofan LM-OTS public key depends on the used LM-OTS parameter set and is either 48 byteor 56 byte.

LMOTSSignatureImpl is a class that implements the interface LMOTSSignature and holdsone LM-OTS signature. It has the following three members:

• byte[][] keys: The keys of the signature


• byte[] c: The n-byte randomizer that is included with the message whenever it isbeing hashed to improve security.

This class does not contain any logic because it acts as a model class. The resulting size ofan LM-OTS signature depends on the used LM-OTS parameter and is between 652 byteand 8516 byte.


LMOTS is the main class of the LM-OTS implementation. It is public and providesseveral methods to generate private keys, public keys, signatures, and methods to validatesignatures. This class is thread-safe and annotated as such.

For LM-OTS private key generation exist three methods with different parameters. Theconsumer can choose between them depending on his needs. In general, if an RNG SEEDis provided for key generation this SEED will be used to generate the private keys. If noSEED is provided then a new SEED will be fetched from the RNG pool of the operatingsystem and stored in the private key. The private key generation methods return anLMOTSPrivateKey instance.

For LM-OTS public key generation exists one method which requires an LM-OTS privatekey. This method calculates the LM-OTS private key from the LM-OTS public key andreturns an LMOTSPublicKey instance. The logic of that method is algorithm 1 from RFC8554 and can be seen in Listing 2.3.

For LM-OTS signature generation exist two methods that make it easier for the consumer.One method takes the message as a byte array and the other one as a string. Both methodsrequire an LM-OTS private key. The logic of that method is algorithm 2 and algorithm 3from RFC 8554 and can be seen in Listings 2.4 and 2.6.

Two methods also exist for LM-OTS signature verification where one takes the messageas a byte array and the other as a string. The logic of that method is algorithm 4a andalgorithm 4b from RFC 8554 and can be seen in Listings 2.7 and 2.8.

All overloaded methods of this LM-OTS implementation are chained to reduce duplicatecode and make the code easier to read and test.

This LM-OTS implementation can be used without LMS and can therefore, be reused insimilar applications in the future. The usage of the class is held as simply as possible andshown below.

The following command shows how an LM-OTS private key with the LM-OTS parameterset LMOTS_SHA256_N32_W8 can be generated:

1 LMOTSPrivateKey privateKey = LMOTS. generatePrivateKey (LMOTS_SHA256_N32_W8) ;

Listing 3.3: LM-OTS Private Key Generation


The generated private key is then needed to generate the corresponding public key:

1 LMOTSPublicKey publicKey = LMOTS. generatePublicKey ( privateKey ) ;

Listing 3.4: LM-OTS Public Key Generation

The private key is also needed for signature generations of a given message:

1 LMOTSSignature s ignature = LMOTS. generateS ignature ( "A t e x t " , privateKey ) ;

Listing 3.5: LM-OTS Signature Generation

Verifying the generated signature can be done with the public key, the signature, and theoriginal message:

1 boolean va l id = LMOTS. v e r i f y S i g n a t u r e ( "A t e x t " , s ignature , publicKey ) ;

Listing 3.6: LM-OTS Signature Generation

Note: The LM-OTS private key must be used for not more than one signature.

3.3.2 Leighton-Micali Signature

Like the LM-OTS part also the LMS part is separated into API and implementationpackages. The API package is quite similar and provides the interfaces of the keys andthe LMS parameter sets. Those interfaces are then implemented in the respective key andsignature classes in the implementation package. The interfaces and classes are describedin this section.

LMSKeyPair is an interface that contains two methods, one to get the LMS private keyand the other one to get the LMS public key.


LMSPrivateKey is an interface that contains all methods that are required by either theconsumer or the HSS implementation. It extends the interfaces Storable and KeySize anddefines the following methods for the LMS private key:

• LMSType getLmsType(): Returns the used LMS parameter set




• LMOTSPrivateKey getNextLmotsKey(): Returns the next unused LM-OTS private key.Throws an exception if no unused keys are available

• byte[][] getPath(int nodenumber): Calculates the path for the LMS signature. Theparameter nodenumber is the number of the used LM-OTS private key in the LMStree

• boolean isExhausted(): Returns true if all LM-OTS keys were used

• void reserveKeys(int numberOfKeys): This method can be used to reserve a few LM-OTS private keys and is relevant for the HSS implementation. Reserving keys isrequired to ensure that no LM-OTS key is reused. Whenever the consumer reservesLM-OTS private keys the LMS private key will be updated and stored on disk. Thenumber of total reserved keys will act as the new q identifier when loaded from thedisk. This means that in case of an application crash all unused keys are lost andcan’t be used but this makes sure that even after an application crash no key is usedtwice. The consumer should not reserve all keys because after an application crashno keys will be available to sign messages. This is a very important function to keepthe application secure

• int getReservedKeys(): Returns the number of reserved keys that is left. If this methodreturns zero the consumer need to reserve new OTS keys

• boolean hasReservedKey(): Returns true if at least one LM-OTS key is reserved

• byte[] calculateRoot(LMOTSPublicKey[] lmotsPublicKeys): This method calculates theLMS tree root which is the public key K


LMSPublicKey is an interface that contains all methods that are required by either theconsumer or the HSS implementation. It extends the interfaces Storable and KeySize anddefines the following methods for the LMS public key:




• byte[] getKey(): Returns the LMS public key

LMSSignature is an interface that contains all methods that are required by either theconsumer or the HSS implementation. It extends the interfaces Storable and KeySize anddefines the following methods for the LMS signature:



• LMOTSSignature getLmotsSignature(): Returns the associated LM-OTS signature

• byte[][] getPath(): Returns the path to the root of the LMS tree

LMSType is the enum that holds all LMS parameter sets that are defined in Table 2.2 inthe theory Chapter 2.2.1 of this thesis. Not all LMS parameter sets have gotten a numericidentifier assigned by NIST. The used LMS parameter set identifiers in this work might notcomply with the identifiers assigned by NIST in the future. For the undefined identifiers,the next free numbers were chosen in this work. The used numeric identifiers can befound in the appendix of this thesis.

LMSKeyPairImpl is a class that implements the interface LMSKeyPair. It holds exactlyone LMS private key and one LMS public key.


LMSPrivateKeyImpl is a class that implements the interface LMSPrivateKey and holdsone LMS private key. It has the following eight members:

• LMOTSPrivateKey[] lmotsPrivateKeys: The set of LM-OTS private keys

• byte[][] leafNodes: The leaf nodes of the LMS tree

• byte[][] topLevelNodes: The top-level nodes of the LMS tree. Currently the first 15levels of the LMS tree are stored here which reduces the time needed for signaturegenerations because those nodes do not need to be recomputed every time



• int reservedKeys: The number of reserved keys that are still available


• LMSType lmsType: The used LMS parameter set

This class contains some logic in three of its methods, byte[] calculateRoot(LMOTSPublicKey[]lmotsPublicKeys), byte[][] getPath(int nodeNumber), and byte[][] buildTree(int keys). Themethod calculateRoot is called once at the end of the LMS public key generation. It returnsthe root of the LMS tree, the LMS public key. Additionally, it stores the hashes of the leafnodes in the LMS private key and also stores the hashes of the top-level nodes which areneeded later for signature generation. Therefore, it must be ensured that this method iscalled once before generating a signature. The methods getPath and buildTree calculate thepath from one node to the root of the LMS tree. The logic is described in appendix D ofRFC 8554 and can be seen in Listing 2.10. To keep the algorithm simple, this method uses aqueue to store the keys instead of a simple array. The queue size is 2h entries large, whereh is the height of the LMS tree. It is initialized with the hashes of the LM-OTS private keysand always the next two entries are used for calculating the parent hash in the LMS tree.Therefore, the queue size shrinks eventually to a size of one. The last entry is then theLMS tree root, the LMS public key. This algorithm can be seen in Listing 3.7.


1 keys = 2^h ;2 nodes = keys * 2 − 1 ;3 f o r ( i n t i =nodes ; r >= 1 ; r −−) {4 keyIndex = i − keys ;5 i f ( i >= keys ) {6 hash = SHA−256( getLmotsPublicKey ( keyIndex ) ) ;7 queue . add ( hash ) ;8 } e l s e {9 r i g h t = queue . p o l l ( ) ;

10 l e f t = queue . p o l l ( ) ;11 hash = SHA−256( l e f t || r i g h t ) ;12 queue . add ( hash ) ;13 }14 }15 re turn queue . p o l l ( ) ;

Listing 3.7: LMS Calculate Root

The methods getNextLmotsKey() and reserveKeys(int numberOfKeys are synchronized so thatonly one thread can access it at a time. This ensures that each thread definitely gets adifferent LM-OTS private key and therefore, prevents LM-OTS key reuse during runtime.Because the methods do not perform heavy computations the synchronization of thosemethods does not have much effect on the performance of the program.

Depending on the used LM-OTS parameter set and LMS parameter set the size of the LMSprivate key object is between 1564 byte and 1.9 GB plus the JVM object overhead e.g., 16byte [53]. It would be possible to drastically reduce the size of the private key (down toa max size of about 800 MB) if only one SEED would be stored in the LMS private keyinstead of one SEED in each LM-OTS private key but this approach would make it harderor even infeasible to efficiently use multiple threads for key generation.

LMSPublicKeyImpl is a class that implements the interface LMSPublicKey and holds oneLMS public key. It has the following four members:

• LMSType lmsType: The used LMS parameter set




• byte[] key: The public key K

This class does not have any special logic. Depending on the used LMS parameter set thesize of the LMS public key object is either 48 byte or 56 byte plus the JVM object overheade.g., 16 byte [53].

LMSSignatureImpl is a class that implements the interface LMSSignature and holds oneLMS signature. It has the following four members:

• LMSType lmsType: The used LMS type


• LMOTSSignature lmotsSignature: The LM-OTS signature of this LMS signature

• byte[][] path: The LM-OTS private key path to the LMS tree root

This class does not have any special logic. Depending on the used LM-OTS parameter setand LMS parameter set the size of the LMS signature object is between 780 byte and 9324byte plus the JVM object overhead e.g., 16 byte [53].

LMS is the main class of the LMS implementation. It is public and provides severalmethods to generate key pairs, signatures, and methods to validate signatures. This classis thread-safe and annotated as such.

The key generation method takes the LMS parameter set and LM-OTS parameter set andan optional RNG SEED as arguments. It calculates the LMS private and public key pairand returns an instance of LMSKeyPair. It calculates 2h LM-OTS private keys and theirrespective LM-OTS public keys. The logic of that method is described in algorithm 5 ofRFC 8554 which can be seen in Listing 2.9. The calculation of the LM-OTS key pairs isdone with multiple threads to significantly improve the LMS key generation. The mainthread creates a thread pool with 16 threads and enqueues a task for each LM-OTS keypair. Each task needs to start with a different RNG SEED calculated from the main RNGSEED to have different LM-OTS keys. This was one major performance problem forweaker LM-OTS parameter sets because for each task the main thread needs to calculate


the starting SEED. Calculating the SEED for the next task is done by iteratively updatingthe main SEED. This process takes some time depending on the used LM-OTS parameterset. For weaker LM-OTS parameter sets the SEED update for 16 tasks took longer thanthe 16 tasks themselves and therefore, the threads needed to wait. Many experimentswere performed to find an appropriate solution. The solution that finally improved theperformance for all parameter sets is to use the main SEED and append the q identifierof the LMS node and hash the result to get a new SEED with a length equal to the mainSEED e.g., H(SEED || q). This process is much faster than updating the same SEED butalso ensures that no key in the LM-OTS private key gets the same SEED and therefore thesame random number. This is also described in Section 2.3 of this thesis. This approachmade this implementation faster than the C implementation of RFC 8554 [1] as can be seenin Chapter 5.

The LMS signatures can be generated using the private key and either the message asbyte array or string. It retrieves the next unused LM-OTS private key and creates anLM-OTS signature with that key and the given message. It then generates the path fromthe LM-OTS private key to the root of the LMS tree and creates the LMS signature withthat information.

The signature verification can also be done with the message as byte array or string. Itperforms the logic from algorithm 6 and algorithm 6a of RFC 8554 which can be seen inListing 2.11 and 2.12.

This LMS implementation can be used without HSS and can therefore be reused in similarapplications in the future. The usage of the class is held as simple as possible and shownbelow.

The following command shows how an LMS key pair with the LM-OTS parameter setLMOTS_SHA256_N32_W8 and the LMS parameter set LMS_SHA256_M32_H15 can begenerated:

1 LMSKeyPair keys = LMS. generateKeys (LMS_SHA256_M32_H5 , LMOTS_SHA256_N32_W8) ;

Listing 3.8: LMS Key Pair Generation


The generated key pair contains the private key and the public key. The private key isthen used to generate an LMS signature which is shown below:

1 LMSSignature s i g = LMS. generateS ignature ( "A t e x t " , keys . getPrivateKey ( ) ) ;

Listing 3.9: LMS Signature Generation

The resulting signature can then be verified using the LMS public key and the originalmessage as shown below:

1 boolean va l id = LMS. v e r i f y S i g n a t u r e ( "A t e x t " , s ig , keys . getPublicKey ( ) ) ;

Listing 3.10: LMS Signature Verification


The HSS part is also separated into API and implementation packages. The API packagecontains the interfaces for the HSS keys. The classes in the implementation packageimplement these interfaces and provide the public methods for HSS key generation,signature generation, and signature verification. The interfaces and classes are describedin this section.

HSSKeyPair is an interface that contains two methods, one to get the HSS private keyand the other one to get the HSS public key.

HSSPrivateKey is an interface that contains all methods that are required by the con-sumer. It extends the interfaces Storable and KeySize and defines the following methodsfor the HSS private key:

• int getLevels(): Returns the number of LMS levels. Possible values are integersbetween 1 and 8

• LMSPrivateKey[] getLmsPrivateKeys(): Returns the list of LMS private keys


• LMSPublicKey[] getLmsPublicKeys(): Returns the list of LMS public keys

• LMSSignature[] getSignatures(): Returns the list of LMS signatures

• String getFilename(): Returns the filename of the HSS private key. If the filename isnull the key will not be stored to disk

• void reserveKeys(int numberOfKeys): Allows the consumer to reserve several keys. Thefuture state is immediately saved on disk

• int getReservedKeys(): Returns the number of unused reserved keys. If this methodreturns zero the consumer needs to reserve more keys

HSSPublicKey is an interface that contains two methods that are required by the con-sumer. It extends the interfaces Storable and KeySize and defines the following methodsfor the HSS public key:

• int getLevels(): Returns the number of LMS levels. Possible values are integersbetween 1 and 8

• LMSPublicKey getPublicKey(): Returns the LMS public key

HSSSignature is an interface that contains all methods that are required by the consumer.It extends the interfaces Storable and KeySize and defines the following methods for theHSS signature:

• int getNumberOfSignedPublicKeys(): Returns the number of signed LMS public keysin the signature chain

• LMSSignature[] getSignatures(): Returns the LMS signatures in the signature chain

• LMSPublicKey[] getLmsPublicKeys(): Returns the LMS public keys in the signaturechain

HSSKeyPairImpl is a class that implements the interface HSSKeyPair. It holds exactlyone HSS private key and one HSS public key.


HSSPrivateKeyImpl is a class that implements the interface HSSPrivateKey and holdsone HSS private key. It has the following five members:

• int levels: The number of LMS levels

• LMSPrivateKey[] lmsPrivateKeys: The set of LMS private keys

• LMSPublicKey[] lmsPublicKeys: The set of LMS public keys

• LMSSignature[] lmsSignatures: The set of LMS signatures

• String filename: The name of the file where the HSS private key will be stored

This class does not have any special logic. Depending on the used levels, LM-OTSparameter set, and LMS parameter set the size of the HSS private key object is between2396 byte and 15.04 GB plus the JVM object overhead e.g., 16 byte [53]. More details aboutthe key sizes can be found in Chapter 5.2 of this thesis.

HSSPublicKeyImpl is a class that implements the interface HSSPublicKey and holds oneHSS public key. It has the following two members:

• int levels: The number of LMS levels

• LMSPublicKey rootPublicKey: The root public key of the LMS tree

This class does not have any special logic. Depending on the used LMS parameter set thesize of the HSS public key object is either 52 or 60 byte plus the JVM object overhead e.g.,16 byte [53].

HSSSignatureImpl is an class that implements the interface HSSSignature and holds oneHSS signature. It has the following three members:

• int numberOfSignedPublicKeys: The number of signed public keys in the signaturechain

• LMSSignature[] lmsSignatures: The set of LMS signatures in the signature chain

• LMSPublicKey[] lmsPublicKeys: The set of LMS public keys in the signature chain


This class does not have any special logic. Depending on the used levels, LM-OTSparameter set, and LMS parameter set the size of the HSS signature object is between 784byte and 75 Kb plus the JVM object overhead e.g., 16 byte [53].

HSS is the main class of the HSS implementation. It is public and provides severalmethods to generate key pairs, signatures, and methods to validate signatures. This classis thread-safe and annotated as such.

For HSS key generation there exist several methods with different parameters which canbe used depending on the needs. Basically, there are two main differences. It is possible tocreate multiple LMS levels where each level has the same LMS parameter set or multipleLMS levels where the LMS parameter set of the first level is different from the other levels.Having smaller LMS trees in the higher levels of the tree allows it to generate a new LMStree much faster if one’s keys are exhausted. With a large LMS tree at the top level, it ispossible to have a very large number of keys. The logic of this method is described inalgorithm 7 of RFC 8554 and can be seen in Listing 2.13.

As well as for LM-OTS and LMS there are two methods for signature generation. One thattakes the message to be signed as byte array and the other one as a string. The logic ofthat method is described in algorithm 8 of RFC 8554 and can be seen in Listing 2.14..

The signature verification is very simple compared to some other methods. It takes themessage either as byte array or as a string, the HSS signature, and the HSS public key. Itverifies then all LMS signatures in the signature chain. If all signatures are valid the HSSsignature is valid.

The main part of this implementation is HSS. The usage of HSS is held as simple as possibleand shown below. The following command shows how an HSS key pair can be generated.For the generation the LM-OTS parameter set LMOTS_SHA256_N32_W8 and two LMSlevels are used where in the first level the LMS parameter set LMS_SHA256_M32_H25 isused and in the second level the LMS parameter set LMS_SHA256_M32_H15 is used:

1 HSSKeyPair keyPair = HSS . generateKeys ( 2 , LMS_SHA256_M32_H25 ,LMS_SHA256_M32_H15 , LMOTS_SHA256_N32_W8, " myPrivateKey . priv " ) ;

Listing 3.11: HSS Key Generation


Note: The key generation of the used parameter sets takes more than 1 hour on modernpersonal computers. For more information see Chapter 5.1.

The generated key pair contains the private key and the public key. The private key isalready stored in the file myPrivateKey.priv. The private key is then used to generate anHSS signature which is shown below:

1 HSSSignature s i g = HSS . generateS ignature ( "A t e x t " , keyPair . getPrivateKey ( ) ) ;

Listing 3.12: HSS Signature Generation

The resulting signature can then be verified using the HSS public key as shown below.The original message, the signature and the respective public key need to be provided:

1 boolean va l id = HSS . v e r i f y S i g n a t u r e ( "A t e x t " , s ig , keyPair . getPublicKey ( ) ) ;

Listing 3.13: HSS Signature Verification

3.4 Testing

Testing the application is a very important part that needs to be done already from thebeginning of the implementation process. HSS internally uses LMS and LMS uses LM-OTStherefore, it is a requirement that each underlying part works as intended. If LM-OTS isnot correctly implemented it would not be possible to have a correctly implemented LMSimplementation and the same applies to LMS and HSS. Each new piece of code needs adedicated unit test to verify that the smallest possible pieces work correctly. Unit testing isdone with JUnit 5 as mentioned in Chapter 3.1.

Besides tests for each small unit of the program, there are also a few End-to-End (E2E) tests.These tests verify that the entire process works correctly by creating key pairs, signaturesand at the end verifying that signature. This is done for LM-OTS, LMS, and HSS. All testsare executed in parallel to reduce time and verify that the application is thread-safe. Ifthe application would not be thread-safe the results of the unit tests would not always becorrect and some tests would either always fail or be at least flaky.


In total there are 78 unit tests and 3 tests are disabled by default because they take toolong to run them every time. Running all unit tests takes about 2 minutes on an AMDRyzen 7 3700X. This could be reduced to a few seconds when the JaCoCo test coveragereport is disabled. The overall test coverage of the application is about 97.5% of allsource code lines. This can be seen in Figure 3.1. The missing 2.5% is mostly sourcecode for larger LMS parameter sets and error handling for errors that are not expected tohappen e.g., NoSuchAlgorithmException if the requested hashing algorithm does not exist.Some of this error handling code can never be called because it is not possible with thedefined parameter sets. They were only introduced to remove IDE warnings and makethe application safe for future adaptions.

Figure 3.1: Unit Test Code Coverage Statistics

Four different types of unit tests are described below. All other tests are very similar tothem and can be seen in the source code of this thesis.

Simple unit tests perform tests on a small unit of the application e.g., private key genera-tion. An example of such a test for LM-OTS private key generation can be seen in Listing3.14. It creates private keys with different parameter sets and verifies some fields of theresulting private key. The test also expects that no exceptions are thrown.

1 @Test2 void generatePr ivateKeyTest ( ) throws NoSuchAlgorithmException {3 f o r ( f i n a l LMOTSType lmotsType : getLmotsTypes ( ) ) {4 f i n a l LMOTSPrivateKey privateKey = LMOTS. generatePrivateKey (

lmotsType ) ;5 f i n a l byte [ ] [ ] privateKeys = privateKey . getKeys ( ) ;6 a s s e r t E q u a l s ( lmotsType . getP ( ) , privateKeys . length ) ;7 byte [ ] previousKey = n u l l ;8 f o r ( i n t i = 0 ; i < lmotsType . getP ( ) ; i ++) {


9 f i n a l byte [ ] currentKey = privateKeys [ i ] ;10 a s s e r t E q u a l s ( lmotsType . getN ( ) , currentKey . length ) ;11 assertNotEquals ( currentKey , previousKey ) ;12 previousKey = currentKey ;13 }14 }15 }

Listing 3.14: LM-OTS Private Key Generation Test

End-2-End unit tests perform several simple key and signature generations as well assignature verifications. If one part of the application is not implemented correctly suchtests will fail e.g., key generation, signature generation, or signature verification. Anexample of such a test for HSS can be seen in Listing 3.15.

Parallel unit test that interacts with the application with multiple threads. It simulatesthe generation of several signatures in parallel. It is important that the state of the HSSprivate key stays consistent and this test does nothing else than checking that it indeedis. The unit test creates an HSS private key with 32 768 LM-OTS keys. It then creates athread pool with 16 threads. Each thread creates message signatures and immediatelyverifies that signature. After all 32 768 keys were used to generate an HSS signature thetest expects that an IllegalStateException is thrown when trying to create another signaturebecause the key is exhausted. With this logic, the test verifies that the library is able to beused by multiple threads and that they do not interfere with each other and that the stateof the private key is always in a consistent state. The source code of this test can be seen inListing 3.16.

1 @Test2 void generateSignatureAndVal idateSignatureTest ( ) throws

NoSuchAlgorithmException , IOException {3 f i n a l S t r i n g message =4 " j f d k l s a j 8 9 4 w a h j r n f a s fkesda f k l fJKFHJPASDHFJKSjf sd k a l j f ( = )

/$% \")/U9asd7as98/D) A79poda98 / ( ) /&=)ZDAST " ;5 f o r ( f i n a l LMOTSType lmotsType : getLmotsTypes ( ) ) {6 f o r ( i n t i = 1 ; i <= 8 ; i ++) {


7 f i n a l HSSKeyPair keyPair = HSS . generateKeys ( i , LMS_SHA256_M32_H5, lmotsType ,

8 " generateSignatureAndVal idateSignatureTest . privkey " ) ;9 f i n a l HSSPrivateKey privateKey = keyPair . getPrivateKey ( ) ;

10 f i n a l HSSPublicKey publicKey = keyPair . getPublicKey ( ) ;11 f i n a l HSSSignature s ignature = HSS . generateS ignature ( message ,

privateKey ) ;12 asser tTrue (HSS . v e r i f y S i g n a t u r e ( message , s ignature , publicKey ) ) ;13 }14 }15 }

Listing 3.15: HSS E2E Test

1 @Test2 void testManySignaturesThreads ( ) throws NoSuchAlgorithmException ,

IOException {3 f i n a l S t r i n g message =4 " j f d k l s a j 8 9 4 w a h j r n f a s fkesda fdsafg ( = ) /$% \")/U9asd7as98sdfa/D

) A79poda98 / ( ) /&=)ZDAST " ;5 f i n a l HSSKeyPair keyPair =6 HSS . generateKeys ( 1 , LMS_SHA256_M32_H15 , LMOTS_SHA256_N32_W8, "

testManySignaturesThreads . privkey " ) ;7 f i n a l HSSPrivateKey privateKey = keyPair . getPrivateKey ( ) ;8 privateKey . reserveKeys (32 _768 ) ;9 f i n a l HSSPublicKey publicKey = keyPair . getPublicKey ( ) ;

10 f i n a l ExecutorServ ice e x e c u t o r S e r v i c e = Executors . newFixedThreadPool (getRuntime ( ) . a v a i l a b l e P r o c e s s o r s ( ) ) ;

11 f i n a l L i s t <Integer > q I d e n t i f i e r s = new ArrayList < >() ;12 f o r ( i n t i = 0 ; i < 32 _768 ; i ++) {13 i n t f i n a l I = i ;14 e x e c u t o r S e r v i c e . execute ( ( ) −> {15 i f ( ! Thread . currentThread ( ) . i s I n t e r r u p t e d ( ) ) {16 f i n a l HSSSignature s ignature ;17 t r y {18 s ignature = HSS . generateS ignature ( message + f i n a l I ,

privateKey ) ;19 a s s e r t F a l s e ( q I d e n t i f i e r s . conta ins ( s ignature .

g e t S i g na tu re s ( ) [ 0 ] . g e t Q I d e n t i f i e r ( ) ) ) ;20 q I d e n t i f i e r s . add ( s ignature . g e t S i gn a tu re s ( ) [ 0 ] .

g e t Q I d e n t i f i e r ( ) ) ;21 asser tTrue (HSS . v e r i f y S i g n a t u r e ( message + f i n a l I ,

s ignature , publicKey ) ) ;


22 } catch ( NoSuchAlgorithmException | IOException e ) {23 e . p r i n t S t a c k T r a c e ( ) ;24 }25 }26 } ) ;27 }28 e x e c u t o r S e r v i c e . shutdown ( ) ;29 t r y {30 i f ( ! e x e c u t o r S e r v i c e . awaitTermination ( Long .MAX_VALUE, TimeUnit .

NANOSECONDS) ) {31 e x e c u t o r S e r v i c e . shutdownNow ( ) ;32 }33 } catch ( InterruptedExcept ion ex ) {34 ex . p r i n t S t a c k T r a c e ( ) ;35 }36 assertThrows ( I l l e g a l S t a t e E x c e p t i o n . c l a s s , ( ) −> {37 f i n a l HSSSignature s ignature = HSS . generateS ignature ( message ,

privateKey ) ;38 } ) ;39 }

Listing 3.16: Parallel Unit Test

Consumer test that shows how the application can be used. It creates an HSS key pair,reserves a few keys, and creates a signature. In the end, it verifies the signature. Thepurpose of this test is more for documentation and not testing the application itself. Theusage of the application can also be seen in Section 3.3.3 of this thesis.

3.5 Benchmarking

All Java benchmarks use JMH to generate repeatable results. All benchmarks are separatedinto several files depending on their JMH benchmark settings. All benchmarks in the samefile have a similar runtime. Depending on the estimated runtime more or less warm-upruns are used. All benchmarks are measured in nanoseconds. An example of such abenchmark for HSS key generations with fast parameter sets, parameter sets with smallLMS trees e.g., LMS_SHA256_M32_H5, can be seen in Listing 3.17. For the used LM-OTS


and LMS parameter sets exists a member variable that is annotated with the used valuesfor it. Each LM-OTS and LMS parameter set combination is then executed 500 times towarm up the JVM and then 100 times for the measurement. The average of those 100 runsis then used as the result in Chapter 5.

1 @State ( Scope . Benchmark )2 @BenchmarkMode (Mode . AverageTime )3 @OutputTimeUnit ( TimeUnit . MILLISECONDS)4 @Warmup( i t e r a t i o n s = 500 , time = 20 , timeUnit = TimeUnit .NANOSECONDS)5 @Measurement ( i t e r a t i o n s = 100 , time = 20 , timeUnit = TimeUnit .NANOSECONDS)6 @Fork ( 1 )7 @Timeout ( time = 3 , timeUnit = TimeUnit .HOURS)8 publ ic c l a s s HSSKeyGenerationBenchmarkFast {9

10 @Param ( {11 "LMS_SHA256_M32_H5" ,12 "LMS_SHA256_M32_H10"13 } )14 p r i v a t e LMSType lmsType ;15 @Param ( {16 "LMOTS_SHA256_N32_W1" ,17 "LMOTS_SHA256_N32_W2" ,18 "LMOTS_SHA256_N32_W4" ,19 "LMOTS_SHA256_N32_W8"20 } )21 p r i v a t e LMOTSType lmotsType ;2223 @Setup ( Level . T r i a l )24 publ ic void setUp ( ) {25 System . out . p r i n t l n ( " Benchmarking " + lmotsType . name ( ) + " " +

lmsType . name ( ) ) ;26 }2728 @Benchmark29 publ ic void testHSSKeyGeneration ( ) throws NoSuchAlgorithmException ,

IOException {30 f i n a l HSSKeyPair keyPair = HSS . generateKeys ( 1 , lmsType , lmotsType ) ;31 }32 }

Listing 3.17: HSS Key Generation - Benchmark


4 Existing Implementations

Although the NIST process for defining recommended hash-based signature schemeswas finalized in October 2020 [13] the used algorithms are not new and there are alreadyexisting implementations of them available. Because those implementations are olderthan the final draft of the NIST recommendation, none of those implementations supportall defined parameter sets. At the moment of writing this thesis there are three relevantimplementations for HSS that can be used for comparison:

• C reference implementation - Cisco

• Python implementation - Cisco

• Go implementation - GitHub user lingyunzhao

Cisco’s C reference implementation: This implementation is referenced in RFC 8554.It is the most promising implementation that is available. It is very fast because it iswritten in C and supports 16 threads. To ensure that no OTS key is reused even if theapplication crashes it supports key storing and loading from disk. The saved key iseven protected against modifications with HMAC. It supports not all parameter setsdefined by NIST. More precisely this implementation supports only the parameter setsdescribed in RFC 8554. The source code of this implementation can be found on GitHubhttps://github.com/cisco/hash-sigs.

Cisco’s Python implementation: Cisco also provides an implementation in Python. Thisimplementation is much slower than the C implementation because its intent is to havean implementation that is easier to read. It is even stated in the description [12] that thisimplementation does not aim to perform efficiently:


https://github.com/cisco/hash-sigs

"The implementation aims for readability over other criteria such as perfor-mance or fully exploiting the Python language."

It does not support multi-threading which makes it much slower. Storing and loading thekey from disk is also supported by this implementation and it does also not support allparameter sets defined by NIST. The source code of this implementation can be found onGitHub https://github.com/davidmcgrew/hash-sigs.

Go implementation: The last relevant implementation is written in Go. It is similar tothe Python implementation but covers even fewer features. It is single-threaded andsupports only a few parameter sets. Storing and loading keys from disk is not supportedby this implementation. The source code of this implementation can be found on GitHub:https://github.com/lingyunzhao/pqcrypto.

The supported features of each implementation including the Java implementation builtin this thesis can be seen in Table 4.1.

Feature C Java Python GoMultithreading x x - -Key storing/loading x x x -HMAC x - - -All parameter sets - x - -Efficient memory management x - - -

Table 4.1: Supported Features of Existing Implementations

The C implementation is the only one that supports multi-threading and therefore, isthe only one that is relevant to be used for a comparison with the Java implementationcreated in this thesis. The other implementations are much slower because they aresingle-threaded.


https://github.com/davidmcgrew/hash-sigs

https://github.com/lingyunzhao/pqcrypto

5 Results

In this chapter, the performance of the Java implementation built in this thesis is comparedto the performance of the Cisco C implementation. Both implementations utilize 16 cores.The used CPU is the AMD Ryzen 7 3700X with 8 cores and hyper-threading enabled. TheCPU runs at a clock of 4.05 GHz. This chapter covers also the various different private key,public key, and signature sizes.

Running the C implementation results in almost always the same results with very littlevariance. The Java implementation behaves differently mainly because of Just-in-TimeCompilation. JIT requires a few warm-up runs to get comparable results. Therefore,the benchmark of the C implementation is run 5 times without any warm-up runs andthe average of those 5 runs is used. For benchmarking the Java implementation severalwarm-up runs are used and after that, the average of the next runs is used as the result.The number of warm-up runs and benchmark runs was chosen according to the runtimeof one run to reduce the time of all benchmarks. The settings will be described for eachbenchmark result.

It is relevant to note that the Java implementation is much less memory efficient comparedto the C implementation. This is the same for the Python and Go implementations. C isnot object-oriented and therefore has no memory overhead for objects. In Java, we makeuse of objects and live with massive memory overhead. Each object has up to 16 byteof overhead on a 64-bit JVM [53]. In the case of a Merkle tree with a height of 25, theapplication creates more than 66 million objects which then have a memory overhead ofmore than 1 GB. With that knowledge, there is no need to make a detailed comparison ofthe consumed memory of both applications. Therefore, only the performance is measuredand compared.


5.1 Performance

In this section, the performance results of the several different key generations, the HSSsignature generations, and HSS signature verifications are shown and explained. The rawbenchmark results can be seen in the tables in the appendix of this thesis.

5.1.1 Leighton-Micali One-Time Signature Scheme

The performance results of LM-OTS are shown in this chapter although they cannotbe compared to any results of the reference implementation of RFC 8554 [1] becausethe reference implementation does not support generating LM-OTS keys and signatureswithout HSS.

Key Generation

The key generation of a single LM-OTS key pair is in general very fast. The overallaverage is about 0.4 ms where the LM-OTS key pair generation depends on the usedLM-OTS parameter set. The slowest LM-OTS key pair generation takes about 1 ms withthe parameter set LMOTS_SHA256_N32_W8. All other parameter sets with the hashfunction SHA-256 are similarly fast and need about 0.2 ms. These results can be seen inFigure 5.1. Times in the graph are given in milliseconds.

Figure 5.1: LM-OTS Key Generation


5.1.2 Leighton-Micali Signature Scheme

The performance results of LMS are shown in this chapter although they cannot becompared to any results of the reference implementation of RFC 8554 [1] because thereference implementation does not support generating LMS keys and signatures withoutHSS.

Key Generation

The performance of LMS key generations is very similar to the HSS key generationswith just one level. This is due to the fact that both are equivalent and result in al-most the same computations. The LMS key generations with the LM-OTS parameter setLMOTS_SHA256_N32_W8 and different LMS parameter sets can be seen in Figure 5.2.Times in the graph are given in milliseconds. The key generations with weaker LM-OTSparameter sets are much faster in comparison.

Figure 5.2: LMS Key Generation


In this section, the HSS performance results of the Java implementation from this thesisare compared to the results of the reference implementation of RFC 8554 [1].


Key Generation

The C implementation does not support that many parameter sets. Therefore, it is notpossible to compare that many different parameter sets. For the key generation the usedLM-OTS parameter sets are:

• LMOTS_SHA256_N32_W1




For the LMS parameter set LMS_SHA256_M32_H5 the key generation results can be seenin Figure 5.3. The results are shown in milliseconds. The Java implementation is slowerwith LMOTS_SHA256_N32_W1, LMOTS_SHA256_N32_W2, and LMOTS_SHA256_N32_W4which are the weaker LM-OTS parameter sets. The Java implementation outperformsthe C implementation slightly with LMOTS_SHA256_N32_W8. Both implementationsperform all key generations in 6 milliseconds or less.

The benchmark used 500 warm-up runs. The biggest difference is between the first twowarm-up runs. The average result of 100 runs is used.

Figure 5.3: HSS Key Generation - H5

For the LMS parameter set LMS_SHA256_M32_H10 the key generation results can beseen in Figure 5.4. The results are shown in milliseconds. The Java implementation isat least slightly faster in all cases. The difference increases with the strongest LM-OTS


parameter set LMOTS_SHA256_N32_W8. For this parameter set, the key generation withthe C implementation is already about 66% slower.



For the LMS parameter set LMS_SHA256_M32_H15 the key generation results can beseen in Figure 5.5. The results are shown in milliseconds. The Java implementation isat least slightly faster in all cases. The difference increases with the strongest LM-OTSparameter set LMOTS_SHA256_N32_W8. For this parameter set, the key generation withthe C implementation is about 55% slower.




For the LMS parameter set LMS_SHA256_M32_H20 the key generation results can beseen in Figure 5.6. The results are shown in seconds. The Java implementation is at leastslightly faster in all cases. The difference increases with the strongest LM-OTS parameterset LMOTS_SHA256_N32_W8. For this parameter set, the key generation with the Cimplementation is about 52% slower.



For the LMS parameter set LMS_SHA256_M32_H25 the key generation results can beseen in Figure 5.7. The results are shown in minutes. The Java implementation is at leastslightly faster in all cases. The difference increases with the strongest LM-OTS parameterset LMOTS_SHA256_N32_W8. For this parameter set, the key generation with the Cimplementation is about 47% slower.

For this parameter set, key generation is much slower compared to the others. Therefore,it would take too long to perform several warm-up runs. To warm up the JVM, 20 runswith LMS_SHA256_M32_H5 were used.

All together the Java implementation performs better in almost all cases. The time savingcan get quite big for stronger LMS parameter sets e.g., for LMS_SHA256_M32_H25 withLMOTS_SHA256_N32_W8 the saved time will be already about 25 minutes. The C imple-mentation is slightly faster with the smallest LMS parameter set LMS_SHA256_M32_H5.The difference is about 1 millisecond which is neglectable. The graphs of all other caseshave a very similar form. This shows that with weaker LM-OTS parameter sets the Cimplementation is faster but the difference is not significant. With stronger LM-OTS



parameter sets the Java implementation is faster and the difference increases significantlywith the most secure parameter set. In some cases, it is even 60% faster than the Cimplementation.

The CPU utilization of key generations can be seen in Figure 5.8. It clearly shows that allCPU cores are fully utilized. Together with the results from above, this is a hint that theJava code is well optimized for LMS and HSS key generations.

Figure 5.8: CPU Utilization - Key Generation


Signature Generation

The HSS signature generation is very fast with the C implementation. All signatures forthe message "A short text that needs to be signed!" are generated in under 2 ms. The mainreason for this is because it uses some kind of fractal Merkle tree traversal [32]. In the Javaimplementation, only the first 15 levels of the Merkle tree are stored in memory. Therefore,it is equally fast for trees that have not more than 15 levels. The results can be seen inFigure 5.9. The chart clearly shows that the performance decreases with Merkle tree heightof 20 and especially Merkle tree height of 25 where the signature generation already takesabout eight seconds.

Figure 5.9: HSS Signature Generation

Signature Validation

HSS signature verification is very fast for both implementations. All signatures are verifiedin under 2 ms. There is no notable difference between the Java implementation and the Cimplementation.

5.2 Key Sizes

To get a feeling of how the selected parameters affect the resulting key and signaturesizes they are visualized in several graphs. The public key sizes do almost not changebetween different parameter sets and are in general very short compared to the signature


size and the private key size. In this section, only key sizes with SHA-256 and the LM-OTSparameter sets LMOTS_SHA256_N32_WX are shown. It is possible to reduce the key sizesby using a shorter hash function e.g., SHA-256/192 or using a smaller LM-OTS parameterset e.g., LMOTS_SHA256_N24_W8.

For the presentation of the LM-OTS key sizes the following LM-OTS parameter sets wereused:





In Figure 5.10 the LM-OTS key sizes are visualized. The graph presents the private key,public key, and the corresponding signature size in byte. The private and public keysare 56 byte long in all cases. The signature sizes decrease with larger W of the LM-OTSparameter set. The same data can also be seen in Figure 5.11 where the data is presentedwith a logarithmic scale. Using weaker LM-OTS parameter sets results in larger signaturesizes but is faster computed than using stronger LM-OTS parameter sets. The LM-OTSkey sizes can also be seen in Table 5.1.

Figure 5.10: LM-OTS Key Sizes

For the presentation of the LMS key sizes the same LM-OTS parameter sets are used asabove. The used LMS parameter sets are:

• LMS_SHA256_M32_H5


Figure 5.11: LM-OTS Key Sizes - Logarithmic scale

Parameter set Private Key [B] Public Key [B] Signature [B]LMOTS_SHA256_N32_W1 56 56 8516LMOTS_SHA256_N32_W2 56 56 4292LMOTS_SHA256_N32_W4 56 56 2180LMOTS_SHA256_N32_W8 56 56 1124

Table 5.1: LM-OTS Key Sizes





Each LMS parameter set is used with each LM-OTS parameter set. The resulting key sizescan be seen in Figure 5.12. The graph uses a logarithmic scale because the private key sizecan get very large. The public key size is for all parameter sets the same, 56 byte. Thesignature size depends mostly on the chosen LM-OTS parameter set. The signature sizeincreases slightly with stronger LMS parameter sets. The private key depends completelyon the selected LMS parameter set. It grows from 1.8 KB to 1.8 GB. The signature sizes arebetween 1.2 KB and 9.3 KB. The LMS key sizes can also be seen in Table 5.2.

For the presentation of the HSS key sizes the same LM-OTS and LMS parameter sets areused as above. Figure 5.13 shows the HSS key sizes with one level. The graph looks verysimilar to 5.12. This is because HSS with only one level is almost the same as LMS. TheHSS key sizes can also be seen in Table 5.3.


Figure 5.12: LMS Key Sizes - Logarithmic Scale

Figure 5.13: HSS Key Sizes Level 1 - Logarithmic Scale

In Figure 5.14 the HSS key sizes with eight levels can be seen. It shows the largest possiblekeys with the defined parameter sets. It looks similar to the graph with one level but theprivate key and signature sizes are about 8 times as large. The largest possible private keyhas a size of about 15 Gigabytes. The largest signature has a size of about 75 KB. This canalso be seen in Table 5.4

Depending on the used parameter sets the consumer can define how many signaturescan be created at most with one HSS private key. The minimum number of signaturesis 32 with one HSS level and an LMS tree with an height of five. The largest number ofsignatures can be created with eight HSS levels where each LMS tree has a height of 25.This setup can create 2200 signatures without reusing a single LM-OTS key.

Note that only the public key sizes and the signature sizes are defined in the RFC [1]. Theprivate key sizes can differ for each LMS and HSS implementation.


Parameter set Private Key [KB] Public Key [B] Signature [KB]W1 & H5 1.820 56 8.684W2 & H5 1.820 56 4.460W4 & H5 1.820 56 2.348W8 & H5 1.820 56 1.292W1 & H10 57.372 56 8.844W2 & H10 57.372 56 4.620W4 & H10 57.372 56 2.508W8 & H10 57.372 56 1.452W1 & H15 1,835.036 56 9.004W2 & H15 1,835.036 56 4.780W4 & H15 1,835.036 56 2.668W8 & H15 1,835.036 56 1.612W1 & H20 58,720.284 56 9.164W2 & H20 58,720.284 56 4.940W4 & H20 58,720.284 56 2.828W8 & H20 58,720.284 56 1.772W1 & H25 1,879,048.220 56 9.324W2 & H25 1,879,048.220 56 5.100W4 & H25 1,879,048.220 56 2.988W8 & H25 1,879,048.220 56 1.932

Table 5.2: LMS Key Sizes

Figure 5.14: HSS Key Sizes Level 8 - Logarithmic Scale



Table 5.3: HSS Key Sizes - 1 Level



Table 5.4: HSS Key Sizes - 8 Level


6 Conclusion and Outlook

To come to an end in this thesis, the main findings of this thesis are summarized and alsoseveral possible open future tasks are explained in this chapter.

6.1 Conclusion

With the benchmark results from the previous chapter, it is now possible to conclude thisthesis. Both implementations, the C reference implementation of RFC 8554 [1] and theJava implementation created in this thesis, have advantages and disadvantages whichneed to be taken into consideration.

The first advantage of the Java implementation is adaptability. It is much easier to add newfeatures to a Java program than to a C program. Even for someone that is not familiar withthe source code. This is partly also because of the next advantage, readability. Java codein general is much easier to read than C code. There exist so many coding conventionsand tools that support the programmer to generate readable and well-documented code.Java is also an object-oriented programming language that allows the programmer toseparate the source code in logical chunks. This makes the overall program more clearand allows parts of the source code to be reused in similar applications. As can be seenin Chapter 5, the performance of the Java implementation was better independent of theused parameter sets. The time savings can get quite big for some parameter sets.

Another advantage of the Java implementation is that not that many exploits exist for Javaprograms as do for C programs. Java code is in general much more secure because it isexecuted in a virtual machine whereas C code does not have that layer in between [54].

This implementation has been created after the final draft of the NIST process and therefore,supports all defined parameter sets. The C implementation was done years before that


and at that time no parameter sets were defined by NIST. Therefore, the C implementationonly supports the parameter sets defined in RFC 8554 [1]. The last advantage of the Javaimplementation is that it is OS independent and can, therefore, be run on any OS that canrun a JVM. There exists a JVM implementation for almost all architectures. C code mustbe compiled for each architecture specifically.

Although the Java implementation does have many advantages over the C implementation,there are also a few disadvantages.

The Java implementation can have a very high memory overhead because each objecthas 16 byte overhead on a 64-bit JVM [53]. This overhead is typically negligible but canbecome a problem with a large number of objects. This is the case with large LMS trees e.g.,H25. There are about 66.000.000 objects held in memory which results in more than 1 GBmemory overhead. This large overhead can make problems on devices with less memorye.g., constrained devices. Another disadvantage of the Java program is that it requires theJVM to warm up before running with optimal performance. The first executions of theprogram are very slow compared to the C program. This is not a problem if the programruns very long but might be a big drawback for short-living programs. Additionally,the warm-up must be performed after each application crash. Though, it is possible toperform some warm-up runs with fast parameter sets which take almost no time. Thisimproves also subsequent executions with larger parameter sets and should be taken intoconsideration when using this program.

Alltogether it is good to have a new standard or recommendation implemented in differentlanguages. In my opinion, this is also one part of the IT security principle of open design.The Java implementation can outperform the C implementation in most cases for keygenerations but requires much more memory than the C implementation. Therefore, Iwould still prefer the C implementation over the Java implementation. This is especiallyrelevant for constrained devices that typically have not that much memory available.

6.2 Future Work

Although this program is ready to be used there are a few open tasks that can be donein the future in the area of this topic. The Cisco C implementation should be adapted to


support all LM-OTS and LMS parameter sets as defined by NIST. This would make thatimplementation complete in regards to the recommendation of NIST [13].

There are also some open improvements and additions to the Java implementation thatwould make sense. One thing would be to reduce the used memory of that implementationby using large arrays instead of creating LM-OTS key objects. The advantage would bethat a lot of memory could be saved for LMS and HSS keys because the JVM objectoverhead will be reduced due to the fact that fewer objects are used [53]. The drawback ofthis approach would be that the readability of the source code will be reduced. Anotherpossible improvement would be to create a Java implementation of SHA that supports theSHA instruction set which could improve the hashing performance. There exists alreadysuch an implementation, the Amazon Corretto Crypto Provider but it is only supportedon 64-bit Linux [55].

In Chapter 5.1 it is shown that the signature generation performs worse with larger LMStrees. This is because only the first 15 levels of nodes in the LMS tree are held in memory.All additional nodes must be recomputed when generating a signature. To improve theLMS and HSS signature generation it would be possible to implement a fractal Merkletree walk [32] which gives currently the best time-memory tradeoff.

It would also be an option to implement HMAC for the private key file on disk to ensurethat the private key was not modified by an attacker. But if someone can access the privatekey file and modify it, there are more severe problems that must be handled in the firstplace. So it is not clear how much an advantage having HMAC for the private key filewould be.

The last open improvement would be to adapt the HSS key storing. Every time theconsumer reserves keys the future state of the private key will be saved to disk to ensurethat even after an application crash no LM-OTS key is reused. Depending on the size ofthe private key it may take some time to store the entire key. There is actually no need tostore the entire key because only the current q identifier changes. It would be possible toonly update the four bytes of the q identifier in the private key file which would be muchfaster. Besides the adaptions of the C implementation and the several improvements ofthe Java implementation, there is also the possibility to implement a similar program forXMS and XMSSMT [26, 27].


Bibliography

[1] S. Fluhrer D. McGrew M. Curcio. Leighton-Micali Hash-Based Signatures. RFC 8554.Internet Research Task Force (IRTF), Apr. 2019. URL: https://www.rfc-editor.org/rfc/rfc8554.txt (cit. on pp. vii, 1, 2, 5, 6, 7, 8, 10, 11, 12, 13, 14, 15, 16, 17, 18,19, 20, 21, 22, 23, 24, 25, 26, 35, 46, 60, 61, 69, 73, 74).

[2] Michele Mosca. “Cybersecurity in an era with quantum computers: will we beready?” In: IEEE Security & Privacy 16.5 (2018), pp. 38–41 (cit. on pp. 1, 3).

[3] Peter W Shor. “Algorithms for quantum computation: discrete logarithms andfactoring”. In: Proceedings 35th annual symposium on foundations of computer science.Ieee. 1994, pp. 124–134 (cit. on pp. 1, 3).

[4] Peter W Shor. “Polynomial-time algorithms for prime factorization and discretelogarithms on a quantum computer”. In: SIAM review 41.2 (1999), pp. 303–332 (cit. onpp. 1, 3).

[5] Lov K Grover. “A fast quantum mechanical algorithm for database search”. In:Proceedings of the twenty-eighth annual ACM symposium on Theory of computing. 1996,pp. 212–219 (cit. on pp. 1, 3, 5).

[6] Edward Eaton. “Leighton-Micali hash-based signatures in the quantum random-oracle model”. In: International Conference on Selected Areas in Cryptography. Springer.2017, pp. 263–280 (cit. on pp. 1, 10, 26, 27).

[7] Leslie Lamport. Constructing digital signatures from a one-way function. Tech. rep.SRI-CSL-98. SRI International Computer Science Laboratory, 1979 (cit. on pp. 1, 10,26).

[8] Michael O Rabin. Digitalized signatures and public-key functions as intractable as factor-ization. Tech. rep. TR-212. Massachusetts Inst of Tech Cambridge Lab for ComputerScience, 1979 (cit. on pp. 1, 10).


https://www.rfc-editor.org/rfc/rfc8554.txt

https://www.rfc-editor.org/rfc/rfc8554.txt

[9] Leon Groot Bruinderink and Andreas Hülsing. ““Oops, I did it again”–Security ofOne-Time Signatures under Two-Message Attacks”. In: International Conference onSelected Areas in Cryptography. Springer. 2017, pp. 299–322 (cit. on pp. 1, 10, 26).

[10] Johannes Buchmann, Erik Dahmen, and Michael Szydlo. “Hash-based digital sig-nature schemes”. In: Post-Quantum Cryptography. Springer, 2009, pp. 35–93 (cit. onpp. 1, 5).

[11] Jonathan Katz. “Analysis of a proposed hash-based signature standard”. In: Interna-tional Conference on Research in Security Standardisation. Springer. 2016, pp. 261–273(cit. on pp. 1, 10, 27).

[12] S. Fluhrer. CISCO Hash-based signatures reference implementation. https://github.com/cisco/hash-sigs. Accessed: 2021-05-09 (cit. on pp. 1, 57).

[13] David A Cooper et al. “Recommendation for stateful hash-based signature schemes”.In: NIST Special Publication 800 (2020), p. 208 (cit. on pp. 2, 5, 6, 7, 8, 9, 10, 16, 21, 24,25, 26, 57, 75).

[14] Lily Chen et al. Report on post-quantum cryptography. NISTIR 8105. US Department ofCommerce, National Institute of Standards and Technology, 2016 (cit. on p. 3).

[15] Charles H Bennett et al. “Strengths and weaknesses of quantum computing”. In:SIAM journal on Computing 26.5 (1997), pp. 1510–1523 (cit. on p. 3).

[16] Richard J Hughes et al. “Quantum cryptography”. In: Contemporary Physics 36.3(1995), pp. 149–163 (cit. on p. 3).

[17] Mark Pecen et al. “Quantum Safe Cryptography and Security: An Introduction,Benefits, Enablers and Challenges, white paper”. In: European TelecommunicationsStandards Institute (2014) (cit. on pp. 3, 5).

[18] Daniel J Bernstein. “Introduction to post-quantum cryptography”. In: Post-quantumcryptography. Springer, 2009, pp. 1–14 (cit. on p. 4).

[19] Daniele Micciancio and Oded Regev. “Lattice-based cryptography”. In: Post-quantumcryptography. Springer, 2009, pp. 147–191 (cit. on p. 4).

[20] Robert J McEliece. “A public-key cryptosystem based on algebraic coding theory”.In: DSN Progress Report (1978), pp. 114–116 (cit. on p. 4).

[21] Raphael Overbeck and Nicolas Sendrier. “Code-based cryptography”. In: Post-quantum cryptography. Springer, 2009, pp. 95–145 (cit. on p. 4).




[22] Jintai Ding and Bo-Yin Yang. “Multivariate public key cryptography”. In: Post-quantum cryptography. Springer, 2009, pp. 193–241 (cit. on p. 5).

[23] Ralph Charles Merkle. “Secrecy, authentication, and public key systems.” PhD thesis.1979 (cit. on pp. 5, 16).

[24] Tom Leighton and Silvio Micali. “Secret-key agreement without public-key cryptog-raphy”. In: Annual International Cryptology Conference. Springer. 1993, pp. 456–479(cit. on p. 5).

[25] National Institute of Standards and Technology. Post-Quantum Cryptography. https://csrc.nist.gov/projects/post-quantum-cryptography. Accessed: 2021-05-02(cit. on p. 5).

[26] Andreas Hülsing et al. “XMSS: eXtended Merkle signature scheme”. In: RFC 8391.IRTF, 2018 (cit. on pp. 5, 6, 75).

[27] Johannes Buchmann, Erik Dahmen, and Andreas Hülsing. “XMSS-a practical for-ward secure signature scheme based on minimal security assumptions”. In: Interna-tional Workshop on Post-Quantum Cryptography. Springer. 2011, pp. 117–129 (cit. onpp. 5, 75).

[28] Fabio Campos et al. “LMS vs XMSS: Comparison of Stateful Hash-Based SignatureSchemes on ARM Cortex-M4”. In: International Conference on Cryptology in Africa.Springer. 2020, pp. 258–277 (cit. on p. 6).

[29] National Institute of Standards and Technology. Post-Quantum Cryptography FAQ.https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/faqs. Accessed:2021-05-03 (cit. on p. 6).

[30] Internet Assigned Numbers Authority. LMS Parameter Sets. https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.

xhtml. Accessed: 2021-05-03 (cit. on p. 7).

[31] Gregory M Zaverucha and Douglas R Stinson. “Short One-Time Signatures.” In:Adv. Math. Commun. 5.3 (2011), pp. 473–488 (cit. on p. 10).

[32] Markus Jakobsson et al. “Fractal Merkle tree representation and traversal”. In:Cryptographers’ Track at the RSA Conference. Springer. 2003, pp. 314–326 (cit. on pp. 18,66, 75).


https://csrc.nist.gov/projects/post-quantum-cryptography

https://csrc.nist.gov/projects/post-quantum-cryptography

https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/faqs




[33] Elaine Barker and John Kelsey. NIST Special Publication 800-90A Recommendationfor Random Number Generation Using Deterministic Random Bit Generators. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf.2015 (cit. on p. 24).

[34] Elaine Barker and John Kelsey. NIST Special Publication Special Publication 800-90Brecommendation for the entropy sources used for random bit generation. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf. 2018 (cit. onp. 24).

[35] David McGrew et al. “State management for hash-based signatures”. In: InternationalConference on Research in Security Standardisation. Springer. 2016, pp. 244–260 (cit. onp. 25).

[36] Phillip Rogaway and Thomas Shrimpton. “Cryptographic hash-function basics:Definitions, implications, and separations for preimage resistance, second-preimageresistance, and collision resistance”. In: International workshop on fast software encryp-tion. Springer. 2004, pp. 371–388 (cit. on p. 26).

[37] Henri Gilbert and Helena Handschuh. “Security analysis of SHA-256 and sisters”.In: International workshop on selected areas in cryptography. Springer. 2003, pp. 175–193(cit. on p. 26).

[38] Elaine Barker. NIST Recommendation for Key Management. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf. Accessed: 2021-05-06 (cit. on p. 27).

[39] Mihir Bellare and Phillip Rogaway. “Random oracles are practical: A paradigm fordesigning efficient protocols”. In: Proceedings of the 1st ACM Conference on Computerand Communications Security. 1993, pp. 62–73 (cit. on p. 27).

[40] Scott R Fluhrer. “Further Analysis of a Proposed Hash-Based Signature Standard.”In: IACR Cryptol. ePrint Arch. 2017 (2017), p. 553 (cit. on p. 27).

[41] Oracle. JDK 15 Release Notes. https://www.oracle.com/java/technologies/javase/15-relnote-issues.html. Accessed: 2021-04-30 (cit. on p. 28).

[42] Gradle Inc. Gradle Build Tool. https://gradle.org/. Accessed: 2021-04-30 (cit. onp. 28).

[43] Roman Ivanov. Checkstyle. https://checkstyle.sourceforge.io/. Accessed: 2021-04-30 (cit. on p. 29).


https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

https://www.oracle.com/java/technologies/javase/15-relnote-issues.html

https://www.oracle.com/java/technologies/javase/15-relnote-issues.html

https://gradle.org/

https://checkstyle.sourceforge.io/

[44] SpotBugs. SpotBugs. https://spotbugs.github.io/. Accessed: 2021-04-30 (cit. onp. 30).

[45] PMD Open Source Project. PMD. https://pmd.github.io/. Accessed: 2021-04-30(cit. on p. 30).

[46] PMD Open Source Project. CPD Cop-pase detector. https://pmd.github.io/latest/pmd_userdocs_cpd.html. Accessed: 2021-04-30 (cit. on p. 30).

[47] EclEmma Team. JaCoCo Java Code Coverage Library. https://www.eclemma.org/jacoco/. Accessed: 2021-04-30 (cit. on p. 31).

[48] Amund Elstad. Keccakj. https://github.com/aelstad/keccakj. Accessed: 2021-04-30 (cit. on p. 31).

[49] Oracle. JDK Security Provider Documentation. https://docs.oracle.com/javase/9/security/oracleproviders.htm. Accessed: 2021-05-13 (cit. on p. 31).

[50] JUnit Team. JUnit. https://junit.org/junit5/. Accessed: 2021-04-30 (cit. on p. 31).

[51] OpenJDK. JMH Java Microbenchmark Harness. https://github.com/openjdk/jmh.Accessed: 2021-04-30 (cit. on p. 31).

[52] Oracle. JDK SecureRandom Number Generation Algorithms. https://docs.oracle.com / javase / 8 / docs / technotes / guides / security / StandardNames . html #

SecureRandom. Accessed: 2021-05-25 (cit. on p. 32).

[53] Nick Mitchell and Gary Sevitsky. “Building memory-efficient Java applications:Practices and challenges”. In: International Conference on Software Engineering. 2008(cit. on pp. 38, 44, 45, 49, 50, 59, 74, 75).

[54] Frank Yellin and Tim Lindholm. The java virtual machine specification. Addison-Wesley,1996 (cit. on p. 73).

[55] Amazon Web Services Inc. Amazon Corretto Crypto Provider (ACCP). https : / /aws.amazon.com/blogs/opensource/introducing-amazon-corretto-crypto-

provider-accp/. Accessed: 2021-04-30 (cit. on p. 75).


https://spotbugs.github.io/

https://pmd.github.io/

https://pmd.github.io/latest/pmd_userdocs_cpd.html

https://pmd.github.io/latest/pmd_userdocs_cpd.html

https://www.eclemma.org/jacoco/

https://www.eclemma.org/jacoco/

https://github.com/aelstad/keccakj

https://docs.oracle.com/javase/9/security/oracleproviders.htm

https://docs.oracle.com/javase/9/security/oracleproviders.htm

https://junit.org/junit5/

https://github.com/openjdk/jmh

https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SecureRandom



https://aws.amazon.com/blogs/opensource/introducing-amazon-corretto-crypto-provider-accp/



Appendix

The raw results of the benchmarks are shown in the tables below. Also the LM-OTSand LMS parameter sets containing the numeric identifiers used in the source code areshown.

Parameter Sets C JavaLMS_SHA256_M32_H5LMOTS_SHA256_N32_W1

0.81 ms 1.54 ms

LMS_SHA256_M32_H5LMOTS_SHA256_N32_W2

0.78 ms 1.45 ms


1.03 ms 1.55 ms


6.03 ms 4.61 ms

Table 1: HSS Key Generation H5 - Benchmark Results


15 ms 11.84 ms


12 ms 9.65 ms


22 ms 14.62 ms


164 ms 98.62 ms




463 ms 341.80 ms


388 ms 281.34 ms


677 ms 468.79 ms


5.16 s 3.31 s



14.62 s 12.12 s


12.27 s 10.59 s


21.19 s 16.96 s


159.23 s 104.60 s



7.54 min 6.64 min


6.53 min 5.86 min


10.93 min 8.17 min


84 min 57.16 min




1.44 ms 1.56 ms


0.71 ms 1.27 ms


1.55 ms 1.32 ms


1.43 ms 251.79 ms


2.07 ms 7,980 ms

Table 6: HSS Signature Generation - Benchmark Results


<1 ms 0.94 ms


<1 ms 0.98 ms


<1 ms 0.69 ms


<1 ms 0.77 ms


<1 ms 1.14 ms

Table 7: HSS Signature Verification - Benchmark Results


LM-OTS Parameter Sets Identifier H n w pLMOTS_SHA256_N32_W1 0x0000 0001 SHA-256 32 1 265LMOTS_SHA256_N32_W2 0x0000 0002 SHA-256 32 2 133LMOTS_SHA256_N32_W4 0x0000 0003 SHA-256 32 4 67LMOTS_SHA256_N32_W8 0x0000 0004 SHA-256 32 8 34LMOTS_SHA256_N24_W1 0x0000 0005 SHA-256 24 1 200LMOTS_SHA256_N24_W2 0x0000 0006 SHA-256 24 2 101LMOTS_SHA256_N24_W4 0x0000 0007 SHA-256 24 4 51LMOTS_SHA256_N24_W8 0x0000 0008 SHA-256 24 8 26LMOTS_SHAKE_N32_W1 0x0000 0009 SHAKE-256 32 1 265LMOTS_SHAKE_N32_W2 0x0000 000A SHAKE-256 32 2 133LMOTS_SHAKE_N32_W4 0x0000 000B SHAKE-256 32 4 67LMOTS_SHAKE_N32_W8 0x0000 000C SHAKE-256 32 8 34LMOTS_SHAKE_N24_W1 0x0000 000D SHAKE-256 24 1 200LMOTS_SHAKE_N24_W2 0x0000 000E SHAKE-256 24 2 101LMOTS_SHAKE_N24_W4 0x0000 000F SHAKE-256 24 4 51LMOTS_SHAKE_N24_W8 0x0000 0010 SHAKE-256 24 8 26

Table 8: LM-OTS Parameter Sets


LMS Parameter Sets Identifier H m hLMS_SHA256_M32_H5 0x0000 0005 SHA-256 32 5LMS_SHA256_M32_H10 0x0000 0006 SHA-256 32 10LMS_SHA256_M32_H15 0x0000 0007 SHA-256 32 15LMS_SHA256_M32_H20 0x0000 0008 SHA-256 32 20LMS_SHA256_M32_H25 0x0000 0009 SHA-256 32 25LMS_SHA256_M24_H5 0x0000 000A SHA-256 24 5LMS_SHA256_M24_H10 0x0000 000B SHA-256 24 10LMS_SHA256_M24_H15 0x0000 000C SHA-256 24 15LMS_SHA256_M24_H20 0x0000 000D SHA-256 24 20LMS_SHA256_M24_H25 0x0000 000E SHA-256 24 25LMS_SHAKE_M32_H5 0x0000 000F SHAKE-256 32 5LMS_SHAKE_M32_H10 0x0000 0010 SHAKE-256 32 10LMS_SHAKE_M32_H15 0x0000 0011 SHAKE-256 32 15LMS_SHAKE_M32_H20 0x0000 0012 SHAKE-256 32 20LMS_SHAKE_M32_H25 0x0000 0013 SHAKE-256 32 25LMS_SHAKE_M24_H5 0x0000 0014 SHAKE-256 24 5LMS_SHAKE_M24_H10 0x0000 0015 SHAKE-256 24 10LMS_SHAKE_M24_H15 0x0000 0016 SHAKE-256 24 15LMS_SHAKE_M24_H20 0x0000 0017 SHAKE-256 24 20LMS_SHAKE_M24_H25 0x0000 0018 SHAKE-256 24 25

Table 9: LMS Parameter Sets


Curriculum Vitae

Ing. Andreas Schöngruber, BSc.17.12.1993A-4040 [email protected]

Experience

Software Developer - BackendDynatrace Austria GmbHSince March 2020

Software Developer - UI TestDynatrace Austria GmbHMarch 2018 - March 2020

Software Developer - Full StackMIC Datenverarbeitung GmbHNovember 2016 - February 2018

Software Developer - ProjectsMIC Datenverarbeitung GmbHMarch 2015 - November 2016

Internship - DevelopmentRacon Software GmbHAugust 2013

Internship - DevelopmentRacon Software GmbHAugust 2012

Education

Computer Science Master’s ProgramJohannes Kepler University LinzJuly 2020 - June 2021

Computer Science Bachelor’s ProgramJohannes Kepler University LinzOctober 2017 - July 2020

HTBLA LeondingOctober 2009 - July 2014

HBLA Raumberg GumpensteinOctober 2008 - July 2009


Statutory Declaration

I hereby declare that the thesis submitted is my own unaided work, that I have not usedother than the sources indicated, and that all direct and indirect sources are acknowledgedas references.

This printed thesis is identical with the electronic version submitted.

Linz, June 2021


Documents

Efficient Implementation of Hash-based Signature Schemes