# Novel Designated Ownership Transfer with Grouping Proof
## 4 Performance Analysis  
This section analyzes the combination of [PERSON]'s protocol [22] with grouping proof protocols that do not require a predetermined sequence [5; 24; 25] and compares the computation capacity loads against our proposed protocol. To ensure unbiased comparison, the analysis was conducted at scan rate of 3.55 M clock cycles per second according to [PERSON] et al. 's effectiveness analysis [23]. Additionally, asymmetric encryption and error-correcting code were employed using the same security strength of \(2^{80}\) bits. The computation time for XOR logic operation was minimal (compared to the crypto-algorithm) and was therefore neglected and not included in the comparison. The reader adopted for this comparison was assumed to have powerful arithmetic capability. Table 3 lists the notations used for the computation comparison. Table 4 presents the computation costs of the compared protocols. Each of the readers in our proposed protocol can manage a maximum of \(r\) tags, and therefore sends only one multicast message to all the tags. The grouping proof protocols in [24; 25] can also send multicast messages to all tags, but, when \(m>r\), the reader must transmit the message multiple times, thus requiring a computation time of \(\lceil m/r\rceil\) times. Our protocol adopts a multilayered grouping proof structure. Although a similar message is broadcast, readers are required to communicate with each other. Therefore, our computation time would require \(\lceil log_{r}(m/r)\rceil\) times. According to the method proposed by [PERSON] et al. [25], the computational cost of the reader would increase depending on the number of \(m\) tags because the reader would need to verify the identification code of each tag. [PERSON] and Peeters [5] and [PERSON] et al. [24] employed methods in which identical messages are broadcast to all tags, ensuring the constant computational capacity required by the reader to generate grouping proofs. \begin{table}
\begin{tabular}{l c c} \hline \hline \multicolumn{1}{c}{**Schemes**} & \multicolumn{1}{c}{**Tag**} & \multicolumn{1}{c}{**Mobile Reader**} \\ \hline [PERSON] [22] + Hermes and Peeters [5] & \(9 mT_{SE}+4 mT_{H}+(\lceil 2/r\rceil)mT_{EC}+(\lceil 2/r\rceil)mT_{ENG}\) & \((4m+7)T_{SE}+4 mT_{H}+T_{SIG}+T_{ENG}\) \\ [PERSON] [22] + [PERSON] et al. [24] & \((9+\lceil 2/r\rceil)mT_{SE}+4 mT_{H}+(\lceil 1/r\rceil)mT_{ENG}\) & \((4m+9)T_{SE}+(4m+2)T_{H}\) \\ [PERSON] [22] + [PERSON] et al. [25] & \(9 mT_{SE}+4 mT_{H}+(\lceil 2/r\rceil)mT_{ENG}\) & \((4m+7)T_{SE}+4 mT_{H}+(\lceil 5\rceil)T_{ENG}+2T_{SIG}\) \\ Our Protocol & \(2T_{C}+T_{M}+2T_{H}+T_{ENG}\) & \(2T_{C}+5T_{SE}+2T_{SIG}+4T_{H}+3T_{NG}+3T_{ENG}\) \\  & & \(+(\lfloor log_{r}(m/r)\rceil)(3T_{SE}+2T_{H}+T_{ENC})\) \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Computational capacity. \begin{table}
\begin{tabular}{l l} \hline \hline
**Symbol** & **Description** \\ \hline \(T_{SE}\) & computation time for conducting symmetric encryption and decryption \\ \(T_{RNG}\) & required time for generating a random number \\ \(T_{H}\) & computation time for executing a hash function \\ \(T_{EC}\) & required time for conducting elliptic curve encryption and decryption \\ \(T_{SIG}\) & required time for proof signing \\ \(T_{M}\) & required time to compute a message authentication code \\ \(T_{G}\) & required time for encrypting and decrypting a group key \\ \(m\) & total tags \\ \(r\) & maximum number of tags that a reader can scanned concurrently \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Computational capacity symbol notations. We use \"OP\" as an abbreviation for our proposed protocol; \"ZY\" represents the combination of Zuo [22] and [PERSON] et al. [25]; \"ZS\" represents the combination of Zuo [22] and [PERSON] et al. [24]; and \"ZH\" represents the combination of Zuo [22] and Hermes and Peeters [5]. Figures 8 and 9 show the readers with the maximum reading capacity of 200 tags employed to determine the computing times required by various methods.