# How Secure Are Two-Way Ping-Pong and LM05 QKD Protocols under a Man-in-the-Middle Attack?
## 3 Security of the Protocols
That would give us a conditional security of the protocol._  
Taken together, the analysis carried out in [20] is applicable and correct for the attacks on two-way protocols in which [PERSON] reads off the states of qubits with the help of ancillas but is inapplicable to MITM attacks. Therefore, their proof is not universal, i.e., cannot be considered unconditional. Can [PERSON] and [PERSON] still achieve reliable security of their two-way protocol? To answer this let us first compare one-way (e.g., BB8) and two-way protocols. Under standard attacks on one way protocols, [PERSON] is left with less and less information about the key when she approaches the critical disturbance \(D_{crit-\text{MM}}=0.11\), i.e., the messages she snatches end up scrambled, up to 50% of the time. However, [PERSON] also scrambles [PERSON] and [PERSON]'s messages so that after PA, half of the messages are deleted and half coincide. So, neither party is left with any usable bit. In two-way protocols under MITM it is different. [PERSON] does not scramble [PERSON] and [PERSON]'s messages at all at higher and higher values of \(D_{\text{CM}}\) and the longer she is in the line the more messages she copies; for \(D_{Max-\text{CM}}=0.5\) their secret keys are identical and no bare PA (hashing only) can change that. However, with two-way protocols, when [PERSON] is not in the line all the time, [PERSON] and [PERSON] carry out the PA, guided by the level of disturbance, i.e., the error rate in the CM. The standard PA uses a binary string of obtained messages to produce a new shorter strings via universal hashing. [PERSON] randomly chooses a (permutation) function \(f:\{0,1\}^{m}\rightarrow\{0,1\}^{k(m)}\) among some universal\({}_{2}\) class of functions. She then sends both \(f(x)\) and a description of \(f\) to [PERSON] via universal hashing. After computing \(f(y)\), where \(y\) is his corresponding string, [PERSON] checks whether it agrees with \(f(x)\). If it does, a basic property of universal hashing allows them to assume that \(x=y\) ([34], p. 214). The problem emerges with this version of the PA, i.e., with algorithms it makes use of, because [PERSON] and [PERSON] should be able to estimate the length \(k(m)\) of the secure key with respect to the length of the raw key \(m\) which would guarantee them that [PERSON] is not in possession of a single bit of \(k(m)\), but via their bare (\"blind\") PA they always get \(x=y\), i.e., they do not have a benchmark for estimating the amount of bits [PERSON] lost. The PA procedures elaborated in the literature do not help since they are made for one-way protocols (BB84, B92, etc.) and are rather involved and intricate--c.f. [35]. We have not found a PA procedure elaborated for two-way protocols in the literature. What makes it challenging is the asymptotic approach of \(I_{AE}(D_{\text{CM}})\) to \(I_{AB}=1\) shown in Figure 1(b), which is absent in the BB84 protocol--see Figure 1(a), on the one hand, and the high \(D\), on the other. Whether we can find an efficient PA algorithm for two-way protocols remains to be seen. A special kind of an aBB84-like protocol in which the \(\mathbb{X}\) basis serves as MM and \(\mathbb{Z}\) as CM proposed by [PERSON] et al. [22] can help us to better understand the problem of unlimited \(D\). We call the protocol a message-control-(a)symmetric BB84 (mcasBB84) protocol. In Table 1 we compare the properties of the BB84, two-way, and mcasBB84 protocols under MITM attacks. Let us consider a MITM attack on mcasBB84 (mcasBB84-MITM) which [PERSON] carries out so as to measure and resend all qubits in the \(\mathbb{X}\) basis. Since [PERSON] receives only \(|0\rangle\) and \(|1\rangle\) messages and resends them unchanged, she does not introduce any disturbance in the MM and \(I_{AB}=1\). [PERSON]'s \(I_{AE}\) rises with her increased presence in the line. If she were in the line all the time, we would have \(D_{\text{CM}}=0.5\) and \(I_{AE}=1\). However, the protocol does not allow that.