# A Hybrid Encryption Scheme for Quantum Secure Video Conferencing Combined with Blockchain
## 6 Experimental Evaluation
### Execution Cost  
In order to test the time cost, the hardware simulation environment for the blockchain application experiment was an Intel Core i5-7200 2.50 GHz dual-core processor with 12G of running memory and a 64 bit Windows 10 computer operating system. The ubuntu20.04 system with 4 GB of memory and 50 GB of hard disk was established by using VMware Workstation Pro 16.2.3. With the open-source Hyperledger fabric v2.2, we built a blockchain network with one Org organization, two peer nodes, and one orderer node and set the block out time to 2 s. The application program was built based on the fabric go sdk. Considering the actual situation of the video conference system, miners generate blocks after uploading the ciphertext information of the meeting minutes to the blockchain. That is, each block only saves the ciphertext information of one meeting minutes. We tested the time cost of uploading the meetings' minutes to the blockchain with different lengths, as shown in Figure 12. According to the length of the meeting minutes in real life, the user's application will use 100, 200, 300, 400, 500, 600, 700, 800, 900, and 1000 characters as the ciphertext information of the meeting minutes and upload them to the blockchain, and the average block generation time is 2232 milliseconds. We found that the block generation time of 300 characters was the longest, while that of 1000 characters was the shortest, so the block generation time had little relationship with the character length, but it was related to the network delay between the application and the blockchain. The reason for the network delay in our experiment was probably the processing power of the computer at that time. According to this experiment, based on the processing time of 1000 characters, the network delay times of other characters were 83, 24, 191, 0, 98, 3, 0, 169, and 34, respectively. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**References** & **Encryption Method** & **Key Randomness** & **Key Generation Mode** & **Scheme Type** \\ \hline [21] & One-time pad & Random & Six-state scheme & Experiment \\ [22] & One-time pad & Random & BB84 scheme & Experiment \\ [25] & Arnold scrambling + block encryption + & Pseudo-random & Two-state Pauli & Experiment \\  & bidirectional diffusion & & quantum walks & \\ [27] & Obfuscation method based on back & Pseudo-random & Quantum random walk & Experiment \\  & propagation neural network & & & \\ [28] & AES & Pseudo-random & Quantum random walk & Experiment \\ Ours & One-time pad + AES & Random & QKD & Actual \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Scheme comparison. \begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Reference [27]** & **Reference [25]** & **Ours** \\ \hline Encryption time (s) & 0.075–0.080 & 0.331–0.339 & 0.0501–0.0505 or greater than 1.5 \\ decryption time (s) & 0.080–0.085 & 0.331–0.339 & 0.0510–0.0515 or greater than 1.5 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Calculation speed test. We created 100, 200, 300, 400, 500, 600, 700, 800, 900, and 1000 blockchain blocks, respectively, for the simulated query experiments and compared the B+ tree query of the cache layer with the original query efficiency of the blockchain, as shown in Figure 13 and Table 6. The query time of B+ tree is the return time of the user's cache layer according to the keyword index. The original query time of the blockchain is the time when the user sends the keyword index to the blockchain and the blockchain returns to the user after querying. In order to ensure the correctness, we calculated the time consumption of different query algorithms, respectively, and then, took the average of 10 times. Through calculation, the original query times of the blockchain with different lengths were 18.9, 19.2, 20.4, 19, 19.6, 21.5, 21.9, 20.3, 17.4, and 20.3, respectively; the query time of the cache B+ tree was 5.7, 8.1, 4.8, 4.6, 8.6, 5.9, 5.6, 6.3, 5.1, and 7.3, respectively.