Two recent works on resettable security by Vipul Goyal and Amit Sahai:
(1) Resettably Secure Computation
presented at Eurocrypt'09.
(2) Resolving the simultaneous Resettability Conjecture
announced at the rump session of TCC'09.
[Later appeared in FOCS'09.]
Oded's comments
Resetting attacks refer to the possibility of forcing a party
to interact several times using the same internal coin tosses.
Such attacks are natural in a context where the party's randomness
is generated offline and hardwired into the party's strategy
(e.g., as in the case of some "smart cards").
Resetting attacks were first considered in the context of
zero-knowledge, first w.r.t a resetting attack on the prover
(when attempting to gain knowledge)
and later w.r.t a resetting attack on the verifier
(when attempting to fool it into accepting false statements).
[The corresponding primitives are denoted rZK and rsZK, resp.]
The current two works extend the study, first by referring
to arbitrary secure multi-party computation, and second by considering
resetting attacks on both parties in the same zero-knowledge arguments.
In the first work resetting attacks on any honest majority
is considered, but in the case of two-party protocols
the single party to be subjected to such attacks is predetermined
(indeed, as in the case of rZK and rsZK).
The second work seems a necessary condition towards handling
resetting attacks on any party (i.e., not a predetermined one)
also in the case that the honest parties are not in majority
(i.e., the two-party case).
Re the 1st work, it is important to note that resettable security
is defined via an ideal model that allows resetting (or rather
invoking the functionality with the same honest-party input
and different inputs for the other party, which may be adaptovely
selected by the adversary). Note that such an attack cannot be
avoided in the real resetting model, and thus it must be allowed in
the ideal model. Consequently, both the real and ideal models for
resetting attcaks are stronger than the corresponding models for
concurrent executions, and thus resettable security does not
necessarily imply concurrent security. (Indeed, this stands in
contrast to the case of zero-knowledge, where the parties are
supposed to interact on a common input, which cannot be modified
by an adversary.)
The original abstract
The first paper appears in the proceedings of Eurocrypt'09, LNCS 5479.
The second in the proceedings of FOCS'09.
Back to
list of Oded's choices.