## 4 Evaluation
### Throughput  
**End-to-End:** Figure 5 shows the end-to-end runtime performance of our proposed scheme compared to AES (Original) across different subset sizes (e.g., 4 MB, 8 MB, and 16 MB). The \(x\)-axis represents the input file size ranging from 10 GB to 100 GB, and the \(y\)-axis represents the total runtime in seconds. The legend distinguishes AES (baseline, single-node execution) and our proposed scheme evaluated on 4, 6, and 8 nodes (e.g., one master and multiple slaves), respectively. The end-to-end runtime for AES includes file read, encryption, decryption, and output generation on a single node. In contrast, our proposed scheme includes file read, quantum-resilient security, which includes PQC-based AES key encapsulation and QKD-based session key masking, parallel AES encryption, inter-node communication, decryption at the master, and the generation of the final output file. As shown in the figure, our proposed scheme consistently achieves lower runtime than the AES (Original) baseline across all subset sizes and file sizes. For 100 GB file, the runtime is reduced from 432.01 to 302.28 s with 4 MB, from 408.38 to 270.44 s with 8 MB, and from 451.86 to 190.86 s with 16 MB, achieving 1.43\(\times\), 1.51\(\times\), and 2.37\(\times\) speedups, respectively. Overall, our proposed scheme shows 1.43\(\times\) to 2.37\(\times\) improvement over AES (Original), depending on the subset size. However, the end-to-end runtime does not scale linearly with the number of nodes, primarily because the decryption phase is centrally performed at the master node. The master node centrally manages the Kyber-decapsulated AES key and QKD-masked secret keys, with the goal of minimizing exposure to key compromise during recovery. Despite this centralized decryption overhead, our scheme shows consistent performance gains across all file sizes, demonstrating its effectiveness in balancing security requirements with parallel execution efficiency. **Encryption:** Figure 6 shows the encryption-only runtime performance of our proposed scheme compared to AES (Original) across various subset sizes (e.g., 4, 8, and 16 MB). As shown in the figure, the encryption stage exhibits linear scalability as the number of nodes increases, enabled by offset-aware partitioning that assigns disjoint byte ranges to each slave, allowing AES encryption to proceed independently without inter-node synchronization and centralized bottlenecks. For 70 GB file, encryption is faster as more nodes are used. With 4 MB sizes, the encryption runtime is reduced from 163.34 s (AES) to 133.83, 128.83, and 88.61 s on 4, 6, and 8 nodes, respectively, achieving 1.26\(\times\) to 1.84\(\times\) speedups. With 8 MB, it is reduced from 155.16 (AES) to 114.67, 72.09, and 20.09 s, showing improvements of 1.35\(\times\) to 7.72\(\times\). The most significant gain is observed with 16 MB, where the encryption runtime decreases from 155.92 (AES) to 54.25, 31.41, and 17.98 s, yielding 2.87\(\times\) to 8.67\(\times\) speedups depending on the number of nodes. A similar trend is observed  
Figure 5: End-to-End Performance comparison between AES (Original) and Proposed (PQC + QKD + AES) across multi-node. for the 100 GB file. With 4 MB, runtime is reduced from 228.86 s (AES) to 220.67, 204.36, and 159.74 s on 4, 6, and 8 nodes, resulting in 1.04\(\times\) to 1.43\(\times\) speedups. With 8 MB, it is reduced from 198.73 (AES) to 176.16, 156.10, and 114.99 s, showing 1.13\(\times\) to 1.73\(\times\) improvements. For 16 MB, the runtime decreases from 252.62 (AES) to 153.41, 43.34, and 31.17 s, achieving 1.65\(\times\) to 8.11\(\times\) speedups. **Decryption:** Figure 7 shows the decryption runtime performance of our proposed scheme compared to AES (Original), evaluated with 100 GB input across different subset sizes (e.g., 4, 8, and 16 MB). As decryption is centrally performed at the master node, the decryption runtime is primarily bounded by the master's local execution, regardless of the number of slave nodes.