Journal of Cryptographic Engineering (2024) 14:551–575

https://doi.org/10.1007/s13389-024-00358-0

RESEARCH ARTICLE

Progressive and efficient verification for digital signatures: extensions

and experimental results
Cecilia Boschini1 · Dario Fiore2 · Elena Pagnin3 · Luca Torresetti4 · Andrea Visconti5

Received: 22 June 2023 / Accepted: 25 June 2024 / Published online: 5 August 2024
© The Author(s) 2024

Abstract
Digital signatures are widely deployed to authenticate the source of incoming information, or to certify data integrity. Common
signature verification procedures return a decision (accept/reject) only at the very end of the execution. If interrupted prema-
turely, however, the verification process cannot infer any meaningful information about the validity of the given signature. This
limitation is due to the algorithm design solely, and it is not inherent to signature verification. In this work, we provide a formal
framework to extract information from prematurely interrupted signature verification, independently of why the process halts:
we propose a generic verification procedure that progressively builds confidence on the final decision. Our transformation
builds on a simple but powerful intuition and applies to a wide range of existing schemes considered to be post-quantum
secure, including some lattice-based and multivariate equations based constructions. We demonstrate the feasibility of our
approach through an implementation on off-the-shelf resource-constrained devices. In particular, an intensive testing activity
has been conducted measuring the increase of performance on three IoT boards—i.e., Arduino, Raspberry, and Espressif—and
a consumer-grade laptop. While the primary motivation of progressive verification is to mitigate unexpected interruptions, we
show that verifiers can leverage it in two innovative ways. First, progressive verification can be used to intentionally adjust the
soundness of the verification process. Second, our transformation splits verification into a computationally intensive offline
set-up (run once), and an efficient online verification that is faster than the original algorithm. We conclude showing how to
tweak our compiler for progressive verification to work on a wide range of signatures with properties, on three real-life use
cases, and in combination with efficient verification.

Keywords Digital signatures · Efficient verification · IoT · Provable security

1 Introduction
Cecilia Boschini, Dario Fiore and Elena Pagnin have contributed equally
to this work. Digital signatures allow one party (the signer) to use her
secret key to authenticate a message in such a way that, at
B Elena Pagnin any later point in time, anyone holding the corresponding
[email protected]
public key (the verifiers) can check its validity. The typical
Cecilia Boschini nature of signature verification procedures is monolithic: the
[email protected]
validity of a signature is determined only after a sequence
Dario Fiore of tests is completed. In particular, if the execution is inter-
[email protected]
rupted in media res (Latin for “in the midst of things”), no
Luca Torresetti conclusive answer can be drawn from the outcomes of the
[email protected]
partial tests. Although this monolithic nature is not a bur-
Andrea Visconti den in many application scenarios, e.g., validating financial
[email protected]
transactions (Bitcoin protocol), installing certified software
1 ETH - Zurich, Zurich, Switzerland
2 4 AIT - Austrian Institute of Technology, Vienna, Austria
IMDEA Software Institute, Madrid, Spain
3 5 Computer Science Department, Università degli Studi di
Chalmers University of Technology and University of
Gothenburg, Göteborg, Sweden Milano, Milan, Italy

123
552 Journal of Cryptographic Engineering (2024) 14:551–575

updates (Android OS), or delivering e-services (e-Health, GPV [24] (hash & sign), MP [32] (Boyen/BonsaiTree), and
electronic tax systems), it is a major limitation to the adoption GVW [25] (homomorphic) (details in Sect. 5). A large part
of digital signatures in cyber-physical systems [39] and in of the security proof is devoted to a detailed analysis of the
secure eager or speculative executions [30], where the speed leakage due to verification queries (that now involve secret
at which verification is performed plays a crucial role. randomness). We consider this leakage analysis a result of
Le et al. [29] proposed to address unexpected interruptions independent interest as it can be used to estimate leakage in
using a new cryptographic primitive called signatures with similar information-theoretic approaches to provably secure
flexible verification. In a nutshell, such schemes admit a ver- algorithmic speed-ups or eager executions.
ification algorithm that increasingly builds confidence on the This extended version of [10] includes additional details
validity of the signature while it performs more steps. In this on the aforementioned contributions, as well as new material
way, at the moment of an interrupt, the verifier is left with a containing the following contributions. We extend our mod-
value α ∈ [0, 1]∪⊥ that probabilistically quantifies the valid- els for efficient and progressive verification to include sig-
ity of the signature, or rejects it. While the primary motivation natures with advanced properties: ring, threshold, homomor-
of flexible verifications is to mitigate unexpected interrup- phic multi-key, attribute-based and constrained (Sect. 7.1).
tions, we observe that the overarching idea of progressive We also show how to combine efficient and progressive ver-
verification has further impacts. In particular, progressive ification in a secure manner (Sect. 8). To analyze the impact
verification can be used to customize the soundness of the of our technique on constrained devices, we developed a
verification process. For example, a smart device may decide library for Mv-style efficient and progressive verification,
to verify at a 30-bit security level, if the signatures come from and tested it against the Rainbow signature scheme. The
specific sources or the battery is below 30%. From a theo- testing activities were performed on three IoT boards and
retical perspective, progressive verification (as introduced in a consumer-grade laptop, and we show the gathered results
this work later on) draws interesting connections between in our experimental evaluations (Sect. 6).
classical, information-theoretic and post-quantum security Rainbow was chosen because, among the NIST final-
notions. ists, it is the only proposal on which our technique applies
directly with interesting efficiency boosts, and has an avail-
1.1 Our contribution able, ready-for-use implementation. In spite of the recent
attacks against Rainbow [6], we believe that the results of our
This work sets out to dismantle the monolithic nature of sig- work can still be useful to showcase the performance boost
nature verification by designing new verification methods obtainable by applying efficient verification to existing con-
for existing signature schemes. Concretely, we investigate structions. In particular, we emphasize that our technique is
two approaches. The first one is to speed-up the verifica- rather general and applies to any scheme with Mv-style veri-
tion process for polynomially many signatures by the same fication. Therefore we believe that understanding the benefit
signer leveraging a one-time computation on the public key of our approach, even from an experimental perspective, can
(efficient verification). The second approach is to re-design be useful for future work, including future attempts to counter
the verification process so that it allows one to extract sen- the recent attacks, e.g., [13].
sible information even when the algorithm is executed only
partially (progressive verification). In this setting it is of par-
ticular interest to investigate the security implications of this 1.2 Related work
new model and what additional features it may bring.
In detail, we introduce formal definitions and security The problem of trading security for less computation during
models for both efficient (Sect. 2) and progressive (Sect. 3) a verification has been considered first by Fischlin [21] and
verification. In terms of realizations, we focus on a specific Armknecht et al. [2] in the context of message authentication
family of schemes that we call with Mv-style verification codes (MACs). Le et al. [29] and by Taleb and Vergnaud [36]
(in brief, the verification includes matrix–vector multiplica- consider the same question for digital signatures.
tions). For schemes in this class, we propose two compil- Le et al. [29] introduce the notion of flexible signatures and
ers, i.e., two information-theoretic transformations that turn a construction based on the Lamport–Diffie one-time signa-
monolithic Mv-style verifications into provably-secure effi- ture [28] with Merkle trees. Taleb and Vergnaud [36] put forth
cient or progressive ones (Sect. 4). We emphasize that our realizations of progressive verification for three specific sig-
compilers leave the signing algorithm and the signatures as nature schemes (RSA, ECDSA and GPV). Differently from
they are; they only provide an alternative, probabilistic, veri- us, both works demand a modification of the signing or key
fication method for them. Our compilers apply to multivariate generation algorithm of the original signature scheme and
polynomials based schemes including MAYO [7], Rainbow also a time variable be input to the progressive or flexible
[18, 19] and LUOV [8]; and lattice-based schemes including verification.

123
Journal of Cryptographic Engineering (2024) 14:551–575 553

One main difference between our model and those of [21, and the rank of a matrix A; 11×n (resp. 01×n ) denotes the
29, 36] is that we aim to capture progressive verification as row vector of length n that has all entries equal to 1 (resp.
an independent feature that can enhance existing schemes, 0), while In denotes the n by n identity matrix of dimen-
rather than a standalone primitive that requires one to change sion n. We omit the explicit dimensions when they are clear
some of the core algorithms of a signature scheme. This is in from the context. We denote the span (linear space) gen-
a way more challenging as it leaves less design freedom when erated by a set of vectors z1 , . . . , zi in the discrete
 vector
crafting these algorithms. In addition, we define progressive space Zqm as z1 , . . . , zi q = {z ∈ Zqm : z = ij=1 a j z j
verification as a stateful algorithm in contrast to stateless mod q, ∃a1 , . . . , ai ∈ Zq }. We denote by L 1 L 2 the result
[21, 29, 36]: although this makes our model slightly more of appending a list of elements L 2 to L 1 . Given two values
involved, it is comparably more general and can capture more a < b, we denote a continuous interval as [a, b] ⊆ R, and
(existing) schemes. a discrete interval as {a, . . . , b} ⊆ Z. A signature scheme
Our model for efficient verification is close the offline-  = (KeyGen, Sign, Ver) with message space M includes
online paradigm used in homomorphic authentication [3, a key generation algorithm (sk, pk) ← KeyGen(1λ ), a sign
15] and verifiable computation [23]; where a preprocessing algorithm σ ← Sign(sk, μ) that outputs a signature σ on a
is done with respect to a function f , and its result can be message μ, and a verification algorithm Ver(pk, μ, σ ) that
used to verify computation results involving the same f . An outputs 1 (accept) or 0 (reject). Throughout the paper, 
early instantiation of this technique for speeding up the ver- satisfies the properties of correctness and existential unforge-
ification of Rabin-Williams signatures appears in [5]. More ability as defined in [36].
recently, Sipasseuth et al. [35] investigate how to speed up
lattice-based signature verification while reducing the mem-
ory (storage) requirements. The overall idea in [35] is similar 2 Efficient verification for digital signatures
to ours (and inspired to Freivalds’ Algorithm): to replace
the inefficient matrix multiplication in the verification with a The core idea of efficient signature verification is to split
probabilistic check via an inner product computation. How- the verification process into two steps. The first step is a
ever, [35] focuses on the DRS signature [34], and investigates one-time and signature-independent setup called ‘offline ver-
the trade-off between pre-computation time for verification ification’. Its purpose is to produce randomness to derive a
and memory storage for this scheme only. Moreover, the work (short, secret) verification key svk from the signer’s public
lacks a formal, abstract analysis of the security impact of such key pk. Note that the offline verification does not change
a shift in the verification procedure. In contrast, we devise a the signature, which remains publicly verifiable; instead it
general framework to model ‘more efficient’ and ‘partial’ ‘randomizes’ pk to obtain a concise verification key svk that
signature verification. Albeit we developed our approach essentially enables one to verify signatures with (almost) the
independently of [35], our techniques can be seen as a gen- same precision as the standard verification, but in a more effi-
eralization of what presented in [35]. cient way. We remark that for secure efficient verification svk
should be hidden to the adversary, yet, the knowledge of svk
1.3 Notation gives no advantage in forging signatures verified in the stan-
dard way using just pk. The second verification step consists
We denote the set of real values by R, integers by Z, natu- of an ‘online verification’ procedure. It takes as input svk
ral numbers by N, and finite fields of integers by Zq , where and can verify an unbounded number of message-signature
q is a (power of a) prime number. Throughout the paper, pairs performing significantly less computation than the stan-
λ ∈ Z≥0 denotes the parameter for computational security dard verification algorithm. For security, it is fundamental
of a cryptographic scheme. A function ε : Z≥0 → [0, 1] svk remains unknown to the adversary. We remark that gen-
is negligible if ε(λ) < 1/poly(λ) for every univariate poly- erating svk during the offline phase achieves efficient online
nomial poly ∈ R[X] and a large enough integer λ ∈ Z≥0 . verification with no impact on the original signing or key
The abbreviation PPT refers to algorithms that are proba- generation algorithms, which was a drawback of previous
bilistic and run in polynomial time. We denote vectors by work [29, 36].
bold, lower-case letters, and matrices by bold, upper-case
letters. We use v[i] to identify the i-th entry of a vector v, 2.1 Syntax for efficient verification
and A[i, j] to identify the entry in the i-th row and j-th col-
umn of a matrix A. The norm of a vector is denoted as v Our definition of efficient verification lets the verifier set
and unless otherwise specified, it is assumed to be the infinity the confidence level k at which she wishes to carry out the
norm, i.e., v = maxi {v[i]}. AT denotes the transposed of signature verification. Notably k determines the amount of
a matrix. We use r ows(A), cols(A), and r k(A) to respec- computation to be performed and thus plays a central role in
tively refer to the number of rows, the number of columns, the security and the efficiency of the new verification.

123
554 Journal of Cryptographic Engineering (2024) 14:551–575

Definition 1 (Efficient verification) A signature scheme  any pair (μ, σ ) with μ ∈ M and σ such that Ver(pk, μ, σ ) =
admits efficient verification if there exist two PPT algorithms 1; we have that ∀ r ≥ r0 :
(offVer, onVer) with the following syntax1 :    
cost offVer(pk, k) + r · cost onVer(svk, μ, σ )
  < e0 (1)
offVer(pk, k): this is a randomized algorithm that on r · cost Ver(pk, μ, σ )
input a public verification key pk, and a
positive integer k ∈ {1, . . . , λ} (where λ 2.2 Security model for efficient verification
is the security parameter of ), returns a
secret verification key svk. Intuitively,  E realizes efficient verification in a secure way
onVer(svk, μ, σ ): on input a secret verification key svk, a if onVer accepts a signature that would be rejected by Ver
message μ, and a signature σ , the effi- only with negligible probability. In the security game (see
cient online verification algorithm out- Fig. 1), the adversary A has access to the signing oracle
puts 0 (reject) or 1 (accept). OSign as well as the efficient verification oracle OonVer.
The goal of the adversary is to produce a signature σ ∗ for a
For convenience we will refer to the signature scheme message μ∗ that was never queried to OSign and for which
augmented with the efficient verification algorithms as  E = Ver returns 0 (reject) and onVer returns 1 (accept).
(, offVer, onVer), and to the integer value k as confidence
level. Definition 4 (Security of efficient verification) A scheme  E
realizes a secure efficient verification for  if for a given secu-
To be meaningful, a realization of efficient verification rity parameter λ and for any confidence level k ∈ {1, . . . , λ},
needs to satisfy the properties of correctness, concrete atom- for all PPT adversaries A the success probability in the
ized efficiency and security. cmvEUF experiment reported
 in Fig. 1 is negligible,
 i.e.:
AdvA, (λ, k) = Pr ExpA, (λ, k) = 1 ≤ ε(λ, k).
cmvEUF cmvEUF
Definition 2 (Correctness of efficient verification) A scheme
 E = (, offVer, onVer) realizes efficient verification Line 7 of the cmvEUF experiment excludes forgeries
correctly if the following conditions hold. For a given against the original signature scheme. This is justified by
security parameter λ, for any honestly generated key pair the correctness of efficient verification and by the fact that
(sk, pk) ← KeyGen(λ), for any message μ ∈ M,  is existentially unforgeable. Notably, both the security
for any signature σ such that Ver(pk, μ, σ ) = 1, and game and the advantage depend on the confidence level k
for any confidence level k ∈ {1, . . . , λ}; it holds that and assume all algorithms are entirely executed.
Pr onVer(svk, μ, σ ) = 1 svk ← offVer(pk, k) = 1 for
any choice of randomness used in offVer.

Amortized efficiency relies on the fact that running 3 Progressive verification for digital
offVer once and reusing its output r times to run onVer is signatures
computationally less demanding than running the standard
verification Ver r times. To formalize this, we will use the The goal of progressive verification is to incrementally
function cost(·) that given as input an algorithm returns its increase the confidence on the validity of a signature, for
computational cost (in some desired computational model). a given message against a public key. Intuitively, the “confi-
In addition, we parameterize concrete amortized efficiency dence” should be proportional to the amount of computation
with two intertwined variables: r0 (number of instances of invested: the further in the execution we go, the higher the
verification), and e0 (ratio between the cost of r0 efficient accuracy of the decision, and thus the confidence of the final
verifications over r0 standard verifications). The lower the outcome (accept/reject).
value of r0 the sooner  E amortizes the computational cost
of offVer. The lower the value of e0 the more efficient  E is 3.1 Existing approaches to progressive verification
with respect to the standard verification. of signatures

Definition 3 (Concrete Amortized Efficiency) Let r0 be a Taleb and Vergnaud give a very intuitive definition of pro-
non-negative integer and 0 < e0 < 1 be a real constant. gressive verification for digital signatures [36]. They model
A scheme  E realizes (r0 , e0 )-concrete amortized efficient digital signatures with progressive verification as a 4-tuple
verification for  if given a security parameter λ and a con- of PPT algorithms (KeyGen, Sign, Ver, ProgVer) such that:
fidence level k; for any key pair (sk, pk) ← KeyGen(λ), for  = (KeyGen, Sign, Ver) is a correct digital signature
scheme; and ProgVer takes in input a public verification key
1 Here pk denotes a public verification key output by KeyGen. pk, a message μ, a signature σ , and some timing parameter t,

123
Journal of Cryptographic Engineering (2024) 14:551–575 555

Fig. 1 Security model for

efficient verification of
signatures: existential
unforgeability under adaptive
chosen message and verification
attack (security game,
experiment and oracles). A is a
PPT algorithm that can query
the oracles in an adaptive and
parallel way. L S is the list of
messages queried to the signing
oracle

and outputs α ∈ {[0, 1] ∩R} ∪ {⊥}, interpreted as an estimate the progressive verification returns α = ⊥. If none of the
on the accuracy of its decision whether the signature be valid. initial t steps fails, the progressive verification returns the
Moreover, the scheme satisfies the following properties: output of a function αprog (t) ∈ [0, 1] that measures the
Correctness If for some tuple of inputs ProgVer(pk,μ,σ ,t) probability the input will be accepted by Ver. The fact of
outputs ⊥, then Ver(pk, μ, σ ) = 0. increasingly building confidence is reflected by functions
Security If for some tuple of inputs ProgVer(pk, μ, σ , t) αprog that are non-decreasing in t, the number of instruc-
outputs α ∈ [0, 1], then this implies Pr Ver(pk, μ, σ ) = 0 ≤ tions checked before returning the answer. Figure 1 in [36]
1 − α (where the probability is taken over the random coins provides an intuitive and graphical representation of this
of ProgVer). statement.
In a nutshell, if α = ⊥, the progressive verification
deems the signature to be invalid (with 100% accuracy). If Definition 5 (Stateful Progressive Verification) Let T ∈ Z>0
α ∈ [0, 1], the algorithm considers the signature valid, and α and αprog : {0, . . . , T } → [0, 1] be an efficiently com-
tells how accurate this statement is. Since progressive verifi- putable function. A signature scheme  admits (T , αprog )-
cation may be interrupted at any arbitrary point t during its progressive verification if there exists a stateful PPT algo-
execution, in practice α is (the output of) a function αprog (t) rithm ProgVer that takes in input pk, μ, σ and some inter-
that “converts” the progress in the verification process into a ruption parameter t ∈ Z>0 , outputs α ∈ {[0, 1] ∩ R} ∪ {⊥},
value representing the accuracy of a positive outcome. and satisfies the following syntax:

Shortcomings First, similarly to [29], also [36] sees signa-

tures with progressive verification as a stand-alone primitive. ProgVer(st, pk, μ, σ , t)
In contrast we view progressive verification as a feature that 1: α ← ⊥
can augment existing schemes without requiring change to 2: if t < 0 : return ⊥
the core algorithms. Second, the definition lacks a precise 3: if t > T : set t ← T
notion of time complexity and does not model how unex- 4: for j = 0, . . . , t
pected interrupts are handled. The model we introduce in (b, st) ←
the remainder of this section takes care of these aspects. In ProgStep j (st, pk, μ, σ )
addition, we generalize progressive verification to be (possi- if (b = 0) : return ⊥
bly) stateful, which can capture more signature schemes as else (b = 1) : α ← αprog ( j)
well as reuse the same syntax to model both efficient and 5: return α
progressive verification (cf. Sect. 8). For convenience we will refer to the signature scheme
augmented with progressive verification as  P =
3.2 Syntax for progressive verification (, ProgVer, T , αprog ).

In order to model progressive verification as an add-on algo- Concretely, ProgVer is made of T + 1 algorithms
rithm we need to derive from Ver an alternative algorithm ProgStep j , for j = 0 to T , that progressively update the
ProgVer (as introduced in Sect. 3.1), that builds confidence state st. We remark that the formalization into steps is without
on the final verification outcome in an increasing way. With- loss of generality: Ver realizes a trivial progressive verifica-
out loss of generality, this task boils down to identifying a tion for T = 0 where the only step is Ver itself. Finally, the
sequence of T + 1 atomic instructions that we call ProgStep interruption value t is input to ProgVer only, and it is not
with the following properties. Each ProgStep performs a given to each ProgStep j . Thus our syntax models the fact
check of some sort on the input it receives. If one step fails, that the steps are agnostic of the interruption value and must

123
556 Journal of Cryptographic Engineering (2024) 14:551–575

work without knowing when to stop, which is essential to same behavior (accept/reject) with discrepancies happening
capture arbitrary interruptions. with probability negligibly close to αprog (t).
Correctness essentially states that signatures accepted by Our security game has three main differences compared to
the standard verification should also be accepted by the pro- [29]:
gressive one, with the highest confidence allowed by the State: in order to take into account that ProgVer main-
number of steps performed. tains a possibly non-trivial state we allow the adversary A
to interact with the progressive verification oracle OProgVer
Definition 6 (Progressive Verification Correctness) Let  P during the query phase, as well as the signing oracle OSign,
be a signature scheme with progressive verification; ProgVer in a concurrent manner.
satisfies progressive verification correctness if, for any value Interruption: queries to OProgVer have the form (μ,σ , t  ),
t ∈ {0, . . . , T }, for any given security parameter λ, for any where t  is the desired interruption value submitted by A (and
key pair (sk, pk) ← KeyGen(λ), for any admissible state st chosen adaptively).
generated by ProgVer, for any admissible message, given Output: instead of a single bit, our experiment returns a
a signature
 σ such that Ver(pk, μ, σ ) = 1 it holds that: pair (b, t ∗ ). The bit b ∈ {0, 1} flags the absence or the poten-
Pr ProgVer(st, pk, μ, σ , t) = αprog (t) = 1. tial presence of a forgery, while t ∗ ∈ {0, . . . , T } reports the
interruption position used in the final progressive verifica-
We follow the approach of [29] and let the progressive tion. Including t ∗ in the output of the experiment allows us
verification algorithm output a value α that either rejects the to measure security in terms of how close the probability of
signature (α = ⊥), or accepts it with certainty α in the real A wining the experiment is from the expected accuracy value
interval [0, 1]. We use the same interruption variable t as in 1 − αprog (t ∗ ).
[29] to model runtime interruptions of the algorithm execu-
tion.2 Definition 7 (Security of progressive verification (progEUF))
Let  be a signature scheme that admits a progressive ver-
Efficient versus progressive verification At a first glance, effi-
ification realization  P .  P realizes a secure progressive
cient verification and progressive verification seem to have
verification for  if for any given security parameter λ, for
the common goal of reducing the computational cost of a
all PPT adversaries A the success probability in the progEUF
signature verification. However the way this objective is
experiment in Fig. 2 is negligible, i.e.,:
achieved in the two models is quite different.
In progressive verification, the verifier (and thus each  
AdvA, P (λ) = Pr ExpA, P (λ) = (1, t ∗ )
progEUF progEUF
ProgVeri ) is unaware of when the computation will be inter-
rupted, and its execution is independent of t. In contrast, in −(1 − αprog (t ∗ )) ≤ ε(λ).
efficient verification the verifier (running offVer) determines
the confidence level k prior to any actual verification (running
Intuitively, Definition 7 states that an adversary has only neg-
onVer).
ligible probability to make ProgVer output a confidence value
In the latter, the (online) verification is aware of the con-
α ∗ higher than the expected one. Let bad(t) denote the prob-
fidence level k (seen as interruption value), and adapts its
ability of accepting a forgery after t verification steps. Then
execution to k. progEUF
by setting αprog (t) = 1 − bad(t), we get AdvA, P (λ) =
 
Pr ExpA, P (λ) = (1, t ∗ ) − bad(t ∗ ) ≤ ε(λ).
Stateful versus stateless verification We define progressive progEUF
verification as stateful. This allows us to keep the framework
In this work, we prove security in the strongest model
as general as possible. Stateless progressive verification, á la
where t  = t, i.e., A has the power to choose when to stop
[29, 36], can be obtained setting st to ∅, this also removes
the verification. Since we put no restriction on the values
the need for analyzing any cross-query leakage due to state
t queried by A to OProgVer during the game, we will see
reuse.
that by running OProgVer on ‘too few’ steps, A may learn
information about the internal state st.
3.3 Security model for progressive verification
Modelling interruptions
Our notion of unforgeability states that signatures rejected In [29], unexpected interruptions are modeled via an inter-
by the standard verification should also be rejected by the ruption oracle iOracle(λ) that returns a value t ∈ {0, . . . , T }
progressive one, except for an inaccuracy factor due to inter- used by the progressive verification.
ruptions. More formally, Ver and ProgVer should have the However, it is not clear whether A may control iOracle or
not.
2 Our αprog (·) is essentially the inverse of the function iExtract (·) in We overcome these ambiguities by letting A output t 
[29]. with every progressive verification query. For the purpose

123
Journal of Cryptographic Engineering (2024) 14:551–575 557

Fig. 2 Security model for

progressive verification of
signatures: existential
unforgeability under adaptive
chosen message and progressive
verification attack (security
game, experiment and oracles).
A can query the oracles
adaptively, in parallel and
polynomially many times in λ.
L S is the list of messages
queried to the signing oracle

of this work, we consider the strongest security model in tational complexity of Ver is dominated by the matrix–vector
which the interruption oracle returns the adversary’s value, multiplication, i.e., cost(Check)  cost(Mv) ∼ mn field
i.e., t ← OInt(t  ) with t = t  . This resembles side-channel multiplications (for M ∈ Zqn×m ).
attack settings, where A may try to freeze the execution of Our compiler for efficient verification is detailed in Fig. 4
the verification. with a sketch of instantiation for the lattice-based scheme
It is possible to relax and generalize our model by set- GPV08 [24] as a running example. Further details on this
ting a different interruption oracle OInt, programmed at the scheme as well as instantiations and details on the concrete
beginning of the game. At each verification query, OInt takes efficiency estimates for MP12 [32], Rainbow [19] and LUOV
as input the adversary’s suggestion for an interruption posi- [8], are deferred to Sect. 5. Table 1 summarizes the efficiency
tion t  and outputs the value t to be used by the progressive results. We obtain secure efficient online verification using
verification. In case t = t  , we are modelling side channel as little as 0.4% (resp. 50%) of the computational cost of the
attacks, but we can also let t be independent of t  . A realistic standard verification for lattice-based signatures on exponen-
definition of OInt is outside the scope of this work. tially large fields (resp. for Rainbow).

Overview of our technique Our transformation takes as input

, a signature scheme with Mv-style verification; and it
4 Generic compilers returns  E = (, offVer, onVer) that securely instantiates
efficient verification for . The heart of our compiler lever-
In this section, we present generic transformations (compil- ages the fact that for any pair of vectors σ and u (often derived
ers) that augment a signature scheme  with either efficient from the message μ), and for any matrix A (of opportune
(Sect. 4.1) or progressive verification (Sect. 4.2). dimensions) if A · σ = u then for any random vector c (of
Our technique works for a specific class of signature opportune dimension) it holds that c · (A · σ ) = c · u. Collect-
schemes that we call with Mv -style verification. In such σ
schemes, Ver can be seen as the combination of two types of ing variables on the left hand yields (c · [A| − In ])· = 0.
u
verification checks: a matrix–vector multiplication (referred Thus one can precompute the vector z ← c · [A| − In ] and
to as Mv = 0, for appropriate matrix M and vector v) and run the efficient online verification check z · v = ? 0, where

other generic checks (collected in the Check subroutine), see v ← (σ , u). In a nutshell the idea is to replace the matrix–
Fig. 3 for details and an explanatory example. Among the vector multiplication with a vector-vector multiplication in a
schemes with Mv-style verification we highlight some of the sound way. Correctness and efficiency are immediate. Sound-
seminal lattice-based signatures [11, 14, 24, 32], homomor- ness essentially comes from the fact that if z · v = 0, then
phic signatures [9, 20, 25], and multivariate signatures [8, with all but negligible probability the original system of linear
19]. equations A · σ = u is satisfied too, as proven in Theorem 1.
We emphasize that our compiler leaves the signing algo-
4.1 A compiler for efficient Mv-style verifications rithm and the signatures as in the original scheme. It only
provides an alternative, probabilistic, verification algorithm.
We present a generic way to realize efficient verification for
signatures with Mv-style verification, whenever the compu-

123
558 Journal of Cryptographic Engineering (2024) 14:551–575

Fig. 3 General structure of a signature with Mv-style verification (on the left); an instructive example: the GPV08 [24] signature verification (on
the right)

Fig. 4 Our compiler for efficient verification of signatures with Mv-style verification. The four scheme-dependent subroutines are: parse pk and
GetZ (in onVer)[ and Check and GetZV (in offVer). The computational complexity of onVer is linear in k, the chosen confidence level

4.1.1 Security analysis poly(λ) << q k is a bound on the total number of verifi-
cation queries and q is the modulo of the algebraic structure
Despite the construction being intuitive, analysing the leak- on which  is built.
age due to verification queries that reuse the same svk is not
Remark 1 For simplicity, Theorem 1 considers only existen-
trivial and is one main technical contribution of this result.
tial unforgeability. The statement and the proof adapt with
ease to other security models such as strong and selective
Theorem 1 Let  be an existentially unforgeable signa-
unforgeability.
ture scheme with Mv-style verification (as in Fig. 3). The
scheme  E = (, offVer, onVer) obtained via our com- Proof of Theorem 1 In the cmvEUF security experiment
piler depicted in Fig. 4 is existentially unforgeable under (Fig. 1), the winning conditions require A to produce a
adaptive chosen message and efficient verification attacks. message-signature pair (μ∗ , σ ∗ ) such that μ∗ has not been
Concretely, the advantage is AdvA, C M V A (λ, k) ≤ qV +1
q k −qV queried to the signing oracle during the game (existential
where k ∈ {1, . . . , r k(M)} denotes the chosen confidence unforgeability); σ ∗ is invalid under the standard verification,
level that grows up to the rank of the matrix M, qV = i.e., Ver(pk, μ∗ , σ ∗ ) = 0; and the pair is accepted by the

123
Journal of Cryptographic Engineering (2024) 14:551–575 559

online verification, i.e., onVer(svk, μ∗ , σ ∗ ) = 1. The goal The final steps of the proof rely on the following lemma.
of the proof is to bound the probability this event occurs.
Lemma 1 For every i = 1 to qV + 1, it holds that
Let Win be the event {ExpcmvEUF
A, (λ, k) = 1}. Let i = 1 to
qV be the index of the queries (μi , σ i ) submitted by A to the
  
OonVer oracle. Define the family of events badi (for i = 1 Pr badi = 1 | i−1
j=1 ¬bad j ≤ .
1
to qV + 1) as: q k −(i−1)

The proof of Lemma 1 is deferred momentarily to let us

badi := {Ver(pk, μi , σ i ) = 0 ∧ onVer(svk, μi , σ i ) = 1}
complete the reasoning that proves the theorem. Using the
where badqV +1 corresponds to A returning a valid forgery inequality provided by Lemma 1, it is easy to see that
qV +1 i−1 qV +1
i=1 Pr badi = 1 | j=1 ¬bad j ≤ i=1 q k −(i−1) .
1
(μ∗ , σ ∗ ) := (μqV +1 , σ qV +1 ) at the end of the experiment.
We can rewrite the winning condition of the security exper- 1
Indeed, q k −(i−1) ≤ q k −q1
for all integers i in [1, qV + 1]
iment as Win = {badqV +1 ∧ μ∗ ∈
V
/ L S } (recall that L S is and for all qV , q, k ∈ N satisfying
qV +1 +1
the list of messages queried to the signing oracle in the game qV < q k . Thus i=1 1
q k −(i−1)
≤ qqkV−q , which proves
V
execution). Consider the event Bad defined as “there exists the bound on the advantage. 

at least one query index i in the game execution for which  i−1 
badi occurs”. Formally: Proof of Lemma 1 To upperbound Pr badi = 1| j=1 ¬bad j
⎧ ⎫ we need to analyze the information leakage due to verifica-
⎨ Ver(pk, μi , σ i ) = 0 ⎬ tion queries. First of all, by correctness onVer(svk, μi , σ i ) =
Bad := ∃ i ∈ {1, . . . , qV } : ∧ . 0 ⇒ Ver(pk, μi , σ i ) = 0 and Ver(pk, μi , σ i ) = 1 ⇒
⎩ ⎭
onVer(svk, μi , σ i ) = 1 onVer(svk, μi , σ i ) = 1 for every possible svk generated
by offVer from pk. Leakage about svk happens in two cases:
Hence,
when an event badi occurs (OonVer accepts where the stan-
    dard verification would reject); and when OonVer rejects a
C MV A
AdvA, (λ, k) = Pr Win ∧ Bad + Pr Win ∧ ¬Bad
    query (here A may learn that some combination of rows of
≤ Pr Bad + Pr Win | ¬Bad pk must appear in svk). Equation (2) gives us a way to bound
the adversary’s advantage (and thus, the magnitude of this
where the inequality comes from applying the definition leakage) in terms of the events badi and ¬badi .
of conditional
 probability and upperbounding Pr Win Bad Consider the i-th query (μi , σ i ) to OonVer. If the oracle
and Pr ¬Bad by 1.  returns 0, the adversary learns that C · (Mi · vi ) = 0 mod q.
We notice that Pr Win ¬Bad is essentially the probabil- In other words, there is at least one row of C ∈ C := {C ∈
ity that the event badi occurs only for i = qV + 1 and never Zqk×n : r k(C) = k}, say c j , that is not in the hyperplane
before, i.e., orthogonal to wi := Mi · vi , i.e., c j · wi = 0 mod q. Note
  that A knows wi since (Mi , vi ) can be computed from the
  
qV
Pr Win ¬Bad ≤ Pr badqV +1 | ¬badi pk, μi and σ i .
i=1 Let us introduce the sets Hi ⊆ C of full-rank matrices
  C ∈ C whose rows are all orthogonal to wi , formally:
In order to bound Pr Bad , we define events Badi∗ (for ⎧ ⎤ ⎡ ⎫
i = 1 to qV ) as “badi occurs
 for the first
 time at query i”, ⎨ c1 ⎬
c · wi = 0 mod q
∗
namely Badi = badi ∧ i−1 Hi := C ∈ C : C = ⎣. . .⎦ ∧ j .
j=1 ¬bad j . Then we have ⎩ ∀ j = 1, . . . , k ⎭
ck
  qV  qV  
Pr Bad = Pr i=1 Badi∗ = i=1 Pr Badi∗
qV  i−1  We assume A be able to pick the vectors wi ∈ Zqn  {0}
≤ i=1 Pr badi | j=1 ¬bad j of her choosing (e.g., by generating suitable pairs (μi , σ i )).
This assumption is generous as it gives the adversary a large
where the second equality holds because the events Badi∗ amount of power and freedom in the game. The restriction
are all disjoint, and the inequality follows from applying w1 = 0 is technical, as otherwise Ver(pk, μ1 , σ 1 ) = 0,
thedefinition of conditional
 probability and upperbounding which is a necessary condition for OonVer leaking informa-
i−1
Pr j=1 ¬bad j by 1, for all i. Thus: tion about svk.
At the first verification query (μ1 , σ 1 ), A has no informa-
⎡ ⎤
V +1
q tion about C beyond the fact that it was uniformly sampled

i−1
C MV A
AdvA, (λ, k) ≤ Pr ⎣badi | ¬bad j ⎦ . (2) from the set C := {C ∈ Zqk×n : r k(C) = k}. There-
i=1 j=1 fore, for any choice of w1 = 0, if the event bad1 occurs,

123
560 Journal of Cryptographic Engineering (2024) 14:551–575

then bad1 = {C 1
 · w1 = 0 mod q ∧ C ←  C}, thus
$
≤
Pr[bad1 ] = Pr C · w1 = 0 mod q ∧ C ← $ C = H1 . qk − (i − 1)
C
The first (rejected) verification query leaks the fact that where the last bound follows from the chain:
C ∈ C \ H1 .
For the second verification query, without loss of general- 1 1
q n−1 > q n−k ⇔ < n−k
ity let w2 be linearly independent from w1 , i.e., w2 ∈
/ w1 q . q n−1 q
In this case, we have
1 1 1− 1
q n−1
⇔ 1− >1− ⇔ >1,
q n−1 q n−k 1− 1
Pr[bad2 ¬bad1 ] = q n−k

= Pr[C · w2 = 0 mod q | C ← $
C ∧ C ∈ (C \ H1 )] as 1 < k < n and q > 1. 

 
Pr C · w2 = 0 mod q ∧ C ← $ C ∧ C ∈ (C \ H )
1 Lemma 2 Let C := {C ∈ Zqk×n : r k(C) = k} be the set of
=  
Pr C ←$ C ∧ C ∈ (C \ H )
1
k × n matrices that are full rank and have entries in Zq (as
  introduced in the proof of Lemma 1).
Pr C · w2 = 0 mod q ∧ C ← $ C
For any given set of vectors {w1 , . . . , wqV +1 } ⊆ Zqn such
≤  
Pr C ← $ C ∧ C ∈ (C \ H )
1
that wi ∈
/ w j q for every i = j, define the collection of sets
qV +1
|H2 | {Hi := {C ∈ C : C · wi = 0 mod q}}i=0 ⊆ C contain-
|C| |H1 |
= |C\H1 |
= ing the matrices having the corresponding wi in their right
|C \ H1 | kernel and H0 = {∅}. It holds that ∀ i = 1, . . . , qV :
|C|
⎛ ⎞
where the inequality follows from the fact that, given three i−1 # $
qn − 1
events E 1 , E 2 , E 3 , it always holds that Pr[E 1 ∧ E 2 ∧ E 3 ] ≤ C\⎝ H j ⎠ ≥ |H1 | · − (i − 1) . (4)
q n−k − 1
min{Pr[E 1 ∧ E 2 ], Pr[E 1 ∧ E 3 ], Pr[E 2 ∧ E 3 ]}; and the j=0

last equality follows since the hyperplanes H1 and H2 have

the same dimension. Proof of Lemma 2 It is easy to see that the cardinality of C is:
The same reasoning applies to the generic i-th verification
|C| = (q n − 1) · (q n − q) · . . . · (q n − q k−1 )
query, where, w.l.o.g., A chooses wi outside the space gen-
erated by the previous w j ’s, i.e., w i ∈
/ w1 , .. . , wi−1 q . At %
k−1
 =q
k(k−1)
2 · (q n− j − 1).
i−1
such query, A knows that C ∈ C \ j=1 H j . Analogously j=0
as before we get that
⎡ ⎤ as we have full freedom for how to pick the first row of

i−1 C (except for c1 = 0); for the second row, we can pick any
Pr ⎣badi = 1 | ¬bad j ⎦ vector c2 that is in Zqn but not in the span of the previous row of
j=1 C (to keep the matrix full rank), and so on. The formula after
 
the final equality follows from decomposing each (q n − q j )
Pr C · wi = 0 mod q ∧ C ← $ C
& k(k−1)
≤     factor as q j (q n− j −1) and observing that k−1 j=1 q = q
j 2 .
i−1
Pr C ∈ C \ j=1 H j ∧ C←$ C The same reasoning applies to computing the cardinality of
| H1 | a generic Hi (for i > 0), after noticing that the rows of the
=   . (3) matrices C ∈ Hi must be picked (as linearly independent
i−1
C\ j=1 H j vectors) from the (n −1)-dimensional hyperplane orthogonal
to wi ; thus
Lemma 2 (stated and proven next) concludes the proof
showing that ∀ i = 2, . . . , qV + 1: %
k−1
k(k−1) %
k−1
|Hi | = (q n−1 − q j ) = q 2 · (q (n−1)− j − 1)
    j=0 j=0
i−1 q n −q
C\ j=1 H j ≥ |H1 | · − (i − 1) .
q n−k −1 k(k−1) %
k
=q 2 · (q n− j − 1)
Substituting this value into Eq. (3) returns: j=1

This proves the base case (i = 1) of the bound in (4):


i−1
|C  ∅| = |H1 | · qqn−k−1
n
1 , since, compared to |H|, |C| has
Pr[badi = 1 | ¬bad j ] ≤ −1
1−q 1−n
j=1 qk · 1−q k−n
− (i − 1) the additional factor j = 0 and the missing factor j = k.

123
Journal of Cryptographic Engineering (2024) 14:551–575 561

q n−k −1
Concretely this means that: Pr[bad1 ] ≤ . For i = 2, 4.2 A compiler for progressive Mv-style verification
q −1 
n

|H1 | qqn−k−1
n
again we get |C\H1 | = |C|−|H1 | = −1
− 1 . For
Our compiler for progressive verification builds on the result
i = 3, we remove from the pool of eligible C all those matri- presented in Sect. 4.1. Given a signature scheme  with Mv-
ces in H1 ∪ H2 , i.e., that have either w1 or w2 in their right style verification, we define the T steps of a progressive
kernel.3 In other words, matrices composed by only rows verification  P for  as shown in Fig. 5.
orthogonal to w1 or to w2 . The hyperplanes w1⊥ and w2⊥ both The value T sets the upper bound on the number of linear
have dimension n − 1, and since we are in a space of dimen- constraints the verifier wants to check, hence T = r ows(M),
sion n, they must intersect in a subspace of dimension n − 2. where M is the matrix employed in the original signature ver-
For a tighter bound we use: H2 \ H1 = H2 − H1 ∩ H2 and ification of . The set of admissible states S includes ∅ and
recall that 0 ≤ H2 − H1 ∩H2 ≤ H1 . Hence after the second any possible state output by some ProgVeri , specifically S =
rejected query the number of possible C becomes:  
{0, 1}×Zrqows(Z )×cols(Z ) ×Zrqows(v)×cols(v) ×{0, 1}λ ∪ ∅. We
extract the confidence level from the probability of a progres-
|C \ (H1 ∪ H2 ) | = |C| − |H1 | − |H2 | + |H1 ∩ H2 | sive forgery (as motivated by the proof of security given in
qn − 1 Theorem 1). It is easy to see that the probability that an adver-
= |H1 | · ( n−k − 2) + |H(n−2) |
q −1 sary creates a progressive forgery for an interruption step t
n−t −1
qn − 1 % k−1 is at most qq n −1 , this follows from the same reasoning as in
= |H1 | · ( − 2) + q k(k−1)/2 (q n− j − 1) the proof of Theorem 1 for efficient verification. Concretely,
q n−k −1
j=2 the bound is derived from the proof of Lemma 2, where we
−1qn 1 only consider Pr[bad1 ] as svk is refreshed with every new
= |H1 | · ( − 2 + n−1 )
q n−k − 1 (q − 1)(q n−k − 1) efficient verification query, and so there is no useful cross-
qn − 1 query leakage, and we replace the confidence level k of the
≥ |H1 | · ( n−k − 2). efficient verification with the interruption parameter t. If the
q −1
size of the underlying algebraic structure is q = 2poly(λ) this
Remark that C could be still composed by some elements probability is negligible already for t = 1. In other words,
of H1 and some of H2 \ H1 ; this would be consistent with for signatures with Mv-style verification defined on expo-
A’s view at this point. nentially large algebraic structures efficient verification and
We can now proceed by induction, assuming (4) holds for progressive verification coincide, trivially. The interesting
the query index i, prove it for i + 1. case is q = poly(λ), as the adversary could create a progres-
sive forgery with non-negligible probability. We remark that
⎛ ⎞ in this section we are not targeting efficiency, and our instanti-
i i−1
C\ H j = C \ ⎝( H j ) ∪ Hi ⎠ ations of progressive verification refresh the svk produced by
j=0 j=0 offVer at every verification query. This way, A cannot exploit
⎛ ⎞ the information possibly leaked by a progressive forgery in
i−1 i−1
future forgery attempts.
= |C| − H j − |Hi | + ⎝ Hj⎠ ∩ Hj
Finally, we note that, as in the case of efficient verification,
j=0 j=0
⎛ ⎞ our compiler leaves the signing algorithm and the signatures
i−1 i−1
as in the original scheme, and only provides an alternative
= C\ H j − |H1 | + ⎝ Hj⎠ ∩ Hj verification algorithm which achieves the progressive verifi-
j=0 j=0
cation property.
i−1
≥ C\ H j − |H1 | 4.2.1 Security analysis
j=0
# $
qn − 1 Theorem 2 Let  be an existentially unforgeable signature
≥ |H1 | · − i + 1 − |H1 |
q n−k − 1 scheme with Mv-style verification (as of Fig. 3). Then the
# n $
q −1 scheme  P obtained via our compiler (in Fig. 5) is a secure
= |H1 | · −i . realization of progressive verification for .
q n−k − 1


 Proof Recall that an adversary A wins the security experi-
ment in Definition 7 if it outputs a message-signature pair
3 The vectors w are assumed not to be multiples of one another. Oth- (μ∗ , σ ∗ ) and an interruption t  such that:
(1) (μ∗ , σ ∗ ) is rejected by Ver, but accepted ProgVer when
i
erwise, A does not extract new information from a rejection, i.e., there
is no additional leakage. it is interrupted at step t ∗ ← OInt(t  ); and

123
562 Journal of Cryptographic Engineering (2024) 14:551–575

(2) the progressive verification algorithm outputs a too ification (enforcing the norm bound β on the signature). The
high confidence level αprog (t ∗ ). GetM algorithm takes in input the public matrix P K = A,
Following Definition 7, we can realize secure and tails to it the identity matrix: M = [A| − In ]. The GetZV
progressive
 verification by setting αprog (t) = routine returns the matrix Z (explained momentarily) and
progEUF
1 − Pr ExpA, (λ) = (1, t) + ε(λ) for all t = 0, . . . , T . the vector v = [σ |H(μ) · 11×n ]. The matrix Z is made up of
The core part of the proof is to estimate this probability. the same ‘randomized key’ vectors produced by GetZ during
Recall that our compiler for efficient Mv-style verifica- the offline verification, i.e., zj = z j ← c j M = [c j A| − c j ].
tion (in Fig. 5) runs offVer at every verification query (line Thus the core verification check (line 7 in onVer) is actually
1 in ProgVer0 ). This means that every verification query is ensuring that zj v j = 0, i.e., c j · A · σ = c j H(μ) which is
answered using a freshly generated svk. In particular, the the probabilistic check of the original verification equality.
progEUF
final verification (line 4 in the ExpA, P (λ) in Fig. 2) checks Efficient Verification for MP12 [32].
A’s output using independent randomness from the previous The parse pk procedure assigns P K ← A = [Ã|A0 | . . .
queries. So, whatever information the adversary may have n×(m̄+nlog q)
| A ] ∈ Zq (the matrix identifying the signer’s
collected from previous queries is useless to win the exper- public key), where m̄ = O(nlog q), and  denotes the num-
iment. As a consequence, the probability that the adversary ber of bits in the message, i.e., μ ∈ {0, 1} . The auxiliary
wins the game equals the probability that the adversary out- public information is P K .aux = (u, β). The Check proce-
puts a valid forgery without querying OProgVer. The latter dure is exactly as in the original verification (enforcing the
is precisely the probability of the event bad1 defined in the norm bound β on the signature). The GetM algorithm takes
proof of Theorem 1, where now we consider the matrix C to in input the public matrix P K = A, and appends to it the
have t ∗rows instead of k. Hence  from Lemma 1 it follows identity matrix to obtain M = [A| − In ]. The GetZV routine
that Pr ExpA, (λ) ≤ (1, t ∗ ) = q1t ∗ and:
progEUF
returns the matrix Z and the vector v. The matrix 
 Z is made

up of vectors of the form z j = [z̃ j | z j + i=1 μ[i]zij |c j ]
0
progEUF that identify a message-dependent lattice (called Aμ in [32]).
AdvA, (λ)
  The vector v is the concatenation of the signature with the
= Pr ExpA, (λ) = (1, t ∗ ) − (1 − αprog (t ∗ ))
progEUF
auxiliary vector, i.e., v = [σ |u]. Note that u is the same for
# # $$ all messages; thus, one could further optimize the online ver-
1 1
≤ t∗ − 1 − 1 − t∗ =0. ification by computing (once and for all) the k inner products
q q
z j [m̄ + nlog q + 1] = c j · u during the offline phase. To

 conclude we notice that the online verification ensures that
zj v j = 0, i.e., c j · Aμ · σ = c j · u which is the probabilistic
check of the original verification equality.
5 Examples of efficient verification
5.2 From multivariate equations
Because any instantiation of our compiler is completely
determined by the four subroutines parse pk, GetM, Check, For signatures based on multivariate equations we take Rain-
and GetZV, in what follows we explain only how these four bow, MAYO, and LUOV as examples. We consider Rainbow,
algorithms work. The complete descriptions of offVer and despite it being broken, as it allows us to anayze the impact of
onVer are derived using the general structure given in Fig. 4. our technique in practice, thanks to its implementation made
available for the NIST standardization process.
5.1 From lattices
Efficient Verification for Rainbow [18]. In the description
We present concrete instantiations of our compiler for two below we consider the standard Rainbow verification. A sim-
categories of LBS: ‘hash & sign’ with representative the ilar approach can be used to speed up the verification also
GPV08 signature [24], and ‘Boyen/BonsaiTree’ style with in the “cyclic” and the “compressed” Rainbow variants as
representative MP12 [32]. in those cases the verification includes an additional initial
phase to reconstruct the full public key. We recall that in
Efficient verification for GPV08 [24]. The parse pk proce- this scheme the public key contains a system of m multivari-
dure splits the public key into P K = A ∈ Zqn×m (the matrix ate quadratic polynomials in n variables. For convenience,
identifying the signer’s public key), and the auxiliary public let N = n(n + 1)/2 and consider the field F = F2r .
information P K .aux = (H, β), i.e., a description of a full- Using a Macaulay matrix representation we can visualize
domain hash function H : {0, 1}∗ → Zqn and the norm bound this system as a wide matrix composed of a quadratic term
β ∈ R. The Check procedure is exactly as in the original ver- Q (actually a m × N submatrix), a linear term L (m × n

123
Journal of Cryptographic Engineering (2024) 14:551–575 563

Table 1 A summary of the concrete efficiency achieved by various instatiations of our compiler for efficient verification
Ring or Field Size (representative schemes) Min. Accuracy Level for Concrete Amortized Online Efficiency
cost(onVer)
128-bit security Efficiency (see Defi- cost(Ver) = kn0
nition 3)

exponential: q = 2128 (FMNP [20]; GVW [25]) k0 = 1 (r0 = 2, e0 = 0.51) 256 < 0.4%
1

large poly.: q = 230 (Boyen [11]; GPV [24]; MP [32]) k0 = 5 (r0 = 6, e0 = 0.86) 256 < 2%
5

small poly.: q = 16 (Rainbow [19] F24 -(36, 32, 32)) k0 = 32 (r0 = 65, e0 = 0.99) 64 = 50%
32

 
In the table, k0 denotes the minimum accuracy level that ralizes efficient verification with 128 bits of security, i.e., for which Pr Bad ≤ 2−128 is
cost(offVer(pk,k ))+r·cost(onVer)
negligible (cf. proof of Theorem 1, with qV = 230 ); r0 is the smallest positive integer for which 0
r·cost(Ver) < 1, and e0 is a (tight)
upperbound on this ratio

h ← H(H(d)salt) and outputs the vector v = [s̃|s|1|h],

where s is part of the signature and s̃ is the ‘quadratic
vector’ obtained by computing all products of pairs of ele-
ments in s (with monomials ordered lexicographically ),
i.e., s̃ ← [s[1]2 , s[1]s[2], . . . , s[n − 1]s[n], s[n]2 ]. Clearly
zj · v = 0 if and only if c j · (Qs̃ + Ls + C) = c j · h, which
is a probabilistic check of the original system of verification
equations in Rainbow.

Efficient Verification for MAYO [7]. MAYO signatures are a

“whipped up” version of unbalanced oil and vinegar (UOV)
signatures. The public key is a trapdoored multivariate map
P : Fqn → Fqm , which consists of a system of m multivariate
quadratic polynomials in n variables, where all polynomials
share a common vanishing linear space O ⊆ Fqn (the oil
space). Beullens optimizes the public key generation so that
Fig. 5 Our compiler for progressive verification of signatures with each polynomial ' pi can( be represented by a matrix of the
Mv-style verification. The algorithms offVer, Check and GetZV are (1) (2)
Pi Pi
precisely as defined in Sect. 4.1, Fig. 4, and T = r ows(M). The nota- form Pi = (3) ∈ Fqn×n and the evaluation of an
tion Z [i, ∗] describes the i-th row of the matrix Z , similarly v[∗, i]
0 Pi
describes the i-th column of v (which is usually a vector v, but may be input x ∈ Fqn is done in the natural way: pi (x) = x T Pi x.
a matrix in some constructions) MAYO signatures also employ a full-domain hash function
H, and 2 “emulsifier” matrices Ei, j ∈ Fqm×m that are part
of the public parameters, that are the same for all signers.
submatrix) and a constant term C (a m × 1 vector). The The parse pk procedure extracts from the public key the
parse pk procedure extracts from the public key P K this matrices P K = (P1 , . . . , Pm ) and other public parameters
P K .aux = (H, {Ei, j }i, 
matrix pk = [Q|L|C] ∈ Fm×(N +n+1) and a description j=1 ).
of a full-domain hash function H : {0, 1}∗ → Fm as the The GetM algorithm extracts the emulsifier matrices Ei, j
auxiliary public information P K .aux = H. The Check pro- from P K .aux and combines them in the matrix M = (E1,1 ,
cedure is trivial and always returns 1. This is because the E2,2 , . . . , E, , E1,2 , . . . , E−1, , −Im ) ∈ Fqk×m(L+1) , where
whole verification can be written as a matrix–vector multi- L = ( + 1)/2 is the total number of emulsifier matrices.
plication. The GetM algorithm extracts from P K the matrix In this case svk consists of: k the confidence level; Z the
representing the system of quadratic multivariate equations compressed version of the train of emulsifier matrices with
[Q|L|C]. Finally, it appends to this the identity matrix, so the final block being the randomness used for compression;
M ← [Q|L|C| − Im ]. We remark that M can be seen as a H the hash function; and P K the polynomials of the signers’
matrix of blocks, where any block has the same height (m = public key. Notably, in MAYO we do not apply our trans-
number of rows), but different length (number of columns). formation to P K , but rather to the emulsifier contained in
The GetZV routine reads the matrix Z = Z made up of P K .aux. Thus Z is general and can be used to efficiently
the rows zj = z j ← c j M = [c j · Q|c j · L|c j · C| − c j ] ∈ verify signatures by any signer using the same MAYO set-
ting (the public parameters).
F1×N +n+1 . In addition, this algorithm parses the signature as
The Check algorithm is trivial and always returns 1.
σ = (s, salt), computes the (salted) hash of the message d as

123
564 Journal of Cryptographic Engineering (2024) 14:551–575

The GetZV algorithm parses σ as (salt, s1 , . . . s ). It uses our findings, that we motivate below. Observe that we only
Z = Z ∈ Fqk×m(L+1) and v = (s̃, ṽ), where ṽ = H(μsalt) compute concrete parameters for Rainbow, so that they can be
and s̃ = (P(s1 ), . . . , P(s ), P  (s1 , s2 ), . . . P (s−1 , s )) ∈ compared with the results of our implementation. The analy-
(+1)
(Fqm ) 2 , here P is the polar form of P. sis of MAYO and LUOV can be conducted analogously when
optimized implementations will be available.
Efficient Verification for LUOV [8]. The parse pk proce- The computational complexity of Ver for signature with
dure splits the public key into P K = (public.seed, Q2 ) (the Mv-style verification, e.g., [8, 18, 19, 24, 25, 32], is domi-
concise information needed to retrieve the full signer’s public nated by a matrix–vector multiplication. Let n = r ows(M)
key), and the auxiliary public information P K .aux = H, i.e., and m = cols(M), with m ≥ n. The cost of computing M · v
a description of a full-domain hash function H : {0, 1}∗ → is, in the worst case, nm filed multiplications. Our offline ver-
Fm , where m = r ows(Q2 ) and F = F2r . The Check pro- ification algorithm executes k vector–matrix multiplications
cedure is trivial and always returns 1. This is because the (one for each zj in Z ), resulting in knm multiplications in
whole LUOV verification can be written as a matrix–vector the worst case. The computational complexity of our online
multiplication The GetM algorithm takes in input P K = verification is dominated by the k vector-vector (inner) prod-
(public.seed, Q2 ) and derives the full public key as done in ucts zi · v, resulting in km multiplications in the worst case.
the original verification: it runs [C|L|Q1 ] ← G(public.seed) Thus, the compiler presented in Sect. 4.1 outputs an efficient
to get the constant constant (vector), the linear (matrix) and verification for signature with Mv-style verification that has
the first quadratic (matrix) parts of the verification equation; the following concrete amortized efficiency:
and then it reconstructs the full quadratic term as Q ←
[Q1 |Q2 ]. Finally it appends to the public key the identity cost(offVer) + r · cost(onVer) knm + rkm
matrix M ← (C, L, Q, −Ir ows(Q) ), we remark that M can =
r · cost(Ver) rnm
be seen as a matrix of blocks, where any block has the same
k k
height (number of rows), but different length (number of = + . (5)
columns). The GetZV routine reads the matrix Z = Z made r n
up of the rows zj = z j ← c j M = (c j ·C, c j ·L, c j ·Q, −c j ).
Clearly the first addend in Eq. (5) comes from amortizing the
It also outputs the vector v = [1|s|s̃|h], where s is part of the
cost of offVer (over verifying r signatures), while the second
signature σ = (s, salt), s̃ is the ‘quadratic vector’ obtained
term is the fix trade-off between the computational costs of
by computing all products of pairs of elements in s, i.e.,
onVer and Ver (at each and every verification). Table 1 col-
s̃ ← [s[1]2 , s[1]s[2], . . . , s[n − 1]s[n], s[n]2 ], finally h is the
lects the figures for three representative classes of signature
hash of the message and the salt, i.e., h ← H(μ0x0salt).
schemes, if we apply our compiler for efficient verification at
Clearly zj · v = 0 if and only if c j · (C + Ls + Qs̃) = c j · h,
128 bit of security. The values are extrapolated as explained
which is a probabilistic check of the original verification
in the reminder of the section. In detail, k0 depends on the
equation in LUOV.
signature  as it is the minimal value of the confidence level k
for which  E is existentially unforgeable; k0 determines the
5.3 Efficiency estimates length of the svk. The value r0 is the minimum number of ver-
ifications to run in order to achieve a concrete efficiency gain
In what follows, we evaluate the efficiency gains provided of e0 . Thus, lower values of e0 and r0 correspond to better
by our compiler using the (r0 , e0 )-concrete efficiency notion efficiency gains. The last column in Table 1 displays the ratio
of Eq. (1). In brief, a  E achieves (r0 , e0 )-concrete amor- k0 /n that essentially tells how much cheaper onVer is com-
tized efficiency if r0 is the smallest, non-negative integer for pared to the original verification Ver (ignoring the one-time
which it holds that e0 < 1, where e0 is an upperbound on cost of running offVer). Again, lower values in this column
the ratio between the cost of running the offline verification correspond to better efficiency; for instance, a ratio of 0.4%
once and using its outcome in r0 online verifications, over the means that the computational cost of Ver is 99.6× higher
cost of running r0 standard signature verifications. For con- than the one of onVer (i.e., onVer is expected to be about
venience, we estimate only the cost of the most expensive 99× faster).
‘steps’ in the verification, namely the ones involving several For convenience we categorize signatures according to the
field element multiplications (e.g., matrix–vector products), size of their underlying algebraic structure.
and disregard the cost of adding elements, generating random
values, reading algorithm inputs or evaluating hash func- The modulo q is exponential in λ: To the best of our knowl-
tions. Moreover, we do not consider ad-hoc optimizations edge, the only LBS constructions that fall in this category
of matrix multiplication due to probabilistic checks using, are the homomorphic signatures by Gorbunov et al. [25]
e.g., Freivalds’ Algorithm or its variant [35]. Table 2 collects and by Fiore et al. [20]. In this case, using our compiler
the common notation, while Table 1 displays a summary of (with some caveats, as we show in the next section) yields

123
Journal of Cryptographic Engineering (2024) 14:551–575 565

Table 2 Parameters involved in

the performance analysis of our q Modulus of the lattice or size of the field
compiler for efficient
verification n Number of rows in the public key
m ∈ (n log q) Number of columns in the public key
β Bound on the noise / size of signatures
σ or U Vector or matrix signatures
k Number of steps in the online verification (confidence level)
r Number of signatures verified (repetitions of onVer)
cost(alg) Number of field multiplications needed to compute alg

Table 3 Details about IoT

Board CPU SRAM Flash
boards adopted
Arduino Due ARM Cortex-M3 (single-core @84MHz) 96KB 512KB
Espressif ESP32 Tensilica Xtensa LX6 (dual-core @240MHz) 520KB 4MB
Raspberry Pi Pico Arm Cortex-M0+ (dual-core @133MHz) 264KB 2MB

that the advantage in the cmvEUF experiment (as per Def- Boyen [11], and its improved version by Micciancio and
inition 4) is negligible in the security parameter λ for any Peikert [32]; as well as the linearly homomorphic scheme by
confidence level k ≥ k0 = 1. However, in [20, 25] the Boneh and Franklin [9]. For the lattice-based constructions,
complexity of Ver is dominated by the matrix-matrix mul- in order to guarantee a negligible advantage in the cmvEUF
tiplication AU where A ∈ Zqn×m is the fixed public key, experiment (see Definition 4) we need to set an appropriate
and U ∈ Zqm×m is the signature.4 We computed parame- value of k ≥ k0 > 1. We argue that ‘appropriate’ values of k
ters for this family of schemes according to Albrecht et al.’s are still ‘small’ in comparison to n and lead to a ‘good’ amor-
methodology [1]. Setting λ = 128, q = 2λ and n = 256 tized efficiency even for ‘few’ verifications. We recall that
yields that reduction algorithms (in particular, the optimized for these constructions Ver computes a product Aσ where
BKZ algorithm) would have runtime 2128 and would solve A ∈ Zqn×m and the signature is just a vector σ ∈ Zqm . To
at most SIS256,2128 ,65536,280 , while the security of the scheme guarantee the security of our efficient verification, the value
relies on a SIS instance with norm bound β = 249d , where k should be set so that q −k be negligible. In other words,
d is the depth of the circuit. We can now use this set of for the cmvEUF advantage to be negligible it must hold that
parameters to determine the concrete amortized efficiency q −k ≤ 2−λ . Hence, to estimate k, one needs to first fix the
reached by our compiler for [20, 25]. Setting k = k0 = 1 value of λ, compute the corresponding q that can guarantee
and n = 256 in Eq. (5), we want to extract the mini- such level of security, and then extract the minimum value
mum r0 for which 1/r0 + 1/256 is smaller than 1, formally k0 for which the above relation holds.
r0 = min{r ∈ Z>0 1/r + 1/256 < 1}. It is easy to see that Computing parameters for lattice-based schemes is not
r0 = 2 suffices and we get 1 > e0 = 0.504 > 1/2 + 1/256. straightforward, as so far there is no unique way to derive the
In other words, the cost of setting up the online verification parameters from a given λ. However, a good measure of the
(running offVer) plus performing r = 2 online verifications security of a set of parameters can be extracted computing
is about half of the cost of running 2 standard verifications, a the root Hermite factor δ introduced in [22]. Concretely, δ
while preserving the security level. Moreover, for this set of provides an indication of how reduction algorithms would
parameters cost(onVer) k0
cost(Ver) = n = 256 < 0.004, i.e., our online
1 perform against the hardness assumption underlying the
verification requires about 0.4% of the computational cost of lattice-based construction. Generally, the ‘smaller’ the δ, the
running the standard verification algorithm; alternatively, we ‘more secure’ the scheme.
can read this results as our onVer is 99× faster than Ver. For Boyen’s signature [11] and its variant by Micciancio
and Peikert [32], we use the parameters provided in [32, Fig.
The modulo q is a large polynomial in λ : This is the most 2]. Since in [32] they set δ = 1.007, to ensure a fair com-
common setting given the ‘small’ size of q. In this category parison, we compute the parameters Gentry et al.’s signature
fall the standard signature schemes by Gentry et al. [24], [24] for the same value of δ. As a result, we observed that
for this δ all of the schemes require about the same mod-
4 In [20] the dimension m additionally depends on the number t ≥ 1 of
ulo q = 230 (for n = 256). For this set of parameters,
distinct identities (users) involved in labeled program. For simplicity, our efficient verification provides 80 (resp. 128; 250) bits
in what follows we consider t = 1.

123
566 Journal of Cryptographic Engineering (2024) 14:551–575

of security with just k0 = 3 (resp. k0 = 5; k0 = 9). Thus our Table 4 Mv-style verification details regarding Rainbow classic ver-
compiler achieves a (4, 0.77)-concrete amortized efficiency sions
(resp.(6, 0.86); (10, 0.94)), and a concrete tradeoff between Version Field used PK matrix size
onVer and Ver of k0 /n < 0.02 (resp. 0.02; 0.04). In partic-
Rainbow I GF(16) (64 × 5050)/2 bytes
ular, for the lower security settings this means that onVer is
Rainbow III GF(256) 80 × 11026 bytes
about 98× faster than Ver.
Rainbow V GF(256) 100 × 19306 bytes
The modulo q is a sub-polynomial in n: The only signature Table 5 Look-up configurations offered by BLEP
schemes in this category are the ones based on multivariate
Config. Type of Optimization
quadratic polynomial equations and stem from the (unbal-
anced) oil and vinegar approach. As a case of study we 0 No look-up table
consider Rainbow with the parameters given for its last NIST 1 compressed look-up tables
submission and available on the the official website.5 For (for roughly half possible inputs)
Level I we have F = F24 and (v1 , o1 , o2 ) = (36, 32, 32), 2 Complete look-up tables
which lead to m = 100 and n = 64 (for consistency in this (for all possible inputs)
paper we set n to be the number of rows of a matrix and m
to denote the number of columns, classically the variables test bed since it supports a variety of boards and several
are swapped for multivariate signatures). Setting k0 = 32 C/C++ language features.
is suitable for good security since q −k0 = 2−4·32 = 2−128 . We used a consumer-grade laptop as a reference platform,
Thus, the minimum number of repetitions r0 to achieve amor- more precisely, a MSI Prestige 14 A10SC equipped with an
tized efficiency (i.e., for which we have k0 /r + k0 /n < 1) Intel i5-10210U [email protected] and 16GB LPDDR4 RAM.
is r0 = 65, the corresponding amortization factor is e0 = On this laptop we installed Linux Mint 20.3.
0.9923 = 32/65 + 32/64. For this set of parameters we For our implementation we focus on Rainbow since,
have cost(onVer) k0
cost(Ver) = n = 64 = 0.5, in other words, our
32
among all the Mv-style signatures, this is the only one
compiler produces an online verification that is 2× faster designed with practical constrains in mind and has an
than the standard verification. For Level III, F = F28 and available, ready-for-use implementation. Albeit Rainbow’s
(v1 , o1 , o2 ) = (68, 32, 48), we have m = 148 and a suitable k security has been recently challenged [6], we consider our
in this case would be k0 = 16, since q −k0 = 2−8·16 = 2−128 . implementation insightful and a useful blueprint for the
For Level V, F = F28 and (v1 , o1 , o2 ) = (96, 36, 64). As a analysis of other schemes based on multivariate polynomial
result we have m = 196, n = 100 and again k0 = 16 but a bet- equations. We believe that the results of our testing activ-
ter amortize efficiency factor e0 = 0, 96 already for r0 = 20. ity can still be useful to showcase the performance boost
We remark that for this set of parameters cost(onVer)
cost(Ver) < 0.16, obtainable by applying efficient verification to existing con-
i.e., our compiler produces an online verification procedure structions. Table 4 shows the parameters used for testing.
that is 6× faster than the standard verification. In order to shorten verification times, our library BLEP
allows the use of look-up tables to speed up addition and
multiplication over finite fields. More precisely, BLEP offers
6 Experimental evaluations with rainbow three possible configurations—i.e., complete, compressed,
or no look-up tables—as shown in Table 5. Users can select
In order to test the feasibility of our verification frame- the appropriate type of optimization based on the desired
works, we developed a library called BLEP [37] that offers a performance criteria and the availability of storage space.
rather straightforward API in C and C++ to perform standard, Since we are dealing with IoT devices, we have to deal with
efficient, and progressive verification for signature schemes tight storage constraints, thus the usage of look-up tables
with Mv-style verification. BLEP has been developed with a and the choice of the storage medium has to be consid-
strong orientation towards performance and portability. ered carefully. Usually, RAM allows for faster access times,
We benchmarked our library using three IoT boards: while flash memory has way more space to work with.
Arduino Due, Espressif ESP32, and Raspberry Pi Pico. Certainly better performance is desirable, but the random
Central Processing Unit (CPU), Random Access Memory access memory can easily fill up, drastically reducing the
(RAM), flash memory and other details about these devices space available for the program stack. On the other hand,
can be found in Table 3. The Zephyr Real-Time Operating relying entirely on flash memory can drastically limit the
System (RTOS) version 3.2.0 has been selected to build our space available for storing the “short” verification key (svk).
This would inevitably affect the maximum security level
achievable when implementing efficient, and progressive ver-
5 https://www.pqcrainbow.org/ (accessed on 20/02/2023). ification on specific constrained devices.

123
Journal of Cryptographic Engineering (2024) 14:551–575 567

Table 6 Reference device: Avg efficient verification times (in microsecs) for Rainbow I, III and V
svk size / pk size (%) Language Configuration Rainbow I (µs) Rainbow III (µs) Rainbow V (µs)

10% C Conf. 0 364 2984 6390

Conf. 1 320 1152 2290
Conf. 2 83 352 780
C++ Conf. 0 390 2152 4550
Conf. 1 262 1192 2570
Conf. 2 83 351 760
20% C Conf. 0 729 5698 12780
Conf. 1 640 2304 4580
Conf. 2 166 704 1560
C++ Conf. 0 780 4304 9100
Conf. 1 524 2384 5140
Conf. 2 166 703 1520
30% C Conf. 0 1094 8952 19170
Conf. 1 960 3456 6870
Conf. 2 249 1056 2340
C++ Conf. 0 1171 6456 13650
Conf. 1 787 3576 7710
Conf. 2 249 1055 2280
40% C Conf. 0 1459 11936 25560
Conf. 1 1280 4608 9160
Conf. 2 332 1408 3120
C++ Conf. 0 1561 8608 18200
Conf. 1 1049 4768 10280
Conf. 2 332 1407 3040
50% C Conf. 0 1824 14920 31950
Conf. 1 1600 5760 11450
Conf. 2 416 1760 3900
C++ Conf. 0 1952 10760 22750
Conf. 1 1312 5960 12850
Conf. 2 412 1759 3800
100% C Conf. 0 3648 29840 63900
Conf. 1 3200 11520 22900
Conf. 2 832 3520 7800
C++ Conf. 0 3904 21520 45500
Conf. 1 2624 11921 25700
Conf. 2 830 3519 7600

With the aim of evaluating the verification times on differ- In Table 6, we present the average efficient verification
ent devices, and since the Mv-style verification time scales times collected on our reference platform with the different
linearly in the number of rows present in the svk, we simply versions of Rainbow, and with various svk sizes (here shown
collected the cost for a single row-vector product. To do so, as percentages with respect to the number of rows of the
we wrote two benchmark programs in C and C++ using the corresponding public key). This data shows the remarkable
API offered by BLEP. These programs have been compiled impact of lookup tables on the experimental results (config-
with gcc and g++, both version 11.3.0, and with the -O3 uraration 1 and 2) even on a standard laptop. This increase
optimization flag enabled. Results of our testing activity are in performance is even more evident when analyzing verifi-
shown in Table 6 and in Figs. 6, 7 and 8. cation times of Rainbow III and V.

123
568 Journal of Cryptographic Engineering (2024) 14:551–575

Fig. 6 Rainbow I: Avg

row-vector product times (in
microsecs) obtained on our IoT
devices

Fig. 7 Rainbow III: Avg

row-vector product times (in
microsecs) obtained on our IoT
devices

In Figs. 6, 7 and 8, we summarize data related to Rainbow III and V is G F(256) and the look-up tables are larger than
I, III and V, respectively. More precisely, we store the look- those used by Rainbow I over G F(16). Therefore, Raspberry
up tables in flash memory (unless otherwise indicated), run is able to get additional timing improvements of about 62%
our benchmark on the three versions of Rainbow, and then and 76% for Configuration 1 and 2, respectively.
collect computation times on our IoT boards (see Table 3).
Testing activity executed with Rainbow I (see Fig. 6) shows
that using look-up tables can reduce the verification times
7 Extensions
by more than 50% on all IoT boards. On the other hand, by
storing the look-up tables in RAM we gain an additional per-
7.1 Signatures with properties
formance improvement of about 8% and 18% on the Arduino
Due board, for the Configuration 1 and 2 respectively. No
Efficient verification can be easily generalized to the case of
significant improvement has been observed on the Espressif
signatures with different security notions, such as strong or
ESP32 and the Raspberry Pi Pico.
selective unforgeability, or with advanced properties. This is
The behaviour of Rainbow III and V is similar to that
of particular interest for LBS, where the versatility of well-
of Rainbow I, except for the ESP32 (see Figs. 7 and 8). In
established hardness assumptions has already given life to a
fact, if we use this board with large look-up tables stored in
variety of constructions under different security models and
flash memory, performance deteriorates considerably. This
realizing advanced properties, including homomorphic [25],
abnormal behaviour does not happen with the Arduino Due,
threshold [4], constrained [38] and indexed attribute based
nor with the Raspberry Pi Pico. We suppose that the hardware
signatures [27]; and yet relying on an Mv-style verification
constraints of ESP32 negatively affect the performance of
(as introduced in the beginning of the section, and displayed
our testing activities. On the other hand, if we store look-
in Fig. 3).
up tables in RAM only the Raspberry Pi Pico is capable of
Signatures with properties require more complex secu-
holding them completely. The finite field used by Rainbow
rity definitions than plain existential unforgeability. Figure 9

123
Journal of Cryptographic Engineering (2024) 14:551–575 569

Fig. 8 Rainbow V: Avg

row-vector product times (in
microsecs) obtained on our IoT
devices

4. A check phase, where the experiment checks whether the

signature output by A is valid and if A won the experi-
ment. The former requires an execution of the verification
algorithm; the latter includes a variety of additional checks
to ensure the signature is actually a forgery (and is not triv-
ially derivable from the adversary’s view, e.g., because it
was output by the signing oracle). We model this second
check with the WinCond predicate. Clearly, the specifi-
cation of WinCond depends on each primitive, and on
the type of unforgeability: If selective, it checks that the
queries and the forgery are consistent with the values val
Fig. 9 Generic description of the unforgeability under adaptive chosen declared at the beginning of the game. If existential, it
message attacks experiment for signatures with properties checks that μ∗ was not queried to the signing oracle. If
strong, it checks that the queries to the signing oracle are
all distinct.
provides a generic formalism to unify the description of the
unforgeability experiments for signatures with properties.
In a nutshell the common requirements are: Adapting the syntax and security experiment of efficient
verification to signatures with properties is rather straight-
1. If the signature guarantees selective unforgeability, the forward. Similarly, our compiler of Sect. 4.1 can be easily
first step in the experiment is for A to declare the target adjusted to work on signatures with properties and with
messages for the forgery; in Fig. 9 this is handled via the Mv-style verification, as we discuss momentarily. Regard-
val variable. If unforgeability is adaptive, val is set to ⊥. ing security, the core part of the proof of Theorem 1 is
2. A setup phase, where a probabilistic routine (denoted information-theoretical, and therefore it does not signifi-
Setup in Fig. 9) generates a set of secret values sval – cantly change when considering signatures that are only
handed over to the oracles– and other public auxiliary selectively unforgeable, or strongly unforgeable. In the fol-
values pval, that include verification keys, delivered to lowing we analyze the impact of our compiler on the
the adversary. efficiency of some schemes whose verification is structured
3. A challenge phase, where the adversary is given access to as in Fig. 3: the constrained LBS in [38], the (indexed)
some, possibly stateful, oracles (usually, at least an oracle attribute-based LBS in [27], the homomorphic LBS in [20],
that returns signatures by honest users), and has to output the threshold LBS in [4], and the multivariate-based ring
a message and a forged signature on it. We model this by signature RingRainbow [33]. This list is by no means an
defining two oracles: exhaustive list. Indeed, in this work we decided to ignore
lattice-based signatures with properties that are obtained
• O K (·; sval, st K ): Returns signing/secret keys (of using the Fiat-Shamir with abort technique from [31], despite
users or other entities that A may corrupt). the fact that wherever the result of Chen et al. [16] is appli-
• O(·; st): Encompasses all the other possible oracles cable, our compiler is too. The reason is that signatures with
(signing, opening for group signatures, etc.). properties that rely on such technique are many, and the effi-

123
570 Journal of Cryptographic Engineering (2024) 14:551–575

ciency gain computation is similar to the one performed in cient verification by letting offVer take as (additional) input
Sect. 5 C and compute M using the algorithm PubEval from [26].
Constrained Signatures (CS). CS allow a signer to sign a The vectors (Z , v) used in the verification might (as in [20])
message only if either the message or the key satisfies cer- or might not (as in [27]) depend on the message. In the latter
tain preset constraints. The verification algorithm of the case the subroutine GetZV in onVer simply returns the input.
lattice-based instantiation of CS by Tsabary [38] includes The impact of the compiler on the efficiency of HS was
an Mv-style check (where the matrix has n rows) and a norm already analyzed in Sect. 5. Regarding the iABS, the sug-
check. Hence, our compiler applies directly to this scheme. gested value of the modulo q is such that q ≥ n 8 . The
Unforgeability requires that n ≥ λ and q ≤ 2λ , so for an standard requirement n ≥ 2 already implies that 1/q k ≤
average value q ∼ 232 , we can set k = 9  λ so that the 1/(28 )k = 1/256k . However, to guarantee the hardness
+1
advantage of A in Theorem 1 is qqkV−q < 1/2256 . Remark of lattice-based problems usually n needs to be at least
V
that larger values of q (that could be required to have higher n = 128. In this case q ≥ 256 , hence already k = 6
+1
security guarantees) imply smaller values of k. Therefore, guarantees that qqkV−q < 1/2305 , thus the unforgeability
V
for this less conservative choice of parameters the efficiency of this iABS. As n = O(d log d) (where d is the depth
gain is cost(onVer)
cost(Ver) = n = 256 < 0.036, i.e., the online ver-
k 9
of C) and the efficiency gain can be bounded as follows:
cost(onVer)
cost(Ver) ≤ O(d log d) = O(d log d) . From this inequality is
ification requires about 3.6% of the computational cost of k 6

running the standard verification algorithm. clear that already for a circuit of depth 4 the online veri-
fication only requires 75% of the computation required by
Indexed Attribute-based Signatures (iABS), and Homomor- standard verification; the impact of our compiler increases
phic Signatures (HS). iABS allow a signer to generate a for larger size of the circuit.
valid signature on a message only if the signer holds a set
of attributes that satisfy some policy (represented by a cir- Threshold Signatures (TS). TS allow h out of  parties to pro-
cuit C). HS allow a signer to sign messages μi so that it is duce a signature on a message. Unforgeability is guaranteed
possible to publicly derive a valid signature for a message μ for up to t colluding parties. Bendlin, Krehbiel, and Peikert
that corresponds to the output of a computation on the orig- [4] introduced a compiler that allows to distribute the signa-
inal messages, i.e., μ = C(μ1 , . . . , μr ). According to the ture generation step of the GPV08 signature, and convert it
type of homomorphism supported by the scheme, the circuit into a TS. The idea is to share the signing trapdoor among
C can encode only linear functions, polynomial functions, or the parties using a h-out-of- secret sharing scheme. Signing
any function of bounded multiplicative degree. In both iABS requires at least h parties to come together to generate a sig-
in [27] and HS in [20] the signature verification is composed nature satisfying a Mv-type equation (where M is the public
by three steps: verification key). Verification is composed by the standard
Mv equation and norm checks. Therefore, the thresholdiz-
1. Computation of the public matrix M from the circuit C ing compiler is composable with our compiler for efficient
(either the policy, or the homomorphic computation spec- verification. As neither of them change the parameters of the
ified by the labelled program); underlying GPV08 scheme, the efficiency gain is the same
2. An ‘Mv’-style check; (Sect. 5).
3. A norm check on the signature.
RingRainbow [33]. RingRainbow is a ring signature scheme
—i.e., a signature that allows a user to sign a message
The first step is critical because the public matrix M can be
anonymously on behalf of a group – based on multivariate
generated through a non-linear transformation, i.e., it might
equations. This scheme is a hash-and-sign type of signature
include multiplications of the public matrix by itself (or by
built as a modification of Rainbow. As thus, it is affected by
a gadget matrix). This would not allow to compute the first
the recent attacks, but we believe its analysis is still impor-
step online from the zi ’s, but the verifier would have to use
tant, as it can serve as a blueprint for the analysis of future
M and the ci ’s instead, defying the purpose of our compiler.
variants avoiding such attacks. Verification requires to check
Hence, our compiler can be applied to these signatures in an
whether the signature satisfies a multivariate quadratic sys-
efficient way only if either (1) C involves solely linear opera-
tem, and can be converted in a Mv-style verification with the
tions on the public matrix, or (2) C is fixed, or (3) C is known
same technique used for Rainbow (cf. Sect. 5). Therefore, our
before running verification.6 In these cases, we achieve effi-
compiler can be applied to RingRainbow as well. To evalu-
6 ate the efficiency gain due to our compiler, we consider the
The construction of group signature in [27] has this iABS as building
block, but it does not satisfy any of these conditions, as the verification efficient version of RingRainbow, (whose parameters can be
circuit depends strongly on the signature. The authors did not find a found in Table 2 in [33]). For λ = 128 and a group of 5 users
straightforward way to modify this construction to have efficient veri- the authors set F = F28 and (v1 , o1 , o2 ) = (36, 21, 22),
fication without significantly impacting the signature length.

123
Journal of Cryptographic Engineering (2024) 14:551–575 571

which yield m = 5 ∗ (v1 + o1 + o2 ) = 395 and n = 43. cation has complexity O(n 2 ) but it can be easily improved
+1
Theorem 1 requires at least qqkV−q = 1/2256 for 128 bits of by dividing the polynomials of size n into smaller pieces and
V
post-quantum security, which is ensured by k ≥ k0 = 36. performing the multiplication on such pieces [12, 17],—our
Plugging these values in our amortized efficiency formula efficient verification employs a (secret) vector and a (public)
k0 k0
r + n (that is the formula derived from Definition 3 for sig-
vector, which obviously reduces the complexity to O(n), and
natures with Mv-style verification) yields that the minimum does not necessarily sacrifice security (verification sound-
number of repetitions r0 to achieve meaningful amortized ness).
efficiency is r0 = 580, and the corresponding amortized effi-
ciency factor is e0 = 0.8992 > 36/580 + 36/43. In this
case, our compiler produces an online verification such that 8 Combining progressive and efficient
cost(onVer) k0
cost(Ver) = n = 43 < 0.86, in other words, our compiler
36
verification
produces an online verification that requires only 86% of the
computation required by the standard verification. Progressive verifications obtained with our transformation
(Sect. 4.2) can be split into two parts: a one-time, computa-
7.2 Applications tionally intensive, setup (ProgStep0 ); and an efficient online
verification (ProgStep1 to ProgStepT , for some opportune
Optimistic Verification. Speculative execution is an optimiza- integer T ≥ 1). This gives rise to custom, i.e., intentionally
tion technique that relies on pre-computing some tasks so adjustable, verification soundness. This property makes post-
that the information be ready when the user prompts for it. quantum-secure verification accessible to a larger range of
This technique is increasingly used to in a wide range of devices, and at the same time draws interesting connections
commodity devices to boost performance. In these settings, between classical, information-theoretic, and post-quantum
progressive verification is a valuable candidates for early security notions.
rejection of incorrect inputs. In particular, with ‘little’ com- The security guarantees discussed thus far hold as long
putations the CPU can identify the most ‘promising’ branch as the employed svk is fresh. In what follows, we investi-
and further optimize its performance. Another concrete use gate sound ways to amortize the setup cost by reusing (and
case is smart vehicle updates, where multiple software need refreshing) the svk produced by ProgStep0 for several online
to be installed ‘at the same time’ to have compatible ver- efficient verifications. We remark that naïvely reusing svk
sions. Thus, a successful upgrade of a number of components makes the confidence function degrade with every new ver-
entails checking, say, N signatures (to verify the authentic- ification, since progressive verification allows for premature
ity of each new piece of software). There are two standard verification outcomes that may leak a substantial amount of
approaches to face this task: the conservative one, where the information about svk, unless the modulo q is exponential,
user verifies all of the N signatures before launching the soft- as shown in the following theorem.
ware update; and the lazy one, where the user verifies each
signature before launching the corresponding update. In the Theorem 3 For signatures with Mv-style verification relying
first case, one may incur into long waiting time (since the on algebraic structures of size q = 2poly(λ) our compiler
signatures have high security level, given the threats that rise for efficient and progressive verification outlined above is
from installing malware on smart vehicles). In the second unforgeable according to Definition 7 and achieves (2, 1/2+
case, one may have to interrupt the update and revert some 1/r ows(M))-concrete amortized efficiency as per Definition
components to previous versions. In contrast, using progres- 3.
sive verification with an optimistic approach lets the verifier
start the N verifications at the same time and interrupt them Proof The proof relies on the same argument used in the
after a number t of steps to check the ‘partial’ results. If one proof of Theorem 1. The security experiment is essentially
signature is invalid, the user should not even bother to start the experiment ExpcmvEUF
A, (λ, k) with a few changes: (1) any
with the installation. If all signature appear valid (until step appearance of onVer is replaced by ProgVer, (2) svk is not
t), the user can proceed with the lazy approach, checking the refreshed at every verification query, and (3) the number k of
remaining constraints while updating its vehicle, knowing rows of C is replaced by the interruption parameters t output
there is a low chance the process fails ‘at the very end’. by OInt at each verification query. Since q is exponential in
the security parameter, C can be a single row vector. In other
Sidestepping Boundaries The offline/online verification words T = 1, thus we can set all interruption values t to 1.
approach allows bypassing known algorithmic barriers by The advantage of an attacker is bounded through Lemma 1
changing the task performed by the signature verification. as in the proof of Theorem 1.
Instead of performing a multiplication between a (public) In this setting, a concrete efficiency gain is achieved
matrix and a (public) vector—in the worst case, a multipli- already with r0 = 2 repetitions. The corresponding amor-

123
572 Journal of Cryptographic Engineering (2024) 14:551–575

tized efficiency value is Definition 10 (Concrete Amortized Efficiency) Let r0 > 0

be an integer, and 0 < e0 < 1 a small, real constant.
cost(offVer(pk, 1)) r0 · cost(onVer(svk, 1, μ, σ )) A scheme  F+E = (, prefVer) realizes (r0 , e0 )-concrete
e0 = +
r0 · cost(Ver(pk, μ, σ )) r0 · cost(Ver(pk, μ, σ )) amortized efficiency if, for a given security parameter λ, for
1
= +
1
. any key pair (sk, pk) ← KeyGen(λ), for any tuple of pairs
2 r ows(M) (μi , σ i ) with μi ∈ M and σ i such that Ver(pk, μi , σ i ) = 1,
for any sequence of admissible states (sti )i=0
r ⊆ S, we have


that for every r ≥ r0 the following holds true:
Next we focus on the trickier and more interesting case where r−1  
q is polynomial. i=0 cost prefVer(sti , pk, μi , σ i , k)
  < e0 (6)
r · cost Ver(pk, μ, σ )
8.1 Efficient & progressive signature verification
with r-bounded randomness reuse 8.2 Security model for pref verification

We introduce the concept of progressive and efficient (pref) Figure 10 collects a description of our security game and
verification with r-bounded randomness reuse. Similarly to experiment for existential unforgeability under adaptive cho-
Definition 5 (progressive signatures), this sustainable variant sen message attack for signatures with progressive and
is defined for a given value k, that determines the maximum efficient verification (r-prefEUF).
desired confidence level achievable by the verification. In
addition to k, we need a second parameter, r, that determines Definition 11 (r-Bounded Progressive Security (r-prefEUF))
the maximum number of times svk can be reused while guar- Let  be a signature scheme that admits a non-trivial real-
anteeing verification soundness. For correctness and security, ization of (r,k)-efficient and progressive verification  F+E .
both k and r are input to the confidence function, which now Then, for a given security parameter λ,  F+E is existen-
is named αpref . tially unforgeable under adaptive chosen message attack with
progressive and efficient verification (r-prefEUF) if for all
Definition 8 (Progressive and Efficient Verification) A sig- efficient PPT adversaries A the success probability in the
nature scheme  = (KeyGen, Sign, Ver) admits a (r, k)- r-prefEUF experiment is:
efficient and (T , αpref )-progressive verification realization
 F+E = (, prefVer) if there exist  
ExpA,,r (λ, k, r) = (ctr∗ , t ∗ )
r-prefEUF
- two positive integers: r (number of reuses of the secret Pr
randomness) and k (interruption step); ∧ (ctr∗ , t ∗ ) = (0, 0)
- an efficiently computable confidence function αpref : ≤ (1 − αpref (t ∗ , ctr∗ )) + ε(λ).
{0, . . . , k} × {0, . . . , r} → [0, 1];
- a set of admissible sequences of states S = {st (1) , 8.3 A compiler for pref Mv-style verification with
st , . . .} (each sequence st ( j) contains r + 1 states sti , i.e.,
(2)
polynomial q
st ( j) = (sti )i=0
r , st = ∅);
0
and We now present a compiler for signatures with Mv-style ver-
- a progressive verification algorithm prefVer consisting ification and q = poly(λ) that realizes efficient bounded
of k + 1 steps prefVer0 , . . ., prefVerk with the same syntax progressive verification. This compiler builds on top of the
as in Definition 5. two compilers presented in Sect. 4.1. Intuitively, the problem
with progressive verification is that if interrupted after t < k
Definition 9 (r-Reuse k-Progressive Correctness)Let  be a steps the process may erroneously accept an invalid signa-
signature scheme that admits progressive and efficient ver- ture with a non-negligible probability ≈ 1/q t . In Sect. 4.2
ification realized by the tuple (r, k, αpref , prefVer, S). Then we mitigate this leakage of information between queries by
 F+E = (, prefVer) satisfies (r, k)-correctness if, for a refreshing the vectors in svk after every verification. This
given security parameter λ, for any key pair (sk, pk) ← conservative approach clearly impacts efficiency. Here we
KeyGen(λ), for any one sequence of admissible states st ← want to prioritize efficiency at the cost of accuracy, and inves-
S, st = (sti )i=0 r , for any choice of r message-signature pairs
tigate how the confidence function degrades when the same
(μi , σ i )i=1 with μi ∈ M and σ i such that Ver(pk, μi , σ i ) =
r
set of vectors zi is used to perform r progressive verifications
1 and for any sequence of interruption values (ti )i=1 r ⊆ (Fig. 11).
{1, . . . , k}, it holds that, for all i = 1, . . . , r: Our compiler works essentially as the efficient verifica-
  tion compiler in Fig. 5, except that the offVer algorithm (that
Pr prefVer(sti , pk, μi , σ i , ti ) = αpref (ti , i) = 1 generates a fresh svk) is run only once every r verifications.

123
Journal of Cryptographic Engineering (2024) 14:551–575 573

Fig. 10 Security model for existential unforgability under chosen message and progressive verification for signatures with stateful, (k, r)-efficient
and progressive verification: queries security game, experiment and oracles

To further optimize the scheme, we replace the GetZV algo- algorithm prefVer0 does not refresh the multipliers. Hence,
rithm by k algorithms GetZVi each of which is run by the for i > 0
corresponding prefVeri . The behavior of GetZVi depends on
 
the signature scheme and in what follows we define it for cost prefVer(sti , μi , σ i , k) = k(n + m) .
each of the three major classes we identified in this paper.
Each algorithm takes as input the corresponding i-th vec- r0 −1  
tors ((ci , zi ), P K .aux, μ) and returns (zi , vi ) that are defined
This yields i=0 cost prefVer(sti , pk, μi , σ i , k)
= knm + r0 k(n  + m). The cost of a verification is domi-
according to the scheme considered:
nated by cost Ver(pk, μ, σ ) = nm multiplications, in the
worst case. Therefore, Eq. (6) yields knm + r0 k(n + m) <
GPV08 [24]: the GetZVi routine returns zi = zi = ci M, r0 nm ⇒ r0 > nm−k(n+m) knm
. From the above formula
and vi = [σ |H(μ)]. we can derive a lower bound on values of r that yield effi-
MP12 [32]: the GetZVi routine outputs zi = [z̃i | zi0 + ciency (recall that by definition r0 ≤ r). A concrete security
 j
j=1 μ[ j]zi |ci ] and vi = [σ |u]. approach should lead to a meaningful upper bound on the
Rainbow [18]: the GetZVi routine outputs zi = zi = value r that can be safely used in realistic applications.
ci M, and vi = [s̃|s|1|h]. Intuitively, lower values of r yield higher accuracy (and unfo-
geability), higher ones guarantee better amortized efficiency.
Finally, the confidence function αpref (·, ·) is defined as:
) 
ctr
1− 1
q t −ctr − if t > 0 9 Conclusions and future work
αpref (t, ctr) = q−(ctr−1) (7)
0 if t = 0
We presented a study on how to achieve efficient and pro-
8.3.1 r0 -concrete amortized efficiency estimates gressive verification for digital signatures. In addition to
putting forth these notions and formal models for them, we
The cost of prefVeri varies depending on whether i = 0 or presented two compilers that allow one to realize efficient
i > 0. When prefVer is run the first time (or with an empty (resp. progressive) verification for a wide class of existing
state), the step prefVer0 generates the state. This includes constructions including lattice-based and multivariate-based.
computing (knm) multiplications, in the worst case. After We demonstrated the feasibility of our approach through
that, every step prefVeri computes at most (n + m) multipli- an implementation on off-the-shelf resource-constrained
cations (the first term represents the cost of running GetZVi ). devices. Finally, we showed how to extend our compiler to
Therefore, work with digital signatures with advanced properties, such
as ring, threshold, homomorphic multi-key, attribute-based
 
cost prefVer(st0 , μ0 , σ 0 , k) = knm + k(n + m) . and constrained signatures. While our constructions show the
feasibility of the desired properties, they also raise some natu-
However, this is true only for the first execution of prefVer, ral follow up questions. For instance, is it possible to realize a
as when executing the verification 1 < r0 < r times, the compiler for LBS with q ∼ poly(λ) that simultaneously pro-

123
574 Journal of Cryptographic Engineering (2024) 14:551–575

Fig. 11 Generic compiler to

obtain efficient and progressive
verification of signature
schemes with Mv-style
verification and q polynomial in
the security parameter

vides efficient and progressive verification? We address this Author Contributions C.B., D.F, and E.P wrote Sections 1–5, 8 and 9.
question in a positive way in Sect. 8, albeit in weaker secu- L.T. and A.V. wrote Section 6, L.T. developed the BLEP library and
run the experiments that produced Figs 6, 7, 8 and Table 6. C.B. wrote
rity model. A solution with full fledged progressive security Section 7.1. E.P wrote section 7.2. All authors reviewed the submitted
remains an interesting open problem. Another question is, Manuscript.
is it possible to generalize our approach to other classes of
digital signatures, e.g., code-based or LBS obtained through Funding Open access funding provided by Chalmers University of
Technology.
the Fiat-Shamir heuristic or from ideal lattices?
Finally, it would be worth to explore more applica-
tions of progressive and efficient verification. On top of the
Declarations
already mentioned applications to real-time systems, another Conflict of interest The authors declare no conflict of interest.
possible avenue is parallel and distributed verification of dig-
ital signatures. Consider a public bulletin board that stores Open Access This article is licensed under a Creative Commons
authenticated (signed) data. For security reasons, one may be Attribution 4.0 International License, which permits use, sharing, adap-
tation, distribution and reproduction in any medium or format, as
tempted to use post quantum signature schemes such as LBS. long as you give appropriate credit to the original author(s) and the
However, the large sizes of the public keys and signatures and source, provide a link to the Creative Commons licence, and indi-
the slow speed of the verification are notorious bottlenecks cate if changes were made. The images or other third party material
to deploy them in such scenarios. Using our approach, a pool in this article are included in the article’s Creative Commons licence,
unless indicated otherwise in a credit line to the material. If material
of parties –acting as verifiers– can be made in charge of run- is not included in the article’s Creative Commons licence and your
ning each a single verification check (i.e., ProgVer includes intended use is not permitted by statutory regulation or exceeds the
only ProgVer0 and ProgVer1 ). In terms of security, although permitted use, you will need to obtain permission directly from the copy-
a single verifier may be wrong with non-negligible probabil- right holder. To view a copy of this licence, visit http://creativecomm
ons.org/licenses/by/4.0/.
ity 1/q, the probability that k honest verifiers are all wrong
becomes negligible already for k = 5. Finally, we think that it
would be interesting to explore the study of efficient and pro-
gressive verification also for more cryptographic primitives,
such as commitments and zero-knowledge proofs.
References
Acknowledgements This work was partly funded by: VR Project
Number 2022-04684, the Swiss National Science Foundation under 1. Albrecht, M.R., Curtis, B.R., Deo, A., Davidson, A., Player, R.,
the SNSF Project Number 182452 and the Postdoc.Mobility Grant Postlethwaite, E.W., Virdia, F., Wunderer, T.: Estimate all the LWE,
Number 203075, the European Research Council (ERC) under the Euro- NTRU schemes! in security and cryptography for networks SCN,
pean Union’s Horizon 2020 research and innovation program under LNCS (2018)
project PICOCRYPT (grant agreement No. 101001283), by the Span- 2. Armknecht, F., Walther, P., Tsudik, G., Beck, M., Strufe, T.:
ish Government under projects SCUM (ref. RTI2018-102043-B-I00), ProMACs: Progressive and resynchronizing macs for continuous
CRYPTOEPIC (ref. EUR2019-103816), and RED2018-102321-T and efficient authentication of message streams. In: Proceedings of the
by the Madrid Regional Government under project BLOQUES (ref. 2020 ACM SIGSAC Conference on Computer and Communica-
S2018/TCS-4339). This work was partially supported by: project SER- tions Security, pp. 211–223 (2020)
ICS (PE00000014) under the NRRP MUR program funded by the 3. Backes, M., Fiore, D., Reischuk, R.M.: Verifiable delegation of
EU—NextGenerationEU, and by project QCI-CAT. computation on outsourced data. In: 2013 ACM SIGSAC CCS,
pp. 863–874. ACM (2013)

123
Journal of Cryptographic Engineering (2024) 14:551–575 575

4. Bendlin, R., Krehbiel, S., Peikert, C.: How to share a lattice trap- 25. Gorbunov, S., Vaikuntanathan, V., Wichs, D.: Leveled fully homo-
door: threshold protocols for signatures and (H)IBE. In: ACNS morphic signatures from standard lattices. In: STOC, pp. 469–477.
(2013) ACM (2015)
5. Bernstein, D.J.: A secure public-key signature system with 26. Gorbunov, S., Vinayagamurthy, D.: Riding on asymmetry: Efficient
extremely fast verification ABE for branching programs. In: ASIACRYPT, LNCS (2015)
6. Beullens, W.: Breaking rainbow takes a weekend on a laptop. In: 27. Katsumata, S., Yamada, S.: Group signatures without NIZK: from
Advances in Cryptology—CRYPTO 2022, pp. 464–479. Springer, lattices in the standard model. In: Advances in Cryptology—
Switzerland (2022) EUROCRYPT (2019)
7. Beullens, W.: Mayo: Practical post-quantum signatures from oil- 28. Lamport, L.: Constructing digital signatures from a one-way func-
and-vinegar maps. In: International Conference on Selected Areas tion. In: Technical report, CSL-98, SRI International (1979)
in Cryptography, pp. 355–376. Springer, New York (2022) 29. Le, D.V., Kelkar, M., Kate, A.: Flexible signatures: making
8. Beullens, W., Szepieniec, A., Vercauteren, F., Preneel, B.: LUOV: authentication suitable for real-time environments. In: ESORICS.
Signature scheme proposal for NIST PQC project (2019) Springer, New York (2019)
9. Boneh, D., Freeman, D.M.: Linearly homomorphic signatures over 30. Loveless, A., Dreslinski, R., Kasikci, B., Phan, L.T.X.: Igor: Accel-
binary fields and new tools for lattice-based signatures. In: PKC, erating byzantine fault tolerance for real-time systems with eager
pp. 1–16. Springer, New York (2011) execution. In: IEEE Real-Time and Embedded Technology and
10. Boschini, C., Fiore, D., Pagnin, E.: Progressive and efficient ver- Applications Symposium (RTAS) (2021)
ification for digital signatures. In: Ateniese, G., Venturi, D. (eds.) 31. Lyubashevsky, V.: Lattice signatures without trapdoors. In: EURO-
Applied Cryptography and Network Security–20th International CRYPT (2012)
Conference, ACNS 2022, Rome, Italy, Proceedings. Lecture Notes 32. Micciancio, D., Peikert, C.: Trapdoors for lattices: Simpler, tighter,
in Computer Science, vol. 13269, pp. 440–458. Springer, New York faster, smaller. In: EUROCRYPT (2012)
(2022) 33. Mohamed, M.S.E., Petzoldt, A.: RingRainbow—An efficient mul-
11. Boyen, X.: Lattice mixing and vanishing trapdoors: a framework tivariate ring signature scheme. In: Progress in Cryptology—
for fully secure short signatures and more. In: PKC, pp. 499–517. AFRICACRYPT, LNCS (2017)
Springer, New York (2010) 34. Plantard, T., Sipasseuth, A., Dumondelle, C., Susilo, W.: DRS:
12. Çalık, Ç., Dworkin, M., Dykas, N., Peralta, R.: Searching for best diagonal dominant reduction for lattice-based signature. In: PQC
karatsuba recurrences. In: Analysis of Experimental Algorithms: Standardization Conference (2018)
Special Event. SEA2 2019, Kalamata, Greece, Revised Selected 35. Sipasseuth, A., Plantard, T., Susilo, W.: Using Freivalds’ Algo-
Papers, pp. 332–342. Springer, New York (2019) rithm to accelerate lattice-based signature verifications. In: ISPEC.
13. Cartor, R., Cartor, M., Lewis, M., Smith-Tone, D.: Iprainbow. In: Springer, New York (2019)
Proceedings of Post-Quantum Cryptography: 13th International 36. Taleb, A.R., Vergnaud, D.: Speeding-up verification of digital sig-
Workshop, PQCrypto 2022, Virtual Event, pp. 170–184. Springer, natures. J. Comput. Syst. Sci. 116, 22–39 (2020)
New York (2022) 37. Torresetti, L.: BLEP: a barebone library for efficient and progres-
14. Cash, D., Hofheinz, D., Kiltz, E., Peikert, C.: Bonsai trees, or how sive verification. https://github.com/torres98/BLEP (2022)
to delegate a lattice basis. In: EUROCRYPT, Springer, New York 38. Tsabary, R.: An equivalence between attribute-based signatures
(2010) and homomorphic signatures, and new constructions for both. In:
15. Catalano, D., Fiore, D., Warinschi, B.: Homomorphic signatures Theory of Cryptography TCC (2017)
with efficient verification for polynomial functions. In: Advances 39. Wang, Q., Khurana, H., Huang, Y., Nahrstedt, K.: Time valid one-
in Cryptology—CRYPTO (2014) time signature for time-critical multicast data authentication. In:
16. Chen, Y., Lombardi, A., Ma, F., Quach, W.: Does fiat-Shamir IEEE INFOCOM (2009)
require a cryptographic hash function? In: Malkin, T., Peikert, C.
(eds.) CRYPTO (2021)
17. De Piccoli, A., Visconti, A., Rizzo, O.G.: Polynomial multiplica-
Publisher’s Note Springer Nature remains neutral with regard to juris-
tion over binary finite fields: new upper bounds. J. Cryptogr. Eng.
dictional claims in published maps and institutional affiliations.
10(3), 197–210 (2020)
18. Ding, J., Chen, M.-S., Petzoldt, A., Schmidt, D., Yang, B.-Y.: Rain-
bow. Available at https://csrc.nist.gov/projects/post-quantum-
cryptography/round-2-submissions. Accessed 21 Sept 2020
19. Ding, J., Schmidt, D.: Rainbow, a new multivariable polynomial
signature scheme. In ACNS, LNCS (2005)
20. Fiore, D., Mitrokotsa, A., Nizzardo, L., Pagnin, E.: Multi-key
homomorphic authenticators. In: ASIACRYPT (2016)
21. Fischlin, M.: Progressive verification: The case of message authen-
tication. In: International Conference on Cryptology in India, pp.
416–429. Springer, New York (2003)
22. Gama, N., Nguyen, P.Q.: Predicting lattice reduction. In: Smart,
N.P. (ed.) Proceedings on Advances in Cryptology–EUROCRYPT.
Lecture Notes in Computer Science, vol. 4965, pp. 31–51. Springer,
New York (2008)
23. Gennaro, R., Gentry, C., Parno, B.: Non-interactive verifiable
computing: Outsourcing computation to untrusted workers. In:
CRYPTO (2010)
24. Gentry, C., Peikert, C., Vaikuntanathan, V.: Trapdoors for hard
lattices and new cryptographic constructions. In: Dwork, C. (ed.)
ACM STOC. ACM, New York (2008)

123