 Research
 Open access
 Published:
Winternitz stack protocols for embedded systems and IoT
Cybersecurity volumeĀ 7, ArticleĀ number:Ā 34 (2024)
Abstract
This paper proposes and evaluates a new bipartite postquantum digital signature protocol based on Winternitz chains and anĀ oracle. Mutually mistrustful Alice and Bob are able to agree and sign a series of documents in a way that makes it impossible (within the assumed security model) to repudiate their signatures. The number of signatures supported by a single public key is still limited, though by a large number. However, the security of the signature scheme is not diminished by repeated application, so when the capacity of a public key is exhausted the last transaction can be used to agree a new key. Some ramifications are discussed, security parameters evaluated and an application area delineated for the proposed concept.
Introduction
Our focus is on supporting multivendor embedded devices that require guaranteed nonrepudiation. Such devices often occur in automotive, aerospace and other safetycritical applications, as well as in all kinds of medical technology. Authentication and integritycontrol techniques that utilise symmetric ciphers are based on sharing a confidential key. The same key is used for signing messages and validating them, so the sender can always repudiate the message by claiming that it was formed by the other party that shares the key. Publickey cryptography does not quite solve this problem. First of all, it is vulnerable to quantum attacks and cannot be relied on in a futureproof technology. Secondly, and perhaps more importantly from a practical point of view, signature calculation and verification require a volume of computations that can be too large for an embedded device operating on a tight power budget.
We attempt to address both issues by proposing a hashbased signature. Such signatures exploit the oneway nature of a cryptographic hash to create an effective publickey/privatekey pair. Large random integers are used as the private key, and their hashes are published to form the public key. When a new message requires a signature, the signer reveals certain integers of the private key. Their choice uniquely identifies the message, and since the only principal who can show the preimage of a hash is the one who created that hash in the first place, a collection of preimages reliably linked to a message can serve as a signature.
There exist quite a few hashbased signature schemes that are well developed and understood, see āRelated workā section for related work. We draw our inspiration from Winternitzās idea to apply a hash to a random seed repeatedly to create a chain, and Reyzin and Reyzinās idea of random index sets (multisets in our approach) generated by a hash and used to index an array of keypairs. However, our proposal differs from the related work by the fact that we build a signature stack using an array of long Winternitz chains (we call this a Winternitz fabric), and we push fixed cardinality multiset frames on it rather than variablecardinality subsets, see āWinternitz stack protocolā section. This way we achieve security that does not diminish under repeated application, so ours is not a fewtime signature scheme, but in fact a constant security scheme, even though the capacity to sign is limited by the length of the fabric. Having said that, for a very modest storage capacity (single gigabytes), a million signatures can be accommodated without recalculation. Storage capacity can be traded in for hash recalculations and under realistic assumptions the storage requirements can be reduced to megabytes without significantly altering the amount of work required for signing, see āPracticalitiesā section. We show that 256bit security (128bit postquantum) is easily achieved by our scheme. The computational burden on the parties after the protocol launch amounts to a few tens of hash calculations by the verifier (same as the original HORS by Reyzin and Reyzin 2002) and only one or two by the signerāa negligible amount compared to the computations involved in a publickey signature scheme such as ECDSA.
The most unusual feature of our solution is its ability to support a mutual signature of two parties using a single public key by repurposing the confirmation preimage for signing the verifierās approval, see āMAWS protocolā section. We propose an extreme version of this mutual protocol, which we call reverse Winternitz stack (RWS), where Alice signs nothing but messages received from Bob, see āReverse Winternitz stack (RWS) protocolā section. As a result Alice could become Bobās public notary without either of them requiring trust. Indeed if a third party trusts Alice (authenticated by her public key) not to collude with Bob and not to deny him service by breaking the protocol, Bob can safely sign his messages by running RWS with her for the third partyās use. If Alice tries to impersonate Bob to sign a message, Bob will be able to prove the signature false, but if the message is in fact genuinely signed by Bob, then Alice is also safe, since Bob will not be able to repudiate his signature. Alice and Bob have instant assurances by the protocol, but any proof for a third party requires dumping Bobās stack. The stack contains digests of all documents that Bobās ever signed with Alice since the establishment of the current public key, as well as additional protocol data the size of that key (hundreds of KB). This gives rise to a small communication requirement in the order of 1Mbyte. In most scenarios involving a guarantee of nonrepudiation, a thirdparty proof is only required after a major event (car breakdown, aircraft malfunction, etc.) to adjudicate on the cause of the event in a multivendor environment.
Another remarkable feature of RWS is its communication asymmetry. Bob receives of the order of 1Ā Kb of data from Alice, but his transmission requirements are limited to only 64 bytes per signature, same as it would be for the 256bit ECDSA. In an IoT situation, where messages are communicated over long distances via a low bitrate radio, transmission requires much power to radiate a strong enough signal to reach a network hub, while reception involves only digital signal processing. Also the maximum radiated power and the transmitter duty cycle of an IoT radio is limited by law to enable public use without harmful interference. By contrast, IoT network hubs are allowed a more powerful transmitter (up to a factor of 10), higher duty cycle (again a factor of 10) and an elevated fullsize antenna to be able to transmit much greater volumes of data. The RWS protocol nicely matches this asymmetry.
The main contributions of the paper are as follows:

The idea of Winternitz stack and an analysis of its security properties

Three signature protocols based on a Winternitz stack with nondecreasing security of a large but limited number of signatures

Analysis of the protocol resource footprints
The next two sections present the basic principles, notations and some security properties of the Winternitz stack. āWinternitz stack protocolā, āMAWS protocolā and āReverse Winternitz stack (RWS) protocolā sections describe the signature protocols. āApplication of RWS to Internet of Thingsā section discusses possible applications, āRelated workā section presents related work and finally there are some conclusions.
Principles of Winternitz stack signature
We begin with the standard definition of Winternitz chain:
Definition 1
For a cryptographic hashfunction H(x) and some arbitrary \(r_0\) of the same bitlength as the image of H, the sequence
is called a lengthN Winternitz chain.
Let us bring several chains together.
Definition 2
(Winternitz fabric) An indexed family of lengthN Winternitz chains \(r^{[k]}_i\), where k is the index, \(0\le k<w\), w is a power of 2, and \(0\le i<N\), is called a Winternitz (w,Ā N)fabric, or just fabric for short. The constant w is called the width and N, the length of the fabric. The indexed family \((E^{[k]})\), where \(E_k=r^{[k]}_N\) where \(0\le k<w\) is called the edge of the fabric. When referring to the edge as a whole we will omit the index: E, or E(F) for the edge of a fabric F.
See Fig.Ā 1 for an illustration. The width of a fabric is constrained to a power of 2, but the length of the chain is arbitrary. For practical purposes chain lengths of the order of one million or less should satisfy most demands for a digital signature. Notice that due to the hardness of the second preimage problem, at most one (w,Ā N)fabric can be produced given an arbitrary widthw edge E for any practical N.
Consider a lengthd sequence of binary strings \(D_j\), \(0\le j<d\), which we will call documents. Let a function
be a random oracle, where \(\mathcal {B}\) is a set of arbitrarylength binary strings and \(\mathcal M_{\kappa ,w}\) is a set of all cardinality\(\kappa\) multisets of integers taken from the range \(\llbracket 0,w1\rrbracket\). Assume the oracle is such that the presence of those integers in the multiset is uncorrelated. A multiset \(M\in \mathcal {M}_{\kappa ,w}\) of this kind can be defined using its characteristic function \(\chi _M:\llbracket 0,w1\rrbracket \rightarrow \llbracket 0,\kappa 1\rrbracket\), such that for any \(x\in \llbracket 0,w1\rrbracket\) x occurs in M \(\chi _M(x)\) times. For convenience, define \(\omega : \mathcal {B}\times \llbracket 0,w1\rrbracket \rightarrow \llbracket 0,\kappa 1\rrbracket\) to be a function such that \(M=\Omega ^{[\kappa ,w]}(b)\) iff \(\omega (b,k)=\chi _M(k)\) for any \(b\in \mathcal {B}\) and \(0\le k<w\). Clearly, for any \(b\in \mathcal {B}\),
Cardinality \(\kappa\) is a security parameter. We assume it is fixed and will discuss the choice of it later on. In the sequel we will not show the dependency of any variables of interest on \(\kappa\) explicitly and will not use explicit upper indices of \(\Omega\) if the omission does not lead to ambiguity.
Definition 3
For an integer \(d>0\), a depthd signature stack over a Wintenitz (w,Ā N)fabric \((r^{[k]}_i)\) is a pair of indexed families (D,Ā T), where \(D=(D_j)_{j\in \llbracket 0,d1\rrbracket }\) is a sequence of documents, and \(T=(r^{[k]}_{N\sigma (k)})_{k\in \llbracket 0,w1\rrbracket }\) is the top of the stack, with the function \(\sigma :\llbracket 0,w1\rrbracket \rightarrow \llbracket 0,N1\rrbracket\) defined thus:
provided that \(\sigma (k)\le N\) for all k in its domain. (The double vertical bar denotes bitstring concatenation.)
A depth0 signature stack is the pair \((\emptyset ,(r^{[k]}_N)_{k\in \llbracket 0,w1\rrbracket })\).
Corollary 1
For any depthd signature stack (D,Ā T) over a Wintenitz (w,Ā N)fabric,
Proof
Sum in k both sides of the equation for \(\sigma\) in Definition 3, make the summation in k innermost in the righthand side and use Eq.Ā 1. \(\square\)
Fabric capacity
Typically what is signed is not the actual content but its cryptographic digest, so \(D_j\) are usually hashimages of the actual documents to be signed. Also, to prevent a replay attack, the original content typically contains a random nonce. Under such assumptions the family \((D_j)\) is a collection of random values which makes the oracle output not only random but also, with a probability very close to 1, free from repetitions. Let us evaluate the capacity of the fabric to carry a signature stack of a large depth d.
First visualise the fabric as w vertical rods that balls can be slid unto, see Fig.Ā 2. Each document \(D_j\) causes balls to be slid on some of the rods according to \(\omega\), the total number of balls being \(\kappa\). Their distribution over the rods is random and uncorrelated. In particular, it is possible but not very probable that some balls for a given document will be slid on the same rod. The distribution \(\sigma (k)\) is the result of repeating āthe sliding of ballsā d times using a total of \(d\kappa\) balls. Choose one rod at random and observe that the probability for a ball to end up taking that rod is 1/w. The number of balls on the rod after \(d\kappa\) balls have been randomly distributed between the rods is governed by the binomial distribution, which gives us the obvious expectation \(E=d\kappa /w\) and the standard deviation
for large d. By Central Limit Theorem of statistics the distribution becomes close to Gaussian at large d. The rule of thumb is that fluctuations of a Gaussian random value very rarely exceed \(6\Delta\) and so we calculate, for large N that we are interested in,
The exact point at which the fabric will prove too small to support the signature stack over it depends on the documents \((D_j)\), but since each document only slides \(\kappa\) balls on the rods, and since we will always use wide fabrics (\(\kappa \ll w\)), the process can be stopped very close to that point. For estimates we should neglect \(\sqrt{N}\) compared to N and use
Oracle entropy
Next let us explore security properties of a signature stack. The lynchpin of security here is the fact that a random oracle \(\Omega (D)\) makes the problem of a second preimage unfeasibly hard, provided that its codomain is a large set. An attacker trying to find some \(D^\prime\) that has the same image as D, \(\Omega (D^\prime )=\Omega (D)\) will have to make a number of attempts commensurate with \(\mathcal {M}_{\kappa ,w}\), which could be astronomically large. We find from elementary combinatorics that for a fabric of width w, a random oracle with the security parameter \(\kappa\) will yield one out of a possible
multisets of cardinality \(\kappa\) with equal probability. For practical reasons, which we will explain later, we are interested in a small \(\kappa\) of the order ten, while we are willing to consider fabrics of a width of a few thousand. Expanding the above for \(\kappa \ll w\) and keeping the first nonvanishing term in 1/w we obtain
Note that this is an estimate from below as all higherorder terms are positive. We are interested in the entropy of the oracle, which equals the binary logarithm of G. To get some idea how large it can be for \(\kappa ^2\lesssim w\) we neglect the term in brackets and use Stirlingās formula for the factorial, which is accurate to within 1% even for \(\kappa\) as small as 10:
Consider a fabric of width \(w=4096\) and an oracle with \(\kappa =31\) and find that \(\log _2 G\) exceeds 259. Notice that it is marginally better than the security of SHA256 with respect to a second preimage attack.
HORS oracle
A true random oracle is not feasible, but it can be approximated very well using the trick invented by Reyzin and Reyzin as they proposed their HORS scheme (Reyzin and Reyzin 2002). Specifically we take a standard hash of the argument D and pare it down to \(\kappa \log _2w\) bits.^{Footnote 1} In our numerical example this would be \(31\times 12=372\) bits. A hash of this length is easy to compute by application of SHA512, taking the first 372 bits of the result. All that remains is to partition the bit string into 12bit chunks, interpret them as unsigned binary integers, and to collect them into a multiset, which will represent the value of \(\Omega (D)\). We call this implementation a HORS oracle and formally define it next.
Definition 4
For any \(w=2^q\) with some positive integers q and \(\kappa\), a HORS oracle is a function \(\eta ^{[\kappa ,w]}: \mathcal {B}\rightarrow \mathcal {M}_{\kappa ,w}\) defined as follows:
where \(\Psi _{\kappa ,w}:\mathcal {B}^{[\kappa q]}\rightarrow \mathcal {M}_{\kappa ,w}\) is the multiset of \(\kappa\) digits of the \(\kappa q\)bit integer argument written in the basew positional number system and \(\hat{H}:\mathcal {B}\rightarrow \mathcal {B}^{[u]}\) is a cryptographic hash function producing a ubit hash value, \(u\ge \kappa q\).
Strictly speaking, a HORS oracle would not be a random oracle even if we disregarded the difference between a cryptographic hash H(x) and a genuine random function. The random oracle makes a random selection of a multiset from the codomain \(\mathcal {M}_{\kappa ,w}\); any \(X\in \mathcal {M}_{\kappa ,w}\) is selected with the same probability. The HORS oracle (again, ignoring the nonrandom nature of the hash) does not select a multiset; it selects \(\kappa\) random numbers from the interval \(\llbracket 0,w1\rrbracket\), which may or may not be pairwise distinct. If they are, then the multiset is a set of cardinality \(\kappa\) and its statistical weight in the codomain of \(\hat{H}\) is \(\kappa !\). If the collection of numbers has a single pairwise collision, its statistical weight is only half as much. Multiple collisions degrade the statistical weight even further. Consequently, even if the image of \(\hat{H}(x)\) is evenly spread over the codomain, the entropy of the HORS oracle may be quite different from the estimate given by Eq.Ā 4. How much different?
It should be noted that the number of proper multisets (i.e. multisets that are not sets) is small compared to the number of sets in the oracleās codomain:
where we kept the first nonvanishing term in the expansion in the birthday^{Footnote 2} parameter \(\gamma =\kappa ^2/w\). The factor \(R=w^\kappa /\kappa !\) corresponds to the number of distinct sets (ignoring the collisions) swept by the indices as they independently cover their value interval \(\llbracket 0,w1\rrbracket\). The most frequent proper multiset has one binary collision. There are
of those, again keeping to the first nonvanishing term in \(\gamma\). Comparing this with the expression for \(G_{+}\) above, we find that the contribution of multiple collisions is higher order in \(\gamma\). Indeed the next term corresponds to two binary collisions since there are a factor of \(\kappa /w\) fewer multisets with one tertiary collision. The statistical weight of the former is
and can safely be neglected for small enough \(\gamma\) (in our example \(\gamma \approx 1/4\)) along with the rest of the higherorder terms. By contrast, the number of multisets that are sets can be approximated to the first order in \(\gamma\) as
We can now construct an approximate probability distribution function (PDF) for multisets by assuming that a multiset is either a set or it has one binary collision:
where z is the normalising constant that satisfies the following:
which gives us \(z=R\). Finally, summing over all sets and proper multisets and keeping to the main order in \(\gamma\) we arrive at the entropy value
where the last step is achieved by taking the binary logarithm of Eq.Ā 4 and keeping to the first order in \(\gamma\). Informally, proper multisets expand the alphabet of the HORS oracle output compared to just sets, thus increasing its entropy, however they make the PDF uneven and this reduces the entropy by almost the same amount. As a result, a HORS oracle with a moderately small \(\gamma\) has almost exactly the same entropy as the random oracle \(\Omega\) provided that the hash function \(\hat{H}\) is close to ideal.
Proof of stack security by reduction
The previous section assumed the framework of the random oracle model (ROM) (Bellare and Rogaway 1993) as it identified the hash function \(\hat{H}(x)\) with a random oracle for the purposes of computing the entropy of \(\eta ^{[\kappa ,w]}\). That is the best we can do given that the statistics of a practical cryptographic hash are unknown but generally believed to be close to ROM. However, in analysing the security of the Windernitz stack, on which all subsequent protocols rely, we prefer to remain within the Standard Model since the irreducible assumptions about the relevant hash functions (and we intend to use two generally different hashes) are weaker than the ROM would impose.
This section presents the key security property (Lemma 1) and its reduction to the those assumptions, which follow below.
Assumption 1
The hash function \(\hat{H}\) used to construct HORS oracle is oneway (preimage and second preimage resistant Rogaway and Shrimpton 2004).
Assumption 2
The hash function H used to construct the Winternitz fabric is preimageresistant.
The key property that provides security to the Winternitz stack is that the HORS oracle is preimage and secondpreimage resistant, which makes it hard to fit a random digest to the top of the stack to forge the signatures of the rest, or even to substitute a new digest for an old without changing the rest of the stack content.
By contrast, in constructing a Winternitz fabric over which the stack is placed, only simple preimage resistance is required of the chain hashfunction. Indeed, an attacker may find a second preimage and claim that it is the next node of the chain in an attempt to split it. However, to succeed the attacker would then have to find the preimage of that second image to continue the chain; this would fail if H is preimage resistant. The fabric is never used up since the shape of the stack top is unpredictable and it may run out of fabric for the next document, so some fabric is left unused using a conservative estimate, and then the principals switch to a new fabric. Consequently the adjudicator is in a position to ask the fabric owner to prove the top of the stack is genuine by exposing the next node of the chain about which the suspicion of chainsplit has arisen.
Let us now redefine \(\omega (b,k)\) (which we defined earlier based on the ideal oracle \(\Omega ^{[\kappa ,w]}\)) in terms of our practical HORS oracle \(\eta ^{[\kappa ,w]}\); this will not lead to a confusion since the sequel has no reference to \(\Omega\). Specifically, \(\omega (b,k)\) from now on will be a function such that \(M=\eta ^{[\kappa ,w]}(b)\) iff for all \(0\le k < w\), k occurs in M \(\omega (b,k)\) times, for any multiset M and string \(b\in \mathcal {B}\).
Proposition 1
For any depthd signature stack (D,Ā T) over a fabric, it is computationally hard to find a family \(D^\prime \ne D\) such that \((D^\prime ,T)\) is a depthd signature stack over the same fabric.
Proof
Essentially one would have to solve the following set of simultaneous equations for \((D^\prime _j)\):
The lefthand side is the sum of d terms. If any document \(D_{l}\) is changed it would be computationally difficult to avoid change in all terms of the sum for which \(l\le m<d1\), since according to Assumption 1, the hash function in \(\eta\), namely \(\hat{H}(x)\), is secondpreimage resistant. Clearly the least work is required when \(l=d1\), i.e. only the last document is changed. Still, one second preimage would need to be found. Alternatively, one could build a stack with a depth \(d1\) using any digests and then find the digest corresponding to the last multiset to be added to result in the same stack edge as defined by \(\sigma _k\). That is also computationally hard due to Assumption 1 (preimage resistance). \(\square\)
The values \(\sigma\) for a stack can be derived from its T by computing \(\beta (T_k,E_k)\) where \(\beta (x,y)\) for \(x\ne y\) is the least positive integer i such that
If \(x=y\), we define \(\beta (x,y)=0\). It should be noted that \(\beta\) is a partial function \(\mathcal {B}\times \mathcal {B}\) \({\mathbb N}\), since the value of i that satisfies its definition may not exist. If i does exist, it is less than the fabric length, which makes the definition constructive.
Since \(T_k=r^{[k]}_{N\sigma (k)}\), \(\beta (T_k,E_k)=\sigma (k)\). From Corollary 1 for a valid stack (D,Ā T) we have:
We will use \((D,\sigma )\) and (D,Ā T) interchangeably where it does not create a confusion.
Definition 5
(Substack) For a depthd stack \(S=(D,\sigma )\) over a (w,Ā N)fabric, a depth\(d^\prime\) stack \(S^\prime =(D^\prime ,\sigma ^\prime )\) over the same fabric is a substack of S if for all \(0\le k<w\), \(\sigma ^\prime (k)\le \sigma (k)\).
Proposition 2
Consider a depth\(d^\prime\) substack \(S^\prime =(D^\prime ,\sigma ^\prime )\) of a depthd stack \(S=(D,\sigma )\). If \(d^\prime =d\), then \(\sigma ^\prime =\sigma\).
Proof
Proof by contradiction. Assume \(\sigma ^\prime \ne \sigma\), and since for all \(0\le k<w\), \(\sigma ^\prime (k)\le \sigma (k)\), then \((\exists k_0) \sigma ^\prime (k_0)<\sigma (k_0)\). But then
By Corollary 1 we have
which is a contradiction since \(d^\prime =d\). \(\square\)
Notice that Proposition 2 does not generalise down. If \(d^\prime <d\), especially when \(d^\prime \ll d\), almost any documents \((D_j)\) will place the top of the substack lower on the fabric than the larger stackās top. Indeed to make the substack tall with a small \(d^\prime\) would require a document whose distribution \(\omega\) over the fabric is restricted to very few values of k which is very improbable for a good approximation of a random oracle. Consequently there exists plenty of substacks of a given stack with a smaller depth.
Lemma 1
(Stack security) If T is known to be the top of a depthd stack (D,Ā T) over a private fabric F with a public edge \(E=E(F)\), the pair (E,Ā T) is sufficient to find d and identify D. It is computationally hard for an adversary with no knowledge of the rest of F to produce an alternative \(D^\prime \ne D\), such that \((D^\prime ,T^\prime )\) with any \(T^\prime\) is a valid depthd stack over a fabric with the same edge E(F).
Proof
To find d from T, use Eq.Ā 5. Next, observe that knowledge of (D,Ā T) is always sufficient to reconstruct all members of the fabric that the stack and any of its substacks occupy down to the edge E. Although given just that knowledge it is possible to construct a valid substack \((D^\prime \ne D,T^\prime )\) for some arbitrary documents \((D^\prime _j)\), but according to Proposition 2 the substack would have to be of a depth less than d, which contradicts the premise of the Lemma. If \(T^\prime =T\), changing even a single \(D_j\) to \(D^\prime _j\ne D_j\) without changing T is computationally hard according to Proposition 1. Finally, if \((D^\prime ,T^\prime )\) is not a substack of (D,Ā T), to produce \(T^\prime\) one would require fabric elements that cannot be derived from T, and the premise states that the fabric is private. These unknown private elements cannot be obtained from the fabric elements at the top of the stack due to Assumption 2. \(\square\)
Ancillary operations
Stack push
Signature stacks over a fabric are inherently sequential. It is possible to extend a stack to accommodate an extra document provided that the fabric is accessible.
Definition 6
Stack push p is a partial function \({\textbf {p}}:\mathcal {D}\times \mathcal {S}_d\) \(\mathcal {S}_{d+1}\), where \(\mathcal {D}\) is, as before, a set of all finite binary strings and \(\mathcal {S}_d\) is an indexed family of sets of all depthd stacks over some fixed (w,Ā N)fabric \((r^{[i]}_k)\):
where
and
provided that all such r exist in the fabric. Otherwise the result is undefined.
Observe that^{Footnote 3} at least for some k, \(\sigma ^\prime (k)>\sigma (k)\). This means that the stack push always depends on unused members of the fabric and requires access to it.
Operations on indexed families
We require two ancillary operations on indexed families: addition and subtraction.
Definition 7
Let A and B be two indexed families \(A=(A_i)_{i\in C}\) and \(B=(B_i)_{i\in C}\) with indices from the same finite \(C\subset {\mathbb Z}^{+}\). We define the difference \(AB\) as the indexed family \(AB=(A_i)_{i\in C^*}\), where
Definition 8
Let A and B be indexed families \(A=(A_i)_{i\in C}\) and \(B=(B_i)_{i\in C^*}\), where \(C\subset {\mathbb Z}^{+}\) is some finite set and \(C^*\subseteq C\). We define the sum \(A+B\) as the indexed family \((Q_i)_{i\in C}\), where
Proposition 3
For any two finite indexed families \(A=(A_i)_{i\in C}\) and \((B_i)_{i\in C}\), where C is a finite index set,
Proof
(by cases) For a given index value i, if \(A_i\ne B_i\) then, by Definition 7, \((AB)_i=A_i\) and i belongs to the index set of \(AB\). But if it does, then by Definition 8
Otherwise \(B_i=A_i\) and, by Definition 7, the index value i does not belong to the index set of \(AB\). Then by Definition 8
\(\square\)
If two parties share a family of bitstrings B and at some point one needs to send to the other a similar family A which has many common members with B, it would be sufficient to communicate \(AB\), which has a much smaller index set, and then the receiving party will restore A by computing \(B+(AB)\).
Definition 9
Given an indexed family \(X=(X_i)_{i\in I}\), where I is a finite index set \(I\subset {\mathbb Z}^{+}\), and some element x, the extension of X with x is the family \(X^\prime = X\triangleright x\) such that \(X^\prime =(X^\prime _i)_{i\in I^\prime }\),
and
Validator
Definition 10
Consider a stack \(S=(D,T)\), \(D=(D_j)_{j\in \llbracket 0,d1\rrbracket }\) and \(T=(T_k)_{k\in \llbracket 0,w1\rrbracket }\), over a widthw fabric of sufficient length, a document \(\delta\), and an indexed family of binary strings \((\tau _k)_{k\in \Gamma }\), with some \(\Gamma \subset \llbracket 0,w1\rrbracket\) such that \(\Gamma \le \kappa\). We define the validator predicate \(\epsilon (\delta ,\tau ,S)\) to be true iff for all \(k\in \llbracket 0,d1\rrbracket\), \(\beta (T^\prime _k,T_k)\) exists and
where the indexed family \(T^\prime =T+\tau\) and the partial function \(\beta\) is the one defined in āProof of stack security by reductionā section.
Proposition 4
Given some \(S=(D,T)\), \(\delta\) and \(\tau\) as per Definition 10, if \(\epsilon (\delta ,\tau ,S)\) then \((D\triangleright \delta ,T+\tau )\) is a valid depth\((d+1)\) stack over the same fabric.
Proof
follows from Definition 3\(\square\)
Winternitz stack protocol
The structures presented so far can be used to create a bipartite protocol where neither party can repudiate a transaction. Under publickey cryptography, the signer is unable to repudiate a properly signed document since the verifier holds the signerās authenticated public key and can prove to an adjudicator that whoever signed the document had to have knowledge of the signerās private key. The parties are assumed to be mutually adversarial to exclude collusion.^{Footnote 4}
Channel model We wish to minimise assumptions about the communication channel between the parties, bearing in mind that beneficial channel properties may depend on trust and/or shared confidential information. We require weak integrity, i.e. that a message sent by one party to the other and which fails the other partyās validation test will be received intact after a finite maximum number of retransmissions that does not depend on the message. No authentication of communicating parties is required; however countermeasures must be put in place to prevent an adversary from injecting messages in the channel at a rate that overwhelms the bona fide recipient. Because both parties are interested in progress, they can share a weak secret based on which all messages are extended with a MAC. However, even if no secret is shared, all protocols we present in the sequel require little computation at the receiving end for message validation (at most \(\kappa +1\) hash evaluations per message), so in practice each protocol contains its own DoS countermeasure, which may or may not be combined with other defences depending on the threat model. We mark received values with an asterisk \(*\) to emphasise that they are not necessarily the same as those sent. Consider the following
Protocol 1
(Bipartite Winternitz Stack (BWS) protocol)
Parties: Alice(signer) and Bob(verifier)
Protocol parameter: fabric width \(w\in \mathbb {N}\), w is a power of 2. Initially:
 I1:

In private: Alice chooses N, produces a random (w,Ā N)fabric F and saves it in local secure storage
 I2:

Alice publishes the fabric edge \(E=E(F)\) and authenticates it out of band. E is now Aliceās public key
 I3:

Alice invites Bob to participate in up to L transactions, \(L\lesssim wN/ \kappa\), see Eq.Ā 3. The invitation and the value of L need not be authenticated
 I4:

In private: Bob creates a random lengthL Winternitz chain \(q^{[k]}\) and authenticates \(Q=q^{[L1]}\) out of band. Q is now Bobās public key, good for L transactions. Also Bob produces the initial stack \(S_0=(\emptyset ,E)\) and saves it in local storage.
 I5:

Alice prepares document \(\delta =L\parallel Q\) and computes a depth1 stack over F: \(S_1 = {\textbf {p}}(Q,(\emptyset ,E))=(D_1,T_1)\), stores it, then communicates \(\tau =T_1E\) to Bob.
 I6:

Bob receives \(\tau ^*\), prepares the same \(\delta\) and checks \(\epsilon (D_1,\tau ^*,S_0)\). If true, \(\tau ^*=\tau\) and Bob sends \(q^{[L2]}\) back to Alice and saves^{Footnote 5}\(S_1=(\emptyset \triangleright D_1,E+\tau )\) in local storage. If false, Bob requests retransmission of \(\tau\) and repeats this step.
(Any nonreceipt of a protocol message so far can be overcome by Automatic Repeat Query (ARQ) safely. If ARQ fails, this constitutes denial of service by the nonresponding party or a protocol violation by the sender. Either way, the protocol fails.)
Repeat for \(j=2..L1\):
 R1:

When Alice wishes to sign the next document \(\delta _j\), she computes
$$\begin{aligned} S_{j}={\textbf {p}}(\delta _j,S_{j1})=(D_j,T_j), \end{aligned}$$stores \(S_j\) and sends to Bob \(\delta _j\) and \(\tau _j=T_jT_{j1}\).
 R2:

Bob receives (\(\delta ^*\),\(\tau ^*\)). Bob checks if he received and validated \(\delta ^*\) from the previous round \(j1\), and if so, (re)sends \(q^{[Lj2]}\) to Alice^{Footnote 6} and remains in step R2 of the current round. Otherwise, \(\delta ^*=\delta ^*_j\) is fresh for the current round. Bob computes \(\epsilon (\delta ^*_j,\tau ^*_j,S_{j1})\). If true, \(\delta ^*_j=\delta _j\) and Bob stores^{Footnote 7}\(S_j=(D_{j1}\triangleright \delta _j,T_{j1}+\tau _j)\), where \((D_{j1},T_{j1})=S_{j1}\), and sends \(q^{[Lj1]}\) to Alice as the acknowledgement. The round is finished. If false, Bob sends a NAK and ignores \(\delta ^*_j\) and \(T^*_j\) as if they had not been received.^{Footnote 8}
 R3:

When Alice receives \(q^*\), which could be a valid preimage or a NAK, she checks the truth value of \(H(q^*)=q^{[Lj]}\). If true, she stores^{Footnote 9}\(q^{[Lj1]}=q^*\); the round is finished. If false, she sends (\(\delta _j\), \(\tau _j\)) again and remains in step R3.
It is easy to see that the protocol is robust. Alice could only be one step behind Bob if she has not received Bobās acknowledgement in round j, since Bob goes straight to round \(j+1\) after he sends it. But then Alice will resend her message, for which the acknowledgement is missing, and Bob will be able to see that the message is from the previous round and will resend his acknowledgement. According to the channel model stated earlier after a finite number of retransmissions Alice will receive the correct acknowledgement and the parties will synchronise. We assume that if a round has exceeded the maximum number of retransmissions, the protocol fails due to DoS.
Also note that step R1 has the highest communication cost as \(\kappa\) hashes have to be communicated to Bob besides the document \(\delta\). The document is typically hashsized, since the actual document text can be communicated out of band, with only its digest being signed by the protocol. It would not be efficient to send \((\delta _j, \tau _j)\) again when, for example, only one element of \(\tau _j\) is received with errors. However, there is an easy solution to this: send elements of \(\tau _j\) onebyone with immediate validation by Bob, who will hash them and compare the result with the stored stack top. This would limit retransmission to individual elements of \(\tau _j\). When \(\kappa\) of them have been received and confirmed, send \(\delta _j\).
Security of the BWS protocol
The security of the protocol rests on the following observations:

Since the fabric is private to Alice, Lemma 1 applies, i.e. the combination of E and T uniquely defines D, making it impossible for Bob to forge Aliceās signature for the current round. Hence Alice cannot repudiate a valid stack (D,Ā T) over a fabric with the edge E, when it is claimed by Bob.

However, Bob could claim to have received only some \(S_{j_B}\), which is a substack \(S_j\) corresponding to a smaller depth \(j_B<j\). For sufficiently small \(j_B\) Bob would be able to forge Aliceās signature using fabric elements from \(S_j\) and thus repudiate the genuine one. However, this scenario is still impossible, since, according to step R3, Alice holds the acknowledgement \(a=q^{[Lj1]}\) at the end of round j and can prove that \(\beta (a,q^{[L1]})=j\). So Bobās stack cannot have less depth than j, which is the same value as Aliceās. Consequently Bob cannot repudiate.

Alice could try to repudiate differently. Since the fabric is available to her in its entirety, she could build a different stack \((D^\prime _j,T^\prime _j)\) of the same depth, not a substack of (D,Ā T), with generally different documents \(D^\prime _j\). Alice could then claim that Bob has received and changed it. However, according to Lemma 1, Bob could only have done it if he had access to Aliceās private fabric (and collusion is outside the threat model of any bipartite signature protocol). Consequently, any dispute between Alice and Bob regarding any stack content should be resolved in favour of Bob automatically, provided that Bobās stack is valid.
Adjudication
BWS supports posttransaction adjudication by an algorithmic third party Judy, who need not authenticate Alice and Bob as long as she has the public values E and \(q^{[L1]}\) authenticated out of band. Keeping to the noncollusion scenario, Judy performs the following steps.

1.
Judy requests from Alice the last \(q=q^{[Lj1]}\) she received from Bob, to determine the last j in the process of its validation using the public \(q^{[L1]}\). Alice will not benefit from reducing j to some \(j_A<j\) since this would enable Bob to potentially forge her signature. However, Alice might chance it to falsely invalidate a few most recent rounds.

2.
Judy requests Bob to provide the last q he sent, which should be the same \(q^{[Lj1]}\). If in the process of validation the value of j turns out to be some \(j_B<j_A\), then Bob is lying and \(j_A\) is accepted as the value of d, since Alice has no access to Bobās chain and since the only source of valid q for her is Bob. If \(j_B>j_A\), Judy accepts \(j_B\) as the correct value of d.

3.
Judy requests a depthd stack over a fabric with the edge E from Bob. Judy then validates the stack and confirms all signatures in it.
Practicalities
Now let us discuss how practical an implementation of the BWS protocol can be. The issue boils down to analysis of three major cost parameters: storage, computation/power and communication.
Storage
The issue of how much storage is required for the fabric is entangled with the issue of how much communication each round involves. Both are dependent on Eq.Ā 4 and the chosen security parameter \({\textbf {Y}}=\log _2G\), which is plotted against the oracle parameter \(\kappa\) in Fig.Ā 3. The curves are drawn up to a point at which \(\kappa \log _2w\simeq 512\). A further increase in \(\kappa\) would necessitate a longer hash value than the output of SHA512 for oracle emulation, which may be a problem. Also one has to remember that Eq.Ā 4 is only an approximation accurate for the region \(\kappa \ll w\). For all the curves in Fig.Ā 3\(\kappa\) is at least one order of magnitude less than w, so the plots should be accurate enough.
If we limit the discussion to the case when the security parameter is at least 256, we can see that it is impossible to reach that level with the fabric narrower than 512 if the standard hash SHA512 is to be used. The width 512 is sufficient for a lesser, 192bit, security but in the quantum case it would be reduced to one half, 89 bits, which may not be sufficient. The wider the fabric, the less the critical value of \(\kappa\). According to Eq.Ā 3, the required storage capacity to store the whole fabric is
where \(\lambda\) is the length of the hash used for the chains of the fabric (which is a parameter independent of the considerations of the oracle length). If the standard SHA256 hash is used for the chains, \(\lambda =32\) bytes. For example, for a fabric sufficient for \(\sim\)1Ā M signatures with security \({\textbf {Y}}=256\) it would appear that storage around 1Ā G bytes would be required (\(\kappa =31\), w = 4096), which is a large but completely feasible amount.
However, speed of access could be traded off for the storage requirement to reduce it by orders of magnitude using hash recalculation. Indeed, instead of storing every member of the fabric \(r^{[k]}_i\), choose a large positive \(\phi\) and substitute \(\phi k_1+k_2\), where \(k_2\in \llbracket 0,\phi 1\rrbracket\), for k. Only store elements \(r^{[k_1,k_2]}_i\) when \(k_2=0\). When in the round part of the protocol and a value of some \(r^{[k_1,k_2]}_i\) is required for \(k_2\ne 0\), apply the hash function to \(r^{[k_1,0]}_i\) \(k_2\) times to obtain it.
It is worth mentioning that the modern GPUequipped PCās hashrate (to say nothing about a clusterās) is measured in billions per second, which makes it possible to compute any required fabric element \(r^{[k]}_i\) from the initial random \(r^{[0]}_i\) in a matter of milliseconds for any realistic fabric length, making it feasible to set \(\phi =N\); only tens of kilobytes of the initial randoms would then be stored. However, the protocols presented in this paper, due to their very low computation cost, may be an attractive option for embedded systems and the IoT as well. A typical cost of a hash calculation on a microcontroller is 10 \(\upmu\)s, down to 1 \(\upmu\)s with hardware acceleration. Expanding a single node of the Winternitz chain \(r^{[0]}_i\) to the next \(\phi\) nodes for \(\phi \sim 1000\) would be a matter of single milliseconds. It would only be required once in 1000 reads from the fabric, which would amortise the computational cost nicely, while reducing the storage requirements from gigabytes to the more affordable megabytes.
Note that the cost of recalculation is on average one hash calculation per fabric element, since elements are recalculated in bunches of \(\phi\) every \(\phi\) steps up the chain and stored in a temporary buffer. There is a difference between the average computation requirements, which affect energy consumption and the application execution time on the one hand, and the peak computation load, which affects latency, power requirements and cooling on the other, so the tradeoff between storage and recalculation in any particular case might be more subtle.
All the above concerns Alice and Alice only. Bob has no access to the fabric. He only needs to store the documents and the top of the stack, which is the same size as Aliceās public key E. The latter neednāt be stored after the first document has been received, since on the one hand, E is not needed for the round part of the protocol, which deals exclusively with the top of the stack, and on the other, it can be reconstructed at any round j by popping documents off the stack in an obvious way (calculating the \(\omega\) values of the documents starting from the last and working backwards). The need to produce E may arise if Judy is involved. However, storing E incurs only a small cost anyway, less than a 50% increase in the required storage capacity, and it is a diminishing fraction as more documents are received to be stored.
Communication The main consideration that drives the choice of the fabric width w is the length of the fabric edge. Since the edge is used as the public key identifying the signer, the latter is interested in having it as short as possible, thus increasing the required \(\kappa\) for a given security parameter. However, in step R1 of Protocol 1 Alice sends \(\kappa\) hashes (the difference between \(T_j\) and \(T_{j1})\) in addition to the document (which is typically represented by the digest of the document file and is one hash in length). Consequently, there is a tradeoff between the public key length and the signature length. FigureĀ 3 indicates that the variation of \(\kappa\) at our target level of security is rather limited, while the size of the public key doubles up every time we widen the fabric. On the other hand, the public key is only communicated once, in step I2, while step R1 of Protocol 1 is invoked as many times as there are documents to be signed before the fabric is used up. This points to the largest affordable w as the best solution. AnĀ increase in w also helps to reduce the fabric length N given the maximum depth \(d_{max}\), which makes it possible to store fewer fabric elements for a given maximum recalculation cost. From this point of view, regimes close to \(\kappa =31\), \(w=4096\) seem optimal: 1Ā K bytes to send in step R1 as a document digest and its signature, and 128Ā K bytes to send in step I2 as a public key, both easily within the capabilities of a lowbitrate communication facilities available to an IoT device.
Computations This is where the proposed protocol excels. Aliceās costs for step R1 are trivial: one SHA512 hash calculation as per Definition 6 and a few table lookups to fetch the fabric elements, if they are 100% stored. If they are recalculated, add \(\kappa\) SHA256 calculations as recalculation cost. One might think that the cost of the SHA512 will increase as j increases, since the new document is concatenated with all the previous ones thus making the hash argument ever longer, but this does not affect the cost. The mechanics of the hash algorithm are such that documents are processed blockbyblock and the current state of the computation is used to produce the result. In round \(j+1\) the hash computation will simply proceed from the point that it reached in round j and will do the same fixed amount of work as that in round j. Another instance of hash calculation (SHA256) is required at step R3 to validate Bobās acknowledgement.
Bob has a similar amount of work to do. At step R2, Bob must validate Aliceās message, which will cost \(\kappa\) SHA256 computations in any case, as it is not dependent on Aliceās storage strategy; this is only a submillisecond time though, even for an IoT platform. There are also some table storage and retrieval operations to store the current top of the stack and retrieve the acknowledgement. If the acknowledgement chain is not 100% stored and requires recalculation, add the cost of another SHA256, but that is all Bob is spending on computations.
MAWS protocol
Even though the BWS protocol is a twoparty transaction, the verifier party (Bob) can only verify that the document has been signed by the signing party (Alice). If Bob disagrees with the document itself, the only option he has is to refuse to acknowledge it, in which case Alice can only repeat the step either indefinitely or until the protocol detects denial of service. The only way to continue would be to reinitialise the protocol with a new fabric at a significant cost.
In this section we will present a solution which gives Bob the power to (in)validate the document at the same time as signing for its receipt. Such a solution is available immediately with the BWS protocol if two stacks are used, one for either party, with Alice and Bob swapping roles for the second stack. This way Alice signs a document using her stack as the signer, and Bob acknowledges as the verifier, then Bob signs his acceptance of the document using his stack as the signer, and Alice acknowledges the receipt of the acceptance as the verifier.
However, it turns out that a single stack is sufficient to sign both the document and its acceptance. Under the bipartite protocol that we are about to present both parties are signers and both are verifiers, but one party has a significantly larger storage and communication (or, more precisely, transmission) requirements than the other.
Before we define the protocol, let us simplify the rules somewhat. Instead of stating it explicitly, we will now assume that each message is validated by the receiver and if the validation fails, a NAK is sent back to the sender, but no change of state occurs at the receiver as if the message were never sent. Also we assume that either the channel is authenticated, in which case the NAK is an authenticated message, or the channel only has weak integrity, and then the NAK is in fact a timeout of a duration exceeding the time required for the maximum number of retransmissions. In both cases the receiving party will be able to identify a NAK with certainty, but in the latter case the reaction to the NAK should be the same as the one to an invalid message, since those can always be injected in the channel by a DoS attacker over large enough period of time. Since we only require weak integrity, the protocols in the sequel will not differentiate between NAKs and invalid messages.
The protocol is fully asynchronous, i.e. each send requires a valid acknowledgement to be received. In the absence of an acknowledgement, the sending party resends its message up to the retransmission limit, then the protocol fails. The protocol does not require the channel between Alice and Bob to have absolute integrity; as before, we mark received values with an asterisk \(*\) to emphasise that they are not necessarily the same as those sent.
Protocol 2
(Mutual Asymmetric Winternitz Stack (MAWS) Protocol)
Parties: Alice and Bob
Protocol parameter: fabric width \(w\in \mathbb {N}\), w is a power of 2.
Initially: as in Protocol 1
Repeat for \(j=2,4..L1\) [only even numbers]:
 R1:

A new transactions document \(\delta _j\) requires signing. Alice computes
$$\begin{aligned} S_{j}={\textbf {p}}(\delta _j,S_{j1})=(D_j,T_j), \end{aligned}$$stores it in local memory overwriting \(S_{j1}\) and computes \(\tau _j=T_j  T_{j1}\).
 R2:

Alice sends \((\delta _j,\tau _j)\) to Bob and goes to step R5 to await acknowledgement.
 R3:

Bob receives \((\delta ^*_j,\tau ^*_j)\) and validates it by \(\epsilon (\delta _j^*,\tau ^*_j,S_{j1})\). If valid, Bob concludes that
$$\begin{aligned} \delta _j=\delta _j^*\;\; \hbox {and}\;\; \tau _j=\tau _j^*, \end{aligned}$$and stores
$$\begin{aligned} S_j=(D_{j1}\triangleright \delta _j,T_{j1}+\tau _j), \end{aligned}$$where \((D_{j1},T_{j1})=S_{j1}\), in local memory overwriting \(S_{j1}\). If Bob approves \(\delta _j\), he forms his signature
$$\begin{aligned} \delta ^\prime _j=H\left( \delta _j \parallel q^{[Lj2]}\right) , \end{aligned}$$otherwise he sets \(\delta ^\prime _j\) to zero.
 R4:

Bob sends the pair \((q^{[Lj1]},\delta ^\prime _j)\) as the acknowledgement to Alice and goes to step R7 to await an acknowledgement.
 R5:

Alice retracts to step R2 unless she receives \((q^{[Lj1]*},\delta ^{\prime *}_j)\) validated by \(H(q^*)=q^{[Lj]}\). If continuing, Alice stores \(q^{[Lj1]}=q^{[Lj1]*}\), computes
$$\begin{aligned} S_{j+1}={\textbf {p}}(\delta ^{\prime *}_j,S_{j})=(D_{j+1},T_{j+1}), \end{aligned}$$and stores it in local memory overwriting \(S_j\), while computing \(\tau _{j+1}=T_{j+1}  T_j\).
 R6:

Alice sends the pair \((\delta ^{\prime *}_j,\tau _{j+1})\) to Bob and waits for acknowledgement at step R9
 R7:

Bob retracts to step R4 unless he receives \((\delta ^{\prime **}_j,\tau _{j+1}^*)\), validated by \(\epsilon (\delta ^{\prime **}_j,\tau _{j+1},S_j)\). If valid, Bob concludes that
$$\begin{aligned} \delta ^{\prime **}=\delta ^{\prime *}_j\;\;\hbox {and}\;\;\tau _{j+1}^*=\tau _{j+1}. \end{aligned}$$and stores
$$\begin{aligned} S_{j+1}=(D_j\triangleright \delta ^{\prime *}_j,T_j+\tau _{j+1}), \end{aligned}$$where \((D_j,T_j)=S_j\), overwriting \(S_j\),
 R8:

Bob sends \(q^{[Lj2]}\) as an acknowledgement to Alice. If \(\delta ^{\prime *}_j=\delta ^{\prime }_j\), the transactions is completed, and Alice knows it. Otherwise, Bobās signature \(\delta ^\prime _j\) was either zero or miscommunicated, and again, Alice knows it. The transaction is null and void; a (complete) repeatround is necessary if both parties still wish to sign.
 R9:

Alice retracts to step R6 unless she receives \(q^{[Lj2]*}\) and validates it by \(H(q^{[Lj2]*})=q^{[Lj1]}\). If valid, she stores \(q^{[Lj2]}=q^{[Lj2]*}\) and checks that
$$\begin{aligned} \delta ^{\prime *}_j=H\left( \delta \parallel q^{[Lj2]}\right) . \end{aligned}$$If the equation holds, then the transaction is completed and Bob knows it. Otherwise Bob either rejected the transaction or his approval was miscommunicated, Bob knows which. Either way, the transaction is null and void; a (complete) repeatround is necessary if both parties still wish to sign.
The protocol is generally robust as the sending of a message is paired with its validation and possible retransmission, except step R4, where Bobās signature is communicated but it cannot be validated before step R7 when Alice has already sent \(\kappa\) hashes and Bobās signature back. If the signature was corrupted in communication at step R7, this would waste the protocol round, in terms of both communication and fabric/chain material.
Security of the MAWS protocol The nonrepudiation properties of MAWS hinge on the fact that Bobās signature is based on the preimage of the latest member of Bobās Winternitz chain disclosed to Alice, namely \(q^{[Nj2]}\). Alice is unable to forge Bobās signature without knowledge of \(q^{[Nj2]}\), and when that value is disclosed to her in step R8, Bobās signature or refusal to sign has been signed by Alice already, in steps R5 and R6.
So it looks as though without hosting a Winternitz fabric, Bob can sign Aliceās documents using nothing more than a single Winternitz chain. The posttransaction adjudication for MAWS is the same as that for BWS, see āAdjudicationā section, except Judy also checks all \(\delta ^\prime\) messages and marks the documents as approved or not approved accordingly.
Reverse Winternitz stack (RWS) protocol
Now let us tighten the communication model. Since the DoS defences would benefit from filtering incoming messages before the protocol calculations based on them are launched anyway, let us assume that Alice and Bob share a weak secret and use a symmetric Message Authentication Code (MAC, e.g. HMAC, based on the same hash function as the chains) to authenticate messages from Alice to Bob and back. Message authentication cannot be used to replace signatures since MACs are symmetric and can be repudiated. However, even a short MAC stops message insertion and message altering attacks very effectively. For example, a 32bit MAC has less than one in a billion chance to be guessed in an attempt to insert or alter a message. On the other hand, for a knownplaintext attack to succeed in obtaining even a short AES128 key, the number of intercepted messages required is many orders of magnitude more than the length of any realistic Winternitz fabric.
Let us therefore adopt a more restrictive channel model whereby a message sent is extremely likely to be received correctly or not at all. Under such conditions MAWS becomes robust and any validation failure can safely be attributed to protocol violation by the sending party.
Given that, we are now able to propose a protocol where Alice has no independent signing function. All Alice does is certify Bobās signatures, effectively turning into a kind of secure signature server. Alice is unable to forge Bobās signature, nor Bob repudiate it. Assuming noncollusion, the mutually mistrustful Alice and Bob are still able to prove to Judy that Bob signed the documents he claims to have signed and to stop him repudiating his signature. The security of the following protocol trivially follows from the security of MAWS.
Protocol 3
(Reverse Winternitz Stack (RWS) Protocol)
Parties: Alice(signature server) and Bob(signer)
Protocol parameter: fabric width \(w\in \mathbb {N}\), w is a power of 2.
Initially: as in Protocol 1
Repeat for \(j=2..L1\):
 R1:

Bob computes the signature
$$\begin{aligned} s_j=H\left( \delta _j \parallel q^{[Lj2]}\right) , \end{aligned}$$where \(\delta _j\) is the document he wishes to sign (or its digest, whichever is shorter), and sends it to Alice via an authenticated channel.
 R2:

Alice eventually receives \(s_j\) from Bob and computes
$$\begin{aligned} S_{j}={\textbf {p}}(s_j,S_{j1})=(D_j,T_j), \end{aligned}$$stores \(S_j\) and sends to Bob \(\tau _j=T_jT_{j1}\).
 R3:

Bob eventually receives \(\tau _j\) and validates it by \(\epsilon (s_j,\tau _j,S_j1)\). If invalid, the protocol fails. Otherwise, Bob stores
$$\begin{aligned} S_j=(D_{j1}\triangleright s_j,T_{j1}+\tau _j), \end{aligned}$$where \((D_{j1},T_{j1})=S_{j1}\), overwriting \(S_{j1}\). Bob also stores \(\delta _j\) under the index j and sends \(q^{Lj2}\) to Alice as the acknowledgement.
 R4:

Alice eventually receives \(q^{[Lj2]}\), checks that \(H(q^{[Lj2]})=q^{[Lj1]}\) and if so, stores \(q^{[Lj2]}\) overwriting \(q^{[Lj1]}\) and completes the round. Otherwise the protocol fails.
The protocol only fails if a party wilfully sends the wrong message. Failure to receive a response should be construed as a communication failure, not a security event, as the protocol stalls awaiting retransmission.
As before, a repudiation attempt from Bob on a given document \(\delta\) will be countered by the retrieval of the latest known q from Alice and a stack of the corresponding depth from Bob. The verifier will then examine all \(s_j\) to find the one for which \(s_j=H\left( \delta \parallel q^{[Lj2]}\right)\), which proves the signature.
The last of the signed documents introduces an uncertainty as to whether or not Alice has completed step R4 on it or not, but it is not a major problem. The verifier may simply delay verification until Alice is quiescent.
Application of RWS to Internet of Things
The variety of IoT devices is very broad. It stretches from systems that have computation and communication capabilities approaching those of ordinary computers, to microcontrollerbased smart sensors on a tight energy budget with lowbitrate longrange (LoRa) radio communications. It is the latter category that presents unique challenges in network security, especially when nonrepudiation is required in a multivendor safetycritical system.
It is little appreciated in literature that IoT communication requirements are quite asymmetric. The success of sending data over the radio depends very much on the transmit power, which has to come out of the overall power budget of the device. IoT platforms tend to transmit little and do it infrequently. There are also legal constraints on the duty cycle and radiated power when operating in the frequency bands available to LoRa transmissions. However, receiving data is possible at a higher data rate spending much less power. In fact the power is used mostly for digital signal processing of the received signals, not the reception process as such; it can be reduced further by doing the processing less fast. In an IoT swarm, the edge server is typically equipped with a more powerful transmitter operating at a higher bitrate. The IoT device can receive such a signal with less battery drain.
Ordinary nonrepudiation protocols, e.g. those that involve cryptographically signing a transaction by both parties, exhibit symmetric computation and communication requirements. For example a 256bit ECDSA produces a 512bit or 64 byte signature, which is not quantum secure. Moreover, even using advanced microprocessors (rather than cheap microcontrollers), such as ARM CortexM4, the signature computation time is measured in hundreds of milliseconds (Fujii and Aranha 2019) compared to hundreds of microseconds for \(\sim\)30 hashes that Bob computes in each round of RWS (\(w=4096\)). The volume of data transmitted by Bob in one round of RWS is the same as it is under ECDSA, namely 32 bytes for the signature s and 32 bytes for the acknowledgment q. The volume of data to receive for Bob is much higher, close to 1 Kbyte. Finally, Bob retains the audit trail of all his signatures with the assurance that all of them (possibly with the exception of the very last one) have been registered by Alice and hence usable in transactions.
The audit trail forces Alice to be honest, especially when there is a system penalty if a proof against Alice is submitted by Bob. If Alice knows that, and if there exists some Proof of Stake for Alice (not necessarily digital), she can be used as Bobās proxy, making it unnecessary for a third party to communicate with Bob for signature validation frequently, especially if delayed validation is compatible with the security model. e.g. in the airplane black box type of application.
Related work
The idea of a hashbased signature scheme is classic, due to Lamport (1979). The basic approach is to associate a pair of nonces with each digit (one for the value 0 and the other for the value 1) of a message digest and use their hashes as the public key. The signer reveals the nonce associated with the value of the corresponding digit to form the message signature, which is only effective for one message. The scheme involves communication of very large signatures. This was improved upon by Merkle (1982) and Winternitz. The former paper proposes to only sign the digits whose value is 1 and to include a checksum to counter bit omission. The latter proposal (Winternitz OneTime Signature, WOTS) is to segment the digest into chunks and use each chunk as an iteration counter in repeatedly hashing the corresponding nonce, again with a checksum guarding against reduction of iteration counters. WOTS was first published as an idea outline in Merkleās conference paper (Merkle 1988), reference 6 of which is to Winternitzās private communication. Neither Merkel nor Winternitz proposed anything to mitigate the onetime nature of Lamportās signature protocol, and the improvements are only in the signature size, which is much shorter than Lamportās, but is still very long compared to publickey cryptography with similar security parameters. This line of research has been continued further; more recent work includes a WOTS\(+\) (HĆ¼lsing 2017) scheme, which extends WOTS, and XMSS (HĆ¼lsing etĀ al. 2018), which extends the original Merkle proposal.
Another line of research was sprung by the seminal paper on HORS (Reyzin and Reyzin 2002), a āHash to Obtain Random Subsetā proposal, which turned out to be very fruitful. The idea here is to hash the digest and partition the hash image into equal length binary integers, the values of which are gathered into an index set. The indices select the preimages to be revealed to form the message signature. An attacker would have to find a different message whose digest produces a subset of the index set under the hash function to obtain a counterfeit signature. The authors of Reyzin and Reyzin (2002) demonstrate that this is computationally hard. The hardness remains significant even when the set of preimages used has expanded after signing a few messages. This approach and its successors are often referred to as fewtime signature schemes. There is an elaboration of HORS by HĆ¼lsing in Bernstein etal. (2015), where the ideas of WOTS\(+\) and an improved version of HORS, HORST, are combined. For the security parameter value 256, which we use as the typical case, the message signature claimed in Bernstein etĀ al. (2015) is 41 thousand bytes, see Table 1 in that paper. This does not compare favourably with about one thousand bytes in the MAWS signature in the typical case, and even less with 64 bytes in RWS (all cases, ignoring input volume). However, the upside of their approach is a short public key, circa 1Ā K bytes, whereas our method would require a public key measured in hundreds of kilobytes (128Ā K in the typical case). Nevertheless, the public key can be stored in an embedded system or obtained by its hash via an unprotected public network, so we do not see the size of the public key as an important parameter.
HORSlike signatures can be shortened further: a recent paper, Lee and Park (2021) claims a reduction by more than a third, but the ballpark cost of communicating a signature of this size is still more than an order of magnitude more expensive than any message of our protocols. Finally, we are aware that the known fewtime signatures have striven to rid themselves of the protocol state as this is seen as undesirable in the general security setting, see (Bernstein etal. 2015). Our protocols are clearly not stateless; however, for the application domain they are intended for it can be an advantage, since not only the transactions but also their ordering is assured by the signature stack; neither can be repudiated. At the end of the spectrum opposite to IoT, where there is continuous communication of largevolume data, the fewtime hashbased signature approach has just seen an improvement (Li etal. 2023).
Protocol versus signature scheme
Since literature on digital signatures is dominated by papers focusing on signature schemes, such as the ones quoted above, the reader may expect the present work to be of the same nature, which it is not. We provide some comments below to draw an appropriate dividing line.
The research community has established certain quality criteria for digital signatures. The central notion for this is the one of signature scheme, which goes back to Goldwasser etĀ al. (1988), where it was first formulated. A signature scheme is a triplet of probabilistic polynomialtime algorithms (G,Ā S,Ā V): a generator G, a signer S and a verifier V, which are used to create a pair (sk,Ā pk) of a secret key and a public key, produce a signature s for a message M using the secret key sk, and to verify, using the public key pk, that the message signature s is valid for the message M, respectively. The scheme is correct iff V(pk,Ā M,Ā S(sk,Ā M)) is true with probability 1 for any message M and any pair (pk,Ā sk) produced by G. Implicit in this definition is the contextfree nature of the scheme. Given the pk anyone should be able to validate any message M based on its s without knowledge of any previous messages that were sent or received by the principals. The proof of a signature is thus selfcontained.
By contrast a signature protocol separates assurances given to the principals engaging in it and any selfcontained proofs a principal is able to submit to an adjudicator. This separation is very fruitful, especially in our chosen case of limited resources, because adjudication is only required in abnormal situations (e.g. catastrophic breakdown, where parties disagree on the origin of the message that caused it). Under normal operating conditions security proofs are only required between the principals, and those may rely on the state of the protocol in addition to the signature of the message and any keys. If the protocol guarantees that every principal has a consistent view of the state and if that can be successfully adjudicated on the basis of each partyās data in case of disagreement (such as the abovementioned breakdown), then the shared protocol state enables the parties to drastically reduce communication without reducing overall security. In our case it is the Winternitz stack, whose security properties have been rigorously studied in āProof of stack security by reductionā section, that embodies the protocol state. Under a Winternitz stack protocol all previous messages influence the signature of the current one.
A Winternitz stack protocol can be treated as a digital signature scheme (G,Ā S,Ā V) only at the point of adjudication. Limiting ourselves to the last protocol, RWS, we could consider as S the mapping of all messages processed so far on the content of Aliceās stack and Bobās response chain, which collectively represent the totality of all signatures. Then we could use as V the validation algorithm described in āAdjudicationā section. However, strictly speaking this would not be a conventional signature scheme, since it does not apply to individual messages in isolation.
Finally, digital signature schemes are often required to resist adaptive attacks, a criterion which is known as Existential UnForgeability against an adaptive Chosen Message Attack (EUFCMA, or, more commonly, EUCMA, Jackson etal. 2019). The criterion is examined by assuming that the attacker can choose and submit messages for the signature oracle S polynomially often, with the messages produced onebyone, taking into account the oracleās previous responses (adaptation). Since our constructed āsignature schemeā does not apply to individual messages but rather to the totality of all messages received so far, adaptation would require rerunning the protocol from the start, which is something no external attacker can do.
Limiting ourselves to RWS, the only possible adaptive actor is Bob, who himself is a party to the protocol. Bob is able to select message for signing and he must know all previous responses from Alice to sign another message, so the EUCMA question is valid even though the EUCMA setting is not. Adaptation would indeed be a concern for a protocol related to a fewtime signature scheme, such as HORS (Reyzin and Reyzin 2002), where the mutual information between the message digest and the private key is less than the information contained in the digest. In the scheme presented in Reyzin and Reyzin (2002) a set is extracted by splitting the digest into fixedsize chunks. Theoretically, an attacker can choose the message to have a digest with many identical chunkvalues thus reducing the size of the set, and with it the number of hash preimages involved in the signature construction, which directly affects the signature security. In the present work the digest is turned into a multiset of a fixed number of elements. Consequently the choice of a message for an attack only influences which chains of a given fabric are used to reveal preimages, not how many preimages are revealed. The EUCMA property is thus assured by construction, requiring no further examination.
Conclusions
The Winternitz stack over a fabric has been proposed as a basis of postquantum digital signature protocols. The security properties of the stack have been studied and a few protocols derived from them. The most interesting protocol, RWS, has a short signature size, 64 bytes, yet it is exclusively hashbased and ensures nonrepudiation. The security level of the protocol depends solely on Aliceās available communication resources and Bobās storage constraints, but not on the partiesā computational resources. For a reasonable amount of storage and compute power the protocol achieves 256bit classical security or 128bit quantum one, which does not diminish as more messages are signed without refreshing the public key. Under realistic assumptions at least 1 mln signatures can be made under the same public key, more if storage/recomputation is not a problem.
The protocol RWS places communication requirements on Alice and Bob asymmetrically, with Alice mostly transmitting and Bob receiving, which helps with the constraints of the low bitrate communication characteristic of the IoT (in particular sensor networks). Alice can then act as a notary and Bob as her client without requiring any trust between them. The protocol provides sufficient assurances to Alice that Bobās signature is genuine, but if this needs to be proven to a thirdparty adjudicator post hoc, Alice and Bob must each supply their validation data. Given a nocollusion threat model, which is mandatory for all bipartite protocols, Bob cannot repudiate. Furthermore Bob cannot sign a document without making Alice aware of it. All of the above aspects closely match a typical IoT scenario.
Availability of data and materials
None produced, none available.
Notes
Remember that the width of a fabric is required to be a power of 2 by the above definition.
So named as it defines the probability of collision in the birthday paradox.
Ignoring the infinitesimal probability of a good approximation of a random oracle producing allzeros (more than 300 zeros in our numerical example)
Note that no bipartite protocol can prevent collusion since the parties can destroy any documents and signatures by mutual consent and run the protocol from the beginning.
Only the latest stack needs to be kept in storage as all the previous ones are its substacks.
Here, as before, we assume that any document that Alice signs contains a nonce making it impossible for two documents to be the same.
See footnote 5.
The NAK (No AcKnowledgement) message can be implemented as noreply, if Alice has a timeout mechanism at her end.
Overwriting the previous value of q.
References
Bellare M, Rogaway P (1993) Random oracles are practical: a paradigm for designing efficient protocols. In: Proceedings of the 1st ACM conference on computer and communications security, CCS ā93. Association for Computing Machinery, New York, pp 62ā73
Bernstein DJ, Hopwood D, HĆ¼lsing A, Lange T, Niederhagen R, Papachristodoulou L, Schneider M, Schwabe P, WilcoxOāHearn Z (2015) SPHINCS: practical stateless hashbased signatures. In: Oswald E, Fischlin N (eds) Advances in cryptologyāEUROCRYPT 2015. Springer, Berlin, pp 368ā397
Fujii H, Aranha DF (2019) Curve25519 for the CortexM4 and beyond. In: Progress in cryptologyāLATINCRYPT 2017. Springer, Berlin, pp 109ā127
Goldwasser S, Micali S, Rivest RL (1988) A digital signature scheme secure against adaptive chosenmessage attacks. SIAM J Comput 17(2):281ā308
HĆ¼lsing A (2017) WOTS\(+\)āshorter signatures for hashbased signature schemes. Cryptology ePrint Archive, Report 2017/965
HĆ¼lsing A, Butin D, Gazdag SL, Rijneveld J, Mohaisen A (2018) XMSS: eXtended Merkle signature scheme. RFC 8391:1ā74
Jackson D, Cremers C, CohnGordon K, Sasse R (2019) Seems legit: automated analysis of subtle attacks on protocols that use signatures. In: Proceedings of the 2019 ACM SIGSAC conference on computer and communications security, CCS ā19. Association for Computing Machinery, New York, pp 2165ā2180
Lamport L (1979) Constructing digital signatures from a oneway function, vol 238. Technical Report CSL98. Technical report, SRI International
Lee J, Park Y (2021) HORSIC\(+\): an efficient postquantum fewtime signature scheme. Appl Sci 11(16):7350
Li L, Lu X, Wang K (2023) eBiBa: a postquantum hashbased signature with small signature size in the continuous communication of largescale data. Comput J. bxad068
Merkle RC (1982) Secrecy, authentication and publickey cryptosystems. UMI Research Press
Merkle RC (1988) A digital signature based on a conventional encryption function. In: Pomerance C (ed) Advances in cryptologyāCRYPTO ā87. Springer, Berlin, pp 369ā378
Reyzin L, Reyzin N (2002) Better than BiBa: short onetime signatures with fast signing and verifying. In: Batten L, Seberry J (eds) Information security and privacy. Springer, Berlin, pp 144ā153
Rogaway P, Shrimpton T (2004) Cryptographic hashfunction basics: definitions, implications, and separations for preimage resistance, secondpreimage resistance, and collision resistance. In: Roy R, Meier W (eds) Fast software encryption. Springer, Berlin, pp 371ā388
Acknowledgements
Discussions with Bruce Christianson and his feedback are gratefully acknowledged.
Funding
No funding acknowledged at this time.
Author information
Authors and Affiliations
Contributions
The single author contributed 100%.
Corresponding author
Ethics declarations
Competing interests
The authors declare no competing interests.
Additional information
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Rights and permissions
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
About this article
Cite this article
Shafarenko, A. Winternitz stack protocols for embedded systems and IoT. Cybersecurity 7, 34 (2024). https://doi.org/10.1186/s42400024002259
Received:
Accepted:
Published:
DOI: https://doi.org/10.1186/s42400024002259