Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

Efficient Platform for Traceable Collaborative Workflow Based on

Digital Signature with Bi-Trapdoor Hash Function
Chun-I Fan1 Yu-Chi Lin2 Yi-Fan Tseng3 Jheng-Jia Huang4
Department of Computer Science and Engineering
National Sun Yat-sen University, Kaohsiung, Taiwan
Electronic Commerce Research Center
National Sun Yat-sen University, Kaohsiung, Taiwan
1
cifan@faculty.nsysu.edu.tw 2 s78a5ndy@gmail.com
3
yftseng1989@gmail.com 4 jhengjia.huang@gmail.com
ABSTRACT
In a collaborative workflow platform, when a group
leader receives a document which requires cooperators support, she/he assigns the task to the cooperators. Each cooperator can modify the document in
real-time and view the other cooperators modifications simultaneously. A worth-discussing problem in
such environment is how to find the specific cooperator efficiently when some errors happen. Another
problem is how to efficiently verify all the revisions
stored on the platform. To deal with the problems,
we first propose a novel bi-trapdoor hash function,
and use it to construct a collaborative workflow platform. The proposed platform has three advantages:
low computation cost in the online phase, rapid approach to finding the editor of a revision in a collaborative platform, and batch verification support for all
revisions.

KEYWORDS
Collaborative Workflow Platform, Trapdoor Hash
Function, Online/Offline Signature

INTRODUCTION

Recently, the concept of cloud computing has become well known and has been applied to various applications. Cloud service models can be
briefly classified into three types: Infrastructure
as a Service (IaaS), Platform as a Service (PaaS),
and Software as a Service (SaaS). In this paper,

ISBN: 978-1-941968-16-1 2015 SDIWC

we focus on SaaS-type collaborative workflow

platforms, such as Wikipedia and Google Docs.
For simplicity, collaborative platform is used to
denote a collaborative workflow platform.
In the past, when a group had a complicated
project requiring all group members support,
completing the work was difficult. The group
leader splits the work into numerous parts and
sends a part to each group member. Each group
member completes her/his task and sends the result back to the group leader. Finally, the group
leader collects the results and arranges them into
a final project report. This traditional cooperation
is obviously inefficient. A collaborative workflow platform solves this problem and makes cooperation more efficient. The group leader manages the task assignments instead of splitting the
work into numerous parts. Through the platform,
each member can edit the same document on-line
and view the current state simultaneously. Additionally, interaction between the members and the
platform are shown in real time in order to allow
everyone in the group to take into account other
members revisions.
Though cooperating via a collaborative platform
has many advantages, problems still exist. Following is a possible scenario between collaborators. A group leader Alice shares a job with Bob
and Cindy using the platform. Problems happen when Alice finds an error in the document.
In a traditional team arrangement, Alice would

250

Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

know that the error was made by the person who

was assigned that part of the job; however, she
cannot find the actual editor on the collaborative
platform. An additional problem is that when all
group members have finished the modifications,
Alice may intend to check whether all revisions
are correct because all revisions are stored on the
collaborative platform.
Although there is no related research on collaborative platforms in cryptography, studies on access control [1][2][3] and similar issues [4][5] for
collaborative platforms have been performed. To
address the problems mentioned above, we consider that not only the editor but also the collaborative platform should be responsible for a revision. Namely, both of them should sign on a
revision. Unfortunately, an appropriate cryptographic signature scheme does not exist for this
environment. However, we believe that existing
studies about online/offline signatures [6], particularly those based on trapdoor hash functions
[7][8][9][10] may be applied. A basic solution
for the problem is for both the editor and the platform to run a digital signature scheme to sign on
the revision separately. Due to the real-time property, the signing phase should be efficient. Another solution is the two-party signature scheme
[11], which allows two entities to sign a message collaboratively. Unfortunately, the solutions
mentioned above are not suitable for a collaborative platform due to performance and additional
requirements.
In this paper, we propose the construction of a
new trapdoor hash function: a bi-trapdoor hash
function that requires two trapdoor keys when
a collision is found, and the design of a onecollision bi-trapdoor hash function for a collaborative platform. Additionally, to solve the identification problem mentioned above, we propose
a signature scheme based on the one-collision bitrapdoor hash function. Since the efficiency of
the online phase affects the real-time constraints
of the collaborative platform, we reduce the computation cost in the signing phase. We also provide a rapid approach to finding the actual editor
of a revision. Batch verification is also proposed
for cooperators to check whether all revisions are

ISBN: 978-1-941968-16-1 2015 SDIWC

correct.
2

PRELIMINARIES

2.1

Trapdoor Hash Function

Definition 1. A trapdoor hash function consists of three algorithms (KeyGen, Hash,

F indCollision).
Let HK and T K be a public hash key and a
private trapdoor key of the trapdoor hash function, denoted by T HHK (). The hash value can
be computed by anyone with the public hash key
HK. However, only the entity who has the private trapdoor key T K is able to find the collision
in polynomial time.
- KeyGen takes a security parameter as input and outputs a key pair (T K, HK).
- Hash takes a message m, a random value r,
and HK as input and outputs the hash value
hm = T HHK (m, r).
- FindCollision is a polynomial-time algorithm which takes as input the message m,
another message m0 , the random value r,
and T K. It then outputs the collision value
c such that
T HHK (m, r) = T HHK (m0 , c).
Definition 2. A trapdoor hash function has the
following properties [12][10].
- Collision-Resistance: Given a message m,
a random values r, and the public hash
key HK, there does not exist a polynomialtime algorithm which can output the collision (m0 , c) such that
T HHK (m, r) = T HHK (m0 , c).
- Semantic Security: Let C be the trapdoor
hash value and m be the message which
was hashed. The semantic security is that
the conditional entropy H[m|C] of the message with a given trapdoor hash value C
is equal to the total entropy H[m] of the

251

Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

message space. Namely, the trapdoor hash

value does not reveal any information about
m.
- Key Exposure Freeness: There does not exist a polynomial-time algorithm which can
forge a collision (m , c ) that satisfies m 6=
m and T HHK (m, r) = T HHK (m , c )
even if the adversary can issue the query on
FindCollision except m .
2.2

Bi-Trapdoor Hash Function

Here we give the definition of bi-trapdoor hash

function, which has the basic properties of trapdoor hash function and also supports collaborative mode. In collaborative mode, the procedure
of finding a collision is divided in two parts and
each part can be accomplished by a different entity.
- Cooperator: An entity who decides collided string is called a cooperator. In a basic trapdoor hash function (1), a cooperator
decides the the collided string m0 .
T H(m, r) = T H(m0 , c)

(1)

- Hash Owner: An entity who decides

whether the collision for a collided string is
generated is called a hash owner. In (1),
the hash owner is able to generate the collision c according to the collided string m0
such that T H(m0 , c) = T H(m, r) for some
given (m, r).
Definition 3. A bi-trapdoor hash function consists of four algorithms (KeyGen, Hash,
CollidedString, GenCollision).
- KeyGen() (T K, HK). The key generation algorithm takes a security parameter
as input and outputs a key pair (T K, HK)
where T K is a secret trapdoor key and HK
is a public hash key.
- Hash(HKO , m, r1 , r2 ) hm . The hash
algorithm takes the hash owners hash key
HKO , a message m, and some random values r1 , r2 as input. It generates the trapdoor
hash value hm .

ISBN: 978-1-941968-16-1 2015 SDIWC

- CollidedString(T KC , m0 , r1 ) c1 . The
collided string algorithm takes as input the
cooperators trapdoor key T KC , the collided string m0 , and the random value r1 selected in Hash algorithm. It then outputs a
collision c1 .
- GenCollision(c1 , T KO , m, r2 ) c2 . The
collision generation algorithm takes as input the owners trapdoor key T KO , the original message m used in Hash algorithm,
and the random value r2 selected in Hash
algorithm. It then generates a collision c2
such that
Hash(m, r1 , r2 ) = Hash(m0 , c1 , c2 )
2.3

Nybergs Fast Accumulated Hash Function

A Nybergs fast accumulated hash function [13]

is a hash function which accumulates the input elements into a group and the order of inputting accumulated elements does not affect the final hash
value. The properties of Nybergs fast accumulated hashing can be widely applied in verification. Let A be the set where the bit-length of
an element in A is A and B be the accumulated
item set. A Nybergs accumulated hash function
is denoted by N H : A B A. The followings
are the properties of Nebergs fast accumulated
hash function.
- Quasi-commutation:
N H(N H(a, b1 ), b2 )
= N H(N H(a, b2 ), b1 ), a A, b1 , b2 B.
- Absorbency:
N H(N H(a, b), b) = N H(a, b), a A, b B.
(2)
For its absorbency, the verification can be simple and efficient when an element c is checked
whether it is in the group. For example, ACC is
the accumulator of the elements (b1 , b2 , . . . , bn )
where n is the total number of accumulated elements. We compute ACC recursively by (3) and

252

Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

verify c by (4). If (4) holds, we confirm that c

belongs to the accumulator ACC.

= N H(a, b1 ), a A, b1 B
h1
hi
= N H(hi1 , bi ), bi B

ACC = hn
N H(ACC, c) = ACC
3

(3)
(4)

THE PROPOSED SCHEME

- After receiving (r10 , K1 ), O chooses

two random values r2 , k2 Zq and
computes r20 = k21 r2 mod q, K2 =
r0
g k2 mod p, R2 = K2 2 mod p, and
hm = HashY (mkR2 , K1 , r10 , K2 , r20 )
r0
r0
= Y H(mkR2 ) K1 1 K2 2 mod p
1
1
= Y H(mkR2 ) (g k1 )k1 r1 (g k2 )k2 r2
= g yH(mkR2 )+r1 +r2 mod p

In order to solve the problems, we design a onecollision bi-trapdoor hash function. We then propose a digital signature scheme using the onecollision bi-trapdoor hash function for a collaborative platform.

CollidedString(x, m0 , R1 , r1 ) c1

3.1

GenCollision(y, m, R2 , r2 ) c2

One-Collision Bi-Trapdoor Hash Function

For simplicity, we denote a cooperator and a hash

owner by C and O. Let p, q be two large primes
where q | (p 1) and g be a generator with order q in Zp . H is a cryptographic one-way hash
function, where H : {0, 1} Zq .
KeyGen() (y, Y )
- Choose two random integers y Zq
and compute Y = g y mod p.
- Output the key pair (y, Y ), where the
lower case letter represents the secret
trapdoor key and the upper case letter
represents the public hash key.
(x, X) denote the key pair of C and (y, Y )
denote the key pair of O. Both of them are
generated by KeyGen algorithm.
HashY (mkR2 , K1 , r10 , K2 , r20 ) hm
- In collaborative mode, C chooses two
random values r1 , k1 Zq and computes r10 = k11 r1 mod q, K1 = g k1
mod p, and R1 = g r1 mod p. C then
sends (r10 , K1 ) to O.

ISBN: 978-1-941968-16-1 2015 SDIWC

- r1 is the value used in Hash algorithm.

C computes c1 as (5) and outputs c1 .
c1 = xH(m0 kR1 ) + r1

mod q (5)

- r2 is the value used in Hash algorithm.

O computes c2 as (6) and outputs c2 .
c2 = yH(mkR2 ) + r2

mod q (6)

The correctness is shown as the following derivation, where all operations are performed under modulo p.
HashX (m0 kR1 , g, c1 , g, c2 )
0
= X H(m kR1 ) g c1 g c2
0
= X H(m kR1 ) g c1 g c2
0
0
= (g x )H(m kR1 ) g xH(m kR1 )+r1 g yH(mkR2 )+r2
0
0
= g xH(m kR1 )+xH(m kR1 )+r1 yH(mkR2 )+r2
= g yH(mkR2 )+r1 +r2
= HashY (mkR2 , K1 , r10 , K2 , r20 )

(7)
Batch((m1,1 , R1,1,1 , c1,1,1 , c1,1,2 , h1,1 ),
. . . , (mi,j , Ri,j,1 , ci,j,1 , ci,j,2 , hi,j ), . . . ,
(mM,nM , RM,nM ,1 , cM,nM ,1 , cM,nM ,2 , hM,nM ))
0/1
Given bi-trapdoor hash tuples and check
values (m1,1 , R1,1,1 , c1,1,1 , c1,1,2 , h1,1 ), . . . ,
(mi,j , Ri,j,1 , ci,j,1 , ci,j,2 , hi,j ), . . . ,
(mM,nM , RM,nM ,1 , cM,nM ,1 , cM,nM ,2 , hM,nM )
for i [1, M ] and j [1, ni ] where M is
total number of users and ni is total number
of the bi-trapdoor hash tuples of user i. N

253

Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

denotes the total number

PMof bi-trapdoor hash
tuples, namely, N = i=1 ni . To check if
HashXi (mi,j kRi,j,1 , g, ci,j,1 , g, ci,j,2 ) = hi,j ,
i [1, M ], j [1, ni ],

the checker performs the following steps.

1. Choose N random integers v1,1 . . . ,
vi,j , . . . , vM,nM Zq for all i [1, M ]
and all j [1, ni ].
2. Check whether (8) holds.
QM

Pni

i=1 Xi

j=1

Table 1. The Notations

vi,j H(mi,j kRi,j,1 ) PM Pni v (c

i=1
j=1 i,j i,j,1 +ci,j,2 )

g
QM Qni vi,j
i=1 j=1 hi,j (mod p)

(8)
There is a special property, base conversion, of
our bi-trapdoor hash function. If a bi-trapdoor
hash value is computed under the public hash key
Y , we call the base of a hash value Y . For this
property, a collision will show the identity of cooperator. Equation (7) shows the base conversion
from Y to X.
3.2

corresponding signature to the challenger; otherwise, the platform will return null. The Verification phase will be started when the challenger
obtains the signature of a specific revision and intends to verify its validity. If the result of verification is true, the challenger will confirm the identity of the editor of the revision. Finally, when all
cooperators finish modifications, the leader will
run the Finish phase with the platform to check
whether all revisions are correct. We present the
details of each phase as follows.

Construction of Collaborative Platform

We present the construction of the collaborative

workflow platform in this section. The notations used in the construction are shown in Table 1. There are seven phases in our proposed
scheme including Initialization, Key Generation, Offline phase, Online phase, Verification,
Finding Editor, and Finish. The Initialization
phase is executed when the service of collaborative platform starts. When a user registers on
the platform, she/he will run the Key Generation
phase to obtain a key pair. The Offline phase will
be executed before the Online phase. When a
user modifies the file, the Online phase will be
also executed by the user. The corresponding signature is generated and is stored on the collaborative platform. When the collaborative platform
receives a search request about finding the actual editor of a specific revision from a challenger
who may be a group member or the leader, the
platform will run the Finding Editor phase. If the
search is successful, the platform will return the

ISBN: 978-1-941968-16-1 2015 SDIWC

Notation
y
Y
x
X
T HY
W
F
(sk, pk)
NH
A
H
m
T
M
ni

Meaning
the secret trapdoor key of the
collaborative platform
the public hash key of the
collaborative platform
the secret trapdoor key of a user
the public hash key of a user
the one-collision bi-trapdoor hash function
with Y
the warrant including the file name and the
identities of the user and the platform
a secure signature scheme,
F = (SKeyGen, SSign, SV erif y)
the platforms secret key and public key of F
Nybergs one-way accumulated hash function
the security parameter of N H
a cryptographic one-way hash function
the message of the modification
a timestamp of the modification
the total number of users
the number of revisions of user i

Initialization phase:
The collaborative platform selects a
secure signature scheme denoted by
F = (SKeyGen, SSign, SV erif y), such
as Schnorr signature scheme [14]. The
platform then runs SKeyGen to obtain the
key pair (sk, pk). It also runs the KeyGen
algorithm of the one-collision bi-trapdoor
hash function to generate its secret trapdoor
key y and public key Y . The platform
then publishes (SV erif y, pk, Y ) and keeps
(sk, y) secret.
Key Generation phase:
When a user registers on the collaborative

254

Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

platform, she/he first performs the KeyGen

algorithm of the bi-trapdoor hash function to
obtain the key pair (x, X). The user then
publishes her/his public key X and keeps x
secret.
Offline phase:
1. The user chooses a random integer
r1 Zq and computes R1 = g r1
mod p. A warrant W containing the
file name and the identities of the user
and the platform is also prepared. The
user then sends (W, R1 ) to the platform.
2. After receiving (W, R1 ), the platform
chooses a random integer r2 Zq and
computes R2 = g r2 mod p.
3. The platform generates the bitrapdoor hash value as hW
=
H(W )
T HY (W, g, r1 , g, r2 ) = Y
R1 R2
and then produces the signature
SW
=
SSignsk (hW , W ) using
its secret key sk.
Next, it sets
W = {hW , W, SW } and sends W to
the user.
4. When the user receives W , she/he
runs SV erif ypk (hW , W, SW ) to check
whether the signature is valid. If true,
the user accepts and stores the signature W . Otherwise, she/he rejects it
and asks the platform to restart the process.
Online phase:
The user runs the CollidedString algorithm
in the one-collision bi-trapdoor hash function with her/his secret trapdoor key x, the
message of the modification m , the timestamp T , r1 , and R1 generated in the offline
phase. The collision c1 is produced as

c1 = CollidedString(x, m kT, R1 , r1 )
= xH(m kT kR1 ) + r1 mod q.
(9)
Upon receiving the collision c1 from the
user, the collaborative platform performs the
following steps.

ISBN: 978-1-941968-16-1 2015 SDIWC

1. Check
if
R1
is
equal
to
c1 H(m kT kR1 )
g X
mod p.
If false,
the platform rejects this collision c1
and asks the user a new collision until
the check is successful.
2. Run the GenCollision algorithm in
the one-collision bi-trapdoor hash
function with the platforms secret
trapdoor key y, the warrant W , r2 , and
R2 used in the offline phase. The collision generated by the platform will be
c2 = GenCollision(y, W, R2 , r2 )
= yH(W kR2 ) + r2 mod q.
(10)
3. Prepare Nybergs one-way accumulators for each user. If the user Ui first
produces the signature with the platform, the platform will choose a random A -bit value Ki for Ui and compute Zi = N H(Ki , m ). If the accumulator Zi of the user Ui has been
generated, the platform updates Zi =
N H(Zi , m ).
4. The signature of m is m =
{m , T, R1 , c1 , c2 , W } where W is
generated in the offline phase.
Verification phase:
If the verifier V receives a signature m =
{m , T, R1 , c1 , c2 , W } and intends to check
its validity, she/he performs the following
steps.
1. Run SV erif ypk (hW , W, SW ) to check
whether hW and the warrant W are
correct. If false, V gets the information that the signature m is invalid
and then aborts the verification.
2. Compute
hm
=
T HX (m kT kR1 , g, c1 , g, c2 ).
The
base of the one-collision bi-trapdoor
hash function can be known from the
warrant W . Then, check whether hm
is equal to hW . If true, V confirms that
the signature m is valid.

255

Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

Table 2. Comparison of offline cost and online cost

[10]
[9]
[7]
[8]
[6]
[11]

Offline cost
User
Platform
2Te + 1Tm + 2Th 2Te + 1Tm + 2Th
481.8Tm
481.8Tm
3Te + 2Tm + 2Th 3Te + 2Tm + 2Th
722.8Tm
722.8Tm
3Te + 2Tm + 2Th 3Te + 2Tm + 2Th
722.8Tm
722.8Tm
4Te + 2Tm + 3Th 4Te + 2Tm + 3Th
963.2Tm
963.2Tm
3Te + 3Tm
3Te + 3Tm
723Tm
723Tm

3Te + Tm + Th
3Te + 3Tm + 1Th
721.4Tm
723.4Tm
Te : the cost of a modular exponentiation
Tm : the cost of a modular multiplication
Th : the cost of a basic hash operation
Ours

Online cost
User
Platform
Te + Tm + 2Th
4Te + 2Tm + 3Th
241.8Tm
963.2Tm
Te + Tm + 2Th
5Te + 3Tm + 3Th
241.8Tm
1204.2Tm
2Te + 2Tm + 2Th 6Te + 4Tm + 4Th
482.8Tm
1445.6Tm
2Te + 3Tm + 2Th 5Te + 5Tm + 5Th
483.8Tm
1207Tm
Tm + Th
3Te + 5Tm + 3Th
1.4Tm
726.2Tm
Te + Th
2Te + Th
240.4Tm
480.4Tm
Tm + Th
2Te + 2Tm + Th
1.4Tm
482.4Tm

Finding Editor phase:

Let Zi be the accumulator of user Ui generated in the online phase. If platform wants to
find the actual editor of the revision m, then
the following steps will be performed.
1. Check if N H(Zi , m) is equal to Zi for
i = 1 to M , where M is the total number of users. If there exists j [1, M ]
such that N H(Zj , m) = Zj , the platform gets the information that the editor of m is user Uj .
2. In this step, the destination is to find
the signature of m which was generated in the online phase. Suppose
that SIGj is the signature set including
{m1 , m2 , . . . , mnj } of Uj . The platform finds the corresponding signature
via the verification for each signature
in SIGj . Finally, the signature
m = {m, T, R1 , c1 , c2 , W } is found.
Finish phase:
Let SIGi = {mi,1 , mi,2 , . . . , mi,j } be
the signature set of user i where mi,j =
(mi,j , Ti,j , Ri,j,1 , ci,j,1 , ci,j,2 , Wi,j ) for i
[1, M ] and j [1, ni ]. The check value
hi,j is included in Wi,j . The platform

ISBN: 978-1-941968-16-1 2015 SDIWC

Total online cost

5Te + 3Tm + 5Th
1205Tm
6Te + 4Tm + 5Th
1446Tm
8Te + 6Tm + 6Th
1928.4Tm
7Te + 8Tm + 7Th
1690.8Tm
3Te + 6Tm + 4Th
727.6Tm
3Te + 2Th
720Tm
2Te + 3Tm + 2Th
483.8Tm

sends all signatures of all group members

SIG1 , SIG2 , . . . , SIGM to the leader. The
leader performs the following steps.
1. Ask
the
group
member
for
for
h0i,1 , h0i,2 , . . . , h0i,ni
i [1, M ], j [1, ni ].

i
all

2. Run
Batch((m1,1 , T1,1 , R1,1,1 , c1,1,1 , c1,1,2 , h01,1 ),
. . . , (mi,j , Ti,j , Ri,j,1 , ci,j,1 , ci,j,2 , h0i,j ), . . . ,
(mM,nM , TM,nM , RM,nM ,1 , cM,nM ,1 ,
cM,nM ,2 , h0M,nM )) for i [1, M ] and
j [1, ni ] to check the validity of
one-collision bi-trapdoor hash tuples.
3. If the result is true, the leader can confirm that all revisions are correct. Otherwise, the leader finds every incorrect
pair (mi ,j , Ti ,j , Ri ,j ,1 , ci ,j ,1 ,
ci ,j ,2 , h0i ,j ) where i [1, M ] and
j [1, ni ] by individual verification.
4. The
leader
runs
0
0
0
SV erif ypk (hi ,j , Wi ,j , SW 0 ).
i ,j
If true, the leader can confirm that the
revision mi ,j is invalid. Otherwise,
the leader can confirm that the check
value h0i ,j from user i is incorrect.

256

Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

Table 3. Comparison of verification cost and storage cost

Verification cost
Finish phase
6Te + 2Tm + 4Th
(2N + M + 1)Te + (4N M 1)Tm
[10]
1443.6Tm
(484N + 239M + 239)Tm
8Te + 4Tm + 4Th
(2N + M + 2)Te + (6N + M + 1)Tm
[9]
1925.6Tm
(486N + 241M + 481)Tm
10Te + 4Tm + 4Th
(4N + 1)Te + (8N 2)Tm
[7]
2405.6Tm
(968N + 238)Tm
8Te + 4Tm + 6Th
(4N + M + 1)Te + (6N M 1)Tm
[8]
1926.4Tm
(966N + 239M + 239)Tm
6Te + 8Tm + 2Th
(2N + 3M + 3)Te + (12N + M + 1)Tm
[6]
1448.8Tm
(492N + 721M + 721)Tm
Te + Th
M Te + (2N 2M )Tm
[11]
240.4Tm
(2N + 238M )Tm
5Te + 3Tm + 2Th
(N + M + 4)Te + Tm + Th
Ours
1203.8Tm
(240N + 240M + 240)Tm
Te : the cost of a modular exponentiation
Tm : the cost of a modular multiplication
Th : the cost of a basic hash operation
M : the total number of group members
N : the total number of the signatures of the M users
q : the prime order of a cyclic group G and |q| = 160.
p : an element in a cyclic group G and |p| = 1024.
n : a product of two large primes and |n| = 1024.
N : a security parameter in [6] and N = 1536.
K : a security parameter in [6] and K = 496.
E : a security parameter in [6] and E = 128.

SECURITY ANALYSIS

In this section, we demonstrate the security of

our one-collision bi-trapdoor hash function. In
the following analysis, C represents an adversary
who has the knowledge of secret key x of the bitrapdoor hash function and O represents an adversary who has the knowledge of secret key y.
In our scheme, computing a collision needs the
cooperation between C and O. To find a collision, one needs to compute both c1 and c2 , which
are the outputs of the algorithm CollidedString
and GenCollision, respectively. However, in the
equation 5 shown in Section 3.1, we can see that
Cs secrete key x is necessary for computing c1 .
And as shown in equation 6, computing c2 needs
the secret key y of O. Therefore, C and O cannot
find a collusion without the knowledge of each
others secret key.
In the analysis of the one-collision property,
since the hash owner whose key pair is (y, Y )
cannot decide the collided string, we only dis-

ISBN: 978-1-941968-16-1 2015 SDIWC

Signature Length
2 (2|n| + 2|q|)
= 4736 bits
2 (3|q| + |p|)
= 3008 bits
2 (3|q| + 2|p|)
= 5056 bits
2 (2|q| + 3|p|)
= 6784 bits
2 (N + K + E )
= 4320 bits
|n|
= 1024 bits
3|q| + 2|p|
= 2528 bits

cuss the case that a malicious cooperator whose

public hash key is (x, X) generates the second collided string with with the same c2 .
Given a valid collision (mkR2 , K1 , r10 , K2 , r20 )
and (m1 kR1 , g, c1 , g, c2 ), if the cooperator generates the second collision c01 on m0 with the same
c2 such that HashY (mkR2 , K1 , r10 , K2 , r20 ) =
HashX (m0 kR1 , g, c01 , g, c02 ), then the secret key
of the cooperator will be revealed by computing
x = (c01 c1 )(H(m0 kR1 ) H(m1 kR1 ))1 .
5

PERFORMANCE

In this section, we compare our scheme with

three types of schemes: online/offline signatures
[6], online/offline signatures based on trapdoor
hash functions [7][8][9][10] and two-party signatures [11]. There are two roles in the collaborative platform: a user and the platform.
Therefore, in our comparison, we assume that
each of them runs a single online/offline signature scheme. The user first signs on the revi-

257

Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

sion of a file and sends the signature to the platform. After receiving the signature, the platform
verifies it and then signs on this signature. For
[7][8][9][10], one can present an online/offline
signature scheme by combining a trapdoor hash
function with the hash-sign-switch paradigm proposed by Shamir et al. [10]. We assume that
the signature scheme used in hash-sign-switch
paradigm is Schnorr signature scheme.
We show the performance in Table 2 and Table
3. According to [15][16][17], we can know that
Te 240Tm and Th 0.4Tm .
6

CONCLUSIONS

To deal with the aforementioned problems, we

have proposed a novel bi-trapdoor hash function
that requires two trapdoor keys when finding a
collision, and took it as a foundation of a collaborative platform. Our proposed scheme has three
advantages: low computation cost in the online
phase; rapid approach to finding the editor of a
revision in a collaborative platform; and batch
verification support for all revisions. In the future
work, we will complete the proofs of the required
properties and security of the proposed scheme.
ACKNOWLEDGEMENT
This work was partially supported by the Ministry of Science and Technology of the Taiwan
under grants MOST 103-2221-E-110-057 and
Aim for the Top University Plan of the National
Sun Yat-sen University and Ministry of Education, Taiwan, R.O.C.
REFERENCES
[1] T. Jaeger and A. Prakash. Requirements of rolebased access control for collaborative systems. In
Proceedings of the First ACM Workshop on Rolebased Access Control, RBAC95, New York, NY,
USA, 1996. ACM.
[2] A.A. El Kalam, Y. Deswarte, A. Baina, and M.
Kaaniche. Access control for collaborative systems: A web services based approach. In IEEE

ISBN: 978-1-941968-16-1 2015 SDIWC

International Conference on Web Services, pages

1064-1071, 2007.
[3] W. Tolone, G.J. Ahn, T. Pai, and S.P. Hong Hong.
Access control in collaborative systems. ACM
Computing Surveys, 37(1):29-41, 2005.
[4] A. Kittur, B. Suh, B.A. Pendleton, and E.H. Chi.
He says, she says: Conflict and coordination in
wikipedia. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems,
CHI07, pages 453-462, New York, NY, USA,
2007. ACM.
[5] H. Zhu. Some issues of role-based collaboration.
In IEEE Canadian Conference on Electrical and
Computer Engineering, volume 2, pages 687-690,
2003.
[6] M. Joye. An efficient on-line/off-line signature
scheme without random oracles. In Proceedings
of 7th International Conference on Cryptology
and Network Security, volume 5339 of Lecture Notes in Computer Science, pages 98-107.
Springer Berlin Heidelberg, 2008.
[7] S. Chandrasekhar, S. Chakrabarti, M. Singhal,
and K.L. Calvert. Efficient proxy signatures based
on trapdoor hash functions. Information Security,
4(4):322-332, 2010.
[8] X. Chen, F. Zhang, H. Tian, B. Wei, and K. Kim.
Discrete logarithm based chameleon hashing and
signatures without key exposure. Computers and
Electrical Engineering, 37(4):614-623, 2011.
[9] H. Krawczyk and T. Rabin. Chameleon signatures. In Proceedings of the Network and Distributed Systems Security Symposium, 2000.
[10] A. Shamir and Y. Tauman. Improved online/offline signature schemes. Advances in
Cryptology-CRYPTO 2001, 2139:355-367, 2001.
[11] M. Bellare and R. Sandhu. The security of practical two-party RSA signature schemes. IACR
Cryptology ePrint Archive, page 60, 2001.
[12] G. Ateniese and B. de Medeiros. On the key exposure problem in chameleon hashes. In Proceedings of the 4th International Conference on Security in Communication Networks, SCN04, pages
165-179, Berlin, Heidelberg, 2005. SpringerVerlag.
[13] K. Nyberg. Fast accumulated hashing. In Proceedings of the Third International Workshop on
Fast Software Encryption, pages 83-87. SpringerVerlag, 1996.

258

Proceedings of The Fourth International Conference on Informatics & Applications, Takamatsu, Japan, 2015

[14] C.P. Schnorr. Efficient identification and signatures for smart cards. Advances in CryptologyCRYPTO89 Proceedings, 435:239-252, 1990.
[15] K. Lauter. The advantages of elliptic curve cryptography for wireless security. IEEE Wireless
Communications, 11(1):62-67, 2004.
[16] Z. Li, J. Higgins, and M. Clement. Performance of finite field arithmetic in an elliptic curve
cryptosystem. In Proceedings of 9th International
Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, pages 249-256, 2001.
[17] Alfred J. Menezes, Scott A. Vanstone, and Paul
C. Van Oorschot. Handbook of Applied Cryptography. CRC Press, Inc. Boca Raton, 2001.

ISBN: 978-1-941968-16-1 2015 SDIWC

259