Ieeepro techno solutions ieee java project - oruta privacy-preserving public auditing

IEEE TRANSACTIONS ON XXXXXX, VOL. X, NO. X, XXXX 201X 1
Oruta: Privacy-Preserving Public Auditing
for Shared Data in the Cloud
Boyang Wang, Baochun Li, Member, IEEE, and Hui Li, Member, IEEE
Abstract—With cloud storage services, it is commonplace for data to be not only stored in the cloud, but also shared across multiple
users. However, public auditing for such shared data — while preserving identity privacy — remains to be an open challenge. In this
paper, we propose the first privacy-preserving mechanism that allows public auditing on shared data stored in the cloud. In particular,
we exploit ring signatures to compute the verification information needed to audit the integrity of shared data. With our mechanism, the
identity of the signer on each block in shared data is kept private from a third party auditor (TPA), who is still able to publicly verify the
integrity of shared data without retrieving the entire file. Our experimental results demonstrate the effectiveness and efficiency of our
proposed mechanism when auditing shared data.
Index Terms—Public auditing, privacy-preserving, shared data, cloud computing.
3
1 INTRODUCTION
CLOUD service providers manage an enterprise-class
infrastructure that offers a scalable, secure and re-
liable environment for users, at a much lower marginal
cost due to the sharing nature of resources. It is routine
for users to use cloud storage services to share data with
others in a team, as data sharing becomes a standard fea-
ture in most cloud storage offerings, including Dropbox
and Google Docs.
The integrity of data in cloud storage, however, is
subject to skepticism and scrutiny, as data stored in an
untrusted cloud can easily be lost or corrupted, due
to hardware failures and human errors [1]. To protect
the integrity of cloud data, it is best to perform public
auditing by introducing a third party auditor (TPA), who
offers its auditing service with more powerful computa-
tion and communication abilities than regular users.
The first provable data possession (PDP) mechanism
[2] to perform public auditing is designed to check the
correctness of data stored in an untrusted server, without
retrieving the entire data. Moving a step forward, Wang
et al. [3] (referred to as WWRL in this paper) is designed
to construct a public auditing mechanism for cloud data,
so that during public auditing, the content of private
data belonging to a personal user is not disclosed to the
third party auditor.
We believe that sharing data among multiple users is
perhaps one of the most engaging features that motivates
cloud storage. A unique problem introduced during the
• Boyang Wang and Hui Li are with the State Key Laboratory of Integrated
Services Networks, Xidian University, Xi’an, 710071, China. Boyang
Wang is also a visiting Ph.D student at Department of Electrical and
Computer Engineering, University of Toronto.
E-mail: {bywang,lihui}@mail.xidian.edu.cn
• Baochun Li is with the Department of Electrical and Computer Engineer-
ing, University of Toronto, Toronto, ON, M5S 3G4, Canada.
E-mail: bli@eecg.toronto.edu
process of public auditing for shared data in the cloud is
how to preserve identity privacy from the TPA, because
the identities of signers on shared data may indicate that
a particular user in the group or a special block in shared
data is a higher valuable target than others.
For example, Alice and Bob work together as a group
and share a file in the cloud. The shared file is divided
into a number of small blocks, which are independently
signed by users. Once a block in this shared file is
modified by a user, this user needs to sign the new block
using her public/private key pair. The TPA needs to
know the identity of the signer on each block in this
shared file, so that it is able to audit the integrity of the
whole file based on requests from Alice or Bob.
a block signed by Alice a block signed by Bob
A A A A A A B A B B
A B
A A A A A A A B B B
A A A A B A A A B B
8th
8th
8th
Auditing Task 1
Auditing Task 2
Auditing Task 3
TPA
Fig. 1. Alice and Bob share a file in the cloud. The TPA
audits the integrity of shared data with existing mecha-
nisms.
As shown in Fig. 1, after performing several auditing
tasks, some private and sensitive information may reveal
to the TPA. On one hand, most of the blocks in shared
file are signed by Alice, which may indicate that Alice
is a important role in this group, such as a group leader.
On the other hand, the 8-th block is frequently modified
by different users. It means this block may contain high-
value data, such as a final bid in an auction, that Alice

2 IEEE TRANSACTIONS ON XXXXXX, VOL. X, NO. X, XXXX 201X
and Bob need to discuss and change it several times.
As described in the example above, the identities of
signers on shared data may indicate which user in the
group or block in shared data is a higher valuable target
than others. Such information is confidential to the group
and should not be revealed to any third party. However,
no existing mechanism in the literature is able to perform
public auditing on shared data in the cloud while still
preserving identity privacy.
In this paper, we propose Oruta1
, a new privacy-
preserving public auditing mechanism for shared data in
an untrusted cloud. In Oruta, we utilize ring signatures
[4], [5] to construct homomorphic authenticators [2], [6],
so that the third party auditor is able to verify the
integrity of shared data for a group of users without
retrieving the entire data — while the identity of the
signer on each block in shared data is kept private from
the TPA. In addition, we further extend our mechanism
to support batch auditing, which can audit multiple
shared data simultaneously in a single auditing task.
Meanwhile, Oruta continues to use random masking
[3] to support data privacy during public auditing, and
leverage index hash tables [7] to support fully dynamic
operations on shared data. A dynamic operation indi-
cates an insert, delete or update operation on a single
block in shared data. A high-level comparison between
Oruta and existing mechanisms in the literature is shown
in Table 1. To our best knowledge, this paper represents
the first attempt towards designing an effective privacy-
preserving public auditing mechanism for shared data
in the cloud.
TABLE 1
Comparison with Existing Mechanisms
PDP [2] WWRL [3] Oruta
Public auditing Yes Yes Yes
Data privacy No Yes Yes
Identity privacy No No Yes
The remainder of this paper is organized as follows.
In Section 2, we present the system model and threat
model. In Section 3, we introduce cryptographic prim-
itives used in Oruta. The detailed design and security
analysis of Oruta are presented in Section 4 and Section
5. In Section 6, we evaluates the performance of Oruta.
Finally, we briefly discuss related work in Section 7, and
conclude this paper in Section 8.
2 PROBLEM STATEMENT
2.1 System Model
As illustrated in Fig. 2, our work in this paper involves
three parties: the cloud server, the third party auditor
(TPA) and users. There are two types of users in a
group: the original user and a number of group users.
The original user and group users are both members
1. Oruta: One Ring to Rule Them All.
of the group. Group members are allowed to access
and modify shared data created by the original user
based on access control polices [8]. Shared data and its
verification information (i.e. signatures) are both stored
in the cloud server. The third party auditor is able to
verify the integrity of shared data in the cloud server on
behalf of group members.
Users
Cloud Server
Third Party Auditor (TPA)
Shared Data Flow
1.Auditing
R
equest
4.Auditing
R
eport
2. Auditing Message3. Auditing Proof
Fig. 2. Our system model includes the cloud server, the
third party auditor and users.
In this paper, we only consider how to audit the
integrity of shared data in the cloud with static groups.
It means the group is pre-defined before shared data
is created in the cloud and the membership of users
in the group is not changed during data sharing. The
original user is responsible for deciding who is able
to share her data before outsourcing data to the cloud.
Another interesting problem is how to audit the integrity
of shared data in the cloud with dynamic groups — a
new user can be added into the group and an existing
group member can be revoked during data sharing —
while still preserving identity privacy. We will leave this
problem to our future work.
When a user (either the original user or a group user)
wishes to check the integrity of shared data, she first
sends an auditing request to the TPA. After receiving the
auditing request, the TPA generates an auditing message
to the cloud server, and retrieves an auditing proof of
shared data from the cloud server. Then the TPA verifies
the correctness of the auditing proof. Finally, the TPA
sends an auditing report to the user based on the result
of the verification.
2.2 Threat Model
2.2.1 Integrity Threats
Two kinds of threats related to the integrity of shared
data are possible. First, an adversary may try to corrupt
the integrity of shared data and prevent users from
using data correctly. Second, the cloud service provider
may inadvertently corrupt (or even remove) data in
its storage due to hardware failures and human errors.
Making matters worse, in order to avoid jeopardizing its
reputation, the cloud server provider may be reluctant
to inform users about such corruption of data.

WANG et al.: ORUTA: PRIVACY-PRESERVING PUBLIC AUDITING FOR SHARED DATA IN THE CLOUD 3
2.2.2 Privacy Threats
The identity of the signer on each block in shared
data is private and confidential to the group. During
the process of auditing, a semi-trusted TPA, who is only
responsible for auditing the integrity of shared data, may
try to reveal the identity of the signer on each block in
shared data based on verification information. Once the
TPA reveals the identity of the signer on each block, it
can easily distinguish a high-value target (a particular
user in the group or a special block in shared data).
2.3 Design Objectives
To enable the TPA efficiently and securely verify
shared data for a group of users, Oruta should be
designed to achieve following properties: (1) Public Au-
diting: The third party auditor is able to publicly verify
the integrity of shared data for a group of users without
retrieving the entire data. (2) Correctness: The third
party auditor is able to correctly detect whether there is
any corrupted block in shared data. (3) Unforgeability:
Only a user in the group can generate valid verification
information on shared data. (4) Identity Privacy: During
auditing, the TPA cannot distinguish the identity of the
signer on each block in shared data.
3 PRELIMINARIES
In this section, we briefly introduce cryptographic
primitives and their corresponding properties that we
implement in Oruta.
3.1 Bilinear Maps
We first introduce a few concepts and properties re-
lated to bilinear maps. We follow notations from [5], [9]:
1) G1, G2 and GT are three multiplicative cyclic
groups of prime order p;
2) g1 is a generator of G1, and g2 is a generator of G2;
3) ψ is a computable isomorphism from G2 to G1,
with ψ(g2) = g1;
4) e is a bilinear map e: G1 × G2 → GT with the
following properties: Computability: there exists
an efficiently computable algorithm for computing
the map e. Bilinearity: for all u ∈ G1, v ∈ G2 and
a, b ∈ Zp, e(ua
, vb
) = e(u, v)ab
. Non-degeneracy:
e(g1, g2) = 1.
These properties further imply two additional proper-
ties: (1) for any u1, u2 ∈ G1 and v ∈ G2, e(u1 · u2, v) =
e(u1, v) · e(u2, v); (2) for any u, v ∈ G2, e(ψ(u), v) =
e(ψ(v), u).
3.2 Complexity Assumptions
Definition 1: Discrete Logarithm Problem. For a ∈
Zp, given g, h = ga
∈ G1, output a.
The Discrete Logarithm assumption holds in G1 if no
t-time algorithm has advantage at least ǫ in solving the
Discrete Logarithm problem in G1, which means it is
computational infeasible to solve the Discrete Logarithm
problem in G1.
Definition 2: Computational Co-Diffie-Hellman
Problem. For a ∈ Zp, given g2, ga
2 ∈ G2 and h ∈ G1,
compute ha
∈ G1.
The co-CDH assumption holds in G1 and G2 if no t-
time algorithm has advantage at least ǫ in solving the
co-CDH problem in G1 and G2. When G1 = G2 and
g1 = g2, the co-CDH problem can be reduced to the
standard CDH problem in G1. The co-CDH assumption
is a stronger assumption than the Discrete Logarithm
assumption.
Definition 3: Computational Diffie-Hellman Prob-
lem. For a, b ∈ Zp, given g1, ga
1 , gb
1 ∈ G1, compute
gab
1 ∈ G1.
The CDH assumption holds in G1 if no t-time al-
gorithm has advantage at least ǫ in solving the CDH
problem in G1.
3.3 Ring Signatures
The concept of ring signatures is first proposed by
Rivest et al. [4] in 2001. With ring signatures, a verifier
is convinced that a signature is computed using one of
group members’ private keys, but the verifier is not able
to determine which one. This property can be used to
preserve the identity of the signer from a verifier.
The ring signature scheme introduced by Boneh et
al. [5] (referred to as BGLS in this paper) is constructed
on bilinear maps. We will extend this ring signature
scheme to construct our public auditing mechanism.
3.4 Homomorphic Authenticators
Homomorphic authenticators (also called homomor-
phic verifiable tags) are basic tools to construct data
auditing mechanisms [2], [3], [6]. Besides unforgeability
(only a user with a private key can generate valid signa-
tures), a homomorphic authenticable signature scheme,
which denotes a homomorphic authenticator based on
signatures, should also satisfy the following properties:
Let (pk, sk) denote the signer’s public/private key
pair, σ1 denote a signature on block m1 ∈ Zp, σ2 denote
a signature on block m2 ∈ Zp.
• Blockless verification: Given σ1 and σ2, two ran-
dom values α1, α2 ∈ Zp and a block m′
=
α1m1 + α2m2 ∈ Zp, a verifier is able to check the
correctness of block m′
without knowing block m1
and m2.
• Non-malleability Given σ1 and σ2, two random
values α1, α2 ∈ Zp and a block m′
= α1m1 + α2m2 ∈
Zp, a user, who does not have private key sk, is not
able to generate a valid signature σ′
on block m′
by
linearly combining signature σ1 and σ2.
Blockless verification allows a verifier to audit the cor-
rectness of data stored in the cloud server with a single
block, which is a linear combination of all the blocks
in data. If the combined block is correct, the verifier

believes that the blocks in data are all correct. In this way,
the verifier does not need to download all the blocks to
check the integrity of data. Non-malleability indicates
that an attacker cannot generate valid signatures on
invalid blocks by linearly combining existing signatures.
Other cryptographic techniques related to homomor-
phic authenticable signatures includes aggregate sig-
natures [5], homomorphic signatures [10] and batch-
verification signatures [11]. If a signature scheme is
blockless verifiable and malleable, it is a homomorphic
signature scheme. In the construction of data auditing
mechanisms, we should use homomorphic authenticable
signatures, not homomorphic signatures.
4 HOMOMORPHIC AUTHENTICABLE RING
SIGNATURES
4.1 Overview
In this section, we introduce a new ring signature
scheme, which is suitable for public auditing. Then, we
will show how to build the privacy-preserving public
auditing mechanism for shared data in the cloud based
on this new ring signature scheme in the next section.
As we introduced in previous sections, we intend to
utilize ring signatures to hide the identity of the signer
on each block, so that private and sensitive information
of the group is not disclosed to the TPA. However,
traditional ring signatures [4], [5] cannot be directly used
into public auditing mechanisms, because these ring
signature schemes do not support blockless verification.
Without blockless verification, the TPA has to download
the whole data file to verify the correctness of shared
data, which consumes excessive bandwidth and takes
long verification times.
Therefore, we first construct a new homomorphic
authenticable ring signature (HARS) scheme, which is
extended from a classic ring signature scheme [5], de-
noted as BGLS. The ring signatures generated by HARS
is able not only to preserve identity privacy but also to
support blockless verification.
4.2 Construction of HARS
HARS contains three algorithms: KeyGen, RingSign
and RingVerify. In KeyGen, each user in the group
generates her public key and private key. In RingSign, a
user in the group is able to sign a block with her private
key and all the group members’ public keys. A verifier
is allowed to check whether a given block is signed by
a group member in RingVerify.
Scheme Details. Let G1, G2 and GT be multiplicative
cyclic groups of order p, g1 and g2 be generators of G1
and G2 respectively. Let e : G1 × G2 → GT be a bilinear
map, and ψ : G2 → G1 be a computable isomorphism
with ψ(g2) = g1. There is a public map-to-point hash
function H1: {0, 1}∗
→ G1. The global parameters are
(e, ψ, p, G1, G2, GT , g1, g2, H1). The total number of users
in the group is d. Let U denote the group that includes
all the d users.
KeyGen. For a user ui in the group U, she randomly
picks xi ∈ Zp and computes wi = gxi
2 ∈ G2. Then, user
ui’s public key is pki = wi and her private key is ski =
xi.
RingSign. Given all the d users’ public keys
(pk1, ..., pkd) = (w1, ..., wd), a block m ∈ Zp, the iden-
tifier of this block id and the private key sks for some
s, user us randomly chooses ai ∈ Zp for all i = s, where
i ∈ [1, d], and let σi = gai
1 . Then, she computes
β = H1(id)gm
1 ∈ G1, (1)
and sets
σs =
β
ψ( i=s wai
i )
1/xs
∈ G1. (2)
And the ring signature of block m is σσσ = (σ1, ..., σd) ∈
Gd
1.
RingVerify. Given all the d users’ public keys
(pk1, ..., pkd) = (w1, ..., wd), a block m, an identifier id
and a ring signature σσσ = (σ1, ..., σd), a verifier first
computes β = H1(id)gm
1 ∈ G1, and then checks
e(β, g2)
?
=
d
i=1
e(σi, wi). (3)
If the above equation holds, then the given block m is
signed by one of these d users in the group. Otherwise,
it is not.
4.3 Security Analysis of HARS
Now, we discuss some important properties of HARS,
including correctness, unforgeability, blockless verifica-
tion, non-malleability and identity privacy.
Theorem 1: Given any block and its ring signature, a
verifier is able to correctly check the integrity of this block
under HARS.
Proof: To prove the correctness of HARS is equiva-
lent of proving Equation (3) is correct. Based on prop-
erties of bilinear maps, the correctness of this equation
can be proved as follows:
d
i=1
e(σi, wi) = e(σs, ws) ·
i=s
e(σi, wi)
= e(
β
ψ( i=s wai
i )
1
xs
, gxs
2 ) ·
i=s
e(gai
1 , gxi
2 )
= e(
β
ψ( i=s gxiai
2 )
, g2) ·
i=s
e(gaixi
1 , g2)
= e(
β
i=s g1
aixi
, g2) · e(
i=s
gaixi
1 , g2)
= e(
β
i=s g1
aixi
·
i=s
g1
aixi
, g2)
= e(β, g2).

Now we prove that HARS is able to resistance to
forgery. We follow the security model and the game
defined in BGLS [5]. In the game, an adversary is given
all the d users’ public key (pk1, ..., pkd) = (w1, ..., wd),
and is given access to the hash oracle and the ring-
signing oracle. The goal of the adversary is to output a
valid ring signature on a pair of block/identifier (id, m),
where this pair of block/identifier (id, m) has never been
presented to the ring-signing oracle. If the adversary
achieves this goal, then it wins the game.
Theorem 2: Suppose A is a (t′
, ǫ′
)-algorithm that can
generate a forgery of a ring signature on a group of users of
size d. Then there exists a (t, ǫ)-algorithm that can solve the
co-CDH problem with t ≤ 2t′
+2cG1
(qH +dqs+qs+d)+2cG2
d
and ǫ ≥ (ǫ′
/(e + eqs))2
, where A issues at most qH hash
queries and at most qs ring-signing queries, e = limqs→∞(1+
1/qs)qs
, exponentiation and inversion on G1 take time cG1
,
and exponentiation and inversion on G2 take time cG2
.
Proof: The co-CDH problem can be solved by solving
two random instances of the following problem: Given
gab
1 , ga
2 (and g1,g2), compute gb
1. We shall construct an
algorithm B that solves this problem. This problem is
easy if a = 0. In what follows, we assume a = 0.
Initially, B randomly picks x2, ..., xn from Zp and sets
x1 = 1. Then, it sets pki = wi = (ga
2 )xi
. Algorithm
A is given the public keys (pk1, ..., pkd) = (w1, ..., wd).
Without loss of generality, we assume A can submit
distinct queries, which means for every ring-signing
query on a block m and its identifier id, A has previously
issued a hash query on block m and identifier id.
On a hash query, B flips a coin that shows 0 with prob-
ability pc and 1 otherwise, where pc will be determined
later. Then B randomly picks r ∈ Zp, if the coin shows
0, B returns (gab
1 )r
, otherwise it returns ψ(ga
2 )r
.
Suppose A issues a ring sign query on a block m and
its identifier id. By the assumption, a hash query has
been issued on this pair of block/identifier (m, id). If the
coin B flipped for this hash query showed 0, then B fails
and exits. Otherwise B has returned H(id)gm
1 = ψ(ga
2 )r
for some r. In this case, B chooses random a2, ..., ad ∈ Zp,
computes a1 = r − (a2x2 + ... + adxd), and returns the
signature σσσ = (ga1
1 , ..., gad
1 ).
Eventually A outputs a forgery σσσ = (σ1, ..., σd)
on block m and identifier id. Again by the assump-
tion, a hash query has been issued on this pair of
block/identifier (m, id). If the coin flipped by B for this
hash query did not show 0 then B fails. Otherwise,
H(id)gm
1 = gabr
1 for some r chosen by B, and B can
output gb
1 by computing (
d
i=1 σxi
i )1/r
.
Algorithm A cannot distinguish between B’s sim-
ulation and real life. If A successfully forges a ring
signature, then B can output gb
1. The probability that
B will not fail is pqs
c (1 − p), which is maximized when
pc = qs/(qs + 1), then the bound of this probability is
1/(e·(1 + qs)), where e = limqs→∞(1 + 1/qs)qs
. Algorithm
B requires d exponentiations on G2 in setup, one expo-
nentiations on G1 for each of A’s hash queries, d + 1
exponentiations on G1 for each of A’s signature queries,
and d exponentiations on G1 in the output phase, so
the running time of B is the running time of A plus
cG1
(qH + dqs + qs + d) + cG2
d.
Because the co-CDH problem can be solved by solving
two random instances of algorithm B. Therefore, if A is
a (t′
, ǫ′
)-algorithm that can generate a forgery of ring
signature on a group of users of size d, then there exists
a (t, ǫ)-algorithm that can solve the co-CDH problem
with t ≤ 2t′
+ 2cG1
(qH + dqs + qs + d) + 2cG2
d and
ǫ ≥ (ǫ′
/(e + eqs))2
.
Theorem 3: For an adversary, it is computational infeasi-
ble to forge a ring signature under HARS.
Proof: As we already proved in Theorem 2, if an
adversary can forge a ring signature, then we can find a
(t, ǫ)-algorithm to solve the co-CDH problem in G1 and
G2, which contradicts to the fact that the co-CDH prob-
lem in G1 and G2 is hard. Therefore, for an adversary,
it is computational infeasible to forge a ring signature
under HARS.
Then, based on Theorem 1 and 3, we show that HARS
is a homomorphic authenticable ring signature scheme.
Theorem 4: HARS is a homomorphic authenticable ring
signature scheme.
Proof: To prove HARS is a homomorphic authenti-
cable ring signature scheme, we first prove that HARS is
able to support blockless verification, which we defined
in Section 3. Then we show HARS is also non-malleable.
Given all the d users’ public keys (pk1, ..., pkd) =
(w1, ..., wd), two identifiers id1 and id2, two ring signa-
tures σσσ1 = (σ1,1, ..., σ1,d) and σσσ2 = (σ2,1, ..., σ2,d), and two
random values y1, y2 ∈ Zp, a verifier is able to check the
correctness of a combined block m′
= y1m1 + y2m2 ∈ Zp
without knowing block m1 and m2 by verifying:
e(H1(id1)y1
H1(id2)y2
gm′
1 , g2)
?
=
d
i=1
e(σy1
1,i · σy2
2,i, wi).
Based on Theorem 1, the correctness of the above
equation can be proved as:
e(H1(id1)y1
H1(id2)y2
gm′
1 , g2)
= e(H1(id1)y1
gy1m1
1 , g2) · e(H1(id2)y2
gy2m2
1 , g2)
= e(β1, g2)y1
· e(β2, g2)y2
=
d
i=1
e(σ1,i, wi)y1
·
d
i=1
e(σ2,i, wi)y2
=
d
i=1
e(σy1
1,i · σy2
2,i, wi).
If the combined block m′
is correct, the verifier also be-
lieves that block m1 and m2 are both correct. Therefore,
HARS is able to support blockless verification.
Meanwhile, an adversary, who does not have any
user’s private key, cannot generate a valid ring signature
σσσ′
on an invalid block m′
by linearly combining σσσ1 and
σσσ2 with y1 and y2. Because if an element σ′
i in σσσ′
is
computed as σ′
i = σy1
1,i · σy2
2,i, the whole ring signature
σσσ′
= (σ′
1, ..., σ′
d) cannot pass Equation (3) in RingVerify.

More specifically, if block m1 and m2 are signed by the
same user, for example, user us, then σ′
s can be computed
as
σ′
s = σy1
1,s · σy2
2,s =
βy1
1 βy2
2
i=s w
y1a1,i
1,i ·w
y2a2,i
2,i
1/xs
.
For all i = s, σ′
i = σy1
1,i · σy2
2,i = g
(y1a1,i+y2a2,i)
1 , where a1,i
and a2,i are random values. When ring signature σσσ′
=
(σ′
1, ..., σ′
d) is verified with the invalid block m′
using
Equation (3):
d
i=1
e(σ′
i, wi) = e(βy1
1 βy2
2 , g2) = e(β′
, g2),
which means it always fails to pass the verification.
Because βy1
1 βy2
2 = H(id1)y1
H(id2)y2
gm′
1 is not equal to
β′
= H(id′
)gm′
1 .
If block m1 and m2 are signed by different users, for
example, user us and user ut, then σ′
s and σ′
t can be
presented as
σ′
s =
βy1
1
i=s w
y1a1,i
i
1/xs
· g
y2a2,s
1 ,
σ′
t = g
y1a1,t
1 ·
βy2
2
i=t w
y2a2,i
i
1/xt
.
For all i = s and i = t, σ′
i = σy1
1,i · σy2
2,i = g
(y1a1,i+y2a2,i)
1 ,
where a1,i and a2,i are random values. When ring sig-
nature σσσ′
= (σ′
1, ..., σ′
d) is verified with the invalid block
m′
using Equation (3):
d
i=1
e(σ′
i, wi) = e(βy1
1 βy2
2 , g2) = e(β′
, g2),
which means it always fails to pass the verification.
Therefore, an adversary cannot output valid ring signa-
tures on invalid blocks by linearly combining existing
signatures, which indicates that HARS is non-malleable.
Because HARS is not only blockless verifiable and but
also non-malleable, it is a homomorphic authenticable
signature scheme.
Now, following the theorem in [5], we show that
a verifier cannot distinguish the identity of the signer
among a group of users under HARS.
Theorem 5: For any algorithm A, any group U with d
users, and a random user us ∈ U, the probability Pr[A(σσσ) =
us] is at most 1/d under HARS, where σσσ is a ring signature
generated with user us’s private key sks.
Proof: For any h ∈ G1, and any s, 1 ≤ s ≤ d, the
distribution {ga1
1 , ..., gad
1 : ai
R
← Zp for i = s, as chosen
such that
d
i=1 gai
1 = h} is identical to the distribution
{ga1
1 , ..., gad
1 :
d
i=1 gai
1 = h}. Therefore, given σσσ =
(σ1, ..., σd), the probability algorithm A distinguishes σs,
which indicates the identity of the signer, is at most 1/d.
Details of the proof about identity privacy can be found
in [5].
5 PRIVACY-PRESERVING PUBLIC AUDITING
FOR SHARED DATA IN THE CLOUD
5.1 Overview
Using HARS and its properties we established in the
previous section, we now construct Oruta, our privacy-
preserving public auditing mechanism for shared data in
the cloud. With Oruta, the TPA can verify the integrity
of shared data for a group of users without retrieving
the entire data. Meanwhile, the identity of the signer on
each block in shared data is kept private from the TPA
during the auditing.
5.2 Reduce Signature Storage
Another important issue we should consider in the
construction of Oruta is the size of storage used for
ring signatures. According to the generation of ring
signatures in HARS, a block m is an element of Zp
and its ring signature contains d elements of G1, where
G1 is a cyclic group with order p. It means a |p|-bit
block requires a d × |p|-bit ring signature, which forces
users to spend a huge amount of space on storing ring
signatures. It is very frustrating for users, because cloud
service providers, such as Amazon, will charge users
based on the storage space they used. To reduce the
storage for ring signatures and still allow the TPA to
audit shared data efficiently, we exploit an aggregated
approach from [6]. Specifically, we aggregate a block
mmmj = (mj,1, ..., mj,k) ∈ Zk
p in shared data as
k
l=1 ηmj,l
instead of computing gm
1 in Equation (1), where η1, ..., ηk
are random values of G1. With the aggregation, the
length of a ring signature is only d/k of the length of
a block. Similar methods to reduce the storage space of
signatures can also be found in [7]. Generally, to obtain
a smaller size of a ring signature than the size of a block,
we choose k > d. As a trade-off, the communication cost
will be increasing with an increase of k.
5.3 Support Dynamic Operations
To enable each user in the group to easily modify
data in the cloud and share the latest version of data
with the rest of the group, Oruta should also support
dynamic operations on shared data. An dynamic opera-
tion includes an insert, delete or update operation on a
single block. However, since the computation of a ring
signature includes an identifier of a block (as presented
in HARS), traditional methods, which only use the index
of a block as its identifier, are not suitable for supporting
dynamic operations on shared data. The reason is that,
when a user modifies a single block in shared data by
performing an insert or delete operation, the indices of
blocks that after the modified block are all changed (as
shown in Figure 3 and 4), and the changes of these
indices require users to re-compute the signatures of
these blocks, even though the content of these blocks
are not modified.

Index Block
1 mmm1
2 mmm2
3 mmm3
...
...
n mmmn
Insert
Index Block
1 mmm1
2 mmm′
2
3 mmm2
4 mmm3
...
...
n + 1 mmmn
Fig. 3. After inserting block mmm′
2, all the indices after block
mmm′
2 are changed
Index Block
1 mmm1
2 mmm2
3 mmm3
4 mmm4
...
...
n mmmn
Delete
Index Block
1 mmm1
2 mmm3
3 mmm4
...
...
n − 1 mmmn
Fig. 4. After deleting block mmm2, all the indices after block
mmm1 are changed
By utilizing index hash tables [7], our mechanism can
allow a user to efficiently perform a dynamic operation
on a single block, and avoid this type of re-computation
on other blocks. Different from [7], in our mechanism, an
identifier from the index hash table is described as idj =
{vj, rj}, where vj is the virtual index of block mmmj, and
rj is a random generated by a collision-resistance hash
function H2 : {0, 1}∗
→ Zq with rj = H2(mmmj||vj). Here, q
is a much smaller prime than p. The collision-resistance
of H2 ensures that each block has a unique identifier. The
virtual indices are able to ensure that all the blocks in
shared data are in the right order. For example, if vi < vj,
then block mmmi is ahead of block mmmj in shared data. When
shared data is created by the original user, the initial
virtual index of block mmmj is computed as vj = j·δ, where
δ is a system parameter decided by the original user.
If a new block mmm′
j is inserted, the virtual index of this
new block mmm′
j is v′
j = (vj−1 + vj)/2. Clearly, if block
mmmj and block mmmj+1 are both originally created by the
original user, the maximal number of inserted blocks that
is allowed between block mmmj and block mmmj+1 is δ. The
original user can estimate and choose a proper value of δ
based on the original size of shared data, the number of
users in the group, the subject of content in shared data
and so on, Generally, we believe δ = 10, 000 or 100, 000 is
good enough for the maximal insert blocks between two
blocks, which are originally created by the original user.
Examples of different dynamic operations on shared data
with index hash tables are described in Figure 5 and 6.
5.4 Construction of Oruta
Now, we present the details of our public auditing
mechanism, Oruta. It includes five algorithms: KeyGen,
SigGen, Modify, ProofGen and ProofVerify. In Key-
Gen, users generate their own public/private key pairs.
Insert
Index Block V R
1 mmm1 δ r1
2 mmm′
2 3δ/2 r′
2
3 mmm2 2δ r2
4 mmm3 3δ r3
...
...
...
...
n + 1 mmmn nδ rn
Index Block V R
1 mmm1 δ r1
2 mmm2 2δ r2
3 mmm3 3δ r3
...
...
...
...
n mmmn nδ rn
Fig. 5. Insert block mmm′
2 into shared data using an index
hash table as identifiers.
Update
Index Block V R
1 mmm′
1 δ r′
1
2 mmm2 2δ r2
3 mmm4 4δ r4
4 mmm5 5δ r5
...
...
...
...
n − 1 mmmn nδ rn
Index Block V R
1 mmm1 δ r1
2 mmm2 2δ r2
3 mmm3 3δ r3
4 mmm4 4δ r4
5 mmm5 5δ r5
...
...
...
...
n mmmn nδ rn
Delete
Fig. 6. Update block mmm1 and delete block mmm3 in shared
data using an index hash table as identifiers.
In SigGen, a user (either the original user or a group
user) is able to compute ring signatures on blocks in
shared data. Each user in the group is able to perform
an insert, delete or update operation on a block, and
compute the new ring signature on this new block in
Modify. ProofGen is operated by the TPA and the cloud
server together to generate a proof of possession of
shared data. In ProofVerify, the TPA verifies the proof
and sends an auditing report to the user.
Note that the group is pre-defined before shared data
is created in the cloud and the membership of the group
is not changed during data sharing. Before the original
user outsources shared data to the cloud, she decides all
the group members, and computes all the initial ring
signatures of all the blocks in shared data with her
private key and all the group members’ public keys.
After shared data is stored in the cloud, when a group
member modifies a block in shared data, this group
member also needs to compute a new ring signature on
the modified block.
Scheme Details. Let G1, G2 and GT be multiplicative
cyclic groups of order p, g1 and g2 be generators of
groups G1, G2, respectively. Let e : G1 × G2 → GT
be a bilinear map, and ψ : G2 → G1 be a com-
putable isomorphism with ψ(g2) = g1. There are three
hash functions H1: {0, 1}∗
→ G1, H2 : {0, 1}∗
→
Zq and h : G1 → Zp. The global parameters are
(e, ψ, p, q, G1, G2, GT , g1, g2, H1, H2, h). The total number
of users in the group is d. Let U denote the group that
includes all the d users.
Shared data M is divided into n blocks, and each block
mmmj is further divided into k elements in Zp. Therefore,

shared data M can be described as a n × k matrix:
M =



mmm1
...
mmmn


 =



m1,1 . . . m1,k
...
...
...
mn,1 . . . mn,k


 ∈ Zn×k
p .
KeyGen. For user ui in the group U, she randomly
picks xi ∈ Zp and computes wi = gxi
2 . The user ui’s
public key is pki = wi and her private key is ski =
xi. The original user also randomly generates a public
aggregate key pak = (η1, ..., ηk), where ηl are random
elements of G1.
SigGen. Given all the d group members’ public keys
(pk1, ..., pkd) = (w1, ..., wd), a block mmmj = (mj,1, ..., mj,k),
its identifier idj, a private key sks for some s, user us
computes the ring signature of this block as follows:
1) She first aggregates block mmmj with the public ag-
gregate key pak, and computes
βj = H1(idj)
k
l=1
η
mj,l
l ∈ G1. (4)
2) After computing βj, user us randomly chooses
aj,i ∈ Zp and sets σj,i = g
aj,i
1 , for all i = s. Then
she calculates
σj,s =
βj
ψ( i=s w
aj,i
i )
1/xs
∈ G1. (5)
The ring signature of block mmmj is σσσj =
(σj,1, ..., σj,d) ∈ Gd
1.
Modify. A user in the group modifies the j-th block
in shared data by performing one of the following three
operations:
• Insert. This user inserts a new block mmm′
j into shared
data. She computes the new identifier of the in-
serted block mmm′
j as id′
j = {v′
j, r′
j}. The virtual index
v′
j = (vj−1 + vj)/2, and r′
j = H2(mmm′
j||v′
j). For the
rest of blocks, the identifiers of these blocks are
not changed (as explained in Figure 5). This user
outputs the new ring signature σσσ′
j of the inserted
block mmm′
j with SigGen, and uploads {mmm′
j, id′
j,σσσ′
j}
to the cloud server. The total number of blocks in
shared data increases to n + 1.
• Delete. This user deletes block mmmj, its identifier idj
and ring signature σσσ′
j from the cloud server. The
identifiers of other blocks in shared data are remain
the same. The total number of blocks in shared data
decreases to n − 1.
• Update. This user updates the j-th block in shared
data with a new block mmm′
j. The virtual index of this
block is remain the same, and r′
j is computed as
r′
j = H2(mmm′
j||vj). The new identifier of this updated
block is id′
j = {vj, r′
j}. The identifiers of other
blocks in shared data are not changed. This user
outputs the new ring signature σσσ′
j of this new block
with SigGen, and uploads {mmm′
j, id′
j,σσσ′
j} to the cloud
server. The total number of blocks in shared data is
still n.
ProofGen. To audit the integrity of shared data, a
user first sends an auditing request to the TPA. After
receiving an auditing request, the TPA generates an
auditing message [2] as follows:
1) The TPA randomly picks a c-element subset J of
set [1, n] to locate the c selected blocks that will be
checked in this auditing process, where n is total
number of blocks in shared data.
2) For j ∈ J , the TPA generates a random value yj ∈
Zq.
Then, the TPA sends an auditing message {(j, yj)}j∈J to
the cloud server (as illustrated in Fig. 7).
Third Party Auditor Cloud Server
{(j, yj)}j∈J
Fig. 7. The TPA sends an auditing message to the cloud
server.
After receiving an auditing message {(j, yj)}j∈J , the
cloud server generates a proof of possession of selected
blocks with the public aggregate key pak. More specifi-
cally:
1) The cloud server chooses a random element rl ∈
Zq, and calculates λl = ηrl
l ∈ G1, for l ∈ [1, k].
2) To hide the linear combination of selected blocks
using random masking, the cloud server computes
µl = j∈J yjmj,l + rlh(λl) ∈ Zp, for l ∈ [1, k].
3) The cloud server aggregates signatures as φi =
j∈J σ
yj
j,i, for i ∈ [1, d].
After the computation, the cloud server sends an au-
diting proof {λλλ,µµµ,φφφ, {idj}j∈J } to the TPA, where λλλ =
(λ1, ..., λk), µµµ = (µ1, ..., µk) and φφφ = (φ1, ..., φd) (as shown
in Fig. 8).
Third Party Auditor Cloud Server
{λλλ,µµµ,φφφ, {idj}j∈J }
Fig. 8. The cloud server sends an auditing proof to the
TPA.
ProofVerify. With an auditing proof {λλλ,µµµ,φφφ, {idj}j∈J
}, an auditing message {(j, yj)}j∈J , public aggregate
key pak = (η1, ..., ηk), and all the group members’
public keys (pk1, ..., pkd) = (w1, ..., wd), the TPA verifies
the correctness of this proof by checking the following

equation:
e(
j∈J
H1(idj)yj
·
k
l=1
ηµl
l , g2)
?
=
d
i=1
e(φi, wi) · e(
k
l=1
λ
h(λl)
l , g2). (6)
If the above equation holds, then the TPA believes that
the blocks in shared data are all correct, and sends a
positive auditing report to the user. Otherwise, it sends
a negative one.
Discussion. Based on the properties of bilinear maps,
we can further improve the efficiency of verification by
computing d+2 pairing operations in verification instead
of computing d+3 pairing operations with Equation (6).
Specifically, Equation (6) can also be described as
e(
j∈J
H1(idj)yj
·
k
l=1
ηµl
l · (
k
l=1
λ
h(λl)
l )−1
, g2)
?
=
d
i=1
e(φi, wi).
(7)
In the construction of Oruta, we leverage random
masking [3] to support identity privacy. If a user wants
to protect the content of private data in the cloud, this
user can also encrypt data before outsourcing it into
the cloud server with encryption techniques, such as
attribute-based encryption (ABE) [8], [12]. With sampling
strategies [2], the TPA can detect any corrupted block in
shared data with a high probability by only choosing a
subset of all blocks in each auditing task. Previous work
[2] has already proved that, if the total number of blocks
in shared data is n = 1, 000, 000 and 1% of all the blocks
are lost or removed, the TPA can detect these corrupted
blocks with a probability greater than 99% by choosing
460 random blocks.
5.5 Security Analysis of Oruta
Now, we discuss security properties of Oruta, includ-
ing its correctness, unforgeability, identity privacy and
data privacy.
Theorem 6: During an auditing task, the TPA is able to
correctly audit the integrity of shared data under Oruta.
Proof: To prove the correctness of Oruta is equivalent
of proving Equation (6) is correct. Based on properties of
bilinear maps and Theorem 1, the right-hand side (RHS)
of Equation (6) can be expanded as follows:
RHS =


d
i=1
e(
j∈J
σ
yj
j,i, wi)

 · e(
k
l=1
λ
h(λl)
l , g2)
=


d
i=1
(
j∈J
e(σ
yj
j,i, wi))

 · e(
k
l=1
η
rlh(λl)
l , g2)
=


j∈J
(
d
i=1
e(σj,i, wi)yj
)

 · e(
k
l=1
η
rlh(λl)
l , g2)
=


j∈J
e(βj, g2)yj

 · e(
k
l=1
η
rlh(λl)
l , g2)
= e(
j∈J
(H1(idj)
k
l=1
η
mj,l
l )yj
, g2) · e(
k
l=1
η
rlh(λl)
l , g2)
= e(
j∈J
H1(idj)yj
·
k
l=1
η j∈J mj,lyj
l ·
k
l=1
η
rlh(λl)
l , g2)
= e(
j∈J
H1(idj)yj
·
k
l=1
η j∈J mj,lyj +rlh(λl)
l , g2)
= e(
j∈J
H1(idj)yj
·
k
l=1
ηµl
l , g2).
Theorem 7: For an untrusted cloud, it is computational
infeasible to generate an invalid auditing proof that can pass
the verification under Oruta.
Proof: As proved in Theorem ??, for an untrusted
cloud, if co-CDH problem in G1 and G2 is hard, it is
computational infeasible to compute a valid ring signa-
ture on an invalid block under HARS.
In Oruta, besides generating valid ring signatures on
arbitrary blocks, if the untrusted cloud can win Game 1,
it can generate an invalid auditing proof for corrupted
shared data, and successfully pass the verification. We
define Game 1 as follows:
Game 1: The TPA sends an auditing message
{j, yj}j∈J to the cloud, the correct auditing proof should
be {λλλ,µµµ,φφφ, {idj}j∈J }, which can pass the verification
with Equation (6). The untrusted cloud generates an in-
valid proof as {λλλ,µµµ′
,φφφ, {idj}j∈J }, where µµµ′
= (µ′
1, ..., µ′
k).
Define ∆µl = µ′
l − µl for 1 ≤ l ≤ k, and at least one
element of {∆µl}1≤l≤k is nonzero. If this invalid proof
still pass the verification, then the untrusted cloud wins.
Otherwise, it fails.
Now, we prove that, if the untrusted cloud can win
Game 1, we can find a solution to the Discrete Logarithm
problem, which contradicts to the fact. We first assume
the untrusted cloud can win Game 1. Then, according to
Equation (6), we have
e(
j∈J
H1(idj)yj
·
k
l=1
η
µ′
l
l , g2) = (
d
i=1
e(φi, wi))e(
k
l=1
λ
h(λl)
l , g2).

Because {λλλ,µµµ,φφφ, {idj}j∈J } is a correct auditing proof, we
also have
e(
j∈J
H1(idj)yj
·
k
l=1
ηµl
l , g2) = (
d
i=1
e(φi, wi))e(
k
l=1
λ
h(λl)
l , g2).
Then, we can learn that
k
l=1
η
µ′
l
l =
k
l=1
ηµl
l ,
k
l=1
η∆µl
l = 1.
For two elements g, h ∈ G1, there exists x ∈ Zp that
g = hx
because G1 is a cyclic group. Without loss of
generality, given g, h ∈ G1, each ηl is able to randomly
and correctly generated by computing ηl = gξl
hγl
∈ G1,
where ξl and γl are random values of Zp. Then, we have
1 =
k
l=1
η∆µl
l =
k
l=1
(gξl
hγl
)∆µl
= g
k
l=1 ξl∆µl
·h
k
l=1 γl∆µl
.
Clearly, we can find a solution to the discrete logarithm
problem. More specifically, given g, hx
∈ G1, we can
compute
h = g
k
l=1 ξl∆µl
k
l=1
γl∆µl = gx
.
unless the denominator is zero. However, as we defined
in Game 1, at least one element of {∆µl}1≤l≤k is nonzero,
and γl is random element of Zp, therefore, the denomi-
nator is zero with probability of 1/p, which is negligible.
It means, if the untrusted cloud wins Game 1, we can
find a solution to the Discrete Logarithm problem with
a probability of 1 − 1/p, which contradicts the fact that
the Discrete Logarithm problem is hard in G1.
Therefore, for an untrusted cloud, it is computational
infeasible to win Game 1 and generate an invalid proof,
which can pass the verification.
Now, we show that the TPA is able to audit the
integrity of shared data, but the identity of the signer
on each block in shared data is not disclosed to the TPA.
Theorem 8: During an auditing task, the probability for
the TPA to distinguish the identities of all the signers on the
c selected blocks in shared data is at most 1/dc
.
Proof: With Theorem 5, we have, for any algorithm
A, the probability to reveal the signer on one block
in shared data is 1/d. Because the c selected blocks
in an auditing task are signed independently, the total
probability that the TPA can distinguish all the signers’
identities on the c selected blocks in shared data is at
most 1/dc
.
Let us reconsider the example in Sec. 1. With Oruta,
the TPA knows each block in shared data is either signed
by Alice or Bob, because it needs both users’ public
keys to verify the correctness of shared data. However,
it cannot distinguish who is the signer on a single block
(as shown in Fig. 9). Therefore, this third party cannot
obtain private and sensitive information, such as who
signs the most blocks in shared data or which block is
frequently modified by different group members.
a block signed by a user in the group
N N N N N N N N N N
N
N N N N N N N N N N
N N N N N N N N N N
8th
8th
8th
Auditing Task 1
Auditing Task 2
Auditing Task 3
TPA
Fig. 9. Alice and Bob share a file in the cloud, and the
TPA audit the integrity of shared data with Oruta.
Following a similar theorem in [3], we show that our
scheme is also able to support data privacy.
Theorem 9: Given an auditing proof = {λλλ,µµµ,φφφ, {idj}jJ
}, it is computational infeasible for the TPA to reveal any
private data in shared data under Oruta.
Proof: If the combined element j∈J yjmj,l, which
is a linear combination of elements in blocks, is directly
sent to the TPA, the TPA can learn the content of data
by solving linear equations after collecting a sufficient
number of linear combinations. To preserve private data
from the TPA, the combined element is computed with
random masking as µl = j∈J yjmj,l +rlh(λl). In order
to still solve linear equations, the TPA must know the
value of rl ∈ Zp. However, given ηl ∈ G1 λl = ηrl
l ∈ G1,
computing rl is as hard as solving the Discrete Loga-
rithm problem in G1, which is computational infeasible.
Therefore, give λλλ and µµµ, the TPA cannot directly obtain
any linear combination of elements in blocks, and cannot
further reveal any private data in shared data M by
solving linear equations.
5.6 Batch Auditing
With the usage of public auditing in the cloud, the TPA
may receive amount of auditing requests from different
users in a very short time. Unfortunately, allowing the
TPA to verify the integrity of shared data for these users
in several separate auditing tasks would be very ineffi-
cient. Therefore, with the properties of bilinear maps, we
further extend Oruta to support batch auditing, which
can improve the efficiency of verification on multiple
auditing tasks.
More concretely, we assume there are B auditing tasks
need to be operated, the shared data in all the B auditing
tasks are denoted as M1, ..., MB and the number of users
sharing data Mb is described as db, where 1 ≤ b ≤ B. To
efficiently audit these shared data for different users in a
single auditing task, the TPA sends an auditing message
as {(j, yj)}j∈J to the cloud server. After receiving the
auditing message, the cloud server generates an auditing
proof {λλλb,µµµb,φφφb, {idb,j}j∈J } for each shared data Mb as
we presented in ProofGen, where 1 ≤ b ≤ B, 1 ≤ l ≤ k,

1 ≤ i ≤ db and



λb,l = η
rb,l
b,l
µb,l = j∈J yjmb,j,l + rb,lh(λb,l)
φb,i = j∈J σ
yj
b,j,i
Here idb,j is described as idb,j = {fb, vj, rj}, where fb is
the identifier of shared data Mb, e.g. the name of shared
data Mb. Clearly, if two blocks are in the same shared
data, these two blocks have the same identifier of shared
data. As before, when a user modifies a single block in
shared data Mb, the identifiers of other blocks in shared
data Mb are not changed.
After the computation, the cloud server sends all the
B auditing proofs together to the TPA. Finally, the TPA
verifies the correctness of these B proofs simultaneously
by checking the following equation with all the
B
b=1 db
users’ public keys:
e(
B
b=1


j∈J
H(idb,j)yj
·
k
l=1
η
µb,l
b,l

 , g2)
?
=
B
b=1
db
i=1
e(φb,i, wb,i) · e(
B
b=1
k
l=1
λ
h(λb,l)
b,l , g2), (8)
where pkb,i = wb,i. If the above verification equation
holds, then the TPA believes that the integrity of all the
B shared data is correct. Otherwise, there is at least one
shared data is corrupted.
Based on the correctness of Equation (6), the correct-
ness of batch auditing can be presented as follows:
B
b=1
db
i=1
e(φb,i, wb,i) · e(
B
b=1
k
l=1
λ
h(λb,l)
b,l , g2)
=
B
b=1
db
i=1
e(φb,i, wb,i) ·
B
b=1
e(
k
l=1
λ
h(λb,l)
b,l , g2)
=
B
b=1
(
db
i=1
e(φb,i, wb,i)) · e(
k
l=1
λ
h(λb,l)
b,l , g2)
=
B
b=1
e(
j∈J
H(idb,j)yj
·
k
l=1
η
µb,l
b,l , g2)
= e(
B
b=1


j∈J
H(idb,j)yj
·
k
l=1
η
µb,l
b,l

 , g2).
If all the B auditing requests on B shared data are
from the same group, the TPA can further improve the
efficiency of batch auditing by verifying
e(
B
b=1


j∈J
H(idb,j)yj
·
k
l=1
η
µb,l
b,l

 , g2)
?
=
d
i=1
e(
B
b=1
φb,i, wi) · e(
B
b=1
k
l=1
λ
h(λb,l)
b,l , g2). (9)
Note that batch auditing will fail if at least one
incorrect auditing proof exists in all the B auditing
proofs. To allow most of auditing proofs to still pass
the verification when there is only a small number of
incorrect auditing proofs, we can utilize binary search
[3] during batch auditing. More specifically, once the
batch auditing of the B auditing proofs fails, the TPA
divides the set of all the B auditing proofs into two
subsets, which contains B/2 auditing proofs in each
subset, and re-checks the correctness of auditing proofs
in each subset using batch auditing. If the verification
result of one subset is correct, then all the auditing proofs
in this subset are all correct. Otherwise, this subset is
further divided into two sub-subsets, and the TPA re-
checks the correctness of auditing proofs in the each
sub-subsets with batch auditing until all the incorrect
auditing proofs are found. Clearly, when the number
of incorrect auditing proofs increases, the efficiency of
batch auditing will be reduced. Experimental results in
Section 6 shows that, when less than 12% of auditing
proofs among all the B auditing proofs are incorrect,
batching auditing is still more efficient than verifying
these auditing proofs one by one.
6 PERFORMANCE
In this section, we first analysis the computation and
communication costs of Oruta, and then evaluate the
performance of Oruta in experiments.
6.1 Computation Cost
The main cryptographic operations used in Oruta in-
clude multiplications, exponentiations, pairing and hash-
ing operations. For simplicity, we omit additions in the
following discussion, because they are much easier to be
computed than the four types of operations mentioned
above.
During auditing, the TPA first generates some random
values to construct the auditing message, which only in-
troduces a small cost in computation. Then, after receiv-
ing the auditing message, the cloud server needs to com-
pute a proof {λλλ,µµµ,φφφ, {idj}j∈J }. The computation cost of
calculating a proof is about (k + dc)ExpG1
+ dcMulG1
+
ckMulZp
+ kHashZp
, where ExpG1
denotes the cost of
computing one exponentiation in G1, MulG1
denotes
the cost of computing one multiplication in G1, MulZp
and HashZp
respectively denote the cost of computing
one multiplcation and one hashing operation in Zp. To
check the correctness of the proof {λλλ,µµµ,φφφ, {idj}j∈J }, the
TPA verifies it based on Equation (6). The total cost of
verifying the proof is (2k + c)ExpG1
+ (2k + c)MulG1
+
dMulGT
+ cHashG1
+ (d + 2)PairG1,G2
. We use PairG1,G2
to denote the cost of computing one pairing operation
in G1 and G2.
6.2 Communication Cost
The communication cost of Oruta is mainly intro-
duced by two factors: the auditing message and the
auditing proof. For each auditing message {j, yj}j∈J , the

0 5 10 15 20
d: the size of the group
0
20
40
60
80
100Generationtime(ms) k=100
k=200
Fig. 10. Impact of d on signature
generation time (ms).
0 50 100 150 200
k: the number of elements per block
0
10
20
30
40
50
60
70
80
Generationtime(ms)
d=10
d=20
Fig. 11. Impact of k on signature
generation time (ms).
0 5 10 15 20
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
Auditingtime(s)
c=460
c=300
Fig. 12. Impact of d on auditing
time (s), where k = 100.
0 50 100 150 200
0.0
0.5
1.0
1.5
2.0
2.5
3.0
Auditingtime(s)
c=460
c=300
Fig. 13. Impact of k on auditing
time (s), where d = 10.
0 5 10 15 20
0
2
4
6
8
10
12
14
Communicationcost(KB)
c=460
c=300
Fig. 14. Impact of d on communi-
cation cost (KB), where k = 100.
0 20 40 60 80 100
0
2
4
6
8
10
12
14
Communicationcost(KB)
c=460
c=300
Fig. 15. Impact of k on communi-
cation cost (KB), where d = 10.
0 20 40 60 80 100
B: the number of audting tasks
1150
1175
1200
1225
1250
1275
1300
1325
Averageauditingtime(ms)
Seperate Auditing
Batch Auditing-D
Batch Auditing-S
Fig. 16. Impact of B on the ef-
ficiency of batch auditing, where
k = 100 and d = 10.
0 2 4 6 8 10 12 14 16
A: the number of incorrect proofs
1150
1175
1200
1225
1250
1275
1300
1325
Averageauditingtime(ms)
Seperate Auditing
Batch Auditing-S
Fig. 17. Impact of A on the ef-
B = 128.
0 2 4 6 8 10 12 14 16
A: the number of incorrect proofs
1290
1295
1300
1305
1310
1315
1320
1325
Averageauditingtime(ms) Seperate Auditing
Batch Auditing-D
Fig. 18. Impact of A on the ef-
B = 128.
communication cost is c(|q| + |n|) bits, where |q| is the
length of an element of Zq and |n| is the length of an
index. Each auditing = {λλλ,µµµ,φφφ, {idj}j∈J } contains (k+d)
elements of G1, k elements of Zp and c elememts of Zq,
therefore the communication cost of one auditing proof
is (2k + d)|p| + c|q| bits.
6.3 Experimental Results
We now evaluate the efficiency of Oruta in experi-
ments. To implement these complex cryptographic op-
erations that we mentioned before, we utilize the GNU
Multiple Precision Arithmetic (GMP)2
library and Pair-
ing Based Cryptography (PBC)3
library. All the following
experiments are based on C and tested on a 2.26 GHz
Linux system over 1, 000 times.
Because Oruta needs more exponentiations than pair-
ing operations during the process of auditing, the elliptic
2. http://gmplib.org/
3. http://crypto.stanford.edu/pbc/
curve we choose in our experiments is an MNT curve
with a base field size of 159 bits, which has a better
performance than other curves on computing exponen-
tiations. We choose |p| = 160 bits and |q| = 80 bits.
We assume the total number of blocks in shared data
is n = 1, 000, 000 and |n| = 20 bits. The size of shared
data is 2 GB. To keep the detection probability greater
than 99%, we set the number of selected blocks in an
auditing task as c = 460 [2]. If only 300 blocks are
selected, the detection probability is greater than 95%.
We also assume the size of the group d ∈ [2, 20] in the
following experiments. Certainly, if a larger group size
is used, the total computation cost will increase due to
the increasing number of exponentiations and pairing
operations.
6.3.1 Performance of Signature Generation
According to Section 5, the generation time of a ring
signature on a block is determined by the number of
users in the group and the number of elements in each

block. As illustrated in Fig. 10 and Fig. 11, when k is
fixed, the generation time of a ring signature is linearly
increasing with the size of the group; when d is fixed, the
generation time of a ring signature is linearly increasing
with the number of elements in each block. Specifically,
when d = 10 and k = 100, a user in the group requires
about 37 milliseconds to compute a ring signature on a
block in shared data.
6.3.2 Performance of Auditing
Based on our proceeding analysis, the auditing perfor-
mance of Oruta under different detection probabilities is
illustrated in Fig. 12–15, and Table 2. As shown in Fig. 12,
the auditing time is linearly increasing with the size of
the group. When c = 300, if there are two users sharing
data in the cloud, the auditing time is only about 0.5
seconds; when the number of group member increases
to 20, it takes about 2.5 seconds to finish the same
auditing task. The communication cost of an auditing
task under different parameters is presented in Fig. 14
and Fig. 15. Compare to the size of entire shared data,
the communication cost that the TPA consumes in an
auditing task is very small. It is clear in Table 2 that
when maintaining a higher detection probability, the
TPA needs to consume more computation and commu-
nication overhead to finish the auditing task. Specifically,
when c = 300, it takes the TPA 1.32 seconds to audit the
correctness of shared data, where the size of shared data
is 2 GB; when c = 460, the TPA needs 1.94 seconds to
verify the integrity of the same shared data.
TABLE 2
Performance of Auditing
System Parameters k = 100, d = 10,
Storage Usage 2GB + 200MB (data + signatures)
Selected Blocks c 460 300
Communication Cost 14.55KB 10.95KB
Auditing Time 1.94s 1.32s
6.3.3 Performance of Batch Auditing
As we discussed in Section 5, when there are multiple
auditing tasks, the TPA can improve the efficiency of ver-
ification by performing batch auditing. In the following
experiments, we choose c = 300, k = 100 and d = 10.
We can see from Fig. 16 that, compare to verifying these
auditing tasks one by one, if these B auditing tasks are
from different groups, batching auditing can save 2.1%
of the auditing time per auditing task on average. If
these B auditing tasks are from the same group, batching
auditing can save 12.6% of the average auditing time per
auditing task.
Now we evaluate the performance of batch auditing
when incorrect auditing proofs exist in the B auditing
proofs. As we mentioned in Section 5, we can use binary
search in batch auditing, so that we can distinguish the
incorrect ones from the B auditing proofs. However,
the increasing number of incorrect auditing proofs will
reduce the efficiency of batch auditing. It is important for
us to find out the maximal number of incorrect auditing
proofs exist in the B auditing proofs, so that the batch
auditing is still more efficient than separate auditing.
In this experiment, we assume the total number of
auditing proofs in the batch auditing is B = 128 (because
we leverage binary search, it is better to set B as a
power of 2), the number of elements in each block is
k = 100 and the number of users in the group is d = 10.
Let A denote the number of incorrect auditing proofs.
In addition, we also assume that it always requires
the worst-case algorithm to detect the incorrect auditing
proofs in the experiment. According to Equation (8) and
(9), the extra computation cost in binary search is mainly
introduced by extra pairing operations. As shown in Fig.
17, if all the 128 auditing proofs are from the same group,
when the number of incorrect auditing proofs is less than
16 (12% of all the auditing proofs), batching auditing
is still more efficient than separate auditing. Similarly,
in Fig. 18, if all the auditing proofs are from different
groups, when the number of incorrect auditing proofs
is more than 16, batching auditing is less efficient than
verifying these auditing proofs separately.
7 RELATED WORK
Provable data possession (PDP), first proposed by
Ateniese et al. [2], allows a verifier to check the correct-
ness of a client’s data stored at an untrusted server. By
utilizing RSA-based homomorphic authenticators and
sampling strategies, the verifier is able to publicly audit
the integrity of data without retrieving the entire data,
which is referred to as public verifiability or public
auditing. Unfortunately, their mechanism is only suitable
for auditing the integrity of static data. Juels and Kaliski
[13] defined another similar model called proofs of re-
trievability (POR), which is also able to check the correct-
ness of data on an untrusted server. The original file is
added with a set of randomly-valued check blocks called
sentinels. The verifier challenges the untrusted server
by specifying the positions of a collection of sentinels
and asking the untrusted server to return the associated
sentinel values. Shacham and Waters [6] designed two
improved POR schemes. The first scheme is built from
BLS signatures, and the second one is based on pseudo-
random functions.
To support dynamic operations on data, Ateniese et
al. [14] presented an efficient PDP mechanism based on
symmetric keys. This mechanism can support update
and delete operations on data, however, insert opera-
tions are not available in this mechanism. Because it
exploits symmetric keys to verify the integrity of data, it
is not public verifiable and only provides a user with a
limited number of verification requests. Wang et al. uti-
lized Merkle Hash Tree and BLS signatures [9] to support
fully dynamic operations in a public auditing mecha-
nism. Erway et al. [15] introduced dynamic provable data
possession (DPDP) by using authenticated dictionaries,

which are based on rank information. Zhu et al. exploited
the fragment structure to reduce the storage of signa-
tures in their public auditing mechanism. In addition,
they also used index hash tables to provide dynamic
operations for users. The public mechanism proposed by
Wang et al. [3] is able to preserve users’ confidential data
from the TPA by using random maskings. In addition,
to operate multiple auditing tasks from different users
efficiently, they extended their mechanism to enable
batch auditing by leveraging aggregate signatures [5].
Wang et al. [16] leveraged homomorphic tokens to
ensure the correctness of erasure codes-based data dis-
tributed on multiple servers. This mechanism is able
not only to support dynamic operations on data, but
also to identify misbehaved servers. To minimize com-
munication overhead in the phase of data repair, Chen
et al. [17] also introduced a mechanism for auditing
the correctness of data with the multi-server scenario,
where these data are encoded by network coding instead
of using erasure codes. More recently, Cao et al. [18]
constructed an LT codes-based secure and reliable cloud
storage mechanism. Compare to previous work [16], [17],
this mechanism can avoid high decoding computation
cost for data users and save computation resource for
online data owners during data repair.
To prevent special attacks exist in remote data storage
system with deduplication, Halevi et al. [19] introduced
the notation of proofs-of-ownership (POWs), which al-
lows a client to prove to a server that she actually holds
a data file, rather than just some hash values of the data
file. Zheng et al. [20] further discussed that POW and
PDP can co-exist under the same framework.
Recently, Franz et al. [21] proposed an oblivious out-
sourced storage scheme based on Oblivious RAM tech-
niques, which is able to hide users’ access patterns on
outsourced data from an untrusted cloud. Vimercati et
al. [22] utilize shuffle index structure to protect users’
access patterns on outsourced data.
8 CONCLUSION
In this paper, we propose Oruta, the first privacy-
preserving public auditing mechanism for shared data
in the cloud. We utilize ring signatures to construct
homomorphic authenticators, so the TPA is able to audit
the integrity of shared data, yet cannot distinguish who
is the signer on each block, which can achieve identity
privacy. To improve the efficiency of verification for mul-
tiple auditing tasks, we further extend our mechanism
to support batch auditing. An interesting problem in our
future work is how to efficiently audit the integrity of
shared data with dynamic groups while still preserving
the identity of the signer on each block from the third
party auditor.
REFERENCES
[1] M. Armbrust, A. Fox, R. Griffith, A. D.Joseph, R. H.Katz, A. Kon-
winski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, and M. Za-
haria, “A View of Cloud Computing,” Communications of the ACM,
vol. 53, no. 4, pp. 50–58, Apirl 2010.
[2] G. Ateniese, R. Burns, R. Curtmola, J. Herring, L. Kissner, Z. Peter-
son, and D. Song, “Provable Data Possession at Untrusted Stores,”
in Proc. ACM Conference on Computer and Communications Security
(CCS), 2007, pp. 598–610.
[3] C. Wang, Q. Wang, K. Ren, and W. Lou, “Privacy-Preserving
Public Auditing for Data Storage Security in Cloud Computing,”
in Proc. IEEE International Conference on Computer Communications
(INFOCOM), 2010, pp. 525–533.
[4] R. L. Rivest, A. Shamir, and Y. Tauman, “How to Leak a Secret,”
in Proc. International Conference on the Theory and Application of
Cryptology and Information Security (ASIACRYPT). Springer-
Verlag, 2001, pp. 552–565.
[5] D. Boneh, C. Gentry, B. Lynn, and H. Shacham, “Aggregate and
Verifiably Encrypted Signatures from Bilinear Maps,” in Proc. In-
ternational Conference on the Theory and Applications of Cryptographic
Techniques (EUROCRYPT). Springer-Verlag, 2003, pp. 416–432.
[6] H. Shacham and B. Waters, “Compact Proofs of Retrievability,”
in Proc. International Conference on the Theory and Application of
Cryptology and Information Security (ASIACRYPT). Springer-
Verlag, 2008, pp. 90–107.
[7] Y. Zhu, H. Wang, Z. Hu, G.-J. Ahn, H. Hu, and S. S.Yau, “Dynamic
Audit Services for Integrity Verification of Outsourced Storage in
Clouds,” in Proc. ACM Symposium on Applied Computing (SAC),
2011, pp. 1550–1557.
[8] S. Yu, C. Wang, K. Ren, and W. Lou, “Achieving Secure, Scalable,
and Fine-grained Data Access Control in Cloud Computing,” in
Proc. IEEE International Conference on Computer Communications
(INFOCOM), 2010, pp. 534–542.
[9] D. Boneh, B. Lynn, and H. Shacham, “Short Signature from the
Weil Pairing,” in Proc. International Conference on the Theory and
Application of Cryptology and Information Security (ASIACRYPT).
Springer-Verlag, 2001, pp. 514–532.
[10] D. Boneh and D. M. Freeman, “Homomorphic Signatures for
Polynomial Functions,” in Proc. International Conference on the
Theory and Applications of Cryptographic Techniques (EUROCRYPT).
Springer-Verlag, 2011, pp. 149–168.
[11] A. L. Ferrara, M. Green, S. Hohenberger, and M. Ø. Pedersen,
“Practical Short Signature Batch Verification,” in Proc. RSA Con-
ference, the Cryptographers’ Track (CT-RSA). Springer-Verlag, 2009,
pp. 309–324.
[12] V. Goyal, O. Pandey, A. Sahai, and B. Waters, “Attribute-Based
Encryption for Fine-Grained Access Control of Encrypted Data,”
in Proc. ACM Conference on Computer and Communications Security
(CCS), 2006, pp. 89–98.
[13] A. Juels and B. S. Kaliski, “PORs: Proofs pf Retrievability for Large
Files,” in Proc. ACM Conference on Computer and Communications
Security (CCS), 2007, pp. 584–597.
[14] G. Ateniese, R. D. Pietro, L. V. Mancini, and G. Tsudik, “Scalable
and Efficient Provable Data Possession,” in Proc. International
Conference on Security and Privacy in Communication Networks
(SecureComm), 2008.
[15] C. Erway, A. Kupcu, C. Papamanthou, and R. Tamassia, “Dynamic
Provable Data Possession,” in Proc. ACM Conference on Computer
and Communications Security (CCS), 2009, pp. 213–222.
[16] C. Wang, Q. Wang, K. Ren, and W. Lou, “Ensuring Data Storage
Security in Cloud Computing,” in Proc. IEEE/ACM International
Workshop on Quality of Service (IWQoS), 2009, pp. 1–9.
[17] B. Chen, R. Curtmola, G. Ateniese, and R. Burns, “Remote Data
Checking for Network Coding-based Distributed Stroage Sys-
tems,” in Proc. ACM Cloud Computing Security Workshop (CCSW),
2010, pp. 31–42.
[18] N. Cao, S. Yu, Z. Yang, W. Lou, and Y. T. Hou, “LT Codes-
based Secure and Reliable Cloud Storage Service,” in Proc. IEEE
International Conference on Computer Communications (INFOCOM),
2012.
[19] S. Halevi, D. Harnik, B. Pinkas, and A. Shulman-Peleg, “Proofs of
Ownership in Remote Storage Systems,” in Proc. ACM Conference
on Computer and Communications Security (CCS), 2011, pp. 491–500.
[20] Q. Zheng and S. Xu, “Secure and Efficient Proof of Storage with
Deduplication,” in Proc. ACM Conference on Data and Application
Security and Privacy (CODASPY), 2012.
[21] M. Franz, P. Williams, B. Carbunar, S. Katzenbeisser, and R. Sion,
“Oblivious Outsourced Storage with Delegation,” in Proc. Finan-
cial Cryptography and Data Security Conference (FC), 2011, pp. 127–
140.
[22] S. D. C. di Vimercati, S. Foresti, S. Paraboschi, G. Pelosi, and
P. Samarati, “Efficient and Private Access to Outsourced Data,”

in Proc. IEEE International Conference on Distributed Computing
Systems (ICDCS), 2011, pp. 710–719.

Ieeepro techno solutions ieee java project - oruta privacy-preserving public auditing

More Related Content

What's hot (16)

Viewers also liked (16)

Similar to Ieeepro techno solutions ieee java project - oruta privacy-preserving public auditing (20)

More from hemanthbbc (10)

Recently uploaded (20)

Ieeepro techno solutions ieee java project - oruta privacy-preserving public auditing