Download presentation

Presentation is loading. Please wait.

1
**Secure Composition of Cryptographic Protocols**

Hi, I’ll be talking about the concurrent password based key exchange in the plain model. This is joint work with Vipul Goyal and Rafi Ostrovsky. Vipul Goyal Microsoft Research, India

2
**Secure Computation Protocols [Yao86, GMW87]**

x3 x2 x1 x4 f(x1,x2,x3,x4) No information other than f(x1,x2,x3,x4)

3
**Secure Computation Protocols contd..**

General positive results [Yao86, GMW87]: secure protocols can be constructed for any poly-time computable functionality Designing cryptographic protocols was a difficult and error prone task: these results show that the design can in fact be automated Secure computation: vibrant research area for the past two decades; large body of published literature

4
Concurrent Security The classical results are only in the standalone setting; only one protocol execution Network setting: possibility of man-in-the-middle attack Starting from the work of Bellovin and Meritt in 92, Password-based key exchange has been studied extensively over the last two decades. This is only a small incomplete list of the prior work done in this area. Password based key exchange has been studied in various security models, namely, random oracle and ideal cipher models, the common reference string model as well as the plain model. In terms of security guarantees, we can differentiate between security in the stand-alone setting vs security in the concurrent setting. I will discuss these settings in more detail very shortly. The focus of this work is on constructing password based key exchange protocols that are secure in the concurrent setting in the plain model.

5
**General Concurrent Setting**

So far, we’ve only considered the stand-alone setting. A more natural and demanding setting is where several instances of a protocol are executed concurrently. In such a setting, several parties across different sessions may be corrupted. The corrupted parties can be seen as a single adversary who is involved in concurrent executions of several left and right sessions. Now It could be the case that an adversary who does not know the secret passwords is able to maul the left sessions in order to succeed in the right sessions. However, in the absence of left sessions, he fails in successfully establish shared keys. The concurrent setting is very realistic, and arguably the only natural setting to consider, if, for instance, we wish to run protocols over the Internet. In the context of password based key exchange, we can imagine several users trying to login to a server at the same time. Very realistic setting: for e.g., protocols running over Internet

6
**Concurrent Security: Model**

Starting from the work of Bellovin and Meritt in 92, Password-based key exchange has been studied extensively over the last two decades. This is only a small incomplete list of the prior work done in this area. Password based key exchange has been studied in various security models, namely, random oracle and ideal cipher models, the common reference string model as well as the plain model. In terms of security guarantees, we can differentiate between security in the stand-alone setting vs security in the concurrent setting. I will discuss these settings in more detail very shortly. The focus of this work is on constructing password based key exchange protocols that are secure in the concurrent setting in the plain model. view

7
**Concurrent Security Strong and far reaching impossibility results in**

“plain model” We will later show example of an attack over protocols in the concurrent setting [CF’01, Lin’03a, Lin’03b, CKL’03, Lin’04, BPS’06] However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

8
Talk Overview Chosen protocol attack to break security in the concurrent setting Natural way of constructing concurrent protocols and the main problem that arises The general paradigm to construct concurrent protocols Multiple ideal call model Prediction paradigm Resettable computation protocols Conclusion and open problems However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

9
**Chosen Protocol Attack**

Consider any protocol π for ZK (AOK) functionality: prover proves it knows w Another protocol π’ chosen according to π. In π’: If party1 can successfully prove knowledge of w (which a verifier of π would accept), party2 gives out w itself: mutual authentication They are both secure standalone. Note that adv can get w in the real world. However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider. π’ π w

10
**Chosen Protocol Attack: Ideal World**

Adv has no way of proving the statement when π replaced by ideal execution Shows impossiblity of such a π even when only 2 executions π’ w 0/1 However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider. ┴

11
**Concurrent Self Composition**

Now say just a single protocol π (multiple copies running); still define π’ as earlier (not executed over the network) Idea: We will eliminate party2 of π’ by converting it into a bunch of garbled circuits and giving to adv Take the next message function of party2 in different rounds, construct GC and give to Adv (as aux input) π’ However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider. π . w

12
**Concurrent Self Composition: Problem**

Problem: Who has the GC keys? Bob should have it Adv needs to perform OT with Bob to execute the GC π’ However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider. π . w

13
**ZK + OT functionality [BPS’06]**

1 or 2, input 1 or 2, input The main problem in this approach can be seen as follows. Note that in the concurrent setting the adversary controls the scheduling of messages across all the sessions. The interleaving of protocol messages could be arbitrary, for e.g., it could be the case that a session s1 contains another session s2. This can be seen as follows. Here the blue arrows denote messages of session s1 and orange arrows correspond to session s2. Now, our simulation is based on rewinding. Also, as is the case with simulators for active adversaries, our simulator would need to extract the adversary’s input in each session and obtain an output from the ideal functionality in order to perform simulation successfully. Focusing here on the orange session, we can imagine that, for example, during the simulation, simulator extracts the adversary’s input in this session and then obtains a corresponding output from the ideal functionality before sending the 3rd message to the adversary. Now, given the above interleaving of sessions s1 and s2, it could happen that at some point during the simulation, the simulator rewinds past the beginning of session s2 while trying to simulate for session s1. If this happens, then the adversary could actually change his input in session s2 when it is re-executed. Notice that in this case, our simulator would extract a new input value from the adversary in session s2, and would therefore need a new query to the ideal functionality in order to successfully continue simulation. Recall that in our definition we do allow the simulator a constant number of queries per session. However, the bad news is that if we use the simulator of Barak et al, then we may require polynomial queries for a session which would violate our definition. In order to solve this problem, we borrow some techniques from the work on precise simulation, which I will now describe. Mode 1: plain ZK functionality Mode 2: plain OT functionality

14
**Concurrent Self Composition**

Adv gets the message to be fed to GC; puts this execution of π on hold Starts another concurrent session of π in the OT mode; gets the relevant wire keys; evaluates GC Adv still can’t get w from GC’s in the ideal world (even given aux input): real world has msg of ZK mode but not ideal π’ π However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider. m m .

15
**Getting Positive Results: General Paradigm**

However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

16
**Simulators in Standalone Setting**

Rewind and Extract Adv input Query TP to get output Continue This way, can argue adv learns no more than output Extract XA XA However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider. F(XA,XH) A F S

17
**Understanding Concurrent Setting**

✕ Simulator would again extract input by rewinding (in the concurrent setting), query TP and continue Any type of rewinding by the simulator is a fundamental problem With that background on concurrent non-malleable zero knowledge, one can think of a natural approach for constructing a concurrently secure password based key exchange protocol. We can start with a two-part computation protocol Pi for the password functionality that is secure in the honest but curious case. Then, in order to obtain security against active adversaries in the concurrent setting, we can compile the semi-honest protocol with concurrent non-malleable zero knowledge arguments due to Barak Prabhakaran and Sahai. Unfortunately, this approach does not work! I will now describe some of the main problems and our solutions.

18
**Main Problem: Specific Adversary**

Say Sim rewinds blue session anywhere The inner session executed twice fully from the beginning Adv may choose a different input each time The main problem in this approach can be seen as follows. Note that in the concurrent setting the adversary controls the scheduling of messages across all the sessions. The interleaving of protocol messages could be arbitrary, for e.g., it could be the case that a session s1 contains another session s2. This can be seen as follows. Here the blue arrows denote messages of session s1 and orange arrows correspond to session s2. Now, our simulation is based on rewinding. Also, as is the case with simulators for active adversaries, our simulator would need to extract the adversary’s input in each session and obtain an output from the ideal functionality in order to perform simulation successfully. Focusing here on the orange session, we can imagine that, for example, during the simulation, simulator extracts the adversary’s input in this session and then obtains a corresponding output from the ideal functionality before sending the 3rd message to the adversary. Now, given the above interleaving of sessions s1 and s2, it could happen that at some point during the simulation, the simulator rewinds past the beginning of session s2 while trying to simulate for session s1. If this happens, then the adversary could actually change his input in session s2 when it is re-executed. Notice that in this case, our simulator would extract a new input value from the adversary in session s2, and would therefore need a new query to the ideal functionality in order to successfully continue simulation. Recall that in our definition we do allow the simulator a constant number of queries per session. However, the bad news is that if we use the simulator of Barak et al, then we may require polynomial queries for a session which would violate our definition. In order to solve this problem, we borrow some techniques from the work on precise simulation, which I will now describe. .

19
Main Problem Contd.. F S A How does the adversary get the outputs and continue in green session? Allowed to query F only once per real world session The main problem in this approach can be seen as follows. Note that in the concurrent setting the adversary controls the scheduling of messages across all the sessions. The interleaving of protocol messages could be arbitrary, for e.g., it could be the case that a session s1 contains another session s2. This can be seen as follows. Here the blue arrows denote messages of session s1 and orange arrows correspond to session s2. Now, our simulation is based on rewinding. Also, as is the case with simulators for active adversaries, our simulator would need to extract the adversary’s input in each session and obtain an output from the ideal functionality in order to perform simulation successfully. Focusing here on the orange session, we can imagine that, for example, during the simulation, simulator extracts the adversary’s input in this session and then obtains a corresponding output from the ideal functionality before sending the 3rd message to the adversary. Now, given the above interleaving of sessions s1 and s2, it could happen that at some point during the simulation, the simulator rewinds past the beginning of session s2 while trying to simulate for session s1. If this happens, then the adversary could actually change his input in session s2 when it is re-executed. Notice that in this case, our simulator would extract a new input value from the adversary in session s2, and would therefore need a new query to the ideal functionality in order to successfully continue simulation. Recall that in our definition we do allow the simulator a constant number of queries per session. However, the bad news is that if we use the simulator of Barak et al, then we may require polynomial queries for a session which would violate our definition. In order to solve this problem, we borrow some techniques from the work on precise simulation, which I will now describe. .

20
**More Details Our simulation is based on rewinding**

XA X’A m2,2 m'2,2 Extract X’A≠XA Extract XA F(XA,XH) F(X’A,XH) m2,3 m'2,3 m'1,2 m1,2 F S A m1,3 Our simulation is based on rewinding Adversary controls scheduling of messages arbitrary interleaving : a session s1 may “contain” another session s2 S extracts adv’s input in each session The main problem in this approach can be seen as follows. Note that in the concurrent setting the adversary controls the scheduling of messages across all the sessions. The interleaving of protocol messages could be arbitrary, for e.g., it could be the case that a session s1 contains another session s2. This can be seen as follows. Here the blue arrows denote messages of session s1 and orange arrows correspond to session s2. Now, our simulation is based on rewinding. Also, as is the case with simulators for active adversaries, our simulator would need to extract the adversary’s input in each session and obtain an output from the ideal functionality in order to perform simulation successfully. Focusing here on the orange session, we can imagine that, for example, during the simulation, simulator extracts the adversary’s input in this session and then obtains a corresponding output from the ideal functionality before sending the 3rd message to the adversary. Now, given the above interleaving of sessions s1 and s2, it could happen that at some point during the simulation, the simulator rewinds past the beginning of session s2 while trying to simulate for session s1. If this happens, then the adversary could actually change his input in session s2 when it is re-executed. Notice that in this case, our simulator would extract a new input value from the adversary in session s2, and would therefore need a new query to the ideal functionality in order to successfully continue simulation. Recall that in our definition we do allow the simulator a constant number of queries per session. However, the bad news is that if we use the simulator of Barak et al, then we may require polynomial queries for a session which would violate our definition. In order to solve this problem, we borrow some techniques from the work on precise simulation, which I will now describe. During simulation, S may rewind past s2 while simulating s1 A may change input every time s2 is re-executed Sim can only query once per session; adv may keep aborting and all rewinds may fail; real concern

21
The General Paradigm The key to a positive result lies in overcoming this problem (differently in different settings) Protocol very natural (similar to GMW paradigm): Take a protocol providing security against semi-honest adversary Compile it with concurrent ZK (For stronger notions, compiling with concurrent non-malleable zero-knowledge [Barak-Prabhakaran-Sahai’06] may be necessary) Keep in mind: Need to successfully rewind at least once (in each session) to extract However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

22
**The Multiple Call Model**

However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

23
**Relaxed Security Notion**

Allow multiple calls per session in the ideal world Problem goes away, simulator can continue If a session executed multiple times with different inputs, just query the TP multiple times for it; get output; continue In particular, positive result known with (expected) constant number of ideal calls per real world session [G-Jain-Ostrovsky’10] However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

24
**The Security Guarantee**

Normal security guarantee: adv learns no more than one output on an input of its choice New security guarantee: learns no more than a few outputs on inputs of its choice Guarantee still meaningful: adv can’t learn input or an arbitrary function of the input e.g., if the functionality only gives out signatures on even numbers, adv can’t get signature on an odd number However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

25
**Concurrent password based key exchange**

A positive result in this model directly leads to the first concurrent PAKE in the plain model [G-Jain-Ostrovsky’10] Any construction in this model shown to satisfy Goldreich-Lindell’01 definition of PAKE More general: settings of authentication/access control Say adv succeeds in guessing only with negl probability. Situation remains same even if you allow constant (or even poly) guesses However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

26
Open Problem What if simulator only allowed to make strict constant number of calls per session (rather than expected) Efficiency related questions: round complexity / communication complexity However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

27
**The Prediction Paradigm**

However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

28
**Prediction Paradigm [G’11]**

Now we stick to the standard definition; positive results hard to come by High level idea: How do we get the output w/o querying TP? We try to predict Can argue prediction important in some sense to get a result in the plain model; if you can’t predict, no secure protocol exists for that functionality However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

29
**Single Input Setting: Minimal Clean Model of CSC**

Various clients, concurrently interacting with a server, holding a single fixed input x y1 Clients x1 . xn f(x, y1) . x Server yn f(x, yn)

30
**Positive Results in this Setting**

Almost all functionalities can be securely realized in the single input setting Plain model, standard definition More precisely: all except where ideal functionality behaves as a (worst case hard) PRF

31
**Positive result implications: Examples**

Private database search: Server holds dbase with k entries, clients holds predicates f1(.) entry1 entry2 . entryk gets entryi if f1(entryi) = 1 . fn(.) Server Immediately gives concurrent private information retrieval, keyword search / pattern matching, etc

32
Examples contd.. Privacy preserving data-mining: secure set intersection, computing the k-th ranked element, etc We get concurrently secure protocols for all these functionalities of special interest Password based key exchange: (only) previous result [GJO’10] was according to a weaker definition of [GL’01], strict improvement

33
Prior to this result Only known result in the plain model, (fully) concurrent setting: zero-knowledge functionality [DNS’98, RK’99, …]

34
**Prediction paradigm: Example**

F S A Sim can rewind several times/ at several places; problem Try to predict output and complete at least one rewinding FAIL: if Adv keeps aborting everywhere; Adv may have aux The main problem in this approach can be seen as follows. Note that in the concurrent setting the adversary controls the scheduling of messages across all the sessions. The interleaving of protocol messages could be arbitrary, for e.g., it could be the case that a session s1 contains another session s2. This can be seen as follows. Here the blue arrows denote messages of session s1 and orange arrows correspond to session s2. Now, our simulation is based on rewinding. Also, as is the case with simulators for active adversaries, our simulator would need to extract the adversary’s input in each session and obtain an output from the ideal functionality in order to perform simulation successfully. Focusing here on the orange session, we can imagine that, for example, during the simulation, simulator extracts the adversary’s input in this session and then obtains a corresponding output from the ideal functionality before sending the 3rd message to the adversary. Now, given the above interleaving of sessions s1 and s2, it could happen that at some point during the simulation, the simulator rewinds past the beginning of session s2 while trying to simulate for session s1. If this happens, then the adversary could actually change his input in session s2 when it is re-executed. Notice that in this case, our simulator would extract a new input value from the adversary in session s2, and would therefore need a new query to the ideal functionality in order to successfully continue simulation. Recall that in our definition we do allow the simulator a constant number of queries per session. However, the bad news is that if we use the simulator of Barak et al, then we may require polynomial queries for a session which would violate our definition. In order to solve this problem, we borrow some techniques from the work on precise simulation, which I will now describe. .

35
PAKE Example . Extract PA PH A S . TP answers whether or not given password is correct (PA = PH) Can predict correctly (with noticeable probability) with at most 1 failed rewinding Sim rewinds; extracts in green session; can’t query TP Simply predicts the output to be 0 (wrong password) The main problem in this approach can be seen as follows. Note that in the concurrent setting the adversary controls the scheduling of messages across all the sessions. The interleaving of protocol messages could be arbitrary, for e.g., it could be the case that a session s1 contains another session s2. This can be seen as follows. Here the blue arrows denote messages of session s1 and orange arrows correspond to session s2. Now, our simulation is based on rewinding. Also, as is the case with simulators for active adversaries, our simulator would need to extract the adversary’s input in each session and obtain an output from the ideal functionality in order to perform simulation successfully. Focusing here on the orange session, we can imagine that, for example, during the simulation, simulator extracts the adversary’s input in this session and then obtains a corresponding output from the ideal functionality before sending the 3rd message to the adversary. Now, given the above interleaving of sessions s1 and s2, it could happen that at some point during the simulation, the simulator rewinds past the beginning of session s2 while trying to simulate for session s1. If this happens, then the adversary could actually change his input in session s2 when it is re-executed. Notice that in this case, our simulator would extract a new input value from the adversary in session s2, and would therefore need a new query to the ideal functionality in order to successfully continue simulation. Recall that in our definition we do allow the simulator a constant number of queries per session. However, the bad news is that if we use the simulator of Barak et al, then we may require polynomial queries for a session which would violate our definition. In order to solve this problem, we borrow some techniques from the work on precise simulation, which I will now describe.

36
**PAKE Example PH Simply predicts the output to be 0 (wrong password)**

. PH A S . Simply predicts the output to be 0 (wrong password) Rewinding strategy failure => predicted output distinguishable (from correct) Output must have been 1, PA must be the correct password!! Now sim can in fact execute the protocol honestly!!! The main problem in this approach can be seen as follows. Note that in the concurrent setting the adversary controls the scheduling of messages across all the sessions. The interleaving of protocol messages could be arbitrary, for e.g., it could be the case that a session s1 contains another session s2. This can be seen as follows. Here the blue arrows denote messages of session s1 and orange arrows correspond to session s2. Now, our simulation is based on rewinding. Also, as is the case with simulators for active adversaries, our simulator would need to extract the adversary’s input in each session and obtain an output from the ideal functionality in order to perform simulation successfully. Focusing here on the orange session, we can imagine that, for example, during the simulation, simulator extracts the adversary’s input in this session and then obtains a corresponding output from the ideal functionality before sending the 3rd message to the adversary. Now, given the above interleaving of sessions s1 and s2, it could happen that at some point during the simulation, the simulator rewinds past the beginning of session s2 while trying to simulate for session s1. If this happens, then the adversary could actually change his input in session s2 when it is re-executed. Notice that in this case, our simulator would extract a new input value from the adversary in session s2, and would therefore need a new query to the ideal functionality in order to successfully continue simulation. Recall that in our definition we do allow the simulator a constant number of queries per session. However, the bad news is that if we use the simulator of Barak et al, then we may require polynomial queries for a session which would violate our definition. In order to solve this problem, we borrow some techniques from the work on precise simulation, which I will now describe.

37
Previous Works Results on concurrent ZK can be seen as a special case of this paradigm (nothing to predict; output is known) Bounded concurrent setting: special case where prediction required only in bounded number of rewindings However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

38
Open Problems Round Complexity: very high; large polynomial depending upon the input size; functionality; security parameter …. Extend results beyond the single input setting: lot to gain if the prediction paradigm can be generalized However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

39
**Resettable Computation Protocols**

However, as it turns out, strong and far reaching impossibility results have been shown for secure computation of functionalities in the concurrent setting. Therefore, we consider a definition for password based key exchange that is weaker than the standard definition for secure computation, yet natural for the our problem. So let me now describe the security definition that we consider.

40
**Typical Secure Computation Protocol**

x3 x2 x1 f(x1,x2,x3,x4) x4

41
**Resettable (Prover) Zero Knowledge**

Statement: x in L Verifier 2 R, W Verifier 1 Prover [Cannetti-Goldreich-Goldwasser-Micali’00] Resettable zero-knowledge arguments exist under standard cryptographic assumptions

42
**Resettable Prover ZK and Concurrent ZK**

Resettable prover ZK is also concurrent ZK Verifier Verifier Prover

43
**Resettable Verifier Zero Knowledge**

Prover 1 W1 Prover 2 W2 R Verifier [Barak-Goldreich-Goldwasser-Lindell’01] Resettable Verifier zero-knowledge arguments exist under standard cryptographic assumptions

44
**Other Works Studying Resettable Model**

[Micali-Reyzin (Eurocrypt 2001)], [Bellare-Fishlin-Goldwasser-Micali (Eurocrypt 2001)], [Micali-Reyzin (Crypto 2001)], [Barak-Lindell-Vadhan (FOCS 2003)], [Zhao-Ding-Lee-Zhu (Eurocrypt 2003)], [Yung-Zhao (Eurocrypt 2007)], [Deng-Lin (Eurocrypt 2007)] Consider only zero-knowledge (or closely related) functionalities

45
Question Do there exist functionalities other than zero knowledge for which resettably secure protocols are possible?

46
**Resettable Secure Computation [G-Sahai’09, G-Maji’11]**

General completeness theorem: For every (PPT computable) two party functionality, there is a resettably secure protocol [G-Sahai’09]: Setting involves a smartcard and a user. User can reset the smartcard anytime. Protocol insecure if smartcard can reset user [G-Maji’11]: general setting; any number of parties can be reset by the adv anytime Build on the techniques of simultaneous resettable ZK by Deng-G-Sahai’09

47
Stateful Computation 0x0a4c1833a1 0x0a3c387 0x0a3c 0x0 0x0a3c3870fb

48
**Stateless Computation**

F(m2) m2’ F(m2’) F Parties in the protocol can be made stateless Parties don’t need to maintain state about any execution, can help in preventing DoS attacks, etc

49
**Impossibility of Concurrently Secure Protocols**

Resettable Protocols are Concurrently Secure too Far reaching impossibility results [Lin03, Lin04, BPS06] ruling out concurrently secure protocols for a large class of functionalities Are we stuck?

50
Model Adversarial user has the power to reset and interact with the smartcard as many times as it wants (in the real model) Simulation only possible if an equivalent power given in the ideal model Thus, in the ideal model, adv user given the power to reset the ideal functionality and interact many times

51
**Ideal Model: Resettable 2pc**

Both parties send their inputs x1 and x2 to TP TP computes result f(x1, x2) and sends it to the adversary Unless adversary aborts, TP sends f(x1, x2) to the honest party The adversary can signal reset to the trusted party. Ideal world comes back to the initial state where adv can choose a different input (and get another output) Thus: we have solved the problem of multiple calls

52
Open Problems Round Complexity: Current protocols have polynomial round complexity Assumptions: What can we do without assuming NIZK’s? Even for weaker notions General study of using same / correlated randomness, or, same / correlated state in cryptographic protocols

53
**General Technique: Other Applications**

Super-polynomial simulation [Garg-G-Jain-Sahai’11] Input indistinguishable computation [Garg-G-Jain-Sahai’11]

54
**Conclusion and Open Problems**

Most of the protocols have round complexity anywhere from super log to a large polynomial Round Complexity: could be improved for many protocols if we could resolve the problem of constant round concurrent ZK (and concurrent NM ZK) What is the right notion of concurrent security which is still achievable? Seems several incomparable notions

55
**Conclusion and Open Problems**

Nice thing: for many of these notions, the protocols are now very similar (based on compiling with C-ZK or CNMZK) Can we understand what is the security guarantee that the protocol achieves: of course can list all the models in which it is secure one by one. But we believe that the world is more beautiful than that.

56
Thank You!

Similar presentations

Presentation is loading. Please wait....

OK

Variations of the Turing Machine

Variations of the Turing Machine

© 2019 SlidePlayer.com Inc.

All rights reserved.

To make this website work, we log user data and share it with processors. To use this website, you must agree to our Privacy Policy, including cookie policy.

Ads by Google