Download presentation
Presentation is loading. Please wait.
Published byReilly Cradduck Modified over 10 years ago
1
OPENING THE BLACK BOX Boaz Barak Institute for Advanced Study Princeton, NJ New Techniques in Cryptography
2
PROGRAMS ARE HARD TO UNDERSTAND Can’t eliminate bugs Understanding compiled progs even harder “Natural state is complete unreadability” HALTING undecidable SAT probably hard Can’t prove lower bounds
3
PROGRAMS AS BLACK BOXES Programming langs – function calls Algorithms – subroutines, recursion Complexity – reductions Ignore actual code – only care about function Very common: Input Output (i.e., input/output relation)
4
PROGRAMS AS BLACK BOXES Ignore actual code – only care about function Common Intuition: No loss in generality since general code is useless anyway: can’t be understood. Sometimes: Formal Justification (HALTING,SAT) Can we justify it in cryptography? Input Output
5
MODERN CRYPTOGRAPHY A Central Activity: Construct scheme and reduce solving (assumed) hard problem to breaking scheme. Implication: Problem actually hard ) scheme unbreakable (before sun collapses) If common intuition holds (code useless) it’s bad for crypto: limits on reductions good for crypto: can “scramble” programs Show that if 9 a scheme-breaking alg then 9 a problem-solving (e.g. factoring) alg.
6
IN THIS TALK Examine common intuition that “code useless” in crypto. This implies: positive results: more powerful reductions Surprisingly, in many cases intuition is false. Get new (believed unobtainable) crypto schemes. negative results: some schemes can’t be obtained
7
TALK PLAN Part I: “Scrambling/Obfuscating Programs”– A negative result [BGI+01]. Part II: “Zero Knowledge on the Internet” – A positive result [B01]. “light” talk – almost no proofs / formal defs Part III: Some subsequent results [BGGL01,B02,BL02,L02,BLV03,KOS03,PR03,P04]
8
PART I: OBFUSCATION Idea: Directly use “code useless” intuition for crypto: Q: Can we take arbitrary prog P and convert to P’ s.t. 1. P’ has same function as P 2. P’ is not much slower/bigger than P 3. P’ is “completely unintelligible” Procedure to convert P P’ is called “obfuscator”.
9
WHY MIGHT OBFs EXIST? Because progs are hard to understand (bugs,HALTING,…) Maybe compiler is already obfuscator? (e.g., “closed source” considered unreadable) Because in crypto we can do anything :) Some commercial candidates. Diffie&Hellman (76): Maybe can obtain public key enc. by “obfuscating” a private key enc. scheme?
10
WHY SHOULD WE CARE? Interesting in its own right. Constructing OWF-based PK crypto [DH76] ( Arguably central problem of crypto.) Software protection. Digital rights management (DRM) …
11
MAIN RESULT (informal) Thm [BGI+01] : General-purpose obfs, even under very weak defs, do not exist. [BGI+01] Barak, Goldreich, Impagliazzo, Rudich, Sahai, Vadhan, Yang “On the (Im)possibility of Obfuscating Programs”, CRYPTO 2001.
12
DEFINING OBFs Def: O : P P “totally fails” on P if 1. P can be efficiently recovered from O (P) (i.e., complete recovery of source code) 2. P is hard to learn (i.e., can’t recover P using BB access to its function) Thm [BGI+01] : 8 O 9 P s.t. O totally fails on P. (assuming OWF exist) * “TASTE” OF PROOF
13
Pf: Show function family {P , } s.t. O totally fails (code recovery + hard to learn) on random member: Thm [BGI+01] : 8 O 9 P s.t. O totally fails on P. (assuming OWF exist) Define P , (b,x)= b=0, x= b=1, x(0, )= 0 otherwise Claim: 8O for random , w.h.p. O totally fails on P ,
14
Define P , (b,x)= b=0, x= b=1, x(0, )= 0 otherwise Claim: 8O for random , w.h.p. O totally fails on P , * “TASTE” OF PROOF Thm [BGI+01] : 8 O 9 P s.t. O totally fails on P. (assuming OWF exist) Pf: Show function family {P , } s.t. O totally fails (code recovery + hard to learn) on random member:
15
Pf: To recover , from P’= O (P , ) - output P’(1,P’) For random , can’t distinguish bet P , and all-zero function using BB access. Define P , (b,x)= b=0, x= b=1, x(0, )= 0 otherwise Claim: 8O for random , w.h.p. O totally fails on P , Note: In paper, rule out OBFs for programs with bounded input length. Black-box access is useless: Can recover source from obf’d code:
16
MEANING OF RESULT Proved: No general-purpose obf exists. Maybe “virtually general-purpose” obf exists? Counter Ex. “Useful” progs (DES,RSA,AES,SHA,…) Similar to critique of NP-completeness results. O secure
17
MEANING OF RESULT Proved: No general-purpose obf exists. Maybe “virtually general-purpose” obf exists? Similar to critique of NP-completeness results. PROBLEM W/ THIS ARGUMENT “Useful” progs (DES,RSA,AES,SHA,…) Counter Ex. O secure
18
PROBLEM W/ THIS ARGUMENT “Useful” progs (DES,RSA,AES,SHA,…) O secure Q: If Alice writes new prog P, how can she know O is secure on P? “assured” progs A: Maker should provide well-defined set of “assured secure” progs. Problem: in many metrics, counter ex. close to “useful”. Counter Ex.
19
TALK PLAN Part I: “Scrambling/Obfuscating Programs”– A negative result [BGI+01]. Part II: “Zero Knowledge on the Internet” – A positive result [B01]. Part III: Some subsequent results [BGGL01,B02,L02,BLV03,KOS03,PR03,P04]
20
PART II: ZERO KNOWLEDGE Recall: Central crypto activity – Construct scheme S s.t. 9 alg A breaks S ) 9 alg B factors integers Standard Pf: B uses A as BB subroutine Q: Can B gain anything by using A’s code? Intuition: NO – don’t know anything about adversary. [B01]: Intuition is false – obtain results previously proven impossible to obtain w/ black-box pf.
21
ZERO-KNOWLEDGE [GMR85] Roughly: Proof with “no added value”: Alice proves X true (e.g., G 3-colorable) to Bob. Bob learns only that X is true Motivation: Interesting in own right. Identification protocols (prove I know password/secret w/o giving any info [FS86] ) General Protocols – voting/auctions/poker (prove I acted properly w/o compromising my secrets) Ex: Alice knows witness (3-coloring) to X=“G is 3col”, wants to convince Bob is true w/o leaking info about witness.
22
ZERO-KNOWLEDGE [GMR85] Roughly: Proof with “no added value”: A central crypto thm of 80’s [GMW86,FS89,BCY89,GK96] : Anything can be proven in zero knowledge. A central question of 90’s [DNS98] : Is knowledge leaked in a concurrent execution? CONCURRENT ZK Alice proves X true (e.g., G 3-colorable) to Bob. Bob learns only that X is true (a.k.a. “zero-knowledge on the internet”) (using only O(1) communication rounds).
23
CONCURRENT ZK A central question of 90’s [DNS98] : Is knowledge leaked in a concurrent execution? Alice Bob 1 Bob 2 Bob 3 … Bob n Known: Coordinated “Bob” may learn something.
24
CONCURRENT ZK A central question of 90’s [DNS98] : Is knowledge leaked in a concurrent execution? Thm [RK99] : Anything can be proven in concurrent ZK # rounds: O ~ (log n) [KPR00,PRS02] Thm [CKPR01] : Protocols w/ black-box proofs require ~ (log n) rounds. Thm [B01] : Anything can be proven in O(1)-round concurrent ZK. Uses (inherently) non-BB proof * “TASTE” OF PROOF skip (concurrent = bounded concurrent)
25
* “TASTE” OF PROOF Tool: Witness Indistinguishable (WI) proofs [FS89] Weaker property than ZK: When proving a statement X of form A Ç B only required to hide from Bob if A or B is true. What we need to know: Anything can be proven in O(1)-round WI. Unlike ZK, WI composes concurrently [FS89] Thm [B01] : Anything can be proven in O(1)-round concurrent ZK.
26
* “TASTE” OF PROOF AliceBob WIP X true or KC(r)<5n Our Proof System: To prove statement X do: KC(r) = length of min-sized TM M s.t. M()=r ( KC(r)<5n=|r|/2 means r is “compressible” ) r 2 R {0,1} 10n Thm [B01] : Anything can be proven in O(1)-round concurrent ZK. A random r is “incompressible” w.h.p. and so protocol is sound. Next: show no info leaked in 2 executions… skip
27
Suppose Bob learns f(X) after 2 concurrent sessions. We show f(X) is easy to compute (even w/o talking to Alice!) Algorithm to compute f(X) will use Bob’s code! AliceBob 1 r=Bob 1 () Bob 2 r’=Bob 2 (p-dialog) f(X)=Bob 3 (dialog) Sample execution: WIP X true or KC(r)<5n WIP X true or KC(r’)<5n
28
Suppose Bob learns f(X) after 2 concurrent sessions. Algorithm to compute f(X) will use Bob’s code! AliceBob 1 r=Bob 1 () Bob 2 r’=Bob 2 (p-dialog) f(X)=Bob 3 (dialog) Sample execution: WIP X true or KC(r)<5n WIP X true or KC(r’)<5n We show f(X) is easy to compute (even w/o talking to Alice!)
29
Compute (w/o Alice!) string monolog indisting from dialog. AliceBob 1 r=Bob 1 () Bob 2 r’=Bob 2 (p-dialog) f(X)=Bob 3 (dialog) Sample execution: Thus Bob 3 (monolog)=Bob 3 (dialog)=f(X) =Bob 3 (monolog) Look ma, no Alice! ? ? X WIP X true or KC(r’)<5n WIP X true or KC(r)<5n
30
We show f(X) is easy to compute (even w/o talking to Alice!) AliceBob 1 r=Bob 1 () Bob 2 r’=Bob 2 (p-dialog) f(X)=Bob 3 (dialog) Thus Bob 3 (monolog)=Bob 3 (dialog)=f(X) =Bob 3 (monolog) Look ma, no Alice! ? ? X WIP X true or KC(r’)<5n WIP X true or KC(r)<5n Compute (w/o Alice!) string monolog indisting from dialog.
31
AliceBob 1 r=Bob 1 () Bob 2 r’=Bob 2 (p-dialog) f(X)=Bob 3 (dialog) Using some tools (pseudorandom gens, PCP thm), can ensure |Bob 1 |,|Bob 2 |,|p-dialog|<n =Bob 3 (monolog) Look ma, no Alice! ? X WIP X true or KC(r’)<5n WIP X true or KC(r)<5n ! ?!
32
TALK PLAN Part I: “Scrambling/Obfuscating Programs” – A negative result [BGI+01]. Part II: “Zero Knowledge on the Internet” – A positive result [B01]. Part III: Some subsequent results [BGGL01,B02,L02,BLV03,KOS03,PR03,P04]
33
PART III: OTHER RESULTS Positive results using our non-BB techniques: Non-Malleable Commitments (MIM attack) [B02] Resettable model (e.g., smartcards) [BGGL01] Strict poly-time extraction [BL02] General bounded-concurrent computation [L03,PR03,P04] Constant-round multi-party computation [KOS03,P04] Password-based authentication prots [P04] Other directions: Limits on non-BB techniques [BLV03] More separations bet BB and non-BB [BGGL01,BL02,L03]
34
OPEN QUESTIONS Can we construct public key encryption based on one-way functions? Understand power of non-black-box techniques in other contexts in crypto and complexity. (impossible using black-box proofs [IR94]) Prove more negative results for non-black-box techniques. ( Interesting connections to other areas [DNRS00,BLV03])
35
THANK YOU!
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.