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

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

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

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=g r h x Open: reveal (x,r)

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

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=g s Commit to a value x using “public key” h: com=g r h x Open: – reveal (x,r) To equivocate to x’: –reveal (x’,r’), where r’=r+s(x-x’)

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”

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

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]

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

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) Alice Maul! Com(v+1) Alice

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

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

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?

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)”

SSTC scheme based on DSA Intuition: use “com=g r h x ” 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’

SSTC scheme based on DSA - Details DSA signature on m with public key y(=g x ): –sig=(r,s), where r=g k, s=k -1 (H(m)+xr) –Note: r s = g H(m) y r, so s is the discrete log of g H(m) y r base r SSTC scheme based on DSA: –Commit to v with tag using public key y(=g x ): com=(r, r a h v ), where r=g k, h=g H(tag) y r Note that for s=DL(h,r), (r,s) is a DSA signature on tag

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)

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

Applications SSZK, NMZK, UCZK –Simpler than [GMY03] constructions

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

Application: SSZK protocol Basic “honest-verifier” ZK: “Initiate- challenge-response” paradigm New SSZK Protocol (sketch) Prover “X is true” Verifier Initiate Challenge Response (Verify) ProverVerifier Initiate Challenge Response (Verify) “X is true” Sign sk (transcript) Verify signature with vk (vk,sk) <-- gen-keys vk Wrap with signature SSTC-Commit(tag=vk, ) SSTC-Open(), - 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)

Application: UCZK Protocol –Ideal functionality F ZK F ZK Prove(Alice,Bob,x,w)Proved(Alice,Bob,x)If R(x,w)

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

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)

SSTCs versus NMTC commitments SSTC(0)SSTC(1)SSTC(n)SSTC(n+1) SSTC(  ) NMTC(0)NMTC(1)NMTC(n)NMTC(n+1) NMTC(  ) …… …… NMTC SSTCTC

Conclusion You should now believe SSTC schemes are –Interesting –Important –Useful –Efficient –Named correctly