This document summarizes a paper on the impossibility of batch updates for cryptographic accumulators. It shows that batch updates, which allow efficient witness updates for multiple insertions and deletions with a single update, cannot be achieved for cryptographic accumulators. The proof demonstrates that the size of the update information required is Ω(m log(N/m)), where m is the number of deletions and N is the total number of elements. Therefore, the size of the update information grows with the number of deletions, preventing truly efficient batch updates.
8. Manager
Acc1, Acc2, Acc3
Insert(x)
Witness
( x , )
Bob Alice
Verify( x , , Acc3) = YES
9. Manager
Acc1, Acc2, Acc3, Acc4
Delete(x)
OK
Bob Alice
Verify( x , , Acc4) = FAIL
10. Manager
Acc1, Acc2, Acc3,…
Cryptographic
Insert(x)
Accumulator
Witness
( x , )
Bob Alice
Verify( x , , Acc3) = YES
11. Main constructions
Security Note
[BeMa94] RSA + RO First definition
[BarPfi97] Strong RSA -
First dynamic
[CamLys02] Strong RSA
accumulator
First universal
[LLX07] Strong RSA
accumultor
[Ngu05] Pairings E-cash, ZK-Sets,…
eStrong RSA
[WWP08] Batch Update
Paillier
[CHKO08] Collision-Resistant Hashing Untrusted Manager
[CKS09] Pairings Group multiplication
12. Manager
Acc1, Acc2, Acc3
x1 w1 x2 w2 x3 w3
Bob 1 Bob 2 Bob 3
13. Problem: after each update of the
accumulated value it is necesarry
to recompute all the witnesses.
14. Delegate Witness Computation?
Manager
Verify(x,w,Acc)
Replica
Constructions (Compute User (Verify)
a single witness)
[CL02] O(|X|) O(1)
[GTT09] O(|X|1/ε) O(ε)
[CHK08] O(log |X|) O(log |X|)
15. Batch Update
[FN02] Manager
…,Acc99, Acc100, Acc101,…, Acc200,…
Upd100,200
Bob 1 Bob 2 Bob 29 Bob 42
(x1,w1,Acc100) (x36,w36,Acc100) (x1,w1,Acc100) (x1,w1,Acc100)
( x2,w2,Acc100) ( x87,w87,Acc100) ( x20,w20,Acc100) ( x2,w2,Acc100)
( x6,w6,Acc100) ( x69,w68,Acc100) ( x6,w6,Acc100)
( x64,w64,Acc100) ….
…
16. Batch Update
[FN02] Manager
…,Acc99, Acc100, Acc101,…, Acc200,…
Bob 1 Bob 2 Bob 29 Bob 42
(x1,w1’,Acc200) (x36,w36’,Acc200) (x1,w1’,Acc200) (x1,w1’,Acc200)
( x2,w2’,Acc200) ( x87,w87’,Acc200) ( x20,w20’,Acc200) ( x2,w2’,Acc200)
( x6,w6’,Acc200) ( x69,w68’,Acc200) ( x6,w6’,Acc200)
( x64,w64’,Acc200) ….
…
17. Batch Update [FN02]
Trivial solution:
UpdXi,Xj = {list of all witnesses for Xj}
More interesting:
|UpdXi,Xj| = O(1)
18. 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}|)
19. 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
20. Correctness
• Definition
The scheme is correct iff:
w := WitGen(x,AccX,SK) Verify(x,w,AccX,PK) = Yes
w := WitGen(x,AccX,SK)
Verify(x,w’,AccX’,PK) = Yes
UpdX,X’ := UpdWitGen(X,X’,SK)
w’ := WitGen(w,AccX,AccX’,UpdX,X’,PK)
21. Security Model [CL02,WWP08]
PK,AccØ
Insert Request for xi
(Adversary)
Acc (Oracle)
…
Delete Request for xj
Acc’
Witness Request for xi
w
…
UpdateInfo Request from k to l
Upd k,l
…
(x,w) such that w is valid but x є X
23. Attack on [WWP08]
User Manager
X0 := Ø
Insert x1
Delete x1 X 1 := {x1}
Please send UpdX1,X2 X2 := Ø
UpdX1,X2
With UpdX1,X2 I can
update my witness wx1
But x1 does not belong to X2!
24. Batch Update is Impossible
• Theorem:
Let Acc be a secure accumulator scheme with deterministic UpdWit
and 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)
26. Proof 2/3
CASE 1 CASE 2
If x is not in X’ => If x is in X’ =>
X={x1,x2,…,xN} Scheme insecure Scheme incorrect
{w1,…,wN}
AccX, AccX’, UpdX,X’ x still in X’ x not in X’ anymore
User
CASE 1
YES
For each element w’ :=
xєX x UpdWit(w,AccX,AccX’,UpdX,X’) w’ valid?
NO
CASE 2
User can reconstruct the set Xd
27. Proof 3/3
• There are ( ) subsets of m elements in a set
N
m
of N elements
• We need log( ) ≥ m log(N/m) bits
N
m
to encode Xd
(See updated version at eprint soon for a detailed proof)
28. Conclusion
• Batch Update is impossible.
• Batch Update for accumulators with few
delete operations?
• Improve the lower bound in a factor of k.
30. 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
31. A more careful analysis
• Pr[Xd leads to a fake witness] ≤ ε(k)
=> #”Good Xd sets” ≥ ( ) (1- ε(k))
N
m
=> |UpdX,X'| ≥ m log(M/m) + log(1- ε(k))
=> |UpdX,X'| ≥ m log(M/m) -1
=> |UpdX,X'| = ( m log(M/m))