5
$\begingroup$

In this paper of J. Baron, et al. (PDF), simulator always aborts the ideal functionality before client outputs its pattern-matching result obtained from the ideal functionality. (See bottom of page 30, and top of page 33)

My questions are:

  1. Why should simulator always abort?
  2. While simulator always abort, is it possible for adversary to distinguish between ideal and real worlds? Since, in ideal world simulator always abort and client will never output anything.
$\endgroup$
2
  • $\begingroup$ Hmm, should we create a pattern-matching or secure-pattern-matching tag? $\endgroup$ – Maarten Bodewes Nov 8 '15 at 14:44
  • $\begingroup$ @MaartenBodewes I would say no as the question is mostly about something else. The example just happens to come from a paper about secure pattern matching. $\endgroup$ – mikeazo Nov 9 '15 at 14:03
4
$\begingroup$

This is very strange, and somewhat suspect. The abort here is one that prevents the client from getting output. However, the real-world adversary may behave in a way that the client does get output. I suggest writing to the authors to ask and/or going through this very carefully. Without having gone through the details at all, my initial guess is that this doesn't seem right. Having said that, I didn't check it at all (and this section does say "Initial...", so maybe this is just part of the simulation).

$\endgroup$
2
  • $\begingroup$ In the paper, they said "Simulator aborts the IF (ideal functionality) before Client outputs its results obtained from the IF". Is it a different thing than sending abort to the IF before IF sends the result to Client? $\endgroup$ – MH Samadani Nov 9 '15 at 14:48
  • $\begingroup$ That's the way I would interpret it. However, this is problematic in general... $\endgroup$ – Yehuda Lindell Nov 9 '15 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.