Examples of protocols that are insecure when run concurrently I was reading Canetti00 Universally Composable security paper. The first page of introduction says that there are some MPC protocols and Zero knowledge protocols that are insecure under concurrent composition. I don't see why protocols might break when concurrently composed together. 

Please provide some examples of protocols that are insecure under concurrent composition. 

Does the same type of attacks hold for parallel composition? What's the difference?

Does the same type of attacks hold if the protocols are run many times one after another (Let's say to improve soundness error)?

Edit: @Mikero gave a nice MPC protocol that is not secure under concurrent composition. Can anyone give an example of ZK protocol that is insecure under concurrent composition?
Consider the function $f : \{L,R\} \times \{ U,D \} \to \{0,1,2\}$ defined by the following table:

$$
   \begin{array}{c|cc}
      f &amp; L &amp; R \\
      \hline
      U &amp; 0 &amp; 0 \\
      D &amp; 1 &amp; 2
   \end{array}
$$

Let's say Alice has input from $\{L,R\}$ (she chooses a column) and Bob has input from $\{U,D\}$ (he chooses a row).

A simple protocol for $f$ is as follows:


Bob announces his input in the clear. If his input is $U$, then parties can halt, as they know the output must be 0.
If Bob's input is $D$, then Alice announces her input in the clear. With both inputs known, the parties can compute the output.


This protocol is secure against active adversaries in a standalone security model, but it is insecure when three instances are executed concurrently.

Imagine the following scenario: 


Bob is honest and chooses one of the instances to have input $U$ and the other two to have input $D$. There are three such combinations ($UDD, DUD, DDU$) and he chooses with uniform probability. 
Alice is corrupt. She wins the game if she can cause the 3 instances to have all distinct outputs. It's not hard to see that she can only win by using different inputs in the two instances where Bob chooses input $D$.


If parties have access to 3 parallel instances of ideal $f$, then it is easy to see that Alice can only win with probability 1/3. In this setting, Alice's choice of input is independent of Bob's. There must be (at least) two $f$-instances where Alice uses the same input, and with probability 1/3 those will both be ones where Bob uses input $D$.

But in the presence of concurrent protocol instances, it is easy for Alice to win with probability 1. The protocols can be run in lockstep, and Alice just waits for the first protocol message in each instance. Then she can send appropriate (different) protocol messages in the instances that proceed to step #2.

Since Alice can influence the protocol in some way that she cannot influence ideal instances of $f$, the protocol is insecure in this setting.



This example is a bit simplified. I assumed that the ideal calls to $f$ were done in parallel. But it is not hard to adapt this kind of example to different requirements on the ideal world. 

The big picture is that a standalone-secure protocol can leak some information early in the protocol, with the reasoning that this information is something that could be deduced from the output anyway (like Bob's input in this case). But in the presence of concurrent composition, and correlated inputs between different instances, this kind of leakage can be unsafe.