## 3 Design
### Overall Architecture  
Figure 2 shows the overall architecture of the proposed distributed encryption scheme. Our proposed scheme consists of a single master and multiple slaves, connected through MPI-based communication. **Security model and threat assumptions:** We assume a semi-honest threat model where the master node is trusted to perform key generation and distribution. Our threat model specifically considers an adversary equipped with a quantum computer, capable of breaking classical public-key algorithms such as RSA and ECC. This threat is critical because these algorithms are traditionally used to exchange symmetric keys (e.g., for AES), which could compromise the entire encryption workflow. To address this, our proposed scheme is designed to be resilient against such quantum attacks on the key-exchange mechanism through a layered integration of Kyber-based PQC for key encapsulation and QKD for protecting key transmission. In addition, slave nodes may be partially compromised, but cannot access complete key materials due to the use of secret sharing and QKD-based key masking. All communication occurs over classical channels without built-in confidentiality. To ensure secure transmission, key materials and data subsets are encrypted before being sent. QKD operations are simulated using Qiskit Aer, and session validity is verified through QBER-based rejection. Trust in the quantum channel is limited to the eavesdropping detection properties of the BB84 protocol. **Master:** The master is responsible for secure key generation, offset partitioning and assignment, and coordination of encryption and decryption across all slaves. The master includes the following components: _UnifiedCryptoModule_ and _Coordinator_. First of all, to improve key confidentiality, _UnifiedCryptoModule_ assigns distinct roles to PQC and QKD. It generates a symmetric AES key and encapsulates it using a Kyber-based PQC key pair (e.g., public and secret keys). The encapsulated key is shared with each slave, while the PQC secret key is masked using a BB84-based QKD key. The QKD key is securely established through a BB84-based protocol between the master and each slave. To improve fault tolerance, the masked PQC secret key can optionally be divided using [PERSON]'s secret sharing [74; 75] and distributed across multiple slaves. This layered design protects different parts of the keying process against separate threats: PQC resists quantum decryption of key exchange, and QKD prevents the secret key from exposure during distribution. Second, _Coordinator_ manages both encryption and decryption stages. During encryption, _Cipher Dispatcher_ logically partitions the target file into fixed-size subsets (e.g., 4, 8, or 16 MB) and assigns byte-range offsets (e.g., offset_start, offset_end) to each slave. To support parallelism, each slave independently encrypts its assigned byte range without requiring inter-node synchronization. This enables globally distributed encryption, as disjoint offsets prevent overlap and remove the need for coordination among nodes. _Cipher Sender_ on the master transmits the assigned offset ranges along with encryption metadata such as the PQC ciphertext and QKD-masked secret key to each slave, enabling local AES key reconstruction and subset encryption. During decryption, _Cipher Receiver_ asynchronously gathers encrypted subsets from all slaves. The collected subsets are then reordered by the _Cipher Sorter_ based on subset indices (e.g., subset_idx). The recovered AES key is then used to decrypt all subsets in parallel using a thread pool, where each decrypted subset is immediately written to the recovered file at its designated offset. This streaming-based and offset-aware decryption approach eliminates the need to aggregate all decrypted data in memory, thereby preventing memory exhaustion and ensuring efficient and stable memory usage even when handling large files.