On Simulation-Sound Trapdoor Commitments

1. On Simulation-Sound Trapdoor Commitments Phil MacKenzie, Bell Labs Ke Yang, CMU

2. Outline • Basic commitment properties (informal) • Binding, hiding • Examples: Physical, Cryptographic • Stronger commitment properties (informal) • Equivocability (trapdoorness) • Non-malleability • Interlude: commitment “tags” • Universal composability • New property: Simulation-sound binding • Definition • Constructions: DSA, Cramer-Shoup signatures, 1-way functions • Applications: SSZK, NMZK, UCZK • How does it fit in? – comparison to NM commitments

3. Basic Commitment properties • A commitment is like a note placed inside a combination safe • Commit stage: Alice writes a note, places it inside a combination safe, spins the lock, and gives the safe to Bob • Open stage: Alice tells Bob the combination • Properties: • Binding: After giving the safe to Bob, Alice cannot alter the note written inside • Hiding: Bob cannot determine the contents of the note until he learns the combination

4. Examples • Physical: note in a combination safe • Cryptographic: • Example [P91]: based on DL assumption • Say discrete log of h wrt g is unknown • Commit to a value x: com=grhx • Open: reveal (x,r)

5. Stronger properties for commitments • Equivocability (trapdoor) • Non-malleability • Universal Composability • Simulation Soundness

6. Stronger properties: Trapdoor commitment scheme [BCC88] • Equivocability: • There is a trapdoor that would allow a sender to alter the value of the commitment • Example: • Discrete log of h wrt g is the trapdoor, say h=gs • Commit to a value x using “public key” h: com=grhx • Open: • reveal (x,r) • To equivocate to x’: • reveal (x’,r’), where r’=r+s(x-x’)

7. Non-malleable commitment scheme [DDN91],[DIO98] • Non-malleability (intuition): • Say Alice makes a commitment com to an (unknown) value v. • [DDN91]: An adversary should not be able to produce a new commitment com’ to a value v’ related to v with non-negligibly better probability after seeing com than before seeing com. • [DIO98]: Like [DDN91], except that the adversary is also required to open com’ after com is opened • We use [DIO98]: “non-malleability wrt opening”

8. Com’ Com Open Open v’ v Com’ Com Open Open v’ v Non-malleable commitment scheme [DDN91],[DIO98] • Non-malleability (wrt opening): • Experiment 1: • Experiment 2: Adversary has no advantage in Expt 1 over Expt 2 in producing com’  com and v’ related to v

9. Interlude: Tag-based definitions • Each commitment will have an associated tag • New goal: prevent the adversary from breaking a security property using a commitment with a new tag • Tags (specifically, identities) are also discussed in [F01], [DKOS01]

10. Com’ Com Open Open tag’ tag’ tag tag v’ v Com’ Com Open Open v’ v Tag-based non-malleable commitment scheme • Non-malleability (wrt opening): • Experiment 1: • Experiment 2: Adversary has no advantage in Expt 1 over Expt 2 in producing com’ with tag’  tag and v’ related to v

11. Alice Alice Example of tag-based security • Authenticated communication model • Use tag-based non-malleable commitments with tag=identity • Bob gains nothing by producing a (mauled) commitment with tag=Alice! Com(v) Maul! Com(v+1)

12. Commit(x) Receipt FCOM Open x Stronger properties: Universally composable commitment scheme [CF01] • Securely realizes the commitment functionality in UC framework • Functionality FCOM • Intuitively it must have equivocability, non-malleability, and “extractability” • Extractability requirement increases complexity

13. (“open”, com, v) tag (“commit”, tag) r com Open v1 com’ v2 tag’ Open Simulation-sound trapdoor commitments • Equivocability + • Simulation-sound binding Adversary should not be able to equivocate a com’ with a new tag’, even though it sees commitments with other tags equivocated

14. Simulation-sound trapdoor commitments • Why the name? • In proofs, we want a simulator to be able to equivocate on commitments, but we don’t want this to help the adversary (equivocate on commitments) • Similar to SSZK: we want a simulator to be able to produce valid proofs of false statements, but we don’t want this to help the adversary (produce valid proofs of false statements) • Alternative: Simulation-Bound?

15. Some history… • Original motivation: in developing an efficient UCZK protocol secure against adaptive adversaries in [GMY03], we needed an efficient commitment scheme with a new security property • We called such a scheme “SSTC” • The property was specific for that application and had a complicated definition • After publishing [GMY03], we discovered a simpler, more natural security property, and more applications for commitment schemes with this property • We “borrowed” the name SSTC • Suggest calling the original scheme “SSTC(GMY)”

16. SSTC scheme based on DSA • Intuition: use “com=grhx” type of trapdoor commitment, but with the trapdoor being a DSA signature on tag • Adversary may see com equivocated, and thus may obtain the trapdoor: the DSA sig on tag • By security of DSA, adversary cannot generate a DSA sig on a new tag’, so he cannot equivocate a com’ with a new tag’

17. SSTC scheme based on DSA - Details • DSA signature on m with public key y(=gx): • sig=(r,s), where r=gk, s=k-1(H(m)+xr) • Note: rs = gH(m)yr, so s is the discrete log of gH(m)yr base r • SSTC scheme based on DSA: • Commit to v with tag using public key y(=gx): • com=(r, rahv), where r=gk, h=gH(tag)yr • Note that for s=DL(h,r), (r,s) is a DSA signature on tag

18. Other SSTC schemes • Based on Strong RSA • Construction based on Cramer-Shoup signatures [CS99] • Based on any one-way function • Construction based on the UC commitment scheme of [CLOS02] • One-way function replaced by signature on tag (signature scheme based on one-way function) • Note: the UC commitment scheme uses a trapdoor permutation (for extractability)

19. What is the relation between SSTC schemes and signatures? • From an SSTC scheme it is easy to construct a signature scheme • (pk,sk) the same • Sign(m): Generate a double opening of a commitment using tag=m

20. Applications • SSZK, NMZK, UCZK • Simpler than [GMY03] constructions

21. Prover “X is true” Verifier Initiate Challenge Response (Verify) Prover Verifier Turns HVZK into Concurrent ZK [D00,JL00] (vk,sk) <-- gen-keys vk “X is true” TC-Commit( ) Initiate Wrap with signature Challenge TC-Open(), Response (Verify) Signsk(transcript) Verify signature with vk Application: SSZK protocol • Basic “honest-verifier” ZK: “Initiate-challenge-response” paradigm • New SSZK Protocol (sketch)

22. Prover “X is true” Verifier Initiate Challenge Response (Verify) - To produce valid proofs of false statements, Sim must equivocate on commitment - For adversary to do the same, he must either use same tag (breaking sig), or a new tag (breaking SSTC) Prover Verifier (vk,sk) <-- gen-keys vk “X is true” SSTC-Commit(tag=vk, ) Initiate Wrap with signature Challenge SSTC-Open(), Response (Verify) Signsk(transcript) Verify signature with vk Application: SSZK protocol • Basic “honest-verifier” ZK: “Initiate-challenge-response” paradigm • New SSZK Protocol (sketch)

23. Application: UCZK Protocol • Ideal functionality FZK FZK Prove(Alice,Bob,x,w) If R(x,w) Proved(Alice,Bob,x)

24. If Charlie must prove something, he must use a different tag (so cannot equivocate) Prover(Alice) Verifier(Bob) “X is true” SSTC-Commit(tag=<Alice,Bob>, ) Initiate Challenge SSTC-Open(), Response (Erase random bits before sending last message) (Verify) Application: UCZK protocol • Proof is bound to <sender,receiver> pair • Only need to prevent an adversary from producing a proof of an incorrect statement that is valid for a different <sender,receiver> pair! • New UCZK Protocol (sketch) • Internal protocol must be an -protocol (to allow straightline extraction)

25. SSTCs versus NM commitments • Making it fair: • Consider tag-based NM commitment schemes • Similar results hold for body-based schemes • Consider NM Trapdoor Commitments • Allow NM adversary to query an equivocation oracle • Refine definitions to allow specific number of equivocated commitments • SSTC(n) and NMTC(n)

26. TC SSTC NMTC SSTCs versus NMTC commitments SSTC(0) SSTC(1) … SSTC(n) SSTC(n+1) … SSTC() NMTC(0) NMTC(1) … NMTC(n) NMTC(n+1) … NMTC()

27. Conclusion • You should now believe SSTC schemes are • Interesting • Important • Useful • Efficient • Named correctly