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 Veriﬁable 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 signiﬁcant

computation cost and demands a high level of parallelisation. We put forth and

formally deﬁne 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 veriﬁable algorithm. It is the ﬁrst time-lock

puzzle that offers a combination of the above features. We use C-TLP to build the

ﬁrst “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 “veriﬁable

delay function” with C-TLP, to gain much better efﬁciency.

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 efﬁcient remedy for the multi-instance setting, where

a server is given multiple instances of a puzzle at once and it should ﬁnd 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 conﬁdential 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 conﬁdential 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 signiﬁcant 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 deﬁne 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 veriﬁcation 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 ﬁrst 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. Speciﬁcally, 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 notiﬁed in almost real-time when a PoR proof is rejected) and fair payment (i.e.

in every veriﬁcation, 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 veriﬁcation 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 ﬁle and 100 veriﬁcations, 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-

ﬁable 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 deﬁne it, and identify its concrete applications, (b) present a can-

didate construction, C-TLP, the ﬁrst multi-instance time-lock puzzle that is built on a

standard time-lock puzzle, supports public veriﬁability, and has low costs, (c) propose

the ﬁrst 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 efﬁciency.

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 ﬁrst 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) veriﬁcation, 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 veriﬁcation to a potentially malicious third-party auditor.

The scheme in [3] has the fastest prove and veriﬁcation 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 efﬁ-

cient way for fair payments and has high costs of setup and auditor onboarding. Xu

et al. in [52] propose a publicly veriﬁable 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 veriﬁcation 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 veriﬁer

to validate VDF’s outputs, it imposes a signiﬁcant 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 ﬁle 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 ﬁle size when a Merkle tree is used, or high concrete veriﬁcation 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 veriﬁcation [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 veriﬁcation

itself or a third-party, acting on the client’s behalf, carries out the veriﬁcation 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-

ﬁne 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 veriﬁes 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 ﬁnd ¨p0,s.t. Ver(h, ¨p) = Ver(h, ¨p0)=1, where ¨p6= ¨p0. There exist ef-

ﬁcient 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 deﬁned as follows [29].

Deﬁnition 1. Let W:{0,1}ψ× {0,1}η→ {0,1}ιbe an efﬁcient 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 deﬁnition 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.

Deﬁnition 2 (Time-lock Puzzle). A time-lock puzzle comprises the following efﬁcient

three algorithms, such that the puzzle satisﬁes completeness and efﬁciency 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

–Efﬁciency: 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 ﬁnd 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 deﬁnitions [9,38, 23].

Deﬁnition 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 deﬁnitions 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 ﬁnd solutions on time, is to solve them in parallel.4Also,

for the client to efﬁciently 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’ ﬂaws, 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

veriﬁability, and has low costs is challenging (we refer readers to Remark 7 for a de-

tailed discussion). In our solution, a client ﬁrst 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 Efﬁcient Publicly Veriﬁable Algorithm. To let the scheme support efﬁcient

public veriﬁability, 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 ﬁnds a solution, it decodes the solution to ﬁnd the opening and sends it to the

public who can check the solution correctness. So, to verify a solution’s correctness, a

veriﬁer only needs to run the commitment’s veriﬁcation algorithm that is: (a) publicly

veriﬁable, and (b) efﬁcient. 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 Deﬁnition

In this section, we provide a formal deﬁnition of a multi-instance time-lock puzzle.

Our starting point is the time-lock puzzle deﬁnition, i.e. Deﬁnition 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 veriﬁability. In the following, we provide the

formal deﬁnition of a multi-instance time-lock puzzle.

Deﬁnition 4 (Multi-instance Time-lock Puzzle). A multi-instance time-lock puzzle

has the following ﬁve algorithms and satisﬁes completeness and efﬁciency 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 ﬁxed 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 veriﬁer.

•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 veriﬁer, it always holds that:

•SolvPuz(pk, [o1, ..., oj]) = [s1, ..., sj], for every j,1≤j≤z

•Verify(pk, Prove(pk, sj), hj)→1

–Efﬁciency: the run-time of algorithm SolvPuz(pk, [o1, ..., oj]) = [s1, ...sj]is bounded

by: poly(j ∆, λ), where poly(.)is a ﬁxed polynomial and 1≤j≤z

Informally, a multi-instance time-lock puzzle is secure if it satisﬁes 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 veriﬁcation. The two properties are formally deﬁned in Deﬁnitions 5 and 6.

Deﬁnition 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 deﬁnition 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 ﬁnd

j-th solution in time δ(j∆)< j∆ using π(∆)parallel processors, with a probability

signiﬁcantly greater than 1

2. As highlighted in [9], we can set δ(∆) = (1 −)∆for a

small , where 0<<1

Deﬁnition 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

Deﬁnition 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 veriﬁability. 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−1ﬁxed 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 zﬁxed size sufﬁciently 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 veriﬁer.

5. Verify:Verify(pk, ¨pj, hj). Veriﬁes 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 ﬁnd 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 satisﬁed. 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 efﬁciency.

Since the MAC’s are privately veriﬁable and secret veriﬁcation keys are needed to check

PoR proofs, SO-PoR also uses C-TLP to efﬁciently make them publicly veriﬁable. In

this case, C-TLP encapsulates the veriﬁcation keys and reveals each of them to ver-

iﬁers only after a certain time. SO-PoR also uses a smart contract which acts as a

public veriﬁer 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 veriﬁcation. 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 efﬁciency in the setting where public veriﬁability 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 veriﬁable.

At a high-level SO-PoR works as follows. The client encodes its ﬁle using an error-

correcting code and for each j-th veriﬁcation 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 veriﬁcations in a smart contract. The

client sends the encoded ﬁle, 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 ﬁle 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 veriﬁcation, after a ﬁxed time,

it manages to ﬁnd the related MAC’s veriﬁcation 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 veriﬁcation; otherwise, it notiﬁes 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 ﬁle is retrievable (see

Appendix G for a formal deﬁnition of the PoR). In SO-PoR, however, a client may not

be available for veriﬁcation. So, it wants to delegate a set of veriﬁcations that it cannot

carry out. Informally, in this setting, it (in addition to ﬁle retrievability) must have three

guarantees: (a) veriﬁcation correctness: every veriﬁcation is performed honestly, so the

client can trust the veriﬁcation’s result without redoing it, (b) real-time detection: the

client is notiﬁed in almost real-time when a proof is rejected, and (c) fair payment:

in every veriﬁcation, 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 veriﬁcation

itself, when it is available. We present our formal deﬁnition 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 veriﬁcation. It deﬁnes 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 ﬁrst delegated veriﬁcation 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 veriﬁcations, ||F||: ﬁle 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 veriﬁcation. 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 ﬁle, 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 ﬁle 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 veriﬁcation (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 veriﬁcation (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. Veriﬁcation 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 Veriﬁcation. For j-th veriﬁcation (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 veriﬁes 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 veriﬁcation, i.e. σj

If either check fails, it aborts and notiﬁes 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 ﬁle: F, and (c) the tags: σi∈σ, generated in step 2b. The proof

generation and veriﬁcation 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 ﬁrst argue that the adver-

sary who corrupts either C⊆ {M1, ..., Mβ}or C0⊆ {S,M1, ..., Mβ−1}with a high

probability, cannot inﬂuence the output of Verify(.)performed by a smart contract in

a blockchain (i.e. the veriﬁcation 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

ﬁle 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 veriﬁability. Brieﬂy, 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-

ﬁcation algorithm in SO-PoR is much faster than the other three protocols; Speciﬁcally,

when c= 460, SO-PoR veriﬁcation5needs about 4.5times fewer computation than

the veriﬁcation 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 ﬁle, 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 ﬁle blocks is retrievable, it sufﬁces 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 ﬁle and z= 100 veriﬁcations, 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 veriﬁcation 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 efﬁcient traditional PoR [45].

Table 2: Outsourced PoR’s Cost Comparison. z: total veriﬁcations, c: number of challenges for

each veriﬁcation, n: total number of ﬁle blocks, c0= (0.1)c, and ||F||: ﬁle bit size.

Computation Cost Communication Cost

Protocols Operation Store SolvPuz Prove Verify Client Server Veriﬁer 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 Efﬁcient 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

veriﬁability is desirable) and TDF (if private veriﬁability sufﬁces). 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 efﬁciency. 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 efﬁciently verify the solutions’ correctness.

To illustrate the efﬁciency 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 efﬁcient 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 ﬁnd 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 efﬁcient veriﬁcation algorithm publicly executable. We also illustrated how to use

C-TLP to construct an efﬁcient 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: Efﬁciently checking

continuous data availability. In: NDSS’20

6. Ateniese, G., Pietro, R.D., Mancini, L.V., Tsudik, G.: Scalable and efﬁcient 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.: Veriﬁable 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 difﬁculty. In: Katz, J., Shacham, H. (eds.) CRYPTO’17

23. Garay, J.A., Kiayias, A., Panagiotakos, G.: Iterated search problems and blockchain security

under falsiﬁable 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 veriﬁcation

model in untrusted environment. In: APWeb-WAIM’18

26. Juels, A., Jr., B.S.K.: Pors: proofs of retrievability for large ﬁles. 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 ﬁle storage with ﬁnancial 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 ﬁle storage with ﬁnancial incentives. In: EuroS&P Workshops’17

32. Kupcu, A.: Efﬁcient 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://ﬁlecoin.io/ﬁlecoin.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 veriﬁable 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.: Efﬁcient veriﬁable 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 efﬁcient 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 ﬁrst

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 efﬁcient 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 veriﬁable. 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) veriﬁcation, 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 efﬁciency 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 ﬁnd 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 ﬁnd 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

ﬁnd 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 efﬁciently compute all g2T1, g2T2,...g2Tn, which is not optimal

either.

We also cover two related but different notions, pricing puzzles, and veriﬁable delay

functions.

Pricing Puzzles. Also known as client puzzles. It was ﬁrst put forth by Dwork et al. [17]

who deﬁned 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 ﬁxed size. Given h, Hand m, the solver must ﬁnd rsuch that the

above equation holds. The size of ris picked in such a way that the expected time to

ﬁnd the solution is ﬁxed (however it does not rule out ﬁnding the solution on the ﬁrst

attempt). The above hash-based scheme allows a solver to ﬁnd 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 ﬁnd the solution. This means the puzzles can be

used only in the cases where the time required to ﬁnd 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 efﬁcient veriﬁcation

mechanism than the one proposed in [42]. But, they are only privately veriﬁable and

not designed to encapsulate an arbitrary message.

Veriﬁable Delay Function (VDF). Allows a prover to provide a publicly veriﬁable

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 ﬁrst formalised by Boneh et al in [9] who

proposed several VDF constructions based on SNARKs along with either incremen-

tally veriﬁable 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-

ﬁcient VDF. It also supports batch veriﬁcation, such that given a single proof a veriﬁer

can efﬁciently check the validity of multiple outputs of the veriﬁable 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 efﬁciently 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 veriﬁable. In a publicly ver-

iﬁable scheme, everyone without knowing a secret can verify proof, whereas a veriﬁer in

a privately veriﬁable 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 ﬁrst was introduced and deﬁned 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 ﬁle block and encrypts each encoded block. Then, it

computes a set of random sentinels and appends them to the encrypted ﬁle. It permutes

all values (i.e. sentinels and encrypted ﬁle blocks) and sends them to the cloud server.

To check if the server has retained the ﬁle, the client speciﬁes random positions of some

sentinels in the encoded ﬁle 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 ﬁle blocks

and the sentinels have been distributed uniformly among the ﬁle blocks. But, as indi-

vidual sentinel is only one-time veriﬁable, there is an upper bound on the number of

veriﬁcations performed by the client, and when reached, the client has to re-encode the

ﬁle. To overcome the issues related to the bounded number of veriﬁcations, the authors

have also suggested that sentinels can be replaced with MAC on every ﬁle block or a

Merkle tree constructed on the ﬁle blocks. This protocol is computationally efﬁcient

and its communication cost is linear with the number of challenges sent6. The sentinel

and MAC-based schemes above are privately veriﬁable while the one uses a Merkle

tree supports public veriﬁability. However, the publicly veriﬁable Merkle tree-based

approach has a communication cost logarithmic with the ﬁle size and the prover has to

send a set of ﬁle blocks to the veriﬁer that yields a high communication cost.

Later on, [45] improves the previous sentinel-based scheme and deﬁnition, and pro-

poses two PoR protocols (with an unlimited number of veriﬁcations), one uses MAC

and the other one relies on BLS signatures. In particular, a client at setup phase, encodes

its ﬁle blocks using error-correcting code and then for each encoded ﬁle block it gener-

ates a tag that can be either a MAC or BLS signature of that block. In the veriﬁcation

phase, it speciﬁes a set of random indices corresponding to the ﬁle’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 ﬁle blocks are sent to the prover. Also, the protocol

based on MAC supports efﬁcient private veriﬁcation. But, the one that uses BLS signa-

tures supports public veriﬁability at the cost of public key operations and it is far less

efﬁcient than the MAC-based one. Within the last decade, researchers have extended

PoR protocols from several perspectives, e.g. those that support: efﬁcient update [47],

the delegation of ﬁle pre-processing [2], or the delegation of veriﬁcation [3].

On the other hand, PDP was ﬁrst 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 veriﬁcation both of which use RSA-based homomorphic veriﬁable

tags generated for each ﬁle 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 ﬁle’s blocks. In both schemes, the proof size is constant,

while the veriﬁcation cost is high as it requires many exponentiations over an RSA

ring. Later on, an efﬁcient and scalable PDP scheme that supports a limited number of

veriﬁcations is proposed in [6]. The scheme supports only privately veriﬁable 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 veriﬁable PoS it is assumed the veriﬁer is fully trusted with the

veriﬁcation correctness, (b) these schemes either have a very high veriﬁcation cost when

the proof size is constant (when signature-based tags are used) or have a communication

cost logarithmic with the entire ﬁle size if their veriﬁcation is efﬁcient (when a Merkle

tree is used), and (c) the privately veriﬁable proofs can have a constant proof size and

efﬁcient veriﬁcation algorithm, but the data owner has to perform the veriﬁcation.

Outsourced PoR Recently, [3, 52] propose outsourced PoR protocols that allow clients

to outsource the veriﬁcation 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 ﬁle block, and stores the encoded ﬁle

and tags on the server. Then, the auditor downloads the encoded ﬁle, generates another

set of MAC’s on the ﬁle 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 veriﬁcation 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-

iﬁes 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 veriﬁcation to the client: CheckLog and ProveLog.CheckLog is more

efﬁcient than the other one, as the auditor sends much fewer challenges to the server

to generate the client’s proof for each veriﬁcation. 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 veriﬁcation, 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 ofﬂine. In this protocol, the veriﬁcation phase is efﬁcient (due to

the use of MACs). In particular, the veriﬁcation’s computation cost for the auditor and

client is linear with the number of challenges and their communication cost is constant

in the ﬁle 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/notiﬁcation: the client

may not be notiﬁed 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 veriﬁable PoR, encodes its data and stores it in

the server. Then, for each veriﬁcation 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 ﬁle.

Xu et al. in [52] propose a publicly veriﬁable 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 veriﬁcations. 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 veriﬁcation 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 veriﬁcation 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 ﬁxed 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 veriﬁer (i.e. client in basic PoSt or third-party in compact PoSt) who can

check the proof. The ﬁrst 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 ﬁle, 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-

ﬁer. Given the two sets of proofs, a veriﬁer can check their correctness and ultimately

conclude that the ﬁle was retrievable within the time period. The scheme is publicly

veriﬁable. However, the veriﬁcation’s computation cost is signiﬁcant. 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 signiﬁcant ﬁnancial cost to the contract and users

due to very high computation and communication costs stem from the veriﬁcation 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 ﬁle 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 veriﬁable. The paper claims that the veriﬁcation 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

veriﬁcation, 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 veriﬁcation 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 veriﬁer performs the validation itself (i.e. private veriﬁcation/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 veriﬁers with the veri-

ﬁcation correctness, or are very inefﬁcient.

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 ﬁle and to do so it

provides proof of data retrievability veriﬁed 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 ﬁle blocks to support

publicly veriﬁable PoR. The mining procedure in this protocol is based on iterative

hashing. In Permacoin, in each veriﬁcation, the prover has to send both challenged ﬁle

blocks and the proof path in the tree, that imposes communication cost logarithmic to

the size of the entire original ﬁle. 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 ﬁle size and the number of miners) or hope that there

are enough active miners in each epoch. Also, since the miners are both veriﬁers 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 veriﬁable 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

veriﬁable 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 efﬁcient 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 veriﬁ-

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 veriﬁcations 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 veriﬁ-

cation cost. Also, they do not guarantee that the entire ﬁle 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 veriﬁcation in the publicly veriﬁable

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 veriﬁcation procedure to

blockchain nodes. The high-level framework proposed in [41] requires only a hash of

the entire ﬁle is stored in a smart contract, where when later on the user access the ﬁle, it

computes the hash of the ﬁle and compares it with the one stored in the contract. In this

scheme, the entire ﬁle has to be accessed by the user for each veriﬁcation 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 veriﬁcation needed in the ﬁrst 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 veriﬁcation.

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

veriﬁcations. 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 veriﬁcation it calls a smart contract who

performs the veriﬁcation 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 veriﬁcation of data stored

in a storage server either require clients to access whole outsourced data for every veri-

ﬁcation, or impose a high communication/computation cost, or clients have to be online

for each veriﬁcation.

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 veriﬁable both of which use a smart contract. In addition, in the privately ver-

iﬁable variant, MAC-based tags and generic secure multi-party computation are used,

e.g. Yao’s garbled circuit [55], while in the publicly veriﬁable 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 veriﬁable variant) or the third

party, acting on a client’s behalf, performs PoR veriﬁcation honestly (in publicly veriﬁ-

able one).

B Notations

We summarise our notations in Table 4.

C Discussion on Time-lock Puzzle

In general, time-lock puzzles by deﬁnition 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 veriﬁcations

h,hjHash values

d,djRandomness of commitment

nNumber of ﬁle 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 ﬁle

FjA ﬁle block

|F|Number of ﬁle 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 deﬁned in [9]. Below, for the sake of com-

pleteness, we provide those deﬁnitions.

Deﬁnition 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

Deﬁnition 9 (Iterated Sequential function). Let g:X→Xbe a (∆, δ (∆))-sequential

function. A function f:N×X→Xdeﬁned 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→Xdeﬁned 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 ﬁnite group

of unknown order, is widely believed to be a candidate for an iterated sequential func-

tion. Its deﬁnition 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, deﬁned 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 ﬁnd the secret signiﬁcantly 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 ﬁnding the blinding factor without performing a sufﬁcient number of squaring

(and without knowing φ(N)). However, ﬁnding φ(N)is as hard as factoring N, also as

long as the encryption is secure and kis sufﬁciently 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 ﬁnding the blinding factor with-

out carrying out enough squaring within time signiﬁcantly less than δ(∆). Thus, any

adversary Acannot ﬁnd the secret without carrying out a sufﬁcient 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 veriﬁers (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 veriﬁer 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 efﬁcient non-interactive com-

mitment scheme in the standard model as well, e.g. Pedersen Commitment.

Remark 5. The efﬁciency 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 efﬁcient veriﬁcation: 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 efﬁcient 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 ﬁnding 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 veriﬁcation 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 ﬁrst prove that

without solving j-th puzzle, a solver cannot ﬁnd 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 sufﬁciently 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), deﬁned in Section 4.3, cannot ﬁnd the next group generator: rj+1 , where

rj+1

$

←Z∗

Nand j≥1, signiﬁcantly 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 ﬁnd 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 Deﬁnition 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. Deﬁnition 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 ﬁnd s1earlier than δ(∆), it has to break

the TLP scheme, and (b) when z > 1: to ﬁnd sjearlier than Tj=δ(j∆), it has to either

ﬁnd at least one of the previous solutions earlier than it is supposed to (that ultimately

requires breaking TLP scheme again), or ﬁnd j-th generator: rj, earlier. Also, we argue

that the commitments: hj, are computationally hiding. Speciﬁcally, 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 ﬁnd sjearlier than Tjas soon as the previous solution: sj−1

is found that requires either breaking the TLP scheme, or ﬁnding 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 ﬁnding the next generator: rjearlier

than Tj−1is negligible, according to Lemma 1. Moreover, for an adversary to ﬁnd a

solution earlier, it may also try to ﬁnd 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 Deﬁnition 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. Deﬁnition 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. ﬁnds 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. Deﬁnition 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 veriﬁcation 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 veriﬁcation’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 ﬁnds 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 veriﬁer, 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 deﬁnition of the traditional PoR scheme [45]. In general,

a PoR scheme considers the case where an honest client wants to store its ﬁle(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 ﬁle is intact and retrievable. A PoR

scheme comprises ﬁve 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 ﬁle: 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 ﬁle size: |F∗|and security: 1λ. It outputs a set of pairs, ¨cj:

(xj, yj), where each pair includes a ﬁle block index: xjand coefﬁcient: yj, both of

them are picked uniformly at random.

•Prove(F∗, σ, #»

c)→π: takes the encoded ﬁle: F∗, (a subset of) tags: σ, and a

vector of unpredictable random challenges: #»

cas inputs and outputs a proof of the

ﬁle 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 ﬁles, the veriﬁcation algorithm accepts a proof

generated by an honest veriﬁer. The soundness requires that if a prover convinces the

veriﬁer (with a high probability) then the ﬁle is stored by the prover; This is formalized

via the notion of an extractor algorithm, that is able to extract the ﬁle in interaction with

the adversary using a polynomial number of rounds. In contrast to the deﬁnition in [45]

where GenChal(.)is implicit, in the above we have explicitly deﬁned it, as its modiﬁed

version plays an integral role in SO-PoR deﬁnition (and protocol).

H SO-PoR Model

In this section, we provide a formal deﬁnition 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 veriﬁcation is needed. There-

fore, it wants to delegate a set of veriﬁcations that it cannot carry out itself. In this

setting, it (in addition to ﬁle retrievability) must have three guarantees: (a) veriﬁcation

correctness: every veriﬁcation is performed honestly, so the client can rely on the veri-

ﬁcation result without the need to re-do it, (b) real-time detection: the client is notiﬁed

in almost real-time when server’s proof is rejected, and (c) fair payment: in every veriﬁ-

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 veriﬁcation itself, analogous to the

traditional PoR, when it is available.

Deﬁnition 10. A Smart Outsourced PoR (SO-PoR) scheme consists of seven algorithms

(Setup,Store,SolvPuz,GenChall,Prove,Verify,Pay) deﬁned 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 veriﬁcation 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 ﬁle: F, and the

number of veriﬁcations: zthat the client wants to delegate. It outputs an encoded

ﬁle: 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 veriﬁcation 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 veriﬁcation index: j, the encoded ﬁle size: |F|, security parameter: 1λ, ﬁrst 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 coefﬁcient: yj.

Also, values xjare derived from vjwhile yjare derived from pp. This algorithm is

run by the server for each veriﬁcation.

•Prove(j, F, σ, #»

c)→π: a probabilistic algorithm that takes the veriﬁcation index

j, encoded ﬁle: F, (a subset of) tags: σ, and a vector of unpredictable challenges:

#»

c, as inputs and outputs a proof of ﬁle retrievability. It is run by the server for each

veriﬁcation.

•Verify(j, π, ¨sj, aux)→d:{0,1}: a deterministic algorithm that takes the veri-

ﬁcation 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 veriﬁcation and invoked only once for each veriﬁcation by only

the server.

•Pay(j, d)→d0={0,1}: a deterministic algorithm that takes the veriﬁcation

index j, the veriﬁcation 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: ﬁle, public-private key pairs, and puzzle solutions,

both the veriﬁcation and pay algorithms, i.e. Verify(.)and Pay(.), output 1when

interacting with the prover, veriﬁer, and client all of which are honest. The soundness

however is split into four properties: extractability, veriﬁcation correctness, real-time

detection, and fair payment, formally deﬁned below. Before we deﬁne the ﬁrst 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 ﬁle 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 veriﬁcation output. The adversary

can send a polynomial number of queries to E. Finally, Aoutputs the description

of a prover: A0for any ﬁle it has already chosen above.

It is said a cheating prover: A0is -admissible if it convincingly answers fraction

of veriﬁcation 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 ﬁle: 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.

Deﬁnition 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 ﬁle 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

veriﬁcation correctly; which is not always the case in SO-PoR. As the veriﬁcation can

be run by miners a subset of which are potentially corrupted. Even in this case, the veri-

ﬁcation correctness must hold, e.g. if a corrupt server sends an invalid proof then even if

β−1miners are corrupt (and colluding with it) the veriﬁcation function will not output

1and if the server is honest and submits a valid proof then the veriﬁcation function does

not output 0even if βminers are corrupt, except with a negligible probability. This is

formalised below.

Deﬁnition 12 (Veriﬁcation 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 veriﬁcation 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 veriﬁcation it can get a correct

result within a (ﬁxed) time period.

Deﬁnition 13 (Υ-real-time Detection). Let A, as deﬁned above, be the adversary who

corrupts either Cor C0. A client, for each j-th delegated veriﬁcation, 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.

Deﬁnition 14 (Fair Payment). SO-PoR supports a fair payment if the client and server

fairness are satisﬁed:

•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 deﬁned 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 deﬁnition also takes into account the fact that the client at the time of

delegated veriﬁcation 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 deﬁnition

ensures that even if the client or/and server are honest, the third party cannot affect the

fairness (except with a negligible probability).

Deﬁnition 15 (SO-PoR Security). A SO-PoR scheme is secure if it is -extractable, and

satisﬁes veriﬁcation 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

deﬁnitions 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 veriﬁcations function) to detect

a veriﬁer if it provides an incorrect veriﬁcation output, so the client cannot rely on the

veriﬁcation 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 veriﬁes proof) when

the client is available. To let SO-PoR deﬁnition support that too, we can simply deﬁne a

ﬂag: ξ, 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 ﬂag

be implicit in the deﬁnitions above, where the default is ξ= 1

I SO-PoR Security Proof

In this section, we ﬁrst 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 Deﬁnition 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 satisﬁes every property

that were deﬁned in Appendix H.

Veriﬁcation correctness (according to Deﬁnition 12). We ﬁrst argue that the adversary

who corrupts either C⊆ {M1, ..., Mβ}or C0⊆ {S,M1, ..., Mβ−1}with a high

probability, cannot inﬂuence the output of Verify(.)performed by a smart contract in

a blockchain; in other words, the veriﬁcation correctness holds. In short, the veriﬁcation

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 veriﬁcation 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 veriﬁcation 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 Deﬁnition 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 ﬁle 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 ﬁrst 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 inﬂuence its output. Note that in [45] only

the permanent tags are used, and since the client generates the challenges and performs

the veriﬁcation, 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 ﬁle 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 ﬁle can be extracted only

by using the permanent tags but not the disposable ones. However, as shown above (i.e.

due to the veriﬁcation correctness), they have a negligible probability of success, when

the blockchain is secure.

Υ-real-time Detection (according to Deﬁnition 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 ﬁx 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 veriﬁcation 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 Deﬁnition 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 veriﬁcation function outputs 0. Therefore, it would sufﬁce

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 veriﬁcation, 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 veriﬁcation. 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 veriﬁes 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. Speciﬁcally, (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 veriﬁcation), is not

derived from the block index. Instead, it depends on (a fresh secret key for j-th veriﬁ-

cation and) the total number of blocks challenged in each veriﬁcation that is a public

value. This means, the veriﬁer does not need to know and verify each challenged block’s

index in the veriﬁcation 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 ofﬂoad 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 veriﬁcation) 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) veriﬁes 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 veriﬁcation. Nevertheless, the added

cost is small and independent of the ﬁle 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 veriﬁable

PoR and smart contract, such that the contract performs the veriﬁcation on the client’s

behalf. However, this approach would have a higher computation or communication

cost (especially in the veriﬁcation phase) than our protocol. Speciﬁcally, there exist two

publicly veriﬁable 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

veriﬁcation phase, whereas SO-PoR requires no exponentiations in this phase. Also,

the BLS signature-based scheme takes a very long time to encode a ﬁle, 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 ﬁle, meaning it would take about 14 hours to encode a 1-GB

ﬁle. But, in SO-PoR the number of exponentiations, in the store phase, is independent

of and much fewer than the ﬁle size. On the other hand, the proof size in the Merkle

tree-based approach is logarithmic with the ﬁle 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 ﬁle 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 veriﬁability, i.e. basic PoSt. Recall, we consider a generic case

where a client outsources zveriﬁcations and in our cost analysis, we also compare

SO-PoR cost with the cost of the most efﬁcient privately veriﬁable 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 veriﬁcation result

in (almost) real-time without the need for it to re-execute the veriﬁcation itself. This

is offered only by SO-PoR. By contrast, in [3] the auditor may never notify the client,

even if it does, its notiﬁcation would not be reliable, and the client has to redo the

veriﬁcation to verify the auditor’s claim. Similarly, in [52] the client has to fully trust

the auditor to get notiﬁed 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 notiﬁed by a potentially malicious auditor as soon

as an unauthorised modiﬁcation 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 veriﬁcation 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] brieﬂy state that the basic PoSt’s veriﬁcation can be

performed by a smart contract who, after ensuring the proofs are valid, pays the server.

Nevertheless, as stated previously, the veriﬁcation 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 ﬁle 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 veriﬁer, as it determines how

ﬂexible the client can be, to pick a new auditor when its current one is misbehaving.

This cost in [3] is signiﬁcantly high, as it requires the veriﬁer to download the entire

ﬁle, 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

veriﬁcation 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 ﬁle, as it is identical in all schemes. We ﬁrst 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 zveriﬁcations. 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 ﬁle 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 veriﬁcation. 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 ﬁle 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 ﬁle’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 veriﬁcation 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 veriﬁcation 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 veriﬁer performs cz exponentiations to compute challenges. To

verify the proof, it carries out 6zexponentiations, cz multiplications, cz additions, and

7zpairings. Therefore, the veriﬁer complexity is O(cz)dominated by expensive expo-

nentiations and pairing operations. Also, we analyse the computation cost of efﬁcient

privately veriﬁable 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 zveriﬁcations it carries out. The client, as veriﬁer 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 veriﬁability, 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 efﬁcient publicly veriﬁable 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 veriﬁer’s complexity is O(z).

Now we compare the protocols above. The veriﬁcation in SO-PoR is much faster

than the other three protocols; ﬁrstly, 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]; Speciﬁ-

cally, when c= 460, SO-PoR veriﬁcation requires about 4.5times fewer computation

than the veriﬁcation in [3] needs. In SO-PoR, the cloud server needs to perform T z

exponentiations to solve puzzles, however this is independent of the ﬁle 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 ﬁle size and is only linear with the number of delegated veriﬁcations;

however, the number of exponentiations in [3] is linear with the ﬁle 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 ﬁle size: 64-

MB, is used, that can be stored locally without the need to use cloud storage, in the

ﬁrst place. Now, we turn our attention to SO-PoR. Let the veriﬁcation 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 veriﬁcation and prove cost of SO-PoR and privately

veriﬁable PoR [45] are identical.

Communication Complexity. In our analysis, we do not take into account the commu-

nication cost of uploading an encoded ﬁle, i.e. ||F||, when the client for the ﬁrst 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 ﬁle 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 ﬁle, 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 ﬁle 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 veriﬁcation the cloud sends to the veriﬁer 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 ﬁle and random challenge of size 128-bit to the server,

who creates a Merkle tree on top of the ﬁle’s blocks. Therefore, the client’s bandwidth

is 128-bit. The server sends to the veriﬁer 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 ﬁle blocks, O(log(n)).

To conclude, the veriﬁer-side bandwidth of SO-PoR (and [52, 5]) is much lower

than [3]. For instance, when ||F|| = 1-GB and z= 100, a veriﬁer 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 ﬁle size; while the proof size complexity of the

rest of the schemes is constant. Thus, SO-PoR’s server-side bandwidth is signiﬁcantly

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 ﬁle, 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 Efﬁcient 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 veriﬁable while compact PoSt uses a

trapdoor delay function (TDF) and is privately veriﬁable. 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 ﬁrst one) into puzzles using C-TLP. It sends to the server all puzzles, encoded

ﬁle and plaintext challenges for the ﬁrst PoR proof. As before, the server generates the

ﬁrst PoR proof using the challenges sent to it in the plaintext. Nevertheless, to ﬁnd 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 efﬁciently veriﬁed 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 veriﬁer 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 ﬁxed ahead of time, or

they can support multiple users.