Content uploaded by Aydin Abadi
Author content
All content in this area was uploaded by Aydin Abadi on Mar 07, 2021
Content may be subject to copyright.
Multi-instance Publicly Verifiable Time-lock Puzzle
and its Applications
Aydin Abadi?1and Aggelos Kiayias?? 1,2
1University of Edinburgh
2and IOHK
Abstract. Time-lock puzzles are elegant protocols that enable a party to lock a
message such that no one else can unlock it until a certain time elapses. Neverthe-
less, existing schemes are not suitable for the case where a server is given multiple
instances of a puzzle scheme at once and it must unlock them at different points
in time. If the schemes are naively used in this setting, then the server has to start
solving all puzzles as soon as it receives them, that ultimately imposes significant
computation cost and demands a high level of parallelisation. We put forth and
formally define a primitive called “multi-instance time-lock puzzle” which allows
composing a puzzle’s instances. We propose a candidate construction: “chained
time-lock puzzle” (C-TLP). It allows the server, given instances’ composition, to
solve puzzles sequentially, without having to run parallel computations on them.
C-TLP makes black-box use of a standard time-lock puzzle scheme and is ac-
companied by a lightweight publicly verifiable algorithm. It is the first time-lock
puzzle that offers a combination of the above features. We use C-TLP to build the
first “outsourced proofs of retrievability” that can support real-time detection and
fair payment while having lower overhead than the state of the art. As another ap-
plication of C-TLP, we illustrate in certain cases, one can substitute a “verifiable
delay function” with C-TLP, to gain much better efficiency.
1 Introduction
Time-lock puzzles are interesting cryptographic primitives that allow sending informa-
tion to the future. They enable a party to lock a message such that, no one else can
unlock it until a certain time has passed3. They have a wide range of applications, such
as e-voting [15], fair contract signing [10], and sealed-bid auctions [42]. Over the last
two decades, a variety of time-lock puzzles have been proposed. Nevertheless, existing
puzzle schemes do not offer any efficient remedy for the multi-instance setting, where
a server is given multiple instances of a puzzle at once and it should find one puzzle’s
solution after another. It is a natural generalisation of the single puzzle setting. Appli-
cation areas include, but not limited to: (a) mass release of confidential documents over
time, (b) gradually revealing multiple secret keys, (c) verifying continuous availabil-
ity of cloud’s services, e.g. data storage or secure hardware, or (d) scheduled private
?aydinabadi@glos.ac.uk
?? akiayias@inf.ed.ac.uk
3There exist protocols that use an assistance of a third party to support time-release of a secret.
This protocols’ category is not our focus in this paper.
payments, where not only is every payment made after a certain period, but also the
payment details remain confidential during the period. If existing puzzle schemes are
used directly in the multi-instance setting, then the server has to deal with all puzzle in-
stances, right after it receives them. This results in a significant computation overhead
and requires a high level of parallelisation.
In this paper, we propose “multi-instance time-luck puzzle”, a primitive that allows
composing a puzzle’s instances, where given the composition, a server can deal with
each instance sequentially. We formally define the primitive and present an instantia-
tion of it, “chained time-lock puzzle” (C-TLP). It makes black-box use of a standard
time-lock puzzle scheme and is equipped with a lightweight verification algorithm that
allows anyone to check the correctness of a solution found by the server. Its overall
computation complexity of solving zpuzzles is equivalent to that of solving only the
last puzzle. The same procedure also imposes a communication overhead linear with
z, i.e. O(z). C-TLP is the first time-lock puzzle scheme that offers all the above fea-
tures. Furthermore, we present concrete applications of the primitive and demonstrate
its use case in a blockchain-based solution. Specifically, we combine the primitive’s
instantiation with a smart contract and apply the combination to “outsourced proofs of
retrievability” research line, and propose “smarter outsourced proofs of retrievability”
(SO-PoR) scheme which offers a combination of real-time detection (i.e. a data owner
client is notified in almost real-time when a PoR proof is rejected) and fair payment (i.e.
in every verification, the storage server is paid only if a PoR proof is accepted) while
imposing very low overhead, that makes it particularly suitable for mission-critical data.
SO-PoR verification and store phases impose 1
4.5and 1
46×105of computation costs im-
posed by the same phases in the fastest outsourced PoR. A server-side bandwidth of
SO-PoR is much lower too; for instance, for a 1-GB file and 100 verifications, a server
in SO-PoR requires 9×104times fewer bits than those required in the state of the art
protocol. Also, we show under certain circumstances C-TLP can play the role of a “veri-
fiable delay function” (VDF) but with much lower overhead, i.e. a prover’s computation
and communication costs will be reduced by factors of 3and 6.5respectively.
Summary of Our Contributions. We (a) put forth the notion of multi-instance time-
lock puzzle, formally define it, and identify its concrete applications, (b) present a can-
didate construction, C-TLP, the first multi-instance time-lock puzzle that is built on a
standard time-lock puzzle, supports public verifiability, and has low costs, (c) propose
the first outsourced PoR that can offer real-time detection and fair payment while main-
taining low costs, and (d) show in certain cases, a VDF can be replaced with C-TLP to
gain better efficiency.
2 Related Work
In this section, we provide a summary of related work. For a comprehensive survey, we
refer readers to Appendix A.
Time-lock Puzzles The idea to send information into the future, i.e. time-lock puz-
zle/encryption, was first put forth by Timothy C. May. A time-lock puzzle allows a
party to encrypt a message such that it cannot be decrypted until a certain time has
passed. In general, a time-lock scheme should allow generating (and verifying) a puz-
zle to take less time than solving it. The scheme that May proposed relies on a trusted
agent. Later, Rivest et al. [42] propose an RSA-based puzzle scheme that does not re-
quire a trusted agent, and is secure against a receiver who may have access to many
computation resources that run in parallel. The latter protocol has been the core of
(almost) all later time-lock puzzle schemes that supports the encapsulation of an ar-
bitrary message. Later, [10, 21] proposed a scheme which also let a puzzle generator
prove (in Zero-knowledge) to a puzzle solver that the correct solution will be recov-
ered after a certain time. Recently, [38,11] propose homomorphic time-lock puzzles,
where an arbitrary function can be run over puzzles before they are solved. In the pro-
tocols, all puzzles have an identical time parameter, and their solutions are supposed
to be discovered at the same time. They are based on the RSA-based puzzle and fully
homomorphic encryption, computationally expensive. Very recently, Chvojka et al. in
[16] propose incremental time-release encryption which lets a server, given a set of en-
crypted messages, discover messages sequentially over time. It is the closest work to
ours. Nevertheless, the scheme uses the RSA time-lock puzzle [42] in a non-black-box
manner, offers no (public) verification, is based on asymmetric key encryption instead
of symmetric key encryption used in the majority of time lock-puzzle schemes, and uses
a non-standard (asymmetric) encryption scheme.
Outsourced Proofs of Retrievability Proofs of retrievability (PoR) schemes, intro-
duced in [26], ensures a client’s data on a cloud server is fully accessible. Ever since a
variety of PoR’s has been proposed. Recently, [3, 52] present outsourced PoR protocols
that let clients outsource the verification to a potentially malicious third-party auditor.
The scheme in [3] has the fastest prove and verification algorithms. It uses message au-
thentication code (MAC) based tags, zero-knowledge proofs and error-correcting codes.
But, it has several shortcomings, i.e. it offers no real-time detection, provides no effi-
cient way for fair payments and has high costs of setup and auditor onboarding. Xu
et al. in [52] propose a publicly verifiable outsourced PoR to improve the previous
scheme’s setup cost. It uses BLS signatures-like tags, polynomial arithmetic and error-
correcting codes. It assumes an auditor is fully trusted during each verification whose
overhead is higher than [3]. Recently in [5] two protocols are proposed, “basic PoSt”
and “compact PoSt”. They ensure that a client’s data remains available on a server for
a period, without the client’s involvement in that period. The basic PoSt uses a Merkle
tree-based PoR and VDF. It has a high communication cost. Since it requires a verifier
to validate VDF’s outputs, it imposes a significant computation cost, in practice. The
compact PoSt has a lower communication cost than the basic one, as it let the server
combine PoR proofs. It is mainly based on a trapdoor delay function (TDF).
Blockchain-based PoR. There exist distributed PoR schemes that let a client distribute
its file among different (tailored) blockchain nodes, e.g. Permacoin [39], Filecoin [34],
and KopperCoin [30]. But, they have either a large proof size (e.g. in [39, 34]) logarith-
mic with the file size when a Merkle tree is used, or high concrete verification overhead
(e.g. in [30]) due to the use of BLS signatures. There are protocols that use blockchain
to verify the retrievability of off-chain data [41, 25, 56, 20, 8, 48]. Nevertheless, they ei-
ther impose a high communication/computation cost [41, 25, 20, 8, 48], or clients have
to be online for each verification [56]. Campanelli et al. [12] present a fair exchange
mechanism over a blockchain that ensures the server gets paid if it provides an accept-
ing PoR proof. But, this scheme assumes either the client can perform the verification
itself or a third-party, acting on the client’s behalf, carries out the verification honestly.
3 Preliminaries
In this section we provide the main primitives used in this work. We provide a notation
table in Appendix B.
3.1 Smart Contract
Cryptocurrencies, such as Bitcoin and Ethereum, in addition to offering a decentralised
currency, support computations on transactions. In this setting, often a certain com-
putation logic is encoded in a computer program, called “smart contract”. To date,
Ethereum is the most predominant cryptocurrency framework that enables users to de-
fine arbitrary smart contracts. In this framework, contract code is stored on the blockchain
and executed by all parties (i.e. miners) maintaining the cryptocurrency, when the pro-
gram inputs are provided by transactions. The program execution’s correctness is guar-
anteed by the security of the underlying blockchain components. To prevent a denial of
service attack, the framework requires a transaction creator to pay a fee, called “gas”,
depending on the complexity of the contract running on it.
3.2 Commitment Scheme
A commitment scheme involves two parties: sender and receiver, and includes two
phases: commit and open. In the commit phase, the sender commits to a message: m
as Com(m, d) = h, that involves a secret value: d. At the end of the commit phase, the
commitment: his sent to the receiver. In the open phase, the sender sends the opening:
¨p= (m, d)to the receiver who verifies its correctness: Ver(h, ¨p)?
= 1 and accepts if the
output is 1. A commitment scheme must satisfy two properties: (a) hiding: infeasible for
an adversary to learn any information about the committed value: m, until the commit-
ment: his opened, and (b) binding: infeasible for an adversary (i.e. the sender) to open
a commitment: hto different values: ¨p0= (m0, d0)than that used in the commit phase,
i.e. infeasible to find ¨p0,s.t. Ver(h, ¨p) = Ver(h, ¨p0)=1, where ¨p6= ¨p0. There exist ef-
ficient non-interactive commitment schemes both in (a) the random oracle model using
the well-known hash-based scheme that Com(m, d)involves computing: H(m||d) = h
and Ver(h, ¨p)requires checking: H(m||d)?
=h, where H(.)is a collision resistance hash
function, and (b) the standard model, e.g. Pedersen scheme [40].
3.3 Pseudorandom Function
Informally, a pseudorandom function (PRF) is a deterministic function that takes a key
and an input; and outputs a value indistinguishable from that of a truly random function
with the same input. A PRF is formally defined as follows [29].
Definition 1. Let W:{0,1}ψ× {0,1}η→ {0,1}ιbe an efficient keyed function. It is
said Wis a pseudorandom function if for all probabilistic polynomial-time distinguish-
ers B, there is a negligible function, µ(.), such that:
P r[BWk(.)(1ψ) = 1] −P r[Bω(.)(1ψ) = 1]
≤µ(ψ)
where the key, k$
← {0,1}ψ, is chosen uniformly at random and ωis chosen uniformly
at random from the set of functions mapping η-bit strings to ι-bit strings.
3.4 Time-lock Puzzle
In this section, we restate the formal definition of a time-lock puzzle as well as RSA-
based time-lock puzzle protocol [42]. We consider the RSA-based puzzle because of its
simplicity and being the core of (almost) all later time-lock puzzle schemes.
Definition 2 (Time-lock Puzzle). A time-lock puzzle comprises the following efficient
three algorithms, such that the puzzle satisfies completeness and efficiency properties.
–Algorithms:
•Setup(1λ, ∆)→(pk, sk): a probabilistic algorithm that takes as input security:
1λand time: ∆parameters. It outputs a public-private key pairs: (pk, sk)
•GenPuz(s, pk, sk)→¨o: a probabilistic algorithm that takes as input a solution:
sand the public-private key pairs: (pk, sk). It outputs a puzzle: ¨o
•SolvPuz(pk, ¨o)→s: a deterministic algorithm that takes as input the public
key: pk and puzzle: ¨o. It outputs a solution: s
–Completeness: always SolvPuz(pk, GenPuz(s, pk, sk )) = s
–Efficiency: the run-time of algorithm SolvPuz(pk, ¨o)is bounded by poly(∆, λ),
where poly(.)is a polynomial.
Informally, a time-lock puzzle’s security requires that the puzzle solution remain
hidden from all adversaries running in parallel within the time period, ∆. It is essential
that no adversary can find a solution in time δ(∆)< ∆, using π(∆)processors running
in parallel and after a potentially large amount of pre-computation. So, such factors are
explicitly incorporated into the puzzle’s definitions [9,38, 23].
Definition 3 (Time-lock Puzzle Security). A time-lock puzzle is secure if for all λ
and ∆, all probabilistic polynomial time adversaries A= (A1,A2)where A1runs in
total time O(poly(∆, λ)) and A2runs in time δ(∆)< ∆ using at most π(∆)parallel
processors, there exists a negligible function µ(.), such that:
P r
A2(pk, ¨o, state)→b
Setup(1λ, ∆)→(pk, sk)
A1(1λ, pk, ∆)→(s0, s1,state)
b$
← {0,1}
GenPuz(sb, pk, sk)→¨o
≤1
2+µ(λ)
An RSA-based time-lock puzzle construction that realises the above definitions was
proposed in [42]. The construction is as follows.
1. Setup:TLP.Setup(1λ, ∆)
(a) Compute N=q1q2, where qiis a large randomly chosen prime number. Then
compute Euler’s totient function of N, as: φ(N)=(q1−1)(q2−1)
(b) Set T=S∆ as the total number of squaring needed to decrypt an encrypted
message m, where ∆is the period (in seconds) within which the message should
remain private and Sis the maximum number of squaring modulo Nper second
that can be performed by a solver.
(c) Choose a random key: kfor a semantically secure symmetric key encryption
that has three algorithms: (GenKey,Enc,Dec)
(d) Pick a uniformly random value rfrom Z∗
N
(e) Compute a= 2Tmod φ(N)
(f) Set pk = (N, T , r)as public key and set sk = (q1, q2, a, k)as secret key.
2. Generate Puzzle:TLP.GenPuz(m, pk, sk)
(a) Encrypt the message using the symmetric key encryption: o1=Enc(k, m)
(b) Encrypt the key: k, as: o2=k+ramod N
(c) Sets: ¨o= (o1, o2)as ciphertext or puzzle. Next, output ¨o
3. Solve Puzzle:TLP.SolvPuz(pk, ¨o)
(a) Find b, where b=r2Tmod N, by using Tnumber of squaring rmodulo N
(b) Decrypt the key’s ciphertext: k=o2−bmod N
(c) Decrypt the message’s ciphertext: m=Dec(k, o1). Output m
Informally, the time-lock puzzle’s security relies on the hardness of factoring prob-
lem, the security of the symmetric key encryption, and sequential squaring assumption.
We refer readers to Appendix C for more discussion on the construction and its security.
4 Multi-instance Time-lock Puzzle
4.1 Strawman Solution
In the following, we elaborate on the problems that would arise if an existing time-lock
puzzle is used directly to handle multiple puzzles at once. Without loss of generality, to
illustrate the problems, we use the well-known TLP scheme presented in Section 3.4.
Consider the case where a client wants a server to learn a vector of messages: # »
m=
[m1, ..., mz]at times [f1, ..., fz]respectively, where the client is available and online
only at an earlier time f0< f1. For the sake of simplicity, let ∆=f1−f0and ∆=
fj+1 −fj, where 1≤j≤z. A naive way to address the problem is that the client uses
the TLP to encrypt each message mjseparately, such that it can be decrypted at time
fjif all ciphertexts and public keys are passed on to the server at time t0. For the server
to decrypt the messages on time, it needs to start decrypting all of them as soon as the
ciphertexts and public keys are given to it.
Parallel Composition Problem. The above naive approach yields two serious issues:
(a) imposing a high computation cost, as the server has to perform S∆
z
P
j=1
jsquaring to
decrypt all messages, and (b) demanding a high level of parallelisation, as each puzzle
has to be dealt with separately in parallel to the rest. The issues can be cast as “parallel
composition problem”, where zinstances of a puzzle scheme are given at once to a
server whose only option, to find solutions on time, is to solve them in parallel.4Also,
for the client to efficiently compute ajfor each message mj, where j > 1, it has to
perform at least one modular multiplication, i.e. aj=a1aj−1= 2jT , where a1= 2T. In
this step, in total z−1modular multiplications are required to compute all ajvalues,
for zmessages (which is not optimal). Note, we do not see the above issues as previous
schemes’ flaws, because they were not initially designed for the multi-puzzle setting.
4.2 An Overview of our Solutions
Our key observation is, in the naive approach, the process of decrypting messages has
many overlaps leading to a high computation cost. So, by removing the overlaps, we can
considerably lower the overall cost both in puzzle solving and puzzle creating phases.
One of our core ideas is to chain the puzzles. While chaining different puzzles may
seem a relatively obvious approach to tackle the issues, designing a secure protocol that
also can make black-box use of a standard time-lock puzzle scheme, supports public
verifiability, and has low costs is challenging (we refer readers to Remark 7 for a de-
tailed discussion). In our solution, a client first encrypts the message that is supposed to
be decrypted after the rest and embeds the information needed for decrypting it into the
ciphertext of the message that will be decrypted before that message. In other words, the
client integrates the information (i.e. a part of public keys) needed to decrypt message
mjinto the ciphertext related to message mj−1. In this case, the server after learning
message mj−1at time fj−1learns the public key needed to perform the sequential squar-
ing to decrypt the next message: mj. This means after fully decrypting mj−1, the server
starts squaring sequentially to decrypt mj
Addressing Parallel Composition Problem. The above approach solves the parallel
composition problem for two main reasons. First, the total number of squaring required
to decrypt all zmessages is now much lower, i.e. S∆z, and is equivalent to the number
of squaring needed to solve only the last puzzle, i.e. z-th one. Second, it does not call
for high parallelisation. Because now the server does not need to deal with all of the
puzzles in parallel; instead, it solves them sequentially one after another.
Adding Efficient Publicly Verifiable Algorithm. To let the scheme support efficient
public verifiability, we use the following novel trick. The client uses a commitment
scheme to commit to every message: miand publishes the commitment. Then, it uses
the time-lock encryption to encrypt the commitment’s opening, i.e. a combination of mi
and a random value. But, unlike the traditional commitment, the client does not open the
commitment itself. Instead, the server does that, after it discovers the puzzle’s solution.
When it finds a solution, it decodes the solution to find the opening and sends it to the
public who can check the solution correctness. So, to verify a solution’s correctness, a
verifier only needs to run the commitment’s verification algorithm that is: (a) publicly
verifiable, and (b) efficient. It can be built in the random oracle or the standard model.
The approach also allows the client at the setup to compute only a single a= 2T
reusable for all zpuzzles, imposing only O(1) cost.
4It should not be confused with the “universally composable” notion put forth in [13].
4.3 Multi-instance Time-lock Puzzle Definition
In this section, we provide a formal definition of a multi-instance time-lock puzzle.
Our starting point is the time-lock puzzle definition, i.e. Definition 2, but we extend it
from several perspectives, so it can: (a) handle multiple solutions/messages in setup, (b)
produce multiple puzzles for the messages, (c) solve the puzzles given the puzzles and
public parameters, and (d) support public verifiability. In the following, we provide the
formal definition of a multi-instance time-lock puzzle.
Definition 4 (Multi-instance Time-lock Puzzle). A multi-instance time-lock puzzle
has the following five algorithms and satisfies completeness and efficiency properties.
–Algorithms:
•Setup(1λ, ∆, z)→(pk, sk,
#»
d): a probabilistic algorithm that takes as input
security: 1λand time: ∆parameters and the total number of solutions/puzzles:
z. Let j∆ be a time period after which j-th solution is found. It outputs public-
private key pair: (pk, sk)and a vector of fixed size secret witnesses:
#»
d
•GenPuz(# »
m, pk, sk,
#»
d)→¨o: a probabilistic algorithm that takes as input a
message vector: # »
m= [m1, ..., mz], the public-private key pair: (pk, sk), and
the witness vector:
#»
d. It outputs ¨o: (#»
o,
#»
h), where #»
ois a puzzle vector, and
#»
h
is a commitment vector. Each j-th element in vectors #»
oand
#»
hcorresponds to a
solution sjof the form: sj=mj||dj
•SolvPuz(pk, #»
o)→#»
s: a deterministic algorithm that takes as input the public
key: pk and puzzle vector: #»
o. It outputs a solution vector: #»
s
•Prove(pk, sj)→¨pj: a deterministic algorithm that takes the public key: pk and
a solution: sj∈#»
s. It outputs a proof, ¨pj: (mj, dj)given to the verifier.
•Verify(pk, ¨pj, hj)→ {0,1}: a deterministic algorithm that takes public key:
pk, proof: ¨pjand commitment: hj∈
#»
h. It outputs 0if it rejects, or 1if it accepts.
–Completeness: for any honest prover and verifier, it always holds that:
•SolvPuz(pk, [o1, ..., oj]) = [s1, ..., sj], for every j,1≤j≤z
•Verify(pk, Prove(pk, sj), hj)→1
–Efficiency: the run-time of algorithm SolvPuz(pk, [o1, ..., oj]) = [s1, ...sj]is bounded
by: poly(j ∆, λ), where poly(.)is a fixed polynomial and 1≤j≤z
Informally, a multi-instance time-lock puzzle is secure if it satisfies two properties:
a solution’s privacy and validity. The former requires its j-th solution to remain hidden
from all adversaries running in parallel within time period: j∆, while the latter one
requires that it is infeasible for a PPT adversary to come up with an invalid solution and
passes the verification. The two properties are formally defined in Definitions 5 and 6.
Definition 5 (Multi-instance Time-lock Puzzle’s Solution-Privacy). A multi-instance
time-lock puzzle is privacy-preserving if for all λand ∆, any number of puzzle: z≥1,
any j(where 1≤j≤z), any pair of randomised algorithm A: (A1,A2), where A1
runs in time O(poly(j ∆, λ)) and A2runs in time δ(j∆)< j∆ using at most π(∆)
parallel processors, there exists a negligible function µ(.), such that:
P r
A2(pk, ¨o, state)→¨a
s.t.
¨a: (bi, i)
mbi,i =mbj,j
Setup(1λ, ∆, z)→(pk, sk ,
#»
d)
A1(1λ, pk, z)→(# »
m,state)
∀j0,1≤j0≤z:bj0$
← {0,1}
GenPuz(# »
m0, pk, sk,
#»
d)→¨o
≤1
2+µ(λ)
where # »
m: [(m0,1, m1,1), ..., (m0,z, m1,z )],# »
m0: (mb1,1, ..., mbz,z), and 1≤i≤z
The definition above also ensures the solutions to appear after j-th one, remain hid-
den from the adversary with a high probability, as well. Similar to [9, 38, 23], it captures
that even if A1computes on the public parameters for a polynomial time, A2cannot find
j-th solution in time δ(j∆)< j∆ using π(∆)parallel processors, with a probability
significantly greater than 1
2. As highlighted in [9], we can set δ(∆) = (1 −)∆for a
small , where 0<<1
Definition 6 (Multi-instance Time-lock Puzzle’s Solution-Validity). A multi-instance
time-lock puzzle preserves a solution validity, if for all λand ∆, any number of puzzles:
z≥1, all probabilistic polynomial-time adversaries A= (A1,A2)that run in time
O(poly(∆, λ)) there is negligible function µ(.), such that:
P r
A2(pk, #»
s,¨o, state)→a
s.t.
a: (j, ¨pj,¨p0)
¨pj: (mj, dj),¨p0: (m0, d0)
mj∈# »
m, dj∈
#»
d, m 6=m0
Verify(pk, ¨p, hj) = 1
Verify(pk, ¨p0, hj) = 1
Setup(1λ, ∆, z)→(pk, sk ,
#»
d)
A1(1λ, pk, ∆, z)→(# »
m,state)
GenPuz(# »
m, pk, sk,
#»
d)→¨o
SolvPuz(pk, #»
o)→#»
s
≤µ(λ)
where # »
m= [m1, ..., mz], and hj∈
#»
h∈¨o
Definition 7 (Multi-instance Time-lock Puzzle Security). A multi-instance time-lock
puzzle scheme is secure if it meets solution-privacy and solution-validity properties.
4.4 Chained Time-lock Puzzle (C-TLP) Protocol
In this section, we present the chained time-lock puzzle (C-TLP), an instantiation of the
multi-instance time lock puzzle. Since we have already presented an outline of C-TLP
(in Section 4.2), in this section we present C-TLP protocol in detail. Recall, a client
wants a server to learn a vector of messages: # »
m= [m1, ..., mz]at times [f1, ..., fz]
respectively, where the client is available and online only at an earlier time f0< f1.
Also, the client wants to ensure that anyone can validate a solution found by the server,
i.e. supports public verifiability. For the sake of simplicity, let ∆=f1−f0and ∆=
fj+1 −fj, where 1≤j≤zand T=S∆. Below, we provide C-TLP protocol. We refer
readers to Appendix D for further remarks on the protocol.
1. Setup:Setup(1λ, ∆, z).
(a) Call: TLP.Setup(1λ, ∆)→(ˆ
pk, ˆ
sk), s.t. ˆ
pk = (N, T , r1)and ˆ
sk = (q1, q2, a, k1)
(b) Pick z−1fixed size random generators: #»
r= [r2, ..., rz]from Z∗
N
(c) Pick z−1random keys: [k2, ..., kz]for a symmetric key encryption. Let
#»
k=
[k1, ..., kz], where k1∈ˆ
sk. Also, pick zfixed size sufficiently large random
values:
#»
d= [d1, ..., dz], e.g. |dj|= 128-bit or 1024-bit depending on the choice
of a commitment scheme.
(d) Set pk = (aux, N, T , r1)as public key. Set sk = (q1, q2, a,
#»
k,#»
r,
#»
d)as secret
key. Note, aux contains a cryptographic hash function’s description and the size
of the random values. Also, note that all generators, except r1are kept secret.
Output pk and sk
2. Generate Puzzle:GenPuz(# »
m, pk, sk)
Encrypt the messages, starting with j=z, in descending order. ∀j, z ≥j≥1 :
(a) Set pkj= (N, T , rj)and skj= (q1, q2, a, kj). Note, if j= 1 then rj∈pk;
otherwise (when j > 1), rj∈#»
r
(b) Generate a puzzle (or ciphertext pair):
•if j=z, then run: TLP.GenPuz(mj||dj, pkj, skj)→¨oj= (oj,1, oj,2)
•otherwise, run: TLP.GenPuz(mj||dj||rj+1, pkj, skj)→¨oj= (oj,1, oj,2)
(c) Commit to each message, e.g. H(mj||dj) = hjand output: hj
(d) Output: ¨oj= (oj,1, oj,2)as puzzle (or ciphertext pair).
By the end of this phase, vectors of puzzles: #»
o= [¨o1, ..., ¨oz]and commitments:
#»
h= [h1, ...hz]are generated. All public parameters and puzzles are given to a server
at time t0< t1, where ∆=f1−f0
3. Solve Puzzle:SolvPuz(pk, #»
o)
Decrypt the messages, starting with j= 1, in ascending order. ∀j, 1≤j≤z:
(a) If j= 1, then set rj=r1, where r1∈pk; Otherwise, set rj=u
(b) Set pkj= (N, T , rj)
(c) Run: TLP.SolvPuz(pkj,¨oj)→xj, where ¨oj∈#»
o
(d) Parse xj. Note that if j < z then xj=mj||dj||rj+1; otherwise, we have xj=
mj||dj. Therefore, xjis parsed as follows.
•if j < z :
i. Parse mj||dj||rj+1 into mj||djand u=rj+1
ii. Output sj=mj||dj
•otherwise (when j=z), output sj=xj=mj||dj
4. Prove:Prove(pk, sj). Parse sjinto ¨pj: (mj, dj), and send the pair to the verifier.
5. Verify:Verify(pk, ¨pj, hj). Verifies the commitment, H(mj, dj)?
=hj. If passed,
accept the solution and output 1; otherwise, reject it and output 0
Theorem 1 (C-TLP Security). C-TLP is a secure multi-instance time-lock puzzle.
Proof (Outline). The proof of Theorem 1 relies on the security of the TLP, symmetric
key encryption, and commitment schemes. It is also based on the fact that the proba-
bility to find a certain random generator is negligible. It shows both C-TLP’s solution
privacy (due to security of the above three schemes) and validity (due to the security of
the commitment) are satisfied. We refer readers to Appendix E for detailed proof. 2
4.5 Cost Analysis Table
We summarize C-TLP’s cost analysis in Table 1. It considers a generic setting where
the protocol deals with zpuzzles. We refer readers to Appendix F for detailed analysis.
Table 1: C-TLP’s Detailed Cost Breakdown
(a) Computation Cost
Protocol Function
Protocol Operation GenPuz SolvPuz Verify Complexity
Exp. z+ 1 T z −
O(T z)
Add. or Mul. z z −
Commitment z−z
C-TLP
Sym. Enc z z −
(b) Communication Cost (in bit)
Protocol Model Client Server Complexity
Standard 3200z1524z
O(z)C-TLP
R.O. 2432z628z
5 Smarter Outsourced PoR (SO-PoR) Using C-TLP
As discussed in Section 2, the existing outsourced PoR’s have serious shortcomings,
e.g. having high costs, not supporting real-time detection, or suffering from the lack of
a fair payment mechanism. In this section, we present SO-PoR to addresses them.
5.1 SO-PoR Overview
SO-PoR uses a unique combination of (a) homomorphic MAC-based PoR [45], (b) C-
TLP, (c) a smart contract, (d) a pre-computation technique, and (e) blockchain-based
random extraction beacon [1, 3]. It uses the MAC-based PoR, due to its high efficiency.
Since the MAC’s are privately verifiable and secret verification keys are needed to check
PoR proofs, SO-PoR also uses C-TLP to efficiently make them publicly verifiable. In
this case, C-TLP encapsulates the verification keys and reveals each of them to ver-
ifiers only after a certain time. SO-PoR also uses a smart contract which acts as a
public verifier on the client’s behalf to verify proofs and pay an honest server. The
pre-computation technique allows the client at setup to generate a constant number of
disposable homomorphic MAC’s for each verification. The combination of disposable
homomorphic MAC’s and C-TLP makes it possible to (a) use a smart contract and (b)
take advantage of MAC’s efficiency in the setting where public verifiability is needed.
This combination has applications beyond PoR. A blockchain-based random extraction
beacon allows the server to independently derive a set of unpredictable random values
from the blockchain such that the values’ correctness is publicly verifiable.
At a high-level SO-PoR works as follows. The client encodes its file using an error-
correcting code and for each j-th verification it does the following. It picks two random
keys: (vj, lj)of a PRF. It uses vjto generate crandom blocks’ indices, i.e. challenged
blocks. It uses ljto generate a disposable MAC on each challenged block. It also uses
C-TLP to make two puzzles, one that encapsulates vj, and another that encapsulates lj.
It deposits enough coins to cover zsuccessful PoR verifications in a smart contract. The
client sends the encoded file, tags and the puzzles to the server. When j-th PoR proof
is needed, the server manages to discover key vjthat lets it determine which file blocks
are challenges. The server also uses the beacon to extract a set of random values from
the blockchain. Using the MAC’s, challenged blocks, and beacon’s outputs, the server
generates a compact PoR proof. The server sends the proof to the contract. After that,
it can delete the related disposable MAC’s. For the same verification, after a fixed time,
it manages to find the related MAC’s verification key: lj. It sends the key to the server
who checks the correctness of ljand PoR proof. If the contract accepts all proofs, then
it pays the server for j-th verification; otherwise, it notifies the client.
5.2 SO-PoR Model Overview
SO-PoR model is built upon the traditional PoR paradigm [45] which is a challenge-
response protocol where a server proves to an honest client that its file is retrievable (see
Appendix G for a formal definition of the PoR). In SO-PoR, however, a client may not
be available for verification. So, it wants to delegate a set of verifications that it cannot
carry out. Informally, in this setting, it (in addition to file retrievability) must have three
guarantees: (a) verification correctness: every verification is performed honestly, so the
client can trust the verification’s result without redoing it, (b) real-time detection: the
client is notified in almost real-time when a proof is rejected, and (c) fair payment:
in every verification, the server is paid only if a proof is accepted. In SO-PoR, three
parties are involved: an honest client, potentially malicious server and a standard smart
contract. SO-PoR also, analogous to [45], allows a client to perform the verification
itself, when it is available. We present our formal definition of SO-PoR in Appendix H.
5.3 SO-PoR Protocol
This section presents SO-PoR protocol in detail, followed by the rationale behind it.
1. Client-side Setup.
(a) Gen. Public and Private Keys: Picks a fresh key: ˆ
kand two vectors of keys: #»
vand
#»
l, where each vector contains zfresh keys. It picks a large prime number: p
whose size is determined by a security parameter, (i.e. its bit-length is equal to
the bit-length of PRF(.)’s output, |p|=ι). Moreover, it runs Setup(.)in C-TLP
scheme to generate a key pair: (pk, sk)
(b) Gen. Other Public Parameters: Sets cto the total number of blocks challenged in
each verification. It defines parameters: wand g, where wis an index of a future
block: Bwin a blockchain that will be added to the blockchain (permanent state)
at about the time first delegated verification will be done, and gis a security
parameter referring to the number of blocks (in a row) starting from w. It sets
z: the total number of verifications, ||F||: file bit size, ∆1: the maximum time is
taken by the server to generate a proof, ∆2: time window in which a message is
(sent by the server and) received by the contract, and eamount of coins paid to
the server for each successful verification. Sets ˆ
pk : (pk, e, g, w , p, c, z, ∆1, ∆2)
(c) Sign and Deploy Smart Contract: Signs and deploys a smart contract: SC to a
blockchain. It stores public parameters: (z, ||F||, ∆1, ∆2, c, g, p, w), on the con-
tract. It deposits ez coins to the contract. Then, it asks the server to sign the
contract. The server signs if it agrees on all parameters.
2. Client-side Store.
(a) Encode File: Splits an error-corrected file, e.g. under Reed-Solomon codes, into
nblocks; F: [F1, ..., Fn], where Fi∈Fp
(b) Gen. Permanent Tags: Using the key: ˆ
k, it computes npseudorandom values: ri
and single value: α, as follows.
α=PRF(ˆ
k, n + 1) mod p, ∀i, 1≤i≤n:ri=PRF(ˆ
k, i) mod p
It uses the pseudorandom values to compute tags for the file blocks.
∀i, 1≤i≤n:σi=ri+α·Fimod p
So, at the end of this step, a set of tags are generated, σ:{σ1, ..., σn}
(c) Gen. Disposable Tags: For j-th verification (1≤j≤z):
i. chooses the related key: vj∈#»
vand computes cpseudorandom indices.
∀b, 1≤b≤c:xb,j =PRF(vj, b) mod n
ii. picks the corresponding key: lj∈
#»
land computes cpseudorandom values:
rb,j and single value: αj, as follows.
αj=PRF(lj, c + 1) mod p, ∀b, 1≤b≤c:rb,j =PRF(lj, b) mod p
iii. generates cdisposable tags.
∀b, 1≤b≤c:σb,j =rb,j +αj·Fymod p
where y=xb,j . At the end of this step, a set σjof ctags are computed,
σj:{σ1,j , ..., σc,j }
(d) Gen. Puzzles: Sets # »
m= [v1, l1, ..., vz, lz]and then encrypts the vector’s elements,
by running: GenPuz(# »
m, pk, sk)in C-TLP scheme. This yields a puzzle vector:
[(V1, L1), ..., (Vz, Lz)] and a commitment vector:
#»
h. The encryption is done in
such a way that in each j-th pair, Vjwill be fully decrypted at times tjand Lj
will be decrypted at time t0
j, where tj+∆1+∆2≤t0
j< tj+1
(e) Outsource File: Stores F, n, ˆ
pk, {σ, σ1, ..., σz,(V1, L1), ..., (Vz, Lz)}on the server.
Also, it stores
#»
hon the smart contract.
3. Cloud-Side Proof Generation. For j-th verification (1≤j≤z), the cloud:
(a) Solve Puzzle and Regen. Indices: Receives and parses the output of SolvPuz(.)in
C-TLP, to extract vj, at time tj. Using vj, it regenerates cpseudorandom indices.
∀b, 1≤b≤c:xb,j =PRF(vj, b) mod n
(b) Extract Key: Extracts a seed: uj, from the blockchain as follows: uj=H(Bγ||...||Bζ),
where γ=w+ (j−1) ·gand ζ=w+j·g
(c) Gen. PoR: Generates a PoR proof.
µj=
c
X
b=1
PRF(uj, b)·Fymod p, ξj=
c
X
b=1
PRF(uj, b)·σb,j mod p
where yis a pseudorandom index: y=xb,j
(d) Register Proofs: Sends the PoR proof: (µj, ξj)to the smart contract within ∆1
(e) Solve Puzzle and Regen. Verification Key: Receives and parses the output of algo-
rithm SolvPuz(.)in C-TLP to extract lj, at time t0
j. Also, it runs Prove(.)in
C-TLP, to generate a proof: ¨pj, of lj’s correctness. It sends ¨pj(containing lj) to
the contract, so it can be received by the contract within ∆2
4. Smart Contract-Side Verification. For j-th verification (1≤j≤z), the contract:
(a) Check Arrival Time: checks the arrival time of the decrypted values sent by the
server. In particular, it checks, if (µj, ξj)was received in the time window:
(tj, tj+∆1+∆2]and whether ljwas received in the time window: (t0
j, t0
j+∆2]
(b) Verify Puzzle Solution: runs Verify(.)in C-TLP to verify ¨pj(i.e. checks the cor-
rectness of lj∈¨pj). If approved, then it regenerates the seed: uj=H(Bγ||...||Bζ),
where γ=w+ (j−1) ·gand ζ=w+j·g
(c) Verify PoR: regenerates the pseudorandom values and verifies the PoR proof.
ξj
?
=µj·PRF(lj, c + 1) +
c
X
b=1
(PRF(uj, b)·PRF(lj, b)) mod p(1)
(d) Pay: if Equation 1 holds, pays and asks the server to delete all disposable tags
for this verification, i.e. σj
If either check fails, it aborts and notifies the client.
5. Client-server PoR: When the client is online, it can interact with the server to check
its data availability too. In particular, it sends crandom challenges and random in-
dices to the server who computes POR using only: (a) the messages sent by the client
in this step, (b) the file: F, and (c) the tags: σi∈σ, generated in step 2b. The proof
generation and verification are similar to the MAC-based schemes, e.g. [45].
Theorem 2. SO-PoR protocol is secure if the MAC’s are unforgeable, PRF(.)is a secure
pseudorandom function, the blockchain and C-TLP protocol are secure, and H(Bγ||...||Bζ)
outputs an unpredictable random value (where ζ−γis a security parameter).
Proof (Outline). Let Mibe a blockchain miners and βbe the maximum number of
miners which can be corrupted in a secure blockchain. We first argue that the adver-
sary who corrupts either C⊆ {M1, ..., Mβ}or C0⊆ {S,M1, ..., Mβ−1}with a high
probability, cannot influence the output of Verify(.)performed by a smart contract in
a blockchain (i.e. the verification correctness holds) due to the security of the underly-
ing blockchain. Then, we argue that if a proof produced by an adversary who corrupts
C0⊆ {S,M1, ..., Mβ−1}is accepted by Verify(.)with probability at least , then the
file can be extracted by a means of an extraction algorithm, due to the security of the
underlying MAC’s, PRF(.)and C-TLP as well as the unpredictability of random extrac-
tor beacon’s output, i.e. H(Bγ||...||Bζ). Next, we argue that after the server broadcasts a
proof at a certain time to the network, the client can get a correct output of Verify(.)at
most after time period Υ, by a means of reading the blockchain, due to the correctness
of Verify(.)and the maximum delay on the client’s view of the output (i.e. Υ-real-time
detection). Also, we argue that fair payment is held due to the security of blockchain
and correctness of Pay(.). We refer readers to Appendix I for detailed proof. 2
5.4 Evaluation
In this section, we provide a summary of comparisons between SO-PoR and outsourced
PoRs [3, 52, 5]. Among the two protocols in [5] we only consider “basic PoSt” as it sup-
ports public verifiability. Briefly, in terms of property, only SO-PoR offers an explicit
solution for real-time detection and fair payment. In terms of computation cost, the veri-
fication algorithm in SO-PoR is much faster than the other three protocols; Specifically,
when c= 460, SO-PoR verification5needs about 4.5times fewer computation than
the verification required in the fastest outsourced PoR [3]. Also, [3] has the worst store
cost, that is much higher than that of SO-PoR; e.g. for a 1-GB file, SO-PoR requires
over 46 ×105times fewer exponentiations than [3] needs in the same phase. SO-PoR
and [5] require a server to solve puzzles (and the imposed cost has to be compensated
5As shown in [4], to ensure 99% of file blocks is retrievable, it suffices to set c= 460.
by the client) but the other two protocols do not need that. Also, I/O cost and proof
complexity of all protocols are O(1) except [5] whose I/O cost and proof complexity
are O(log n). The server-side bandwidth of SO-PoR is much lower than the rest; e.g.,
for 1-GB file and z= 100 verifications, a server in SO-PoR requires 9×104,7and
1729 times fewer bits than those required in [3], [52] and [5] respectively. A client in
SO-PoR has a higher bandwidth than the rest (but this cost is one-off). Thus, SO-PoR
offers additional properties, it has lower verification cost and lower server-side band-
width than the rest while its other costs remain reasonable. Table 2 outlines the cost
comparison results. For a full analysis, we refer readers to Appendix K where we also
compare SO-PoR costs with that of the most efficient traditional PoR [45].
Table 2: Outsourced PoR’s Cost Comparison. z: total verifications, c: number of challenges for
each verification, n: total number of file blocks, c0= (0.1)c, and ||F||: file bit size.
Computation Cost Communication Cost
Protocols Operation Store SolvPuz Prove Verify Client Server Verifier Proof Size
Exp. z+ 1 T z − − 128(n+
SO-PoR Add. or Mul. 2(n+cz )z4cz 2z(1 + c)cz + 19z)884z−O(1)
Exp. 9n− − −256z+ 4672n+
[3] Add. or Mul. 10n−4z(c+c0)z(9c+ 3) 128n||F|| 256zO(1)
Exp. −−z(3 + c) 6z
Add. or Mul. 4n−2z(3c+ 4) 2cz
[52]
Pairing − − 7z−2048n6144z−O(1)
Exp. −3T z −3z128cz log n+
[5] Add. or Mul. −T z − − 128 4096z−O(log n)
6 C-TLP as Efficient Variant of VDF
There are cases where a client wants a server to learn distinct random challenges, at
different points in time within a certain period, without the client’s involvement in that
period. Such challenges can let the server generate certain proofs that include but are
not limited to the continuous availability of services, such as data storage or secure
hardware. The obvious candidates that can meet the above needs are VDF (if public
verifiability is desirable) and TDF (if private verifiability suffices). PoSt protocols in
[5] are two examples of the above cases. We observed that in these cases, VDF/TDF
can be replaced with C-TLP to gain better efficiency. The idea is that the client computes
random challenges, encodes them into C-TLP puzzles and sends them to the server who
can eventually solve each puzzle, extract a subset of challenges and use them for the re-
lated proof scheme while letting the public efficiently verify the solutions’ correctness.
To illustrate the efficiency gain, we compare C-TLP performance with the two current
VDF functions [50, 9]. Table 3 summarises the result. The cost analysis considers the
generic setting where zoutputs are generated. Among several VDF schemes proposed
in [9], we focus on the one that uses sequential squaring, as it is more efficient than
the other schemes in [9]. As the table indicates, the overall cost of [9] in each of the
three phases is much higher than C-TLP and [50]. Now, we compare the computation
cost of C-TLP with [50]. At setup, a client in C-TLP performs at most 3z+ 1 more
exponentiations than it does in [50]. But, at both prove and verify phases, C-TLP out-
performs [9], especially when they are in the same model. In particular, at the prove
phase, C-TLP, in both models, requires T z fewer multiplications than [50] does. Also,
in the same phase, it requires 3times fewer exponentiations than [50]. In the verify
phase, when C-TLP is in the standard model, it has a slightly lower cost than [50] has in
the random oracle model. However, when both of them are in the random oracle model,
C-TLP has a much lower cost, as it requires no exponentiations whereas [50] needs 3z
exponentiations. Hence, C-TLP supports both standard and random oracle models and
in both paradigms, it outperforms the fasted VDF, i.e. [50], designed in the random or-
acle model. Furthermore, the proof size in C-TLP is 3.2and 6.5times shorter than [9]
and [50] respectively, when they are in the same model. In Appendix L, we also show
how C-TLP can be employed in the PoSt protocols [5] to reduce costs.
Table 3: VDF’s Cost Comparison
Computation Cost
Protocols Model Operation Setup Prove Verify Proof size (bit)
Exp. 3z+ 1 T z 2z1524zStandard Mul. z−z
Exp. z+ 1 T z −628z
C-TLP
R.O. Mul. − − −
Exp. 230 T z z 2048z[9] R.O. Mul. −2z·230 2z·230
Exp. −3T z 3z4096z[50] R.O. Mul. −T z −
7 Conclusion
Time-lock puzzles are important cryptographic protocols with various applications. But,
existing puzzle schemes are not suitable to deal with multiple puzzles at once. In this
work, we put forth the concept of composing multiple puzzles, where given puzzles
composition at once, a server can find one puzzle’s solution after another. This process
does not require the server to deal with all of them in parallel which reliefs the server
from having numerous parallel processors and allows it to save considerable compu-
tation overhead. We proposed a candidate construction: chained time-lock puzzle (C-
TLP) that possesses the aforementioned features. Furthermore, C-TLP is equipped with
an efficient verification algorithm publicly executable. We also illustrated how to use
C-TLP to construct an efficient outsourced proofs of retrievability scheme that supports
real-time detection and fair payment while keeping its costs considerably lower than
the state of the art protocols. Moreover, we showed how VDF’s in certain settings can
be replaced with C-TLP to gain considerable cost improvement.
References
1. Abadi, A., Ciampi, M., Kiayias, A., Zikas, V.: Timed signatures and zero-knowledge proofs
-timestamping in the blockchain era-. IACR Cryptology ePrint Archive 2019, 644 (2019)
2. Armknecht, F., Barman, L., Bohli, J., Karame, G.O.: Mirror: Enabling proofs of data repli-
cation and retrievability in the cloud. In: 25th USENIX Security 16
3. Armknecht, F., Bohli, J.M., Karame, G.O., Liu, Z., Reuter, C.A.: Outsourced proofs of re-
trievability. In: CCS’14
4. Ateniese, G., Burns, R.C., Curtmola, R., Herring, J., Kissner, L., Peterson, Z.N.J., Song,
D.X.: Provable data possession at untrusted stores. In: CCS’07
5. Ateniese, G., Chen, L., Etemad, M., Tang, Q.: Proof of storage-time: Efficiently checking
continuous data availability. In: NDSS’20
6. Ateniese, G., Pietro, R.D., Mancini, L.V., Tsudik, G.: Scalable and efficient provable data
possession. In: SECURECOMM’08
7. Badertscher, C., Maurer, U., Tschudi, D., Zikas, V.: Bitcoin as a transaction ledger: A com-
posable treatment. In: Katz, J., Shacham, H. (eds.) CRYPTO’17
8. Banerjee, P., Nikam, N., Ruj, S.: Blockchain enabled privacy preserving data audit. CoRR
abs/1904.12362 (2019)
9. Boneh, D., Bonneau, J., B¨
unz, B., Fisch, B.: Verifiable delay functions. In: Shacham, H.,
Boldyreva, A. (eds.) CRYPTO’18
10. Boneh, D., Naor, M.: Timed commitments. In: Bellare, M. (ed.) CRYPTO 2000
11. Brakerski, Z., D¨
ottling, N., Garg, S., Malavolta, G.: Leveraging linear decryption: Rate-1
fully-homomorphic encryption and time-lock puzzles. In: TCC’19,
12. Campanelli, M., Gennaro, R., Goldfeder, S., Nizzardo, L.: Zero-knowledge contingent pay-
ments revisited: Attacks and payments for services. In: CCS’17
13. Canetti, R.: Universally composable security: A new paradigm for cryptographic protocols.
In: 42nd Annual Symposium on Foundations of Computer Science, FOCS 2001, 14-17 Oc-
tober 2001, Las Vegas, Nevada, USA. pp. 136–145. IEEE Computer Society (2001)
14. Cash, D., K¨
upc¸¨
u, A., Wichs, D.: Dynamic proofs of retrievability via oblivious ram. J. Cryp-
tol. (2017)
15. Chen, H., Deviani, R.: A secure e-voting system based on RSA time-lock puzzle mechanism.
In: BWCCA’12 ,
16. Chvojka, P., Jager, T., Slamanig, D., Striecks, C.: Generic constructions of incremental and
homomorphic timed-release encryption. IACR Cryptol. ePrint Arch.
17. Dwork, C., Naor, M.: Pricing via processing or combatting junk mail. In: Brickell, E.F. (ed.)
CRYPTO’92
18. Erway, C.C., K¨
upc¸¨
u, A., Papamanthou, C., Tamassia, R.: Dynamic provable data possession.
In: CCS’09
19. Etemad, M., K¨
upc¸¨
u, A.: Transparent, distributed, and replicated dynamic provable data pos-
session. In: Jacobson, M., Locasto, M., Mohassel, P., Safavi-Naini, R. (eds.) ACNS’13
20. Francati, D., Ateniese, G., Faye, A., Milazzo, A.M., Perillo, A.M., Schiatti, L., Giordano,
G.: Audita: A blockchain-based auditing framework for off-chain storage. CoRR’19
21. Garay, J.A., Jakobsson, M.: Timed release of standard digital signatures. In: Blaze, M. (ed.)
FC’02
22. Garay, J.A., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol with chains of vari-
able difficulty. In: Katz, J., Shacham, H. (eds.) CRYPTO’17
23. Garay, J.A., Kiayias, A., Panagiotakos, G.: Iterated search problems and blockchain security
under falsifiable assumptions. IACR Cryptology ePrint Archive (2019)
24. Groza, B., Petrica, D.: On chained cryptographic puzzles. In: SACI’06,
25. Hao, K., Xin, J., Wang, Z., Jiang, Z., Wang, G.: Decentralized data integrity verification
model in untrusted environment. In: APWeb-WAIM’18
26. Juels, A., Jr., B.S.K.: Pors: proofs of retrievability for large files. In: CCS’07
27. Kamara, S.: Proofs of storage: Theory, constructions and applications. In: CAI’13
28. Karame, G., Capkun, S.: Low-cost client puzzles based on modular exponentiation. In:
Gritzalis, D., Preneel, B., Theoharidou, M. (eds.) ESORICS ’10
29. Katz, J., Lindell, Y.: Introduction to Modern Cryptography. Chapman and Hall/CRC Press
(2007)
30. Kopp, H., B¨
osch, C., Kargl, F.: Koppercoin - A distributed file storage with financial incen-
tives. In: ISPEC’16
31. Kopp, H., M¨
odinger, D., Hauck, F.J., Kargl, F., B¨
osch, C.: Design of a privacy-preserving
decentralized file storage with financial incentives. In: EuroS&P Workshops’17
32. Kupcu, A.: Efficient cryptography for the next generation secure cloud. Brown University
(2010)
33. Kuppusamy, L., Rangasamy, J., Stebila, D., Boyd, C., Nieto, J.M.G.: Practical client puzzles
in the standard model. In: Youm, H.Y., Won, Y. (eds.) ASIACCS ’12
34. Labs, P.: Filecoin: A decentralized storage network (2017), https://filecoin.io/filecoin.pdf
35. Luu, L., Teutsch, J., Kulkarni, R., Saxena, P.: Demystifying incentives in the consensus com-
puter. In: Ray, I., Li, N., Kruegel, C. (eds.) CCS’15
36. Ma, M.: Mitigating denial of service attacks with password puzzles. In: ITCC’05
37. Mahmoody, M., Moran, T., Vadhan, S.P.: Time-lock puzzles in the random oracle model. In:
CRYPTO’11
38. Malavolta, G., Thyagarajan, S.A.K.: Homomorphic time-lock puzzles and applications. In:
CRYPTO’19
39. Miller, A., Juels, A., Shi, E., Parno, B., Katz, J.: Permacoin: Repurposing bitcoin work for
data preservation. In: S&P’14
40. Pedersen, T.P.: Non-interactive and information-theoretic secure verifiable secret sharing. In:
CRYPTO ’91
41. Renner, T., M ¨
uller, J., Kao, O.: Endolith: A blockchain-based framework to enhance data
retention in cloud storages. In: PDP’18
42. Rivest, R.L., Shamir, A., Wagner, D.A.: Time-lock puzzles and timed-release crypto. Tech.
rep. (1996)
43. Ruj, S., Rahman, M.S., Basu, A., Kiyomoto, S.: Blockstore: A secure decentralized storage
framework on blockchain. In: AINA’18
44. Sengupta, B., Ruj, S.: Keyword-based delegable proofs of storage. In: ISPEC’18
45. Shacham, H., Waters, B.: Compact proofs of retrievability. In: ASIACRYPT. pp. 90–107
(2008)
46. Shen, S., Tzeng, W.: Delegable provable data possession for remote data in the clouds. In:
ICICS 2011
47. Shi, E., Stefanov, E., Papamanthou, C.: Practical dynamic proofs of retrievability. In: CCS’13
48. Vorick, D., Champine, L.: Sia: Simple decentralized storage. Nebulous Inc (2014)
49. Waters, B., Juels, A., Halderman, J.A., Felten, E.W.: New client puzzle outsourcing tech-
niques for dos resistance. In: CCS’04
50. Wesolowski, B.: Efficient verifiable delay functions. In: Ishai, Y., Rijmen, V. (eds.) EURO-
CRYPT’19
51. Wilkinson, S., Boshevski, T., Brandoff, J., Buterin, V.: Storj: a peer-to-peer cloud storage
network (2014)
52. Xu, J., Yang, A., Zhou, J., Wong, D.S.: Lightweight delegatable proofs of storage. In: ES-
ORICS’16
53. Xue, J., Xu, C., Bai, L.: Dstore: A distributed system for outsourced data storage and re-
trieval. Future Generation Comp. Syst. 2019
54. Xue, J., Xu, C., Zhang, Y., Bai, L.: Dstore: A distributed cloud storage system based on smart
contracts and blockchain. In: ICA3PP’18
55. Yao, A.C.: Protocols for secure computations (extended abstract). In: FOCS’1982
56. Zhang, Y., Deng, R.H., Liu, X., Zheng, D.: Blockchain based efficient and robust fair pay-
ment for outsourcing services in cloud computing. Inf. Sci. (2018)
A Survey of Related Work
A.1 Time-lock Puzzles
The idea to send information into the future, i.e. time-lock puzzle/encryption, was first
put forth by Timothy C. May. A time-lock puzzle allows a party to encrypt a message
such that it cannot be decrypted until a certain amount of time has passed. In general,
a time-lock scheme should allow generating (and verifying) a puzzle to take less time
than solving it. The time-lock puzzle scheme that May proposed lies on a trusted agent.
Later on, Rivest et al [42] propose a protocol that does not require a trusted agent and
is secure against a receiver who may have access to many computation resources that
can be run in parallel. It is based on Blum-Blum-Shub pseudorandom number generator
that relies on modular repeated squaring, believed to be sequential. The scheme in [42]
allows (only) the puzzle creator to verify the correctness of the puzzle solution using a
secret key and the original secret message. This scheme has been the core of (almost)
all later time-lock puzzles schemes that supports the encapsulation of an arbitrary mes-
sage. Later on, [10, 21] proposed timed commitment schemes that offer more security
properties, in the sense that they allow a puzzle generator to prove (in Zero-knowledge)
to a puzzle solver that the correct solution (e.g. a signature of a public document) will be
recovered after a certain time before the solver starts solving the puzzle. These schemes
are more complex, due to the use of zero-knowledge proofs, and less efficient than [42].
Recently, [38,11] propose protocols for homomorphic time-lock puzzles, where an ar-
bitrary function can be run over puzzles before they are solved. They mainly use fully
homomorphic encryption and the RSA puzzle, proposed in [11], in a nutshell. In these
protocols, all puzzles have an identical time parameter, and their solutions are supposed
to be discovered at the same time. The main difference between the two protocols is the
security assumption they rely on (i.e. the former uses a non-standard assumption while
the latter relies on a standard one). Since both schemes use a generic fully homomor-
phic encryption, it is not hard to make them publicly verifiable. However, they are only
of theoretical interest as in practice they impose high computation and communication
costs, due to the use of fully homomorphic encryptions.
Very recently, Chvojka et al. in [16] propose incremental time-release encryption
that allows a server to decrypt messages sequentially over time. This is the closest work
to ours. Nevertheless, the scheme uses the RSA time-lock puzzle [42] in a completely
non-black-box manner, offers no (public) verification, and is based on asymmetric key
encryption instead of symmetric key encryption used in the majority of time lock-
puzzle schemes including in [42]. The latter issue leads to a higher computation cost
(compared to standard time lock puzzles) and can negatively affect efficiency gains
the scheme tries to achieve. At a high level, the scheme works as follows. A client
who wants its messages [m1, m2, . . . , mn]to be revealed at time [f1, f2...,fn], at setup
computes g2T1(modN), g2T2(modN), . . . , g 2Tn(modN), where gis a random value,
Nis a RSA modulus and Tiis the number of squaring required to find message miat
time fi. Then, it uses asymmetric key encryption to encrypt each mi, such that g2Tiis
used as randomness for the encryption’s key generation algorithm. Then, it publishes all
ciphertexts and gat time f0< f1. For a server to discover m1, it performs T1squaring
to find g2T1. Then, it runs the encryption’s key generation algorithm that takes g2T1as
input and returns secret and public keys. The server uses the secret key to decrypt the
message. After that, it performs modular squaring on g2T1until it computes g2T2. Then,
it calls the key generation algorithm again this time using g2T2as the randomness to
find the secret key with which it can discover m2. It carries on the above process until it
discovers mn. The idea of computing g2Ti+1 from g2Ti, proposed in the above scheme,
is very similar to the notion of “time-line” proposed by Garay et al. in [21]. Also, the
asymmetric encryption used in the above scheme is not standard. Because its key gen-
eration algorithm is deterministic and takes an extra input which is randomness from
which public key and private keys are extracted. Whereas, in standard asymmetric en-
cryption schemes, a key generation algorithm is probabilistic and only takes a security
parameter. Moreover, as discussed in section 4.1, in the case where the time intervals
are equal, e.g. TN−TN−1=Tj−Tj−1, the client still has to perform in total n−1mod-
ular multiplications to efficiently compute all g2T1, g2T2,...g2Tn, which is not optimal
either.
We also cover two related but different notions, pricing puzzles, and verifiable delay
functions.
Pricing Puzzles. Also known as client puzzles. It was first put forth by Dwork et al. [17]
who defined it as a function that requires a certain amount of computation resources
to solve a puzzle. In general, the pricing puzzles are based on either hash inversion
problems or number-theoretic. In the former category, a puzzle generator generates a
puzzle as: h=H(m||r), where His a hash function, mis a public value and ris a
random value of a fixed size. Given h, Hand m, the solver must find rsuch that the
above equation holds. The size of ris picked in such a way that the expected time to
find the solution is fixed (however it does not rule out finding the solution on the first
attempt). The above hash-based scheme allows a solver to find a solution faster if it has
more computational power resources running in parallel. The application area of such a
puzzle includes defending against denial-of-service (DoS) attacks, reaching a consensus
in cryptocurrencies, etc. A variant of such a puzzle uses iterative hashing; for instance,
to generate a set of puzzles in the case where the solver receives a service proportional
to the number of puzzles it solves [24], or to generate password puzzle to mitigate
DoS attacks [36]. However, the iterative hashing schemes are partially parallelizable,
in the sense that every single invocation of the hash function can be run in parallel.
Later on, [37] investigates the possibility of constructing (time-lock) puzzles in the
random oracle model. Their main result was negative, that rules out time-lock puzzles
that require more parallel time to solve than the total work required to generate. Also
[37] proposes an iterative hash-based mechanism (very similar to [36]) that allows a
puzzle generator to generate a puzzle with nparallel queries to the random oracle, but
the solver needs nrounds of serial queries. Nevertheless, this scheme is also partially
parallelizable, as each instance of the puzzle can be solved in parallel. Note that the
above hash-based puzzle schemes would have very limited applications if they are used
directly to encapsulate a message: m0of arbitrary size. The reason is that, in these
schemes, the solution size: |r|plays a vital role in (adjusting) the time taken to solve
the puzzle. If the solution size becomes bigger, as a result of combining rwith m0, i.e.
rm0, then it would take longer to find the solution. This means the puzzles can be
used only in the cases where the time required to find a solution is long enough, and is a
function of |rm0|, which seriously restricts its application. Researchers also propose
non-parallelizable pricing puzzles based on number theoretic [49, 33, 28] whose main
application is to resist DoS attacks. These schemes have a more efficient verification
mechanism than the one proposed in [42]. But, they are only privately verifiable and
not designed to encapsulate an arbitrary message.
Verifiable Delay Function (VDF). Allows a prover to provide a publicly verifiable
proof stating it has performed a pre-determined number of sequential computations.
It has many applications, e.g. in decentralised systems to extract trustworthy public
randomness from a blockchain. VDF was first formalised by Boneh et al in [9] who
proposed several VDF constructions based on SNARKs along with either incremen-
tally verifiable computation or injective polynomials, or based on time-lock puzzles,
where the SNARKs based approaches require a trusted setup. Later on, [50] improved
the previous VDF’s from different perspectives and proposed a scheme based on RSA
time-lock encryption, in the random oracle model. To date, this protocol is the most ef-
ficient VDF. It also supports batch verification, such that given a single proof a verifier
can efficiently check the validity of multiple outputs of the verifiable delay function. As
discussed above, (most of) VDF schemes are built upon time-lock puzzles, however the
converse is not necessarily the case, as VDF’s are not designed to encapsulate an arbi-
trary private message, and they take a public message as input while time-lock puzzles
are designed to conceal a private input message.
A.2 Proof of Storage
Traditional Proof of Storage Proof of storage (PoS) is a cryptographic protocol that
allows a client to efficiently verify the integrity or availability of its data stored in a re-
mote server, not necessarily trusted [27]. PoS can be categorised into two broad classes:
Proofs of Retrievability (PoR) and Proofs of Data Possession (PDP). The main dif-
ference between the two categories is the level of security assurance provided. PoR
schemes guarantee that the server maintains knowledge of all of the client’s outsourced
data, while PDP protocols only ensure that the server is storing most of the client data.
From a technical point of view, the main difference in most prior PDP and PoR con-
structions is that PoR schemes store a redundant encoding of the client data on the server
by employing an error-correcting code, e.g. Reed-Solomon codes, while such encoding
is not used in PDP schemes. Hence, PoR schemes provide stronger security guaran-
tees compared to PDP at the cost of additional storage space and encoding/decoding,
(for more details see [32, 47,14]). Furthermore, each PoR and PDP scheme can be also
grouped into two categories; namely, publicly and privately verifiable. In a publicly ver-
ifiable scheme, everyone without knowing a secret can verify proof, whereas a verifier in
a privately verifiable scheme requires the knowledge of a secret. Moreover, in general,
in PoR and PDP schemes there are no assumptions on the behaviour of the adversary.
It is allowed to deviate from the protocol arbitrarily, i.e. an ‘’active” adversary.
The notion of PoR first was introduced and defined in [26], where the authors de-
signed a protocol that uses random sentinels, symmetric key encryption, error-correcting
code, and pseudorandom permutation. In this protocol, a client in the setup phase, ap-
plies error-correcting code to every file block and encrypts each encoded block. Then, it
computes a set of random sentinels and appends them to the encrypted file. It permutes
all values (i.e. sentinels and encrypted file blocks) and sends them to the cloud server.
To check if the server has retained the file, the client specifies random positions of some
sentinels in the encoded file and asks the server to return those sentinel values. Next,
the client checks if it gets the sentinels it asked for. In this scheme, the security holds,
as the server cannot feasibly distinguish between sentinels and the actual file blocks
and the sentinels have been distributed uniformly among the file blocks. But, as indi-
vidual sentinel is only one-time verifiable, there is an upper bound on the number of
verifications performed by the client, and when reached, the client has to re-encode the
file. To overcome the issues related to the bounded number of verifications, the authors
have also suggested that sentinels can be replaced with MAC on every file block or a
Merkle tree constructed on the file blocks. This protocol is computationally efficient
and its communication cost is linear with the number of challenges sent6. The sentinel
and MAC-based schemes above are privately verifiable while the one uses a Merkle
tree supports public verifiability. However, the publicly verifiable Merkle tree-based
approach has a communication cost logarithmic with the file size and the prover has to
send a set of file blocks to the verifier that yields a high communication cost.
Later on, [45] improves the previous sentinel-based scheme and definition, and pro-
poses two PoR protocols (with an unlimited number of verifications), one uses MAC
and the other one relies on BLS signatures. In particular, a client at setup phase, encodes
its file blocks using error-correcting code and then for each encoded file block it gener-
ates a tag that can be either a MAC or BLS signature of that block. In the verification
phase, it specifies a set of random indices corresponding to the file’s blocks; and accord-
ingly the server sends a proof to it. These two schemes have a low communication cost,
as due to the homomorphic property of the tags, the prover can aggregate proofs into a
single authenticator value and no file blocks are sent to the prover. Also, the protocol
based on MAC supports efficient private verification. But, the one that uses BLS signa-
tures supports public verifiability at the cost of public key operations and it is far less
efficient than the MAC-based one. Within the last decade, researchers have extended
PoR protocols from several perspectives, e.g. those that support: efficient update [47],
the delegation of file pre-processing [2], or the delegation of verification [3].
On the other hand, PDP was first introduced in [4]. PDP protocols focus only on
verifying the integrity of outsourced data. In this setting, clients can ensure that a certain
percentage of data blocks are available. The authors in [4] propose two schemes, for
public and private verification both of which use RSA-based homomorphic verifiable
tags generated for each file block and use the spot-checking techniques (similar to [45])
6It is not hard to make the communication cost of this scheme constant; for instance, by letting
the server order the challenged sentinels, concatenate them and send a hash of the concatenated
value to the client.
to check a random subset of a file’s blocks. In both schemes, the proof size is constant,
while the verification cost is high as it requires many exponentiations over an RSA
ring. Later on, an efficient and scalable PDP scheme that supports a limited number of
verifications is proposed in [6]. The scheme supports only privately verifiable PDP and
is based on a combination of pre-computation technique and symmetric key primitives.
Ever since, researcher proposed different variants of PDP, e.g. dynamic PDP [18], multi-
replica PDP[19], keyword-based PDP [44].
Thus, (a) in publicly verifiable PoS it is assumed the verifier is fully trusted with the
verification correctness, (b) these schemes either have a very high verification cost when
the proof size is constant (when signature-based tags are used) or have a communication
cost logarithmic with the entire file size if their verification is efficient (when a Merkle
tree is used), and (c) the privately verifiable proofs can have a constant proof size and
efficient verification algorithm, but the data owner has to perform the verification.
Outsourced PoR Recently, [3, 52] propose outsourced PoR protocols that allow clients
to outsource the verification to a third party auditor not necessarily trusted. The scheme
in [3] uses MAC-based tags, zero-knowledge proofs, and error-correcting codes. At a
high level, the protocol works as follows. At the setup, the client encodes its data using
error-correcting codes, generates MAC on every file block, and stores the encoded file
and tags on the server. Then, the auditor downloads the encoded file, generates another
set of MAC’s on the file blocks. It uploads the MAC’s to the cloud. Also, the auditor
proves to the client in zero-knowledge that it has created each MAC correctly. To do
that, it uses a non-interactive zero-knowledge proof in the random oracle model. If the
client accepts all zero-knowledge proofs, it sings every proof and sends the signatures
back to the auditor. In the verification phase, the auditor sends two sets of random chal-
lenges extracted from a blockchain. Upon receiving the challenges, the server provides
two separate proofs, one for the auditor and the other one for the client. The auditor ver-
ifies the proof generated for it and locally stores the clients’ proofs. In the case where
the auditor’s proof is not accepted, an honest auditor would inform the client who will
come online and checks both its proofs and the auditors’ proof. The scheme provides
two layers of verification to the client: CheckLog and ProveLog.CheckLog is more
efficient than the other one, as the auditor sends much fewer challenges to the server
to generate the client’s proof for each verification. In the case where the client’s check
fails, the client will assume that either the server or auditor has acted maliciously, and to
pinpoint the malicious party, it needs to proceed to ProveLog where allows the client to
audit the auditor. In this verification, the auditor must reveal its secret keys with which
the client checks all the proofs provided by the server to the auditor for the entire period
that the client was offline. In this protocol, the verification phase is efficient (due to
the use of MACs). In particular, the verification’s computation cost for the auditor and
client is linear with the number of challenges and their communication cost is constant
in the file size.
Although the protocol in [3] is appealing, it has several shortcomings: (a) auditor
can get a free ride: in the case where a known highly reputable server, e.g. Google or
Amazon, always generates accepting proofs for both client and auditor, an economi-
cally rational auditor can skip performing its part (e.g. to save computation cost) and
get still paid by the client. This deviation from the protocol can never be detected by the
client in the protocol. (b) no guarantee for a real-time detection/notification: the client
may not be notified in the real-time about the data unavailability if the auditor is ma-
licious; therefore, this scheme is not suitable for the case where a client’s involvement
for the data extraction is immediately needed once a misbehaviour is detected, e.g., in
the case of hardware depreciation. (c) a high cost of auditor onboarding: revoking an
auditor and onboarding a new one, imposes a high cost on the client and new auditor,
as new auditor need to re-run the setup phase (that includes data downloading, zero-
knowledge proofs) and the client needs to verify and sign the zero-knowledge proofs.
(d) ProveLog costs even an honest auditor: the only way for the client to ensure the
auditor has fully followed the protocol is to run ProveLog that requires the auditor to
reveal its secret values. After that, an honest auditor has to re-run the computationally
expensive setup again. Since the auditor is not trusted and no guarantee that it alerts the
client as soon as the server’s misbehaviour is detected, its involvement in the protocol
seems unnecessary; and the whole scheme can be replaced with a much simpler one:
the client, similar to a standard privately verifiable PoR, encodes its data and stores it in
the server. Then, for each verification time, the server gets the random challenges from
the blockchain and publishes proofs in bulletin board (to timestamp it). When the client
comes online, it checks the proofs and accordingly takes the required action, e.g. pays
the server, tries to recover the file.
Xu et al. in [52] propose a publicly verifiable PoR to improve the computation cost
at setup. The scheme uses BLS signatures-like tags, polynomial arithmetics, and poly-
nomial commitments; unlike previous schemes, each tag has a more complex structure.
In this protocol, an auditor is assumed to be fully trusted during the verifications. Later
on, however, when it is revoked by the client it may become malicious, i.e. may collude
with the server and reveal its secret. This scheme allows a client to update its tags when
a new auditor joins. To do that, the client needs to download all the blocks’ tags, refresh
them locally, and uploaded the fresh tags to the server. The verification for auditor and
client involves public key operations and is more expensive than the one in [3]. The use
of an auditor’s revocation remains unclear in the paper, as auditors are assumed to be
honest in this protocol. A delegatable PDP is proposed in [46] to ensure only autho-
rised parties can verify the integrity of remote data. However, the delegated party in this
scheme is fully trusted with the correctness of verification it performs. The scheme uses
authenticator tags similar to BLS signatures based ones.
Very recently, proof of “storage-time” has been proposed in [5]. The paper proposes
two protocols: basic PoSt and compact PoSt. At a high level, they offer the guarantee to
a client that its data has been available on a remote storage server for a fixed time period:
T. The idea is that a client uploads to a server its data once, then the server generates
proofs of storage (e.g. PoR) periodically, collects them and sends the collection after
the time Tto a verifier (i.e. client in basic PoSt or third-party in compact PoSt) who can
check the proof. The first protocol, basic PoSt, uses Merkle tree-based PoR and VDF. In
this protocol, The client precomputes a set of metadata (tags, challenges, and their re-
lated proofs). It sends the file, metadata, and a single challenge to the server. The server
uses the challenge to generate a PoR. It feeds the hash of the PoR to VDF to generate
an output. It considers the hash of VDF’s output as the next challenge from which the
next PoR is generated. This process goes on until all zPoR’s are generated. It sends all
PoR proofs along with the proofs proving the correctness of VDF’s outputs to a veri-
fier. Given the two sets of proofs, a verifier can check their correctness and ultimately
conclude that the file was retrievable within the time period. The scheme is publicly
verifiable. However, the verification’s computation cost is significant. As, it requires
the validator to validate the correctness of VDF’s outputs, that imposes a high cost. In
total (for zPoR proofs) it involves at least 3zmodular exponentiations even if it uses the
fastest VDF, proposed in [50]. Such costs are missed out and not taken into account in
the paper. Moreover, the use of the Merkle tree introduces a high communication cost,
as well. The authors suggest a smart contract can play the validator’s role. However,
we argue that this would impose a significant financial cost to the contract and users
due to very high computation and communication costs stem from the verification and
prove algorithms. The second protocol, compact PoSt, allows the server to combine
PoR proofs that ultimately reduces the communication cost. The protocol’s design is
very similar to the previous one, but it replaces the Merkle tree approach with simply
hashing the entire file and replaces the VDF with a trapdoor delay function (TDF) that
requires a secret to generate/verify the delay function’s output. Therefore, this protocol
is only privately verifiable. The paper claims that the verification in this protocol can be
performed by a trusted third-party, e.g. smart contract. Nevertheless, we argue that this
is not the case. As, the scheme requires a set of secrets (e.g. challenges) to perform the
verification, while a smart contract does not maintain a private state. If the challenges
are given to the contract, then the server can read the contract and compute all proofs
in one go (which violates the security requirement set out in the paper). Moreover, the
same security issue would arise in the case where the verification is delegated to a third-
party auditor who may collude with the server (as the auditor can send all challenges
to the server at once). Therefore, the only secure option, in the compact PoSt, is that
the verifier performs the validation itself (i.e. private verification/validation). Note that
all the above outsourced PoR schemes [3, 52, 5] assume the client behaves honestly to-
wards the server. Otherwise, a malicious client can generate the tags in a way that makes
an honest server generate invalid proofs.
Hence, the existing outsourced PoR protocols either suffer from several security
issues and guarantee no real-time detection or have to fully trust verifiers with the veri-
fication correctness, or are very inefficient.
Distributed PoR using a (Tailored) Blockchain Distributed PoR allows data to be
distributed to numerous storage servers to achieve robustness, and address a single point
of failure issue. Permacoin [39] is one of those that distribute data among customised
blockchain nodes and repurposes mining resources of Bitcoin blockchain miners. In
Permacoin, each miner needs to prove that it has a portion of the file and to do so it
provides proof of data retrievability verified by other miners. The miner, in this scheme
needs to invest on both computation resources and storage resources (to generate proof
of retrievability). The protocol uses a Merkle tree built on top of file blocks to support
publicly verifiable PoR. The mining procedure in this protocol is based on iterative
hashing. In Permacoin, in each verification, the prover has to send both challenged file
blocks and the proof path in the tree, that imposes communication cost logarithmic to
the size of the entire original file. In this scheme, an accepting proof only indicates a
portion of the data holding by that miner (prover) is retrievable. Thus, for a data owner
to have a guarantee that the entire data is retrievable, it has to either wait for a long
period of time (depending on the file size and the number of miners) or hope that there
are enough active miners in each epoch. Also, since the miners are both verifiers and
provers (storage providers), it is assumed that the storage providers are economically
rational (which is weaker than a malicious one).
Filecoin and KopperCoin in [34, 30] respectively, offer similar features, i.e. repur-
posing Bitcoin and supporting distributed PoR. However, Filecoin, in addition to a
Merkle tree, uses generic zero-knowledge proofs (i.e. zk-SNARKS) that result in a high
overall computation cost and requires a trusted party to generate the system parameters.
Filecoin uses proof of work as well as PoR. On the other hand, KopperCoin uses BLS
signature-based publicly verifiable PoR that has a constant communication cost but has
a high computation cost. Unlike Filecoin, KopperCoin does not use a PoW.
In the same line of research, [31] proposes a customised blockchain that supports
distributed PoR as well as preserving the privacy of on-chain payments between stor-
age users and providers. It however is computationally expensive as it uses publicly
verifiable tags based on BLS signatures for PoR and ring signatures for the privacy-
preserving payments. Likewise, [43] proposes a high-level distributed PoR framework
whose aim is efficient utilization of storage resources offered by storage providers. It
also uses BLS signatures and a Merkle tree along with a smart contract for payments.
Similarly, [54,53] propose schemes that allow a user to store its encrypted data in the
blockchain. The scheme uses a Merkle tree for PoR and a smart contract to transfer fees
to the blockchain nodes storing the data. In these two schemes, the data owner is the
party who sends random challenges to storage nodes, so it has to be online when verifi-
cation is needed. Storj [51] also falls in this category where there is a tailored blockchain
comprising a set of storage nodes that store a part of data and provide proofs when they
are challenged. In Storj, there are trusted nodes, Satellite, who do the verifications on
behalf of the clients. The scheme uses a Merkle tree-based PoR.
So, existing distributed PoR protocols have either a large proof size or high verifi-
cation cost. Also, they do not guarantee that the entire file is retrievable in real-time.
Verifying Remote (off-chain) data via a Blockchain To relax the assumption that
an auditor is fully trusted with the correctness of verification in the publicly verifiable
PoR schemes while storing data off-chain, e.g. in a cloud, researchers proposed nu-
merous protocols, e.g. [41, 25, 56, 20, 8, 48], that delegate the verification procedure to
blockchain nodes. The high-level framework proposed in [41] requires only a hash of
the entire file is stored in a smart contract, where when later on the user access the file, it
computes the hash of the file and compares it with the one stored in the contract. In this
scheme, the entire file has to be accessed by the user for each verification which is what
exactly PoR schemes avoid doing. The protocol in [25] uses BLS signature-based tags
and Merkle tree where the tags are broadcast to all blockchain nodes. However, sur-
prisingly, the protocol assumes the cloud server is fully trusted and stores data safely,
which raises the question that “why is a data verification needed in the first place?”. In
this protocol, the tags are generated by the cloud who sends them to the nodes. The tags
are never checked against the outsourced data. So, the only security guarantee [25] of-
fers is the immutability of tags. The high-level scheme proposed in [56] allows a client
to pay the storage server in a fair manner. The scheme uses a blockchain for payment
and Merkle tree for PoR. In this protocol, the client has to be online and send random
challenges to the server for every verification.
Audita [20] uses an augmented blockchain and RSA signature-based PDP [4] to
achieve its goal. In this scheme miners, for each epoch, pick a dealer who sends a
challenge to the storage node(s) to get proofs of data possession. Similar to Permacoin
[39], Audita substitutes proof of work with PDP, so if a proof is accepted a new block
is added to the chain. But, in Audita every miner carries out expensive public key based
verifications. The protocol proposed in [8], similar to [3], uses a third-party auditor. It
mainly uses, a smart contract and BLS signature-based tags. In this protocol, unlike [3],
when the auditor raises a dispute during the verification it calls a smart contract who
performs the verification again to detect a misbehaving party, i.e. the server or auditor.
The protocol is computationally more expensive than [3] and inherits the same issues,
i.e. issues (a-c) stated above. Sia [48] is a mechanism in which a data owner distributes
its data among off-chain storage servers who periodically provide a PoR to a smart
contract signed between the data owner and the servers. Each server gets paid if its
proof is accepted by the contract. In this scheme, a Merkle tree-based PoR is used.
As evident, the schemes designed for blockchain-based verification of data stored
in a storage server either require clients to access whole outsourced data for every veri-
fication, or impose a high communication/computation cost, or clients have to be online
for each verification.
Fair Exchange of Digital Services Campanelli et al. [12] propose a scheme that al-
lows different parties to exchange digital services (and goods) over Bitcoin blockchain.
This scheme, for instance in PoR context, allows the storage provider to get paid if and
only if the data owner receives an accepting proof. It has two variants, publicly and
privately verifiable both of which use a smart contract. In addition, in the privately ver-
ifiable variant, MAC-based tags and generic secure multi-party computation are used,
e.g. Yao’s garbled circuit [55], while in the publicly verifiable one BLS signature tags
and zk-SNARK are used. Nevertheless, this scheme assumes that either the client is
available and online when PoR is provided (in privately verifiable variant) or the third
party, acting on a client’s behalf, performs PoR verification honestly (in publicly verifi-
able one).
B Notations
We summarise our notations in Table 4.
C Discussion on Time-lock Puzzle
In general, time-lock puzzles by definition are sequential functions. In their construc-
tion, it is required a function inherently sequential, e.g. modular squaring, is called
iteratively for a certain number of times. The notions of sequential function and iterated
Table 4: Notation Table.
Setting Symbol Description
Generic
zNumber of puzzles or delegated verifications
h,hjHash values
d,djRandomness of commitment
nNumber of file blocks
m,mjPlaintext messages
¨oPair representation
#»
oVector representation
¨p: (mj, dj)Commitment opening
HHash function
C-TLP
λTLP security parameter
∆Time win. message remains hidden
SMax. squaring done per sec.
T T =S∆
sjj-th solution
¨ojj-th puzzle, ¨oj: (oj,1, oj,2)
fjTime when j-th solution is found
k, kjSym. key encryption keys
pk, sk Public and secret keys
q1, q2Large prime numbers
NRSA modulus, N=q1q2
Setting Symbol Description
SO-PoR
PRF Pseudorandom function
ˆ
k, vj, ljPRF’s keys
ιSecurity parameter, ι= 128-bit
pLarge prime number, |p|=ι
wBlockchain block index
gBlockchain security parameter: chain quality
λ0Blockchain generic security parameter
FOutsourced encoded file
FjA file block
|F|Number of file blocks, |F|=n
||F|| File bit-size
σiPermanent tag
σb,j Disposable tag
α, αj, ri, rb,j Pseudorandom values
cNumber of challenges
BjBlockchain’s j-th block
(µj, ξj)j-th PoR proof
∆1Time taken to generate a PoR
∆2Time taken a contract gets a message
eCoins paid for an accepting PoR
sequential functions, in the presence of an adversary possessing a polynomial number
of processors, have been generalised and defined in [9]. Below, for the sake of com-
pleteness, we provide those definitions.
Definition 8 (∆, δ(∆))-Sequential function). For a function: δ(∆), time parameter:
∆and security parameter: λ=O(log(|X|)),f:X→Yis a (∆, δ(∆))-sequential
function if the following conditions hold:
•There exists an algorithm that for all x∈Xevaluates fin parallel time ∆using
poly(log(∆), λ)processors.
•For all adversaries Athat run in parallel time strictly less than δ(∆)with poly(∆, λ)
processors:
P r hyA=f(x)
yA
$
← A(λ, x), x $
←Xi≤negl(λ)
where δ(∆) = (1 −)∆and < 1
Definition 9 (Iterated Sequential function). Let g:X→Xbe a (∆, δ (∆))-sequential
function. A function f:N×X→Xdefined as f(k, x) = g(k)(x) = g◦g◦... ◦g
| {z }
k×
is
an iterated sequential function, with round function g, if for all k= 2o(λ)the function
h:X→Xdefined by h(x) = f(k, x)is (k∆, δ (∆))-sequential.
The main property of an iterated sequential function is that iteration of the round
function g, is the fastest way to evaluate the function. Iterated squaring in a finite group
of unknown order, is widely believed to be a candidate for an iterated sequential func-
tion. Its definition is as follows.
Assumption 1 (Iterated Squaring) Let N be a strong RSA modulus, rbe a generator
of ZN,∆be a time parameter, and T=poly(∆, λ). For any A, defined above, there is
a negligible function µ(.)such that:
P r
A(N, r, y)→b
r$
←ZN, b $
← {0,1}
if b= 0, y $
←ZN
otherwise y=r2T
≤1
2+µ(λ)
Theorem 3 (RSA-based TLP Security). Let Nbe a strong RSA modulus and ∆be
the period within which the solution/secret remains hidden. If the sequential squaring
assumption holds, factoring Nis a hard problem and the symmetric key encryption is
semantically secure, then RSA-based TLP scheme (presented in Section 3.4) is a secure
time-lock puzzle.
Proof (sketch). Let a solver be A= (A1,A2), where A1runs in total time O(poly(∆, λ))
and A2runs in time δ(∆)< ∆ using at most π(∆)parallel processors. For the solver
to find the secret significantly earlier than δ(∆), given the public parameters, it needs to
either: (a) compute φ(N), so it can generate the blinding factor: bas fast as it is done in
the encryption phase, or (b) break the symmetric key encryption, or (c) extract kfrom
o2by finding the blinding factor without performing a sufficient number of squaring
(and without knowing φ(N)). However, finding φ(N)is as hard as factoring N, also as
long as the encryption is secure and kis sufficiently large it cannot break the symmetric
key encryption. Moreover, the blinding factor is a uniformly random element of the ring
(due to Assumption 1), so it prevents the solver from finding the blinding factor with-
out carrying out enough squaring within time significantly less than δ(∆). Thus, any
adversary Acannot find the secret without carrying out a sufficient number of squaring
that would take it δ(∆)2
Remark 1. In the original TLP protocol proposed [42], it is implicitly assumed that the
type of secret key kis converted in step 2b. Because, in step 1c its type is byte string,
while in step 2b its type is integer of ZN. Such point plays a role when the protocol is
implemented, in practice.
D Further Remarks on C-TLP Protocol
In this section, we provide some remarks on C-TLP scheme presented in Section 5.3.
Remark 2. Recall, to make each puzzle instance, a distinct random generator: rj, is
used. This is the reason, in the C-TLP protocol, before a puzzle is generated in step 2b,
a new public key is set in step 2a. Also, at the beginning of the protocol only r1is public
and the rest of the generators are kept secret. They are found and used sequentially after
their related puzzle is solved.
Remark 3. The commitments opening, including the commitment random values, are
not known to other verifiers (than the puzzle generator) at the beginning of the protocol.
At this point, only the committed values are public. Once a solver solves each puzzle,
it extracts one of the commitments’ opening and sends it to a public verifier who can
check if the opening matches the commitment.
Remark 4. In C-TLP, we use the folklore hash-based commitment scheme, in the ran-
dom oracle model, only to achieve more computation improvement than that can be
achieved in the standard model. But C-TLP can use any efficient non-interactive com-
mitment scheme in the standard model as well, e.g. Pedersen Commitment.
Remark 5. The efficiency of C-TLP scheme stems from three crucial factors: (a) re-
moving computation overlaps when solving different puzzles: even though solving j-th
puzzle, where j > 1, requires jT squaring, (j−1)Tof the squaring is used to solve
previous puzzles that leads to z+1
2times computation cost reduction at the server-side,
(b) supporting reusable single public parameter: a= 2T, generated only once that costs
O(1), as opposed to the RSA-based TLP whose cost is linear: O(z), and (c) support-
ing efficient verification: due to the way each message is encoded (i.e. embedding the
opening in a solution).
Remark 6. A future research direction would be extending SO-PoR and C-TLP schemes
to multiple users setting. Currently, both schemes are in the single user setting.
Remark 7. In the following, we outline an approach (based on the chaining technique)
that looks an option to construct an efficient C-TLP; however, as we will show it would
not be secure. In particular, one uses the TLP to generate zpublic and secret key pairs.
Then, it uses the TLP to compute z-th puzzle as TLP.GenPuz(mz, pkz, skz)→¨oz. Then,
it embeds ¨ozinto (z−1)-th one, i.e. TLP.GenPuz(mz−1||¨oz, pkz−1, skz−1)→¨oz−1.
This process goes on until ¨o1is created. It sends the combined puzzles and public key
(including all random generators) to the server; with the hope that puzzles can be solved
sequentially and the time gap between finding two solutions will be ∆. This approach
is not secure, because as soon as the server accesses ¨o1and public parameters, it can
in parallel perform Tsquaring on every generator, i.e. r2T
i, for all i, 1≤i≤z. In
this case, as soon as ¨o1is solved and ¨o2is extracted, it has enough information to
immediately solve ¨o2and accordingly the rest of the puzzles without doing any further
exponentiation. Moreover, as stated in Section A.1, the scheme in [16] that uses the
chaining technique to construct a secure chained puzzle, has a set of drawbacks, e.g. it
lacks a verification mechanism, uses the original time-lock puzzle in a non-black-box
fashion, and uses a non-standard asymmetric encryption.
E C-TLP Security Proof
In this section, we present the security proof of C-TLP scheme. We first prove that
without solving j-th puzzle, a solver cannot find the parameters needed to solve the
next puzzle, i.e. (j+ 1)-th one.
Lemma 1 (Next Group Generator Privacy). Let kbe a random key for a symmetric
key encryption, and Nbe a sufficiently large RSA modulus. Let the security parameter
be λ=|N|=|k|. In C-TLP, given puzzle vector: #»
oand public key: pk, an adversary
A= (A1,A2), defined in Section 4.3, cannot find the next group generator: rj+1 , where
rj+1
$
←Z∗
Nand j≥1, significantly smaller than Tj=δ(j∆), except with a negligible
probability in the security parameter, µ(λ)
Proof. Since the next generator: rj+1 , is: (a) encrypted along with the j-th puzzle so-
lution: sj, and (b) picked uniformly at random from Z∗
N, for the adversary to find rj+1
without performing enough squaring, i.e. Tj, it has to either (a) break the symmetric
key scheme, decrypt the related ciphertext: siand extract the random value from it, or
(b) correctly guess rj+1. In both cases, the probability of success is negligible in secure
parameter µ(λ), i.e. 2−|k|in the former case and 2−|N|in the latter one. 2
In the following, we prove that the privacy of a solution in C-TLP scheme is pre-
served according to Definition 5.
Theorem 4 (C-TLP Solution Privacy). Let Nbe a strong RSA modulus and ∆be
a time parameter. If the sequential squaring assumption holds, factoring Nis a hard
problem, H(.)is a random oracle and the symmetric key encryption is semantically
secure, then C-TLP encoding zsolutions is a privacy-preserving multi-instance time-
lock puzzle w.r.t. Definition 5.
Proof. In the following, we argue for an adversary A= (A1,A2), where A1runs in
total time O(poly(j ∆, λ)),A2runs in time δ(j∆)< j ∆ using at most π(∆)parallel
processors, and j∈[1, z], (a) when z= 1: to find s1earlier than δ(∆), it has to break
the TLP scheme, and (b) when z > 1: to find sjearlier than Tj=δ(j∆), it has to either
find at least one of the previous solutions earlier than it is supposed to (that ultimately
requires breaking TLP scheme again), or find j-th generator: rj, earlier. Also, we argue
that the commitments: hj, are computationally hiding. Specifically, when z= 1, the
security of C-TLP is reduced to the security of the TLP and the scheme is secure as
long as TLP is, as the two schemes would be identical. On the other hand, when z > 1,
the adversary has to either find sjearlier than Tjas soon as the previous solution: sj−1
is found that requires either breaking the TLP scheme, or finding any generator rjbe-
fore sj−1is extracted, when j∈[2, z]. Nevertheless, the TLP scheme is secure (under
RSA, sequential squaring, and security of symmetric key encryption assumptions) ac-
cording to Theorem 3, and also the probability of finding the next generator: rjearlier
than Tj−1is negligible, according to Lemma 1. Moreover, for an adversary to find a
solution earlier, it may also try to find a (partial information of) pre-image of the com-
mitment: hjbefore fully (or without) solving the puzzle. But, this is infeasible for a PPT
adversary, given output of a random oracle: H(.). Thus, C-TLP is a privacy-preserving
multi-instance time-lock puzzle scheme. 2
Next, we prove that the validity of a solution in C-TLP scheme is preserved accord-
ing to Definition 6.
Theorem 5 (C-TLP Solution Validity). Let H(.)be a hash function modeled as a ran-
dom oracle. Then, C-TLP preserves a solution validity w.r.t. Definition 6.
Proof. The proof boils down to the security (i.e. binding property) of the traditional
hash-based commitment scheme. In particular, given an opening pair, ¨p: (mj, dj)and
the commitment hj=H(mj, dj), for an adversary to break the solution validity, it has
to come up (m0
j, d0
j), such that H(m0
j, d0
j) = hj, where mj6=m0
j, i.e. finds a collision
of H(.). However, this is infeasible for a PPT adversary, as H(.)is collision resistance,
in the random oracle model. 2
In the following, we restate the main theorem presented in Section 4.4 and then
prove it.
Theorem 1 (C-TLP Security). C-TLP is a secure multi-instance time-lock puzzle.
Proof. According to Theorems 4 and 5, the privacy and validity of a solution in C-TLP
are preserved, respectively. So, w.r.t. Definition 7, C-TLP is a secure multi-instance
time-lock puzzle. 2
F Asymptotic Cost Analysis of C-TLP
In this section, we analyse the communication and computation complexity of C-TLP.
We consider a generic setting where the protocol deals with zpuzzles.
Computation Complexity. For a client to generate zpuzzles, in total: in step 1a, it per-
forms one exponentiation over modφ(N). In step 2b, it ztimes calls TLP.GenPuz(.).
This in total involves zsymmetric key-based encryption, zmodular exponentiations
over ZNand zmodular additions. Also, in step 2c it performs zinvocations of a com-
mitment scheme (to commit), i.e. if a hash-based commitment is used then it would
involve zinvocations of a hash function, and if Pedersen commitment is used then it
would involve 2zexponentiations and zmultiplications, where all operations, in the
latter commitment, are done over a mod qfor a large prime number: q, e.g. |q|= 1024-
bit. Thus, the overall computation complexity of the client is O(z). For the server to
solve zpuzzles, it ztimes calls TLP.SolvPuz(.). This in total involves T z modular
squaring over ZN,zmodular additions over ZN, and zsymmetric key based decryption.
The server’s cost of proving, in step 4, is very low, as it involves only parsing zstrings.
Therefore, the server total computation complexity is O(T z). The verification cost, in
step 5, only involves zinvocation of commitment scheme (to verify each opening) and
it is independent of the RSA security parameters. If the hash-based commitment is used,
then it would involve zinvocations of a hash function, if Pedersen commitment is used,
then in total it would involve 2zexponentiations and zmultiplications performed over
modq. Thus, the verification’s complexity is O(z).
Communication Complexity. In step 2, the client publishes two vectors: #»
oand
#»
h, with
2zand zelements respectively. Each element of #»
ois a pair (oj,1, oj,2), where oj,1is an
output of symmetric key encryption, e.g. |oj,1|= 128-bit, and oj,2is an element of ZN,
e.g. |oj,2|= 2048-bit. Also, each element hjof
#»
his either an output of a hash function,
when a hash-based commitment is used, e.g. |hj|= 256-bit, or an element of Fqwhen
Pedersen commitment is used, e.g. |hj|= 1024-bit. Therefore, its total bandwidth is
about 2432zbits when the former, or 3200zbits when the latter commitment scheme
is used. Also, its complexity is O(z). Note, in C-TLP, when a server finds a solution,
it does not broadcast anything, instead it moves on to the next step: Prove(.). For the
server to prove, in step 4, in total, it sends zpairs (mj, dj)to the verifier, where mjis
an arbitrary message, e.g. |mj|= 500-bit, and djis either a long enough random value,
e.g. |dj|= 128-bit, when the hash-based commitment is used, or an element of Fqwhen
Pedersen scheme is used, e.g. |dj|= 1024-bit. Therefore, its bandwidth is about either
628zor 1524zbits when the former or latter commitment scheme is used respectively.
The solver’s communication complexity is O(z).
G Traditional PoR Model
In this section, we restate a definition of the traditional PoR scheme [45]. In general,
a PoR scheme considers the case where an honest client wants to store its file(s) on a
potentially malicious server, i.e active adversary. It is a challenge-response interactive
protocol where the server proves to the client that its file is intact and retrievable. A PoR
scheme comprises five algorithms:
•Setup(1λ)→sk: a probabilistic algorithm, run by a client, that takes as input a
security: 1λand outputs a secret key.
•Store(sk, F )→(F∗, σ ): a probabilistic algorithm, run by a client, that takes as
input the secret key: sk and a file: F. It encodes F, denoted by F∗as well as
generating a set of tags: σ, where F∗and σis stored on the server.
•GenChal(|F∗|,1λ)→#»
c: a probabilistic algorithm, run by a client, that takes as
input the encoded file size: |F∗|and security: 1λ. It outputs a set of pairs, ¨cj:
(xj, yj), where each pair includes a file block index: xjand coefficient: yj, both of
them are picked uniformly at random.
•Prove(F∗, σ, #»
c)→π: takes the encoded file: F∗, (a subset of) tags: σ, and a
vector of unpredictable random challenges: #»
cas inputs and outputs a proof of the
file retrievability. It is run by a server.
•Verify(sk, #»
c, π)→ {0,1}: takes the secret key: sk, vector of random challenges:
#»
c, and the proof πas inputs. It outputs either 0if it rejects, or 1if it accepts the
proof. It is run by a client.
Informally, a PoR scheme has two main properties: correctness and soundness. The
correctness requires that for any key, all files, the verification algorithm accepts a proof
generated by an honest verifier. The soundness requires that if a prover convinces the
verifier (with a high probability) then the file is stored by the prover; This is formalized
via the notion of an extractor algorithm, that is able to extract the file in interaction with
the adversary using a polynomial number of rounds. In contrast to the definition in [45]
where GenChal(.)is implicit, in the above we have explicitly defined it, as its modified
version plays an integral role in SO-PoR definition (and protocol).
H SO-PoR Model
In this section, we provide a formal definition of SO-PoR. As previously stated, it builds
upon the traditional PoR model [45], presented in Appendix G. In SO-PoR, unlike the
traditional PoR, a client may not be available every time verification is needed. There-
fore, it wants to delegate a set of verifications that it cannot carry out itself. In this
setting, it (in addition to file retrievability) must have three guarantees: (a) verification
correctness: every verification is performed honestly, so the client can rely on the veri-
fication result without the need to re-do it, (b) real-time detection: the client is notified
in almost real-time when server’s proof is rejected, and (c) fair payment: in every verifi-
cation, the server is paid only if the server’s proof is accepted. In SO-PoR, three parties
are involved: an honest client, potentially malicious server and a standard smart con-
tract. SO-PoR also allows a client to perform the verification itself, analogous to the
traditional PoR, when it is available.
Definition 10. A Smart Outsourced PoR (SO-PoR) scheme consists of seven algorithms
(Setup,Store,SolvPuz,GenChall,Prove,Verify,Pay) defined below:
•Setup(1λ, ∆, z)→(ˆ
sk, ˆ
pk): a probabilistic algorithm, run by a client. It takes as
input a security: 1λ, time parameter: ∆, and the number of verification delegated:
z. It outputs a set of secret and public keys.
•Store(ˆ
sk, ˆ
pk, F, z )→(F, σ, #»
o, aux): a probabilistic algorithm, run only once
by a client. It takes as input the secret key: ˆ
sk, public key: ˆ
pk, a file: F, and the
number of verifications: zthat the client wants to delegate. It outputs an encoded
file: F, a set of tags: σ, a set of zpuzzles: #»
o, and public auxiliary data: aux. First
three outputs are stored on the server and last output: aux, is stored on a smart
contract.
•SolvPuz(ˆ
pk, #»
o)→#»
s: a deterministic algorithm that takes as input the public key:
ˆ
pk and puzzle vector: #»
o. It for each j-th verification outputs a pair: ¨sj: (vj, lj)
of solutions, where vjand ljare outputted at time tjand t0
jrespectively and t0
j>
tj. Therefore, the algorithm in total outputs zpairs. Value ljis sent to the smart
contract right after it is discovered. This algorithm is run by the server.
•GenChall(j, |F|,1λ,¨sj, aux)→#»
c: a probabilistic algorithm that takes as input
a verification index: j, the encoded file size: |F|, security parameter: 1λ, first com-
ponent of the related solution pair, vj∈¨sj, and public parameters: pp ∈aux
containing a blockchain and its parameters. It outputs pairs ¨cj: (xj, yj), where
each pair includes a pseudorandom block’s index: xjand random coefficient: yj.
Also, values xjare derived from vjwhile yjare derived from pp. This algorithm is
run by the server for each verification.
•Prove(j, F, σ, #»
c)→π: a probabilistic algorithm that takes the verification index
j, encoded file: F, (a subset of) tags: σ, and a vector of unpredictable challenges:
#»
c, as inputs and outputs a proof of file retrievability. It is run by the server for each
verification.
•Verify(j, π, ¨sj, aux)→d:{0,1}: a deterministic algorithm that takes the veri-
fication index j, proof: π, second component of the related solution pair: lj∈¨sj,
and public auxiliary data: aux. If the proof is accepted, it outputs d= 1; other-
wise, outputs d= 0. The default value of dis 0. This algorithm is run by the smart
contract for each verification and invoked only once for each verification by only
the server.
•Pay(j, d)→d0={0,1}: a deterministic algorithm that takes the verification
index j, the verification output: d. If d= 1, it transfers eamounts to the server and
outputs 1. Otherwise, it does not transfer anything, and outputs 0. The default value
of d0is 0. The algorithm is run by the contract, and invoked only by Verify(.).
A SO-PoR scheme must satisfy two main properties: correctness and soundness.
The correctness requires, for any: file, public-private key pairs, and puzzle solutions,
both the verification and pay algorithms, i.e. Verify(.)and Pay(.), output 1when
interacting with the prover, verifier, and client all of which are honest. The soundness
however is split into four properties: extractability, verification correctness, real-time
detection, and fair payment, formally defined below. Before we define the first property,
extractability, we provide the following experiment between an environment: Eand
adversary: Awho corrupts C({S,M1, ..., Mβ}, where βis the maximum number
of miners which can be corrupted in a secure blockchain. In this game, Aplays the role
of corrupt parties and Esimulating an honest party’s role.
1. Eexecutes Setup(.)algorithm and provides public key: ˆ
pk, to A.
2. Acan pick arbitrary file F0, and uses it to make queries to Eto run: Store(ˆ
sk, ˆ
pk,
F0, z)→(F0∗, σ, #»
o, aux)and return the output to A. Also, upon receiving the out-
put of Store(),Acan locally run algorithms: SolvPuz(ˆ
pk, #»
o)and GenChall(j,
|F0∗|,1λ,¨sj, aux)→#»
cas well as Prove(j, F ∗, σ, #»
c)→π, to get their outputs as
well.
3. Acan request Ethe execution of Verify(j, π, ¨sj, aux)for any F0used to query
Store(). Accordingly, Einforms Aabout the verification output. The adversary
can send a polynomial number of queries to E. Finally, Aoutputs the description
of a prover: A0for any file it has already chosen above.
It is said a cheating prover: A0is -admissible if it convincingly answers fraction
of verification challenges [45]. Informally, a SO-PoR scheme supports extractability, if
there is an extractor algorithm: Ext(ˆ
sk, ˆ
pk, P0), that takes the secret-public keys and the
description of the machine implementing the prover’s role: A0and outputs the file: F0.
The extractor can reset the adversary to the beginning of the challenge phase and repeat
this step polynomially many times for of extraction, i.e. the extractor can rewind it.
Definition 11 (-extractable). A SO-PoR scheme is -extractable if for every adver-
sary: Awho corrupts C({S,M1, ..., Mβ}, plays the experiment above, and out-
puts an -admissible cheating prover: A0for a file F0, there exists an extraction algo-
rithm that recovers F0from A0, given honest parties public-private keys and A0, i.e.
Ext(ˆ
sk, ˆ
pk, A0)→F0, except with a negligible probability.
In the above game, the environment, acting on honest parties’ behalf, performs the
verification correctly; which is not always the case in SO-PoR. As the verification can
be run by miners a subset of which are potentially corrupted. Even in this case, the veri-
fication correctness must hold, e.g. if a corrupt server sends an invalid proof then even if
β−1miners are corrupt (and colluding with it) the verification function will not output
1and if the server is honest and submits a valid proof then the verification function does
not output 0even if βminers are corrupt, except with a negligible probability. This is
formalised below.
Definition 12 (Verification Correctness). Let βbe the maximum number of miners
that can be corrupted in a secure blockchain network and λ0be the blockchain security
parameter. Also, let Abe the adversary who (plays the above game and) corrupts par-
ties in either C⊆ {S,M1, ..., Mβ−1}or C0⊆ {M1, ..., Mβ}. In SO-PoR, we say the
correctness of j-th verification is guaranteed if:
in the former case :P r[VerifyC(j, π , ¨sj, aux) = 1] ≤µ(λ0)
in the latter case :P r[VerifyC0(j, π , ¨sj, aux) = 0] ≤µ(λ0)
where µ(.)is a negligible function.
Also, a client needs to have a guarantee that for each verification it can get a correct
result within a (fixed) time period.
Definition 13 (Υ-real-time Detection). Let A, as defined above, be the adversary who
corrupts either Cor C0. A client, for each j-th delegated verification, will get a correct
output of Verify(.), by means of reading a blockchain, within time window Υ, after the
time when the server is supposed to send its proof to the blockchain network. Formally,
Read(Υ, VerifyD(j, π, ¨sj, aux)) → {0,1}
where D({C, C0}, except with a negligible probability.
Definition 14 (Fair Payment). SO-PoR supports a fair payment if the client and server
fairness are satisfied:
•Client Fairness: An honest client is guaranteed that it only pays (ecoins) if the
server provides an accepting proof, except with a negligible probability.
•Server Fairness: An honest server is guaranteed that the client gets a correct proof
if the client pays (ecoins), except with a negligible probability.
Formally, let Abe the adversary who corrupts either Cor C0, as defined above. To
satisfy a fair payment:
P r[PayD(.) = b∩VerifyD(.) = b]≥1−µ(λ0),(2)
the following inequality must hold:
P r[PayD(.) = b0∩VerifyD(.) = b]≤µ(λ0),(3)
where D({C, C0}, b 6=b0, and b, b0({0,1}
The above definition also takes into account the fact that the client at the time of
delegated verification is not necessarily available to make the payment itself, so the
payment is delegated to a third party, e.g. a smart contract. In this case, the definition
ensures that even if the client or/and server are honest, the third party cannot affect the
fairness (except with a negligible probability).
Definition 15 (SO-PoR Security). A SO-PoR scheme is secure if it is -extractable, and
satisfies verification correctness, Υ-real-time detection, and fair payment properties.
Remark 8. The folklore assumption is that (in a secure blockchain) a smart contract
function always outputs a correct result. However, this is not the case and it may fail
under certain circumstances. For instance, as shown in [35] all rational miners may not
verify a certain transaction. As another example, an adversary (although with a negli-
gibly small probability) discards a certain honestly generated blocks, reverses the state
of blockchain and contract, or breaks a client’s signature scheme. Accordingly, in our
definitions above, we take such cases into consideration and allow the possibility that a
function outputs an incorrect result even though with a negligibly small probability.
Remark 9. SO-PoR model differs from traditional (e.g. [26, 45]) and outsourced PoR
(e.g. [3, 52]) models in several aspects. Only the SO-PoR model offers all the proper-
ties. In particular, traditional PoRs only offer extractability while outsourced ones offer
liability as well, that allows a client (by re-running all verifications function) to detect
a verifier if it provides an incorrect verification output, so the client cannot rely on the
verification result provided. As another difference, the SO-PoR model takes into ac-
count the case where an adversary can corrupt both the server and some miners at the
same time.
Remark 10. SO-PoR should also support the traditional PoR where only client and
server interact with each other (e.g. client generates challenges, and verifies proof) when
the client is available. To let SO-PoR definition support that too, we can simply define a
flag: ξ, in each function, such that when ξ= 1, it acts as the traditional PoR; otherwise
(when ξ= 0), it performs as a delegated one. For the sake of simplicity, we let the flag
be implicit in the definitions above, where the default is ξ= 1
I SO-PoR Security Proof
In this section, we first restate the main security theorem of SO-PoR protocol (presented
in Section 5.3) and then prove it.
Theorem 2. SO-PoR protocol is secure (according to Definition 15) if the tags/MAC’s
are unforgeable, PRF(.)is a secure pseudorandom function, the blockchain is secure,
C-TLP protocol is secure, and H(Bγ||...||Bζ)outputs an unpredictable random value
(where ζ−γis a security parameter).
Proof (sketch). In the following, we prove that SO-PoR protocol satisfies every property
that were defined in Appendix H.
Verification correctness (according to Definition 12). We first argue that the adversary
who corrupts either C⊆ {M1, ..., Mβ}or C0⊆ {S,M1, ..., Mβ−1}with a high
probability, cannot influence the output of Verify(.)performed by a smart contract in
a blockchain; in other words, the verification correctness holds. In short, the verification
correctness boils down to the security of the underlying blockchain. In the case where
the adversary corrupts C(when the server provides an accepting proof), for the adver-
sary to make the verification function output 0, it has to: (a) either forge the server’s
signature, or (b) fork the blockchain so the chain comprising the accepting proof is dis-
carded. In case (a), if it manages to forge the signature, it can generate a transaction that
includes a rejecting proof where the transaction is signed on the server’s behalf. In this
case, it can broadcast the transaction as soon as the transaction containing an accepting
proof is broadcast, to make the latter transaction stale. Nevertheless, the probability of
such an event is negligible, (λ0), as long as the signature is secure. Moreover, due to
the liveness property of blockchain, an honestly generated transaction will eventually
appear on an honest miner’s chain [22]. In case (b), the adversary has to generate long
enough (valid) chain that excludes the accepting proof, but this also has a negligible
success probability, (λ0), under the assumption that the hash power of the adversary
is lower than those of honest miners (i.e. under the honest majority assumption) and
due to the liveness property. Now we turn our attention to the case where the adversary
corrupts C0(when the server provides a rejecting proof). In this case, for the adversary
to make the verification function to output 1, the honest miners must not validate the
transaction that contains the proof. Nevertheless, as long as the blockchain is secure
and the computational advantage of skipping transaction validation is low, i.e. the val-
idation imposes a low computation cost, the miners check the transaction’s validation
[35]. Also, as shown in [35] when a transaction validation imposes a high computation
cost, two generic techniques can be used to support exact or probabilistic correctness
(of a smart contract function output). We conclude the correctness of Verify(.)output
is guaranteed with a high probability.
-extractable (according to Definition 11). In the following, we show that if a proof
produced by an adversary: Awho corrupts C0⊆ {S,M1, ..., Mβ−1}is accepted by
Verify(.)with probability at least , then the file can be extracted by a means of an
extraction algorithm. As mentioned before, Verify(.)can use both disposable and per-
manent tags, in the latter case Verify(.)is run by a smart contract, while in the former
one the client runs it. For the sake of simplicity, we first consider the case where C0=S.
In this case, the extractability proof is similar to the one in [45], with a few differences,
in SO-PoR: (a) the extractor can use both disposable tags and permanent tags (when the
former run out), (b) assumes C-TLP protocol is secure, (c) assumes H(Bγ||...||Bζ)out-
puts a random value even if βminers try to influence its output. Note that in [45] only
the permanent tags are used, and since the client generates the challenges and performs
the verification, it does not use other primitives; hence, it does not require other security
assumptions. As proven in Theorems 4 and 5, C-TLP protocol is secure. Moreover, as
analysed and proven in [1, 3], an output of H(Bγ||...||Bζ)is random value even if some
blocks are generated or selectively disseminated by malicious miners. We conclude that
the extractor can extract the file when C0=S, and the extractor is interacting a -
admissible prover. Now we move on to the case where C0⊆ {S,M1, ..., Mβ−1}. In
this case, the proof (provided by S) is rejecting but the corrupt miners may try to make
Verify(.)output 1. Note, if they succeed to do so, then the file can be extracted only
by using the permanent tags but not the disposable ones. However, as shown above (i.e.
due to the verification correctness), they have a negligible probability of success, when
the blockchain is secure.
Υ-real-time Detection (according to Definition 13). In the following, we argue that after
the server broadcasts a proof at a certain time, say t, to the network, the client can get
a correct output of Verify(.)at most after time period Υ, by a means of reading the
blockchain. The proof is split into two parts: (a) correctness of Verify(.)output, and
(b) the maximum delay on the client’s view of the output. Since we have already shown
above that (when Cor C0is corrupt) the correctness of Verify(.)output is guaranteed,
we focus on the latter property, i.e. the delay. To describe the delay, we need to recall
two blockchain notions: liveness and slackness [22, 7]. Informally, liveness states that
an honestly generated transaction will eventually be included more than kblocks deep
in an honest party’s blockchain [22]. It is parameterised by wait time: uand depth: k. We
can fix the parameters as follows. We set kas the minimum depth of a block considered
as the blockchain’s state (i.e. a part of the blockchain that remains unchanged with a
high probability, e.g. k≥6) and uthe waiting time that the transaction gets kblocks
deep. As shown in [7], there is a slackness on honest parties’ view of the blockchain. In
particular, there is no guarantee that at any given time, all honest miners have the same
view of the blockchain, or even the state. But, there is an upper-bound on the slackness,
denoted by WindowSize, after which all honest parties would have the same view on a
certain part of the blockchain state. This means when an honest party (e.g. the server)
propagates its transaction (containing the proof) all honest parties will see it on their
chain after at most: Υ=WindowSize +utime period. So when the adversary corrupts
Cor C0, but in the latter case the server constructs a valid transaction (regardless of
the proof status) the client by reading the blockchain (i.e. probing the miners) can get
a correct result after at most time period Υwhen the server sends the proof. Also,
when parties in C0are corrupt and the transaction (containing the proof) is not valid, as
discussed above (for verification correctness) the honest miners would detect the invalid
transaction and do not include in the chain, therefore the output of Verify(.)would be
the same as its default value: 0; the same holds when the server sends nothing to the
network. This concludes the proof related to Υ-real-time detection in SO-PoR protocol.
Fair Payment (according to Definition 14). The proof takes into consideration that the
correctness of an output of Verify(.)is guaranteed (as shown above). It boils down to
the correctness of Pay(.)as it is interrelated to the output of Verify(.). In particular,
for the adversary to make inequality 3 not hold, it has to break Pay(.)correctness, e.g.
pays the server despite the verification function outputs 0. Therefore, it would suffice
to show the adversary who corrupts Cor C0cannot affect Pay(.)output’s correctness.
To do so, we can apply the same argument used to prove the correctness of Verify(.)
above, as the correctness of Pay(.)relies on the security of the blockchain as well. 2
J Further Remarks on SO-PoR Protocol
Remark 11. In SO-PoR, for a security reason the server must record j-th PoR proof
in the contract before ljis recovered. Also, the way disposable tags are generated in
SO-PoR differs from those computed in previous PoR schemes, despite having similar-
ities structure-wise. Moreover, with slight adjustments, we can reduce the contract-side
storage cost to constant. For more details, we refer readers to Appendix J which also
explains why strawman approaches are not suitable substitutes for SO-PoR.
Remark 12. In each verification, e.g. j-th one, it is required that the server can: (a) learn
the random challenges, (b) compute a proof, and (c) record it in the smart contract, be-
fore it is able to learn key lj; otherwise, (i.e. if it learns ljbefore sending and registering
the proof), it can tamper with the data and pass the verification. Because by knowing
ljit can construct valid tags for the data that has been tampered with. That is why, in
the protocol, it is required: t0
j≥tj+∆1+∆2. Also, C-TLP parameters (i.e. maximum
power of the adversary and delay parameters) are public, so are time points/window
at which PoR proofs should be provided in SO-PoR. Therefore, in SO-PoR the client
can always set TLP parameters such that a puzzle is solved at a certain time point or
within an appropriately sized window, so the server can provide each PoR proof to the
contract who verifies it within a certain time. Moreover, since the parameters are public,
the server can check them, before it agrees to serve the client.
Remark 13. The way disposable tags are generated in SO-PoR differs from those com-
puted in traditional/outsourced PoR schemes, in spite of having similarities structure-
wise. Specifically, (unlike existing protocols, e.g. [45, 3]) in SO-PoR, each random
value, rb,j, used to generate a disposable tag of a block (for j-th verification), is not
derived from the block index. Instead, it depends on (a fresh secret key for j-th verifi-
cation and) the total number of blocks challenged in each verification that is a public
value. This means, the verifier does not need to know and verify each challenged block’s
index in the verification phase, which leads to a lower cost.
Remark 14. With minor adjustments, we can reduce the smart contract storage cost
from O(z)to constant, O(1) and offload the cost to the server. The idea is that the
client after computing the commitmnet vector:
#»
h= [h1, ...hz], in step 2d, it preserves
the ordering of the elements (i.e. hjis associated with j-th verification) and constructs a
Merkle tree on top of them. It stores the tree and the vector on the server, and stores only
the tree’s root: R, on the contract. In this case, the server in step 3e after recovering ¨pj=
(lj, dj), computes: hj=H(lj||dj), and sends a Merkle tree proof (that hjcorresponds
to R) along with ¨pjto the contract. In step 4b, the contract: (a) checks if hj=H(lj||dj),
and (b) verifies the Merkle tree proof. The rest remains unchanged. As a result, the
number of values stored in the contract is now O(1). This adjustment comes with an
added communication cost: O(|hj|log z)for each verification. Nevertheless, the added
cost is small and independent of the file size. For instance, when z= 106and |hj|=
256, the added communication cost is only about 5.1kilobit.
Remark 15. One might be willing to use a combination of existing publicly verifiable
PoR and smart contract, such that the contract performs the verification on the client’s
behalf. However, this approach would have a higher computation or communication
cost (especially in the verification phase) than our protocol. Specifically, there exist two
publicly verifiable PoR schemes, based on either (a) BLS signatures, e.g. [45], or (b)
Merkle tree, e.g. [39]. The former approach, in total, requires zc exponentiations in the
verification phase, whereas SO-PoR requires no exponentiations in this phase. Also,
the BLS signature-based scheme takes a very long time to encode a file, as the required
number of exponentiations is O(|F|). For instance, as measured in [3], it takes about 55
minutes to encode a 64-MB file, meaning it would take about 14 hours to encode a 1-GB
file. But, in SO-PoR the number of exponentiations, in the store phase, is independent
of and much fewer than the file size. On the other hand, the proof size in the Merkle
tree-based approach is logarithmic with the file size, i.e. 256zc log |F|bits, that leads
to a high server-side’s communication cost. By contrast, the proof size in SO-PoR is
independent of the file size and is much shorter, i.e. 884zbits.
K SO-PoR’s Full Evaluation
In the following, we provide a full analysis of SO-PoR and compare its properties and
detailed costs to those protocols that support outsourced PoR (O-PoR), i.e. [3, 52, 5].
Note, there are two protocols proposed in [5]; in the following, we only consider the
one that supports public verifiability, i.e. basic PoSt. Recall, we consider a generic case
where a client outsources zverifications and in our cost analysis, we also compare
SO-PoR cost with the cost of the most efficient privately verifiable PoR [45], too.
Properties. We start with a crucial feature that any O-PoR must have: real-time detec-
tion. Recall, real-time detection requires a client to receive a correct verification result
in (almost) real-time without the need for it to re-execute the verification itself. This
is offered only by SO-PoR. By contrast, in [3] the auditor may never notify the client,
even if it does, its notification would not be reliable, and the client has to redo the
verification to verify the auditor’s claim. Similarly, in [52] the client has to fully trust
the auditor to get notified on-time. The basic PoSt in [5] requires the server to collect
all PoR’s and send them to a validator in one go. This means, the client and validator
cannot detect data tampering in real-time if a subset of the PoR’s are invalid; instead
they need to wait until zPoR’s are collected by the server. So, [3, 52, 5] are not suitable
for the cases where a client must be notified by a potentially malicious auditor as soon
as an unauthorised modification on the sensitive data is detected. The fair payment is
another vital property in O-PoR, as the cloud server and auditor must be paid fairly,
in the real world when they serve a client. This feature is explicitly captured by only
SO-PoR. The protocols in [3, 52] do not have any mechanism in place. In [3], one may
allow the auditor to pay the server on the client’s behalf. But, this is problematic. The
server and auditor can collude to save costs, in a way that the server generates accepting
proofs for the client but generates no proof for the auditor, and still the auditor pays it.
This violates the fair payment and cannot be detected by the client unless it performs
all the verification itself. On the other hand, a client in [52] has to fully trust the auditor
(with the payment too), otherwise the auditor can collude with the server to violate the
fair payment. The authors of [5] briefly state that the basic PoSt’s verification can be
performed by a smart contract who, after ensuring the proofs are valid, pays the server.
Nevertheless, as stated previously, the verification cost of this protocol is too high for
a smart contract, i.e. imposes at least zmodular exponentiations over RSA modulus
and requires a high number of messages logarithmic with the file size to be sent to the
contract. Thus, even though it can support fair payment in theory, it is very costly in
practice. Another property is the cost of onboarding a new verifier, as it determines how
flexible the client can be, to pick a new auditor when its current one is misbehaving.
This cost in [3] is significantly high, as it requires the verifier to download the entire
file, generate metadata, and prove in zero-knowledge the correctness of metadata to the
client. But, that cost in SO-PoR and [52, 5] is very low as the client only sends them
a small set of parameters without the need to access the outsourced data. Furthermore,
as stated above, a client in [52] has to fully trust the auditor with the correctness of
verification but this is not the case in SO-PoR and [3, 5], as they consider a potentially
malicious auditor (under different assumptions). Table 5 summaries the result of the
comparison between the four protocols’ main properties.
Table 5: O-PoR Property Comparison. X∗indicates the property is met only in theory.
Properties
Protocols Real-time Detection Fair Payment Untrusted Auditor
SO-PoR X X X
[3] × × X
[52] × × ×
[5] ×X∗X∗
Computation Complexity. In our analysis, we do not take into account the cost of
erasure-coding a file, as it is identical in all schemes. We first analyse the computa-
tion cost of SO-PoR. A client in step 2b performs nmultiplications and nadditions
to generate permanent tags. In step 2c, it performs cz multiplications and cz additions
to generate disposable tags for zverifications. The client in step 2d invokes GenPuz(.)
function, in C-TLP, that costs O(z). So, the client’s total computation cost of preparing
and storing a file is O(n+cz). Now we consider the cloud server’s cost that can be
categorised into two classes: (a) solving a puzzle: SolvPuz(), run only once, and (b)
generating PoR run for each verification. In particular, the cloud in step 3a, invokes
SolvPuz(), in C-TLP, that costs O(T z )this includes the cost in step 3e as well. To
compute proofs, in step 3c, it performs 2cz multiplications and 2cz additions. So, the
server to generate proof is O(cz). Next, we analyse the cost of the smart contract. In
step 4b, it invokes Verify(.), in C-TLP, that in total costs O(z), this involves invoking
zhash function’s instances. Also, the contract in step 4c performs z(1 + c)and z(1 + c)
modular multiplications and additions respectively. Thus, the total cost is O(cz)involv-
ing mainly modular additions and multiplications.
Now we analyse the computation cost of [3]. To prepare file tags, a client performs:
nmultiplications and nadditions. Also, to verify tags generated by the auditor, the
client has to engage in a zero-knowledge protocol that requires it to carry out 6nex-
ponentiations and 2nmultiplications. Therefore, the client’s computation complexity
is O(n). Also, the auditor in total performs 3nmultiplications, 3nadditions and 3n
exponentiations to prepare file’s metadata, so its complexity at this phase is O(n). For
the cloud to generate zproofs, in total it performs 2z(c+c0)multiplications and the
same number of additions, where c0is the number of challenges sent by the auditor to
the cloud (on client’s behalf) and c>c0, e.g. c0= (0.1)c. So, the total complexity of
the cloud is O(z(c+c0)). Next, we consider the verification cost. The auditor performs
z(1 + c)multiplications and z(1 + c)additions to verify PoR. It also performs 2cz
additions in CheckLog algorithm that requires the client to perform z(2c+ 1) additions
and cz multiplications. Nevertheless, as discussed in Section 2, running only CheckLog
does not allow the client to detect a misbehaving auditor. Thus, it has to run ProveLog
too, that requires the client to perform cz multiplications and cz additions and requires
the auditor to reveal all its secrets to the client. So, the total verification complexity is
O(cz). Now we turn our attention to the computation complexity of [52]. To prepare
metadata, the client needs to perform 2nmultiplication and 2nadditions, so the client’s
complexity is O(n). For the cloud to generate a proof it needs to perform 3zexponen-
tiations, z(3c+ 6) multiplications and z(3c+ 2) additions. So, its complexity is O(cz).
On the other hand, the verifier performs cz exponentiations to compute challenges. To
verify the proof, it carries out 6zexponentiations, cz multiplications, cz additions, and
7zpairings. Therefore, the verifier complexity is O(cz)dominated by expensive expo-
nentiations and pairing operations. Also, we analyse the computation cost of efficient
privately verifiable PoR in [45]. A client in the store phase performs nmultiplications
and nadditions to construct the tags. So, its complexity is O(n). A server performs 2cz
multiplications and 2cz additions to generate proofs, so in total 4cz or O(cz)modular
operations for zverifications it carries out. The client, as verifier this time, performs
in total 2z(1 + c)or O(z(1 + c)) modular operations. Next, we turn our attention to
[5], and evaluate the cost of the protocol that supports public verifiability, basic PoSt.
As stated by the authors, they add a VDF to the PoR construction in [34] which uses
a Merkle tree-based PoR. Since, this PoR scheme only involves invocations of hash
function, here we only focus on VDF cost as it dominates other computation costs. We
assume that the most efficient publicly verifiable delay function VDF [50] is used. In
the setup, the client constructs a Merkle tree on the entire data by invoking a hash func-
tion many times and also generates a random challenge. We ignore these costs as they
are dominated by VDF’s costs. To generate zPoR’s, the server invokes VDF ztimes
that in total runs in time period T. This involves 3Tz modular exponentiations over ZN
(where Nis a RSA modulus), and T z modular multiplications. Therefore, its complex-
ity is O(T z). For a validator to ckeck the proofs output by VDF, it performs 3zmodular
exponentiations over Z∗
N(or modφ(N)). So the verifier’s complexity is O(z).
Now we compare the protocols above. The verification in SO-PoR is much faster
than the other three protocols; firstly, it requires no exponentiations in this phase, whereas
[52, 5] do, and secondly, it requires 9c+3
2(1+c)times fewer computation than [3]; Specifi-
cally, when c= 460, SO-PoR verification requires about 4.5times fewer computation
than the verification in [3] needs. In SO-PoR, the cloud server needs to perform T z
exponentiations to solve puzzles, however this is independent of the file size. The sever
in [5] also performs 3T z modular exponentiations, which is 3times higher than the
number of exponentiations done by the server in SO-PoR. The protocols in [3, 45] do
not include the puzzle-solving procedure (and they do not offer all features that SO-
PoR does). Furthermore, the proving cost in SO-PoR is similar to that of in [3], and
is much better than [52], as the latter one requires both exponentiations and pairing
operations while the prove algorithm in SO-PoR does not involve any exponentiations.
The proving cost in [5] is the lowest, as it requires only invocations of a hash function.
Also, the store phase in SO-PoR has a much lower computation cost than the one in [3].
The reason is that the number of exponentiations required (in this phase) in SO-PoR is
independent of file size and is only linear with the number of delegated verifications;
however, the number of exponentiations in [3] is linear with the file size. For instance,
when ||F|| = 1-GB, the total number of blocks is: n=1−GB
128−bit = 625 ×105. Since
the number of exponentiations in [3] is linear with the number of blocks, i.e. 9n, the
total number of exponentiations imposed by store algorithm is: 5625 ×105which is
very high. This is the reason why in the experiment in [3] only a small file size: 64-
MB, is used, that can be stored locally without the need to use cloud storage, in the
first place. Now, we turn our attention to SO-PoR. Let the verification be done every
month for a 10-year period, in this case, z= 120. So, the total number of exponenti-
ations required by the store in SO-PoR is 121. This means the store phase in SO-PoR
requires over 46 ×105times fewer exponentiations than the one in [3] needs. On the
other hand, the store algorithm in [52] does not involve any exponentiations; however,
its number of modular additions and multiplication is higher than the ones imposed by
the store in SO-PoR. The store cost in [5] is the lowest, as it requires only invocations of
a hash function. Furthermore, the verification and prove cost of SO-PoR and privately
verifiable PoR [45] are identical.
Communication Complexity. In our analysis, we do not take into account the commu-
nication cost of uploading an encoded file, i.e. ||F||, when the client for the first time
sends it to the cloud, as it is identical in all schemes. The communication cost of SO-
PoR is as follows. The client, in step 2e, sends npermanent tags, zc disposable tags, and
the output of GenPuz(.)to the server and contract, where each (permanent/disposable)
tag: σj∈Fpand |σj|= 128-bit. Note the client also sends a few public parameters:
ˆ
pk, whose size is short. Therefore, the client’s bandwidth is: 128(n+cz + 19z)bits,
while its communication complexity is O(n+cz). The cloud in step 3d, sends zpairs
(µj, ξj), where µj, ξj∈Fpand |µj|=|ξj|= 128-bit. Also, in step 3e, it sends to the
contract the output of Prove(.), in C-TLP, whose total size is 628zbits. So, the clouds
total bandwidth is about 884zbits and its complexity is O(z)which is independent of
and constant in the file size.
The communication cost of [3] is as follows. The client sends ntags to the server,
where the size of each tag is about 128 bits. So its bandwidth is 128n, and its complexity
is O(n). The auditor also sends ntags to the server, where each tag size is also 128 bits.
It also sends the tags to the client along with zk proofs that contain 4nelements in
total, where 2nof them are elements of ZNand each element size is 2048 bits, and
each of the other 2nelements is 160 bits long. Also, the auditor in ProveLog sends z
pairs to the client with the bandwidth of 256z. So, the auditor’s total bandwidth and
complexity is 4672n+ 256zand O(n+z)respectively. Moreover, the cloud sends
the entire file, F, to the auditor in the store phase and also sends 2zpairs of PoR to
the auditor, where each element of the pair is of size 128 bits. Therefore, the cloud’s
total bandwidth is ||F|| + 256z, while its complexity is O(||F|| +z). Note that the
cloud’s proof size complexity is constant and independent of the file size, i.e. O(1).
Now, we analyse the communication cost of [52]. The client bandwidth and complexity
are 2048nand O(n)respectively, as it sends to the cloud 2ntags, where each tag size is
1024 bits. Also, the cloud bandwidth and complexity are 6144zand O(z)respectively,
as for each verification the cloud sends to the verifier 6elements each of them is 1024-
bit long. Furthermore, in [45] the client bandwidth in the store phase is 128n, while the
server bandwidth is 256z. In this scheme, the complexity of a proof size is O(1). In
[5], the client can send only the file and random challenge of size 128-bit to the server,
who creates a Merkle tree on top of the file’s blocks. Therefore, the client’s bandwidth
is 128-bit. The server sends to the verifier cz PoR proofs that cost it in total at least
128cz log(n)bits. Also, the server sends VDF’s proofs for zoutputs, that cost in total
4096z. Therefore, the server’s total bandwidth is (128cz log n) + 4096z. The reason
the cost involves c(the number of challenges) is that unlike the other three schemes,
this scheme does not support a linear combination of tags/proofs (e.g. homomorphic
tags), and in each proving phase cproofs are generated. Furthermore, in this scheme,
the complexity of a proof size is logarithmic with the number of file blocks, O(log(n)).
To conclude, the verifier-side bandwidth of SO-PoR (and [52, 5]) is much lower
than [3]. For instance, when ||F|| = 1-GB and z= 100, a verifier in SO-PoR requires
62×106fewer bits than the one in [3] does. A client in SO-PoR has a higher bandwidth
than it would have in the rest of the protocols. But, this cost is one-off, at the setup
phase. The server-side bandwidth of SO-PoR is the lowest; for instance (for the same
parameters above) a server in SO-PoR requires 9×104,7, and 1729 times fewer bits than
those required in [3], [52] and [5] respectively. Moreover, [5] has the worst proof size
complexity, which is logarithmic to the file size; while the proof size complexity of the
rest of the schemes is constant. Thus, SO-PoR’s server-side bandwidth is significantly
lower than the rest while having constant proof size.
Remark 16. In [3], the additional costs to secure parties against a malicious client stem
from only the store phase, where an auditor downloads the entire file, generates zero-
knowledge proofs, and has the client sign them after verifying the proofs. Therefore, the
overheads of proving and verifying phases, in this protocol, would remain unchanged if
the protocol considers an honest client.
L More Efficient Proof of Storage-Time
In the following, we show how C-TLP can be used in the PoSt protocols that were pro-
posed in [5] to improve their costs. As stated previously, two protocols: basic PoSt and
compact PoSt, supporting proof of storage-time (in the random oracle) are proposed in
[5], where basic PoSt uses VDF and is publicly verifiable while compact PoSt uses a
trapdoor delay function (TDF) and is privately verifiable. Also, recall that VDF/TDF is
used to allow the server to derive multiple challenges at different points over a certain
time period T. Note, both types of delay function (VDF and TDF) impose the same
computation cost to the server, i.e. 3T z modular exponentiations and T z modular mul-
tiplication if the fastest delay function is used [50].
Now we show how to replace the delay function in these schemes with C-TLP, in
the random oracle. As in the PoSt protocols, the client at the setup precomputes random
challenges (and their PoR tags). But, it encodes all challenges for z−1PoR proofs (ex-
cluding first one) into puzzles using C-TLP. It sends to the server all puzzles, encoded
file and plaintext challenges for the first PoR proof. As before, the server generates the
first PoR proof using the challenges sent to it in the plaintext. Nevertheless, to find j-th
challenge to generate j-th PoR proof, the server solves the related puzzle, where j > 1.
It sends to the client all PoR proofs (or a combination of them) after period T. Also, if
the basic PoSt is used, the server sends C-TLP proofs that can be efficiently verified by
anyone. On the other hand, if the compact PoSt is used, then the server does not need
to send the C-TLP’s proofs, as the client already knows the random challenges. The
adjustments considerably improve the PoSt protocols’ costs. In particular, the server’s
computation cost would be 1
3of the costs imposed by either of the original PoSt pro-
tocols. Also, there will be 3zfurther reduction in the number of exponentiations: (a) at
the verifier side, in the basic PoSt, as it does not need to perform any exponentiation
to check the correctness of C-TLP’s output, (b) at the client-side, in the compact PoSt,
as the client does not need to evaluate TDF at the setup to precompute the challenges
which in total involves 3zmodular exponentiations over φ(N). Moreover, the proof
size would be reduced by a factor of 6.5.
Remark 17. Although the use of C-TLP in the PoSt protocols can reduce the com-
putation and communication costs, (a) the server-side I/O cost in these schemes (i.e.
O(log n)in the basic PoSt and O(n)in the compact one), and (b) PoR’s proof size
complexity in the basic PoSt, will remain the same. Because these costs stem from the
underlying PoR schemes, used as a black box, by the two PoSt protocols.
Remark 18. In general, VDF’s offer certain features that (C-)TLP schemes do not offer,
e.g. in VDF’s parameters zor their outputs do not need to be fixed ahead of time, or
they can support multiple users.