4

It's a very standard move in a game-based security proof to have a transition in which we "abort" on some event such as a hash collision; the two games are identical apart from the abort step, and we add the probability of the abort to the advantage term at the end. Example: https://eprint.iacr.org/2023/1368

I'm curious if anyone has explicitly formalized and justified this step. The way aborts are used seems very similar to but slightly different from either the "failure events" in Shoup's paper or the "bad events" in Bellare and Rogaway; neither of those papers contains the word "abort". In particular, it's clear that in the case of "failure events"/"bad events" that the attacker keeps making queries and still returns a final result, while it's not clear to me what happens after an "abort".

Note that this is not related to aborts in the protocol, as in eg Dilithium signing or Kyber encapsulation rejection; this is to do with aborts used as a tool in proofs about a protocol.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
Paul Crowley
  • 247
  • 1
  • 10

1 Answers1

2

This is interesting. The use of "abort" must be early. For example, Goldreich used it in his textbook, and we can find it in his draft from July 2000 (see p421, "in this case A' aborts"):

http://www.wisdom.weizmann.ac.il/%7Eoded/PSBookFrag/sign1.ps

This example is in the proof of Lamport's one-time signature (1979), and it is used in the case when the reduction can not succeed. One may exhaustively search the related literature for earlier use of "abort" in this line.

This example may also show a difference between "abort" and "bad event": if the reduction algorithm knows it fails already, it simply aborts; otherwise, a bad event happened but the reduction does not know and continues.

xacid
  • 74
  • 2