# How CL-signature can act as positive & additive accumulator?

A paper (http://ieeexplore.ieee.org/abstract/document/7961987/) proposes a Braavos (adaptively sound dynamic positive accumulator).

Braavos uses two other accumulators. One is adaptively sound positive additive accumulator $ACC_A$ and the other is an non-adaptively sound positive dynamic accumulator $ACC_{NA}$.

In the paper, the authors says that they uses Camenisch-Lysyanskaya (CL) signatures (http://dl.acm.org/citation.cfm?id=1766811.1766838) as $ACC_A$.

I cannot understand how CL signature can be adopted as $ACC_A$.

$ACC_A$ requires {Gen, Add, Del, MemWitUpOnAdd, VerifyMem} protocols, but in the CL protocol they does not exist. {only Gen, Sign, and Verify}

My goal is to implement Idemix with Braavos (same as the paper).

Does anyone can let me know how can I implement $ACC_A$ using CL signature.

## 1 Answer

Any signature scheme can work as an accumulator: when elements are signed with the manager's secret key, signature works as a system membership witness (positive acc). It is also additive because you can only add elements in the system by signing them, you cannot cancel a signature in the future (to delete them).

• Thanks for your reply. But does a signature represent only one element? How it accumulates 'multiple elements' into one value? – takita Feb 14 at 4:07
• correct! It doesn't accumulate, you can just consider the set of all signed elements as a positive additive accumulator. Proof of membership equals signature verification. If you are referring to accumulator size=1 of Fig.10 (signatures column), I think it just means that you don't need to store anything else than the public key to verify a proof membership. If you ever want to remove a member from the set, you need a second accumulator to add the deleted elements there (this makes it dynamic). – Joho Feb 15 at 1:34
• or add the still valid ones, depends on the implementation (Braavos or BraavosB-Appendix) – Joho Feb 15 at 1:45