1 / 21

Identity-Based Zero-Knowledge

Identity-Based Zero-Knowledge. Jonathan Katz Rafail Ostrovsky Michael Rabin U. Maryland U.C.L.A. Harvard U. History: recall original ZK motivation of GMR. Prover can interactively convince verifier that x is in L

toya
Download Presentation

Identity-Based Zero-Knowledge

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Identity-Based Zero-Knowledge Jonathan Katz Rafail Ostrovsky Michael Rabin U. Maryland U.C.L.A. Harvard U. 1

  2. History: recall original ZK motivation of GMR • Prover can interactively convince verifier that x is in L • Later, verifier can not convince someone else • This prevents off-line plagiarism (i.e. Verifier later claiming the proof as his own). 2

  3. What about on-line Adv? • Verifier can play man-in-the-middle • Handled by the “designated verifier proofs” • [Jackobson,Sako, Impagliazzo], others • This LIMITS the dissemination of proofs! 3

  4. What we want… • To publish the proofs as widely as possible with the authors names • Prevent plagiarism • So, why not use NIZK? 4

  5. NIZK reminder [BFM] • Common reference string (R.S.) • Prover sends a single message • Its transferable • Its ZK: • Can simulate the same view [BDPM] • Can simulate with the same R.S. [DDOPS] 5

  6. So are we done? • Any verifier can take a NIZK proof, and either • change it a bit, but still keep it valid or (The first point can be addressed with non-malleable NIZK [DDN][S][DDPOS]) • claim it as his own and simply copy 6

  7. Non-Malleable NIZK • Non-malleability [DDN] “can not constructed related encrypted msg” • Non-malleability for NIZK [S][DDOPS] “whatever the verifier can prove after seeing a prove, it can do without seeing the proof” Technical points: • (1) generation of CRS; • (2) 1 thm vs. many theorems; • (3) adaptivity; • (4) adv. challenges and the guarantees • So, use the strongest def, are we done? 7

  8. What is the def. of preventing plagiarism? • You have an NP theorem and a witness • You want is transferable • You have your name (id) as part of it… • Want to “bind” the proof to your name (id) such that nobody can change the proof to a different id’ 8

  9. ID-ZK • This talk we concentrate on NIZK (but the notion applies to interactive setting as well) • A new notion: NIZK with extractable identity: • Prover(id,x,w,CRS)  proof • 2 public algs: • check correctness • extract id from proof • ZK: for all x in L, and all id, can generate comp indist. View. (1 thm or multiple thms). • Sound (w.h.p. can not “cheat”) 9

  10. Security of ID-ZK • Sound • Can not change identities • Informally: no poly-time Adv. Can take one or several ID-ZK proofs, and construct a proof for a new id of an “interesting” theorem • Interesting  something can Adv. Could not do without any help. 10

  11. Security of ID-ZK (cont.) • NIZK with extractable identity is ID-ZK if: • Adv asks for ID-ZK proofs of different theorems, and different id’s • Adv comes up with a proof of a thm with a new id • Simulator can output comp. indist. Distribution of thms with new id without any ID-ZK proofs. • again several variants of what Adv can ask, the strongest is simulation-soundness 11

  12. Remarks about the model • PK-infrastructure – does it help? (i.e. what if the prover “signs” his proof?) • No, the adv can just get rid of the signature and substitute his own! 12

  13. Remarks about the model (cont.) • NIZK with a single random string – what does security mean? (since simulator must have a trapdoor info) • The point is that we can do the proof without the trapdoor – if there is an adv who can cheat, the proof implies that we can use it to derive the contradiction! 13

  14. How easy is it to construct? Also, what is the connection to NIZK in the non-interactive setting? 14

  15. Why not use non-mall NIZK? • Claim 1: there exists non-malleable NIZK proofs which are not ID-ZK. • Claim2: there exists ID-ZK NIZK proofs that are not non-malleable NIZK. 15

  16. Why not use non-mall NIZK? • Claim 1: there exists non-malleable NIZK proofs which are not ID-ZK. • Standard non-mall NIZK do not have any ID. I can simply copy the proof and claim it as my own • Remark: [DDN] showed how with ID’s non-mall NIZK is easier to build, this is different! 16

  17. Why not use non-mall NIZK? • Claim2: there exists ID-ZK proofs that are not non-malleable. • Proof idea: take ID-ZK proof, where we attach the first (undetermined) bit. This is malleable, but can still be shown to be ID-ZK! 17

  18. ID-ZK are closely related to non-mall NIZK • Claim 3: assuming any non-mall NIZK we can construct ID-ZK NIZK. • Claim 4: assuming any ID-ZK NIZK, we can construct non-mall NIZK 18

  19. ID-ZK are closely related to non-mall NIZK • Claim 3: assuming any non-mall NIZK we can construct ID-ZK • given (x,w,id) we construct ID-ZK: as follows: • Define langue L’(x,id): “either x in L or (a new portion) of CRS is a commitment to id”. • Send is ID-ZK (id, non-mall-NIZK for L’). • Intuition: if can create new id, violates non-malleability! 19

  20. ID-ZK are closely related to non-mall NIZK • Claim 4: assuming any ID-ZK we can construct non-mall NIZK • Proof idea: use as ID a signature public-key, i.e. id = PK. • Let B = id-zk(id,x in L) • Send (id; B; signpk(B)) • Note: same proof-structure works for interactive case. 20

  21. CONCLUSIONS • Many previous works (including DDN) used identities in constructions but this is the first formal definition of binding names to proofs. • Our definition is the most interesting part, seems to be a useful building block. • What about application-specific efficient implementations? 21

More Related