Why do we need multiple adversaries in a game-based definition?

Question

Consider we have a protocol, where multiple algorithms of it are run by an adversary.

When we want to define a game for that protocol (or its security properties), I have seen that an adversary is defined as $A=(A_1,A_2,...A_n)$. Then each of them (e.g. $A_1$) calls a certain algorithm and outputs something (in other words its role is one-off).

Question: Why do we need multiple adversaries instead of a single one? why cannot always use only one adversary (like here)?

Answer 1

It is a way of formalizing a security definition as an interactive game played against an adversary.

In an interactive game between an adversary and challenger, the adversary outputs some value, then the challenger responds, then the adversary chooses another value, etc etc. It's possible to define things at this level of formality (by using phrases like "adversary outputs a value and gets another value in response"). But sometimes you also want to introduce some precise notation about this interaction.

One way to do this is to think of the adversary (and challenger) as "next message" functions. This paper is considering $A_1$ to be the algorithm that outputs the adversary's first thing, $A_2$ is the algorithm that takes the challenger's response as input and outputs the adversary's second thing, etc. This kind of notation is formal and precise, but clunky. It's often also necessary to allow $A_1$ to pass its internal state ahead to $A_2$, etc. In the paper that you link, the goal is to apply to literally any interactive security game, thus the more formal style.

Here's an example for chosen plaintext security for public-key encryption. A perfectly reasonable way to define it would look like this:

• Challenger chooses $b\gets \{0,1\}$, generates a keypair $(pk,sk)$, and gives $pk$ to the adversary
• Adversary chooses plaintexts $m_0,m_1$
• Challenger encrypts $m_b$ and gives the result to the adversary
• Adversary outputs a guess $b'$, and wins the game if $b'=b$

A more "formalistic" way of defining the same interaction might read:

• $b \gets \{0,1\}$ [challenger chooses random bit $b$]
• $(sk,pk) \gets \textsf{KeyGen}$ [challenger chooses key]
• $(m_0,m_1,\textsf{state}) \gets A_1(pk)$ [adversary gets public key and chooses two plaintexts]
• $c \gets \textsf{Enc}(pk,m_b)$ [challenger encrypts one of the plaintexts]
• $b' \gets A_2(\textsf{state}, c)$ [adversary gets ciphertext and outputs a bit $b'$]
• declare the adversary winner if $b = b'$