Efficient Platform for Traceable Collaborative Workflow Based on Digital Signature with Bi-Trapdoor Hash Function

Efficient Platform for Traceable Collaborative Workflow Based onDigital Signature with Bi-Trapdoor Hash Function

Chun-I Fan1 Yu-Chi Lin2 Yi-Fan Tseng3 Jheng-Jia Huang4

Department of Computer Science and EngineeringNational Sun Yat-sen University, Kaohsiung, Taiwan

Electronic Commerce Research CenterNational Sun Yat-sen University, Kaohsiung, [email protected] [email protected]

[email protected] [email protected]

ABSTRACTIn a collaborative workflow platform, when a groupleader receives a document which requires coopera-tors’ support, she/he assigns the task to the cooper-ators. Each cooperator can modify the document inreal-time and view the other cooperators’ modifica-tions simultaneously. A worth-discussing problem insuch environment is how to find the specific cooper-ator efficiently when some errors happen. Anotherproblem is how to efficiently verify all the revisionsstored 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 plat-form. The proposed platform has three advantages:low computation cost in the online phase, rapid ap-proach to finding the editor of a revision in a collabo-rative platform, and batch verification support for allrevisions.

KEYWORDSCollaborative Workflow Platform, Trapdoor HashFunction, Online/Offline Signature

1 INTRODUCTION

Recently, the concept of cloud computing has be-come well known and has been applied to var-ious applications. Cloud service models can bebriefly classified into three types: Infrastructureas a Service (IaaS), Platform as a Service (PaaS),and Software as a Service (SaaS). In this paper,

we focus on SaaS-type collaborative workflowplatforms, such as Wikipedia and Google Docs.For simplicity, collaborative platform is used todenote a collaborative workflow platform.

In the past, when a group had a complicatedproject requiring all group members’ support,completing the work was difficult. The groupleader splits the work into numerous parts andsends a part to each group member. Each groupmember completes her/his task and sends the re-sult back to the group leader. Finally, the groupleader collects the results and arranges them intoa final project report. This traditional cooperationis obviously inefficient. A collaborative work-flow platform solves this problem and makes co-operation more efficient. The group leader man-ages the task assignments instead of splitting thework into numerous parts. Through the platform,each member can edit the same document on-lineand view the current state simultaneously. Addi-tionally, interaction between the members and theplatform are shown in real time in order to alloweveryone in the group to take into account othermembers’ revisions.Though cooperating via a collaborative platformhas many advantages, problems still exist. Fol-lowing is a possible scenario between collabora-tors. A group leader Alice shares a job with Boband Cindy using the platform. Problems hap-pen when Alice finds an error in the document.In a traditional team arrangement, Alice would

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

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

know that the error was made by the person whowas assigned that part of the job; however, shecannot find the actual editor on the collaborativeplatform. An additional problem is that when allgroup members have finished the modifications,Alice may intend to check whether all revisionsare correct because all revisions are stored on thecollaborative platform.Although there is no related research on collab-orative platforms in cryptography, studies on ac-cess control [1][2][3] and similar issues [4][5] forcollaborative platforms have been performed. Toaddress the problems mentioned above, we con-sider that not only the editor but also the collab-orative platform should be responsible for a re-vision. Namely, both of them should sign on arevision. Unfortunately, an appropriate crypto-graphic signature scheme does not exist for thisenvironment. However, we believe that existingstudies about online/offline signatures [6], par-ticularly those based on trapdoor hash functions[7][8][9][10] may be applied. A basic solutionfor the problem is for both the editor and the plat-form to run a digital signature scheme to sign onthe revision separately. Due to the real-time prop-erty, the signing phase should be efficient. An-other solution is the two-party signature scheme[11], which allows two entities to sign a mes-sage collaboratively. Unfortunately, the solutionsmentioned above are not suitable for a collabora-tive platform due to performance and additionalrequirements.In this paper, we propose the construction of anew trapdoor hash function: a bi-trapdoor hashfunction that requires two trapdoor keys whena collision is found, and the design of a one-collision bi-trapdoor hash function for a collab-orative platform. Additionally, to solve the iden-tification problem mentioned above, we proposea signature scheme based on the one-collision bi-trapdoor hash function. Since the efficiency ofthe online phase affects the real-time constraintsof the collaborative platform, we reduce the com-putation cost in the signing phase. We also pro-vide a rapid approach to finding the actual editorof a revision. Batch verification is also proposedfor cooperators to check whether all revisions are

correct.

2 PRELIMINARIES

2.1 Trapdoor Hash Function

Definition 1. A trapdoor hash function con-sists of three algorithms (KeyGen, Hash,F indCollision).Let HK and TK be a public hash key and aprivate trapdoor key of the trapdoor hash func-tion, denoted by THHK(). The hash value canbe computed by anyone with the public hash keyHK. However, only the entity who has the pri-vate trapdoor key TK is able to find the collisionin polynomial time.

- KeyGen takes a security parameter λ as in-put and outputs a key pair (TK,HK).

- Hash takes a message m, a random value r,andHK as input and outputs the hash valuehm = THHK(m, r).

- FindCollision is a polynomial-time algo-rithm which takes as input the message m,another message m′, the random value r,and TK. It then outputs the collision valuec such that

THHK(m, r) = THHK(m′, c).

Definition 2. A trapdoor hash function has thefollowing properties [12][10].

- Collision-Resistance: Given a message m,a random values r, and the public hashkey HK, there does not exist a polynomial-time algorithm which can output the colli-sion (m′, c) such that

THHK(m, r) = THHK(m′, c).

- Semantic Security: Let C be the trapdoorhash value and m be the message whichwas hashed. The semantic security is thatthe conditional entropy H[m|C] of the mes-sage with a given trapdoor hash value Cis equal to the total entropy H[m] of the

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


message space. Namely, the trapdoor hashvalue does not reveal any information aboutm.

- Key Exposure Freeness: There does not ex-ist a polynomial-time algorithm which canforge a collision (m∗, c∗) that satisfies m 6=m∗ and THHK(m, r) = THHK(m

∗, c∗)even if the adversary can issue the query onFindCollision except m∗.

2.2 Bi-Trapdoor Hash Function

Here we give the definition of bi-trapdoor hashfunction, which has the basic properties of trap-door hash function and also supports collabora-tive mode. In collaborative mode, the procedureof finding a collision is divided in two parts andeach part can be accomplished by a different en-tity.

- Cooperator: An entity who decides col-lided string is called a cooperator. In a ba-sic trapdoor hash function (1), a cooperatordecides the the collided string m′.

TH(m, r) = TH(m′, c) (1)

- Hash Owner: An entity who decideswhether the collision for a collided string isgenerated is called a hash owner. In (1),the hash owner is able to generate the col-lision c according to the collided string m′

such that TH(m′, c) = TH(m, r) for somegiven (m, r).

Definition 3. A bi-trapdoor hash function con-sists of four algorithms (KeyGen, Hash,CollidedString, GenCollision).

- KeyGen(λ)→ (TK,HK). The key gener-ation algorithm takes a security parameter λas input and outputs a key pair (TK,HK)where TK is a secret trapdoor key and HKis a public hash key.

- Hash(HKO,m, r1, r2) → hm. The hashalgorithm takes the hash owner’s hash keyHKO, a message m, and some random val-ues r1, r2 as input. It generates the trapdoorhash value hm.

- CollidedString(TKC ,m′, r1) → c1. The

collided string algorithm takes as input thecooperator’s trapdoor key TKC , the col-lided string m′, and the random value r1 se-lected in Hash algorithm. It then outputs acollision c1.

- GenCollision(c1, TKO,m, r2) → c2. Thecollision generation algorithm takes as in-put the owner’s trapdoor key TKO, the orig-inal message m used in Hash algorithm,and the random value r2 selected in Hashalgorithm. It then generates a collision c2such that

Hash(m, r1, r2) = Hash(m′, c1, c2)

2.3 Nyberg’s Fast Accumulated Hash Func-tion

A Nyberg’s fast accumulated hash function [13]is a hash function which accumulates the input el-ements into a group and the order of inputting ac-cumulated elements does not affect the final hashvalue. The properties of Nyberg’s fast accumu-lated hashing can be widely applied in verifica-tion. Let A be the set where the bit-length ofan element in A is λA and B be the accumulateditem set. A Nyberg’s accumulated hash functionis denoted by NH : A×B → A. The followingsare the properties of Neberg’s fast accumulatedhash function.

- Quasi-commutation:NH(NH(a, b1), b2)= NH(NH(a, b2), b1),∀a ∈ A, b1, b2 ∈ B.

- Absorbency:

NH(NH(a, b), b) = NH(a, b),∀a ∈ A, b ∈ B.(2)

For its absorbency, the verification can be sim-ple and efficient when an element c is checkedwhether it is in the group. For example, ACC isthe accumulator of the elements (b1, b2, . . . , bn)where n is the total number of accumulated ele-ments. We compute ACC recursively by (3) and

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


verify c by (4). If (4) holds, we confirm that cbelongs to the accumulator ACC.

h1 = NH(a, b1), a ∈ A, b1 ∈ Bhi = NH(hi−1, bi), bi ∈ BACC = hn

(3)NH(ACC, c) = ACC (4)

3 THE PROPOSED SCHEME

In order to solve the problems, we design a one-collision bi-trapdoor hash function. We then pro-pose a digital signature scheme using the one-collision bi-trapdoor hash function for a collab-orative platform.

3.1 One-Collision Bi-Trapdoor Hash Func-tion

For simplicity, we denote a cooperator and a hashowner by C and O. Let p, q be two large primeswhere q | (p − 1) and g be a generator with or-der q in Z∗p. H is a cryptographic one-way hashfunction, where H : {0, 1}∗ → Z∗q .

• KeyGen(λ)→ (y, Y )

- Choose two random integers y ∈ Z∗qand compute Y = g−y mod p.

- Output the key pair (y, Y ), where thelower case letter represents the secrettrapdoor key and the upper case letterrepresents the public hash key.

(x,X) denote the key pair of C and (y, Y )denote the key pair of O. Both of them aregenerated by KeyGen algorithm.

• HashY (m‖R2, K1, r′1, K2, r

′2)→ hm

- In collaborative mode, C chooses tworandom values r1, k1 ∈ Z∗q and com-putes r′1 = k−11 r1 mod q, K1 = gk1

mod p, and R1 = gr1 mod p. C thensends (r′1, K1) to O.

- After receiving (r′1, K1), O choosestwo random values r2, k2 ∈ Z∗q andcomputes r′2 = k−12 r2 mod q, K2 =

gk2 mod p, R2 = Kr′22 mod p, and

hm = HashY (m‖R2, K1, r′1, K2, r

′2)

= Y H(m‖R2)Kr′11 K

r′22 mod p

= Y H(m‖R2)(gk1)k−11 r1(gk2)k

−12 r2

= g−yH(m‖R2)+r1+r2 mod p

• CollidedString(x,m′, R1, r1)→ c1

- r1 is the value used inHash algorithm.C computes c1 as (5) and outputs c1.

c1 = xH(m′‖R1) + r1 mod q (5)

• GenCollision(y,m,R2, r2)→ c2

- r2 is the value used inHash algorithm.O computes c2 as (6) and outputs c2.

c2 = −yH(m‖R2) + r2 mod q (6)

The correctness is shown as the follow-ing derivation, where all operations are per-formed under modulo p.

HashX(m′‖R1, g, c1, g, c2)

= XH(m′‖R1)gc1gc2

= XH(m′‖R1)gc1gc2

= (g−x)H(m′‖R1)gxH(m′‖R1)+r1g−yH(m‖R2)+r2

= g−xH(m′‖R1)+xH(m′‖R1)+r1−yH(m‖R2)+r2

= g−yH(m‖R2)+r1+r2

= HashY (m‖R2,K1, r′1,K2, r

′2)

(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/1Given bi-trapdoor hash tuples and checkvalues (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 istotal number of users and ni is total numberof the bi-trapdoor hash tuples of user i. N

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


denotes the total number of bi-trapdoor hashtuples, namely, N =

∑Mi=1 ni. To check if

HashXi(mi,j‖Ri,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

∈ Z∗q for all i ∈ [1,M ]and all j ∈ [1, ni].

2. Check whether (8) holds.∏Mi=1X

∑nij=1 vi,jH(mi,j‖Ri,j,1)

i g∑M

i=1

∑nij=1 vi,j(ci,j,1+ci,j,2)

≡∏M

i=1

∏ni

j=1 hvi,ji,j (mod p)

(8)

There is a special property, base conversion, ofour bi-trapdoor hash function. If a bi-trapdoorhash value is computed under the public hash keyY , we call the base of a hash value Y . For thisproperty, a collision will show the identity of co-operator. Equation (7) shows the base conversionfrom Y to X .

3.2 Construction of Collaborative Platform

We present the construction of the collaborativeworkflow platform in this section. The nota-tions used in the construction are shown in Ta-ble 1. There are seven phases in our proposedscheme including Initialization, Key Genera-tion, Offline phase, Online phase, Verification,Finding Editor, and Finish. The Initializationphase is executed when the service of collabo-rative platform starts. When a user registers onthe platform, she/he will run the Key Generationphase to obtain a key pair. The Offline phase willbe executed before the Online phase. When auser modifies the file, the Online phase will bealso executed by the user. The corresponding sig-nature is generated and is stored on the collabo-rative platform. When the collaborative platformreceives a search request about finding the ac-tual editor of a specific revision from a challengerwho may be a group member or the leader, theplatform will run the Finding Editor phase. If thesearch is successful, the platform will return the

corresponding signature to the challenger; other-wise, the platform will return null. The Verifi-cation phase will be started when the challengerobtains the signature of a specific revision and in-tends to verify its validity. If the result of verifica-tion is true, the challenger will confirm the iden-tity of the editor of the revision. Finally, when allcooperators finish modifications, the leader willrun the Finish phase with the platform to checkwhether all revisions are correct. We present thedetails of each phase as follows.

Table 1. The Notations

Notation Meaningy the secret trapdoor key of the

collaborative platformY the public hash key of the

collaborative platformx the secret trapdoor key of a userX the public hash key of a user

THY the one-collision bi-trapdoor hash functionwith Y

Wthe warrant including the file name and theidentities of the user and the platform

F a secure signature scheme,F = (SKeyGen, SSign, SV erify)

(sk, pk) the platform’s secret key and public key of FNH Nyberg’s one-way accumulated hash functionλA the security parameter of NHH a cryptographic one-way hash functionm∗ the message of the modificationT a timestamp of the modificationM the total number of usersni the number of revisions of user i

• Initialization phase:The collaborative platform selects asecure signature scheme denoted byF = (SKeyGen, SSign, SV erify), suchas Schnorr signature scheme [14]. Theplatform then runs SKeyGen to obtain thekey pair (sk, pk). It also runs the KeyGenalgorithm of the one-collision bi-trapdoorhash function to generate its secret trapdoorkey y and public key Y . The platformthen publishes (SV erify, pk, Y ) and keeps(sk, y) secret.

• Key Generation phase:When a user registers on the collaborative

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


platform, she/he first performs the KeyGenalgorithm of the bi-trapdoor hash function toobtain the key pair (x,X). The user thenpublishes her/his public key X and keeps xsecret.

• Offline phase:

1. The user chooses a random integerr1 ∈ Z∗q and computes R1 = gr1

mod p. A warrant W containing thefile name and the identities of the userand the platform is also prepared. Theuser then sends (W,R1) to the plat-form.

2. After receiving (W,R1), the platformchooses a random integer r2 ∈ Z∗q andcomputes R2 = gr2 mod p.

3. The platform generates the bi-trapdoor hash value as hW =THY (W, g, r1, g, r2) = Y H(W )R1R2

and then produces the signatureSW = SSignsk(hW ,W ) usingits secret key sk. Next, it setsσW = {hW ,W, SW} and sends σW tothe user.

4. When the user receives σW , she/heruns SV erifypk(hW ,W, SW ) to checkwhether the signature is valid. If true,the user accepts and stores the signa-ture σW . Otherwise, she/he rejects itand asks the platform to restart the pro-cess.

• Online phase:The user runs theCollidedString algorithmin the one-collision bi-trapdoor hash func-tion with her/his secret trapdoor key x, themessage of the modification m∗, the times-tamp T , r1, and R1 generated in the offlinephase. The collision c1 is produced as

c1 = CollidedString(x,m∗‖T,R1, r1)= xH(m∗‖T‖R1) + r1 mod q.

(9)Upon receiving the collision c1 from theuser, the collaborative platform performs thefollowing steps.

1. Check if R1 is equal togc1XH(m∗‖T‖R1) mod p. If false,the platform rejects this collision c1and asks the user a new collision untilthe check is successful.

2. Run the GenCollision algorithm inthe one-collision bi-trapdoor hashfunction with the platform’s secrettrapdoor key y, the warrant W , r2, andR2 used in the offline phase. The colli-sion generated by the platform will be

c2 = GenCollision(y,W,R2, r2)= yH(W‖R2) + r2 mod q.

(10)

3. Prepare Nyberg’s one-way accumula-tors for each user. If the user Ui firstproduces the signature with the plat-form, the platform will choose a ran-dom λA-bit value Ki for Ui and com-pute Zi = NH(Ki,m

∗). If the ac-cumulator Zi of the user Ui has beengenerated, the platform updates Zi =NH(Zi,m

∗).

4. The signature of m∗ is σm ={m∗, T, R1, c1, c2, σW} where σW isgenerated in the offline phase.

• Verification phase:If the verifier V receives a signature σm∗ ={m∗, T, R1, c1, c2, σW} and intends to checkits validity, she/he performs the followingsteps.

1. Run SV erifypk(hW ,W, SW ) to checkwhether hW and the warrant W arecorrect. If false, V gets the informa-tion that the signature σm∗ is invalidand then aborts the verification.

2. Compute hm∗ =THX(m

∗‖T‖R1, g, c1, g, c2). Thebase of the one-collision bi-trapdoorhash function can be known from thewarrant W . Then, check whether hm∗is equal to hW . If true, V confirms thatthe signature σm∗ is valid.

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


Table 2. Comparison of offline cost and online cost

Offline cost Online cost Total online costUser Platform User Platform

[10] 2Te + 1Tm + 2Th 2Te + 1Tm + 2Th Te + Tm + 2Th 4Te + 2Tm + 3Th 5Te + 3Tm + 5Th≈ 481.8Tm ≈ 481.8Tm ≈ 241.8Tm ≈ 963.2Tm ≈ 1205Tm

[9] 3Te + 2Tm + 2Th 3Te + 2Tm + 2Th Te + Tm + 2Th 5Te + 3Tm + 3Th 6Te + 4Tm + 5Th≈ 722.8Tm ≈ 722.8Tm ≈ 241.8Tm ≈ 1204.2Tm ≈ 1446Tm

[7] 3Te + 2Tm + 2Th 3Te + 2Tm + 2Th 2Te + 2Tm + 2Th 6Te + 4Tm + 4Th 8Te + 6Tm + 6Th≈ 722.8Tm ≈ 722.8Tm ≈ 482.8Tm ≈ 1445.6Tm ≈ 1928.4Tm

[8] 4Te + 2Tm + 3Th 4Te + 2Tm + 3Th 2Te + 3Tm + 2Th 5Te + 5Tm + 5Th 7Te + 8Tm + 7Th≈ 963.2Tm ≈ 963.2Tm ≈ 483.8Tm ≈ 1207Tm ≈ 1690.8Tm

[6] 3Te + 3Tm 3Te + 3Tm Tm + Th 3Te + 5Tm + 3Th 3Te + 6Tm + 4Th≈ 723Tm ≈ 723Tm ≈ 1.4Tm ≈ 726.2Tm ≈ 727.6Tm

[11] – – Te + Th 2Te + Th 3Te + 2Th≈ 240.4Tm ≈ 480.4Tm ≈ 720Tm

Ours 3Te + Tm + Th 3Te + 3Tm + 1Th Tm + Th 2Te + 2Tm + Th 2Te + 3Tm + 2Th≈ 721.4Tm ≈ 723.4Tm ≈ 1.4Tm ≈ 482.4Tm ≈ 483.8Tm

•Te : the cost of a modular exponentiation•Tm : the cost of a modular multiplication•Th : the cost of a basic hash operation

• Finding Editor phase:Let Zi be the accumulator of user Ui gener-ated in the online phase. If platform wants tofind the actual editor of the revision m, thenthe following steps will be performed.

1. Check if NH(Zi,m) is equal to Zi fori = 1 to M , where M is the total num-ber of users. If there exists j ∈ [1,M ]such that NH(Zj,m) = Zj , the plat-form gets the information that the edi-tor of m is user Uj .

2. In this step, the destination is to findthe signature of m which was gen-erated in the online phase. Supposethat SIGj is the signature set including{σm∗1 , σm∗2 , . . . , σm∗nj

} of Uj . The plat-form finds the corresponding signaturevia the verification for each signaturein SIGj . Finally, the signatureσm = {m,T,R1, c1, c2, σW} is found.

• Finish phase:Let SIGi = {σmi,1

, σmi,2, . . . , σmi,j

} bethe 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 valuehi,j is included in σWi,j

. The platform

sends all signatures of all group membersSIG1, SIG2, . . . , SIGM to the leader. Theleader performs the following steps.

1. Ask the group member ifor h′i,1, h

′i,2, . . . , h

′i,ni

for alli ∈ [1,M ], j ∈ [1, ni].

2. RunBatch((m1,1, T1,1, R1,1,1, c1,1,1, c1,1,2, h

′1,1),

. . . , (mi,j, Ti,j, Ri,j,1, ci,j,1, ci,j,2, h′i,j), . . . ,

(mM,nM, TM,nM

, RM,nM ,1, cM,nM ,1,cM,nM ,2, h

′M,nM

)) for i ∈ [1,M ] andj ∈ [1, ni] to check the validity ofone-collision bi-trapdoor hash tuples.

3. If the result is true, the leader can con-firm that all revisions are correct. Oth-erwise, the leader finds every incorrectpair (mi∗,j∗ , Ti∗,j∗ , Ri∗,j∗,1, ci∗,j∗,1,ci∗,j∗,2, h

′i∗,j∗) where i∗ ∈ [1,M ] and

j∗ ∈ [1, ni∗ ] by individual verification.

4. The leader runsSV erifypk(h

′i∗,j∗ ,W

′i∗,j∗ , S

′W ′

i∗,j∗).

If true, the leader can confirm that therevision mi∗,j∗ is invalid. Otherwise,the leader can confirm that the checkvalue h′i∗,j∗ from user i∗ is incorrect.

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


Table 3. Comparison of verification cost and storage cost

Verification cost Finish phase Signature Length

[10] 6Te + 2Tm + 4Th (2N +M + 1)Te + (4N −M − 1)Tm 2 · (2|n|+ 2|q|)≈ 1443.6Tm ≈ (484N + 239M + 239)Tm = 4736 bits

[9] 8Te + 4Tm + 4Th (2N +M + 2)Te + (6N +M + 1)Tm 2 · (3|q|+ |p|)≈ 1925.6Tm ≈ (486N + 241M + 481)Tm = 3008 bits

[7] 10Te + 4Tm + 4Th (4N + 1)Te + (8N − 2)Tm 2 · (3|q|+ 2|p|)≈ 2405.6Tm ≈ (968N + 238)Tm = 5056 bits

[8] 8Te + 4Tm + 6Th (4N +M + 1)Te + (6N −M − 1)Tm 2 · (2|q|+ 3|p|)≈ 1926.4Tm ≈ (966N + 239M + 239)Tm = 6784 bits

[6] 6Te + 8Tm + 2Th (2N + 3M + 3)Te + (12N +M + 1)Tm 2 · (λN + λK + λE)≈ 1448.8Tm ≈ (492N + 721M + 721)Tm = 4320 bits

[11] Te + Th MTe + (2N − 2M)Tm |n|≈ 240.4Tm ≈ (2N + 238M)Tm = 1024 bits

Ours 5Te + 3Tm + 2Th (N +M + 4)Te + Tm + Th 3|q|+ 2|p|≈ 1203.8Tm ≈ (240N + 240M + 240)Tm = 2528 bits

•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.

4 SECURITY ANALYSIS

In this section, we demonstrate the security ofour one-collision bi-trapdoor hash function. Inthe following analysis, C represents an adversarywho has the knowledge of secret key x of the bi-trapdoor hash function and O represents an ad-versary who has the knowledge of secret key y.In our scheme, computing a collision needs thecooperation between C and O. To find a colli-sion, one needs to compute both c1 and c2, whichare the outputs of the algorithm CollidedStringand GenCollision, respectively. However, in theequation 5 shown in Section 3.1, we can see thatC’s secrete key x is necessary for computing c1.And as shown in equation 6, computing c2 needsthe secret key y of O. Therefore, C and O cannotfind a collusion without the knowledge of eachother’s 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-

cuss the case that a malicious cooperator whosepublic hash key is (x,X) generates the sec-ond collided string with with the same c2.Given a valid collision (m‖R2, K1, r

′1, K2, r

′2)

and (m1‖R1, g, c1, g, c2), if the cooperator gener-ates the second collision c′1 on m′ with the samec2 such that HashY (m‖R2, K1, r

′1, K2, r

′2) =

HashX(m′‖R1, g, c

′1, g, c

′2), then the secret key

of the cooperator will be revealed by computing

x = (c′1 − c1)(H(m′‖R1)−H(m1‖R1))−1.

5 PERFORMANCE

In this section, we compare our scheme withthree types of schemes: online/offline signatures[6], online/offline signatures based on trapdoorhash functions [7][8][9][10] and two-party sig-natures [11]. There are two roles in the col-laborative platform: a user and the platform.Therefore, in our comparison, we assume thateach of them runs a single online/offline signa-ture scheme. The user first signs on the revi-

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


sion of a file and sends the signature to the plat-form. After receiving the signature, the platformverifies it and then signs on this signature. For[7][8][9][10], one can present an online/offlinesignature scheme by combining a trapdoor hashfunction with the hash-sign-switch paradigm pro-posed by Shamir et al. [10]. We assume thatthe signature scheme used in hash-sign-switchparadigm is Schnorr signature scheme.We show the performance in Table 2 and Table3. According to [15][16][17], we can know thatTe ≈ 240Tm and Th ≈ 0.4Tm.

6 CONCLUSIONS

To deal with the aforementioned problems, wehave proposed a novel bi-trapdoor hash functionthat requires two trapdoor keys when finding acollision, and took it as a foundation of a collab-orative platform. Our proposed scheme has threeadvantages: low computation cost in the onlinephase; rapid approach to finding the editor of arevision in a collaborative platform; and batchverification support for all revisions. In the futurework, we will complete the proofs of the requiredproperties and security of the proposed scheme.

ACKNOWLEDGEMENT

This work was partially supported by the Min-istry of Science and Technology of the Taiwanunder grants MOST 103-2221-E-110-057 and”Aim for the Top University Plan” of the NationalSun Yat-sen University and Ministry of Educa-tion, Taiwan, R.O.C.

REFERENCES

[1] T. Jaeger and A. Prakash. Requirements of role-based access control for collaborative systems. InProceedings of the First ACM Workshop on Role-based Access Control, RBAC’95, New York, NY,USA, 1996. ACM.

[2] A.A. El Kalam, Y. Deswarte, A. Baina, and M.Kaaniche. Access control for collaborative sys-tems: A web services based approach. In IEEE

International Conference on Web Services, pages1064-1071, 2007.

[3] W. Tolone, G.J. Ahn, T. Pai, and S.P. Hong Hong.Access control in collaborative systems. ACMComputing 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 inwikipedia. In Proceedings of the SIGCHI Confer-ence on Human Factors in Computing Systems,CHI’07, pages 453-462, New York, NY, USA,2007. ACM.

[5] H. Zhu. Some issues of role-based collaboration.In IEEE Canadian Conference on Electrical andComputer Engineering, volume 2, pages 687-690,2003.

[6] M. Joye. An efficient on-line/off-line signaturescheme without random oracles. In Proceedingsof 7th International Conference on Cryptologyand Network Security, volume 5339 of Lec-ture 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 basedon 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 andsignatures without key exposure. Computers andElectrical Engineering, 37(4):614-623, 2011.

[9] H. Krawczyk and T. Rabin. Chameleon signa-tures. In Proceedings of the Network and Dis-tributed Systems Security Symposium, 2000.

[10] A. Shamir and Y. Tauman. Improved on-line/offline signature schemes. Advances inCryptology-CRYPTO 2001, 2139:355-367, 2001.

[11] M. Bellare and R. Sandhu. The security of prac-tical two-party RSA signature schemes. IACRCryptology ePrint Archive, page 60, 2001.

[12] G. Ateniese and B. de Medeiros. On the key ex-posure problem in chameleon hashes. In Proceed-ings of the 4th International Conference on Secu-rity in Communication Networks, SCN’04, pages165-179, Berlin, Heidelberg, 2005. Springer-Verlag.

[13] K. Nyberg. Fast accumulated hashing. In Pro-ceedings of the Third International Workshop onFast Software Encryption, pages 83-87. Springer-Verlag, 1996.

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


[14] C.P. Schnorr. Efficient identification and signa-tures for smart cards. Advances in Cryptology-CRYPTO’89 Proceedings, 435:239-252, 1990.

[15] K. Lauter. The advantages of elliptic curve cryp-tography for wireless security. IEEE WirelessCommunications, 11(1):62-67, 2004.

[16] Z. Li, J. Higgins, and M. Clement. Perfor-mance of finite field arithmetic in an elliptic curvecryptosystem. In Proceedings of 9th InternationalSymposium on Modeling, Analysis and Simula-tion of Computer and Telecommunication Sys-tems, pages 249-256, 2001.

[17] Alfred J. Menezes, Scott A. Vanstone, and PaulC. Van Oorschot. Handbook of Applied Cryptog-raphy. CRC Press, Inc. Boca Raton, 2001.

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


Documents

Efficient Platform for Traceable Collaborative Workflow Based on Digital Signature with Bi-Trapdoor Hash Function