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 rewindingXA
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: ExampleF 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 Protocolx3 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!