On the Impossibility of Batch Update for

Cryptographic Accumulators

Philippe Camacho and Alejandro HeviaUniversity of Chile

Certificate Authority

CABob

Bob

Bob Alice

PKI

Bob

Bob

CRL/OSCP

? YES/NO

BobBob Alice

Certificate Authority

?Insert/Delete

Owns a Set of valid certificates

X={x1,x2,…}

Bob Alice

CentralAuthority

?INSERT/DELETE

Owns a Set X={x1,x2,…}

Bob Alice

CentralAuthority

Central Authority

(PK,SK)

INSERT x Sign(x,SK)= σx

Replay Attack

Does x belong to X?

YES: σx

Central Authority

(PK,SK)

Delete x

Replay Attack

Does x belong to X?

YES: σx

ManagerAcc1, Acc2Acc1

Insert(x)

( x , )

Acc1, Acc2, Acc3

Verify( x , , Acc3) = YES

Witness

Bob Alice

Manager

Delete(x)

Acc1, Acc2, Acc3, Acc4

Verify( x , , Acc4) = FAIL

OK

Bob Alice

Manager

Insert(x)

( x , )

Acc1, Acc2, Acc3,…

Verify( x , , Acc3) = YES

Witness

Bob Alice

CryptographicAccumulator

Main constructionsSecurity Note

[BeMa94] RSA + RO First definition

[BarPfi97] Strong RSA -

[CamLys02] Strong RSA First dynamic accumulator

[LLX07] Strong RSA First universal accumultor

[Ngu05] Pairings E-cash, ZK-Sets,…

[WWP08] eStrong RSAPaillier

Batch Update

[CHKO08] Collision-Resistant Hashing Untrusted Manager

[CKS09] Pairings Group multiplication

Manager

Bob 1 Bob 2 Bob 3

x1 w1 x2 w2 x3 w3

Acc1Acc1, Acc2Acc1, Acc2, Acc3

Problem: after each update of theaccumulated value it is necesarryto recompute all the witnesses.

Delegate Witness Computation?

ConstructionsReplica

(Compute a single witness)

User (Verify)

[CL02] O(|X|) O(1)

[GTT09] O(|X|1/ε) O(ε)

[CHK08] O(log |X|) O(log |X|)

ManagerVerify(x,w,Acc)

Manager…,Acc99, Acc100, Acc101,…, Acc200,…

(x1,w1,Acc100)( x2,w2,Acc100)( x6,w6,Acc100)

(x36,w36,Acc100)( x87,w87,Acc100)

(x1,w1,Acc100)( x20,w20,Acc100)( x69,w68,Acc100)( x64,w64,Acc100)

…

(x1,w1,Acc100)( x2,w2,Acc100)( x6,w6,Acc100)

….

Bob 42Bob 29Bob 1 Bob 2

Upd100,200

Batch Update[FN02]

Manager…,Acc99, Acc100, Acc101,…, Acc200,…

(x1,w1’,Acc200)( x2,w2’,Acc200)( x6,w6’,Acc200)

(x36,w36’,Acc200)( x87,w87’,Acc200)

(x1,w1’,Acc200)( x20,w20’,Acc200)( x69,w68’,Acc200)( x64,w64’,Acc200)

…

(x1,w1’,Acc200)( x2,w2’,Acc200)( x6,w6’,Acc200)

….

Bob 42Bob 29Bob 1 Bob 2

Batch Update[FN02]

Batch Update [FN02]

Trivial solution: UpdXi,Xj

= {list of all witnesses for Xj}

More interesting:|UpdXi,Xj

| = O(1)

What happens with [CL02]?• PK=(n,g) with n=pq and g є Zn*

• AccØ := g mod n

• Insert(x,Acc) := Accx mod n /* x prime */

• Delete(x,Acc) := Acc1/x mod n

• WitGen(x,Acc) := Acc1/x mod n

• Verify(x,w,Acc): wx = Acc

• |UpdXi,Xj| = O(|{list of insertions / deletions}|)

?

Syntax of B.U. Accumulators

Algorithm Returns Who runs it

KeyGen(1k) PK,SK,AccØ Manager

AddEle(x,AccX,SK) AccX {x} Manager

DelEle(x,AccX,SK) AccX\{x} Manager

WitGen(x,AccX,SK) Witness w relative to AccX Manager

Verify(x,w,AccX,PK) Returns Yes whether x є X User

UpdWitGen(X,X’,SK) UpdX,X’ for elements x є X X’ Manager

UpdWit(w,AccX,AccX’,UpdX,X’,PK) New witness w’ for x є X’ User

Correctness

• DefinitionThe scheme is correct iff:

w := WitGen(x,AccX,SK) Verify(x,w,AccX,PK) = Yes

w := WitGen(x,AccX,SK)

UpdX,X’ := UpdWitGen(X,X’,SK)

w’ := WitGen(w,AccX,AccX’,UpdX,X’,PK)

Verify(x,w’,AccX’,PK) = Yes

Manager

Security Model [CL02,WWP08]User

(Adversary) (Oracle)

Insert Request for xi

Acc

Delete Request for xj

Acc’

PK,AccØ

Witness Request for xi

w

Upd k,l

UpdateInfo Request from k to l

…

…

…

(x,w) such that w is valid but x є X

Batch Update Construction [WWP08]

Attack on [WWP08]

But x1 does not belong to X2!

User

X0 := Ø

Insert x1

Delete x1 X 1 := {x1}

Please send UpdX1,X2 X2 := Ø

UpdX1,X2

With UpdX1,X2 I can

update my witness wx1

Manager

Batch Update is Impossible

• Theorem:Let Acc be a secure accumulator scheme with deterministic UpdWitand Verify algorithms.

For an update involving m delete operations in a set of N elements,the size of the update information UpdX,X' required by the algorithm

UpdWit is (m log(N/m)).

In particular if m=N/2 we have |UpdX,X'| = (m) = (N)

X={x1,x2,…,xN} X={x1,x2,…,xN}

AccX , {w1,w2,…,wN} Compute AccX, {w1,w2,…,wN}

Delete Xd:={xi1

,xi2,…,xim

}X’ := X\Xd

AccX’ , UpdX,X’Compute

AccX’,UpdX,X’

Proof 1/3

User Manager

Proof 2/3

User

X={x1,x2,…,xN}{w1,…,wN}AccX, AccX’, UpdX,X’

For each element xєX

w’ := UpdWit(w,AccX,AccX’,UpdX,X’)x w’ valid?

YES

NO

CASE 1

User can reconstruct the set Xd

CASE 1

If x is not in X’ => Scheme insecure

x still in X’

CASE 2

CASE 2

If x is in X’ => Scheme incorrect

x not in X’ anymore

Proof 3/3

• There are subsets of m elements in a set of N elements

• We need log ≥ m log(N/m) bits to encode Xd

( )Nm

( )Nm

(See updated version at eprint soon for a detailed proof)

Conclusion

• Batch Update is impossible.

• Batch Update for accumulators with few delete operations?

• Improve the lower bound in a factor of k.

Thank you!

Correction

• With negligible probability Bob could obtain a fake witness (and the scheme would still be secure)

=> The number of “good”subsets Xd is less than

( )N

m

A more careful analysis

• Pr[Xd leads to a fake witness] ≤ ε(k)

=> #”Good Xd sets” ≥ (1- ε(k))

=> |UpdX,X'| ≥ m log(M/m) + log(1- ε(k))

=> |UpdX,X'| ≥ m log(M/m) -1

=> |UpdX,X'| = ( m log(M/m))

( )Nm