DISTRIBUTION

BACKGROUND

Field

[0001] This disclosure is generally related to the field of quantum communication. More specifically, this disclosure is related to a system and method for quantum key distribution.

Related Art

[0002] The development of quantum mechanics has resulted in applications in many aspects of life. Quantum mechanics can be applied to cryptography, including quantum key distribution protocols like Bennett Brassard (BB84), Differential Phase-Shift (DPS), Coherent One- Way (COW), and SARG (derived from BB84). A quantum key distribution system typically includes three components: 1) a quantum engine for quantum-related functions, including generating keys and transmitted the generated keys to corresponding key management modules; 2) a key management module for managing keys received from the quantum engine, including storing a pool of keys; 3) and an application which requests keys from the key management module. The key pool managed by the key management module is a shared resource. As a result, when multiple applications concurrently request keys from the key management module, the key management module can only process the requests in serial. The key management module can only respond to one request at a time, and thus can only obtain one key at a time from the shared key pool.

[0003] Because the single shared key pool can become a bottleneck, the typical quantum key distribution system can result in congestion. As the number of requests increases, so does the average waiting time for an application to obtain a response to its request. This may result in a marked decrease in the quality of service of the quantum key distribution system. SUMMARY

[0004] One embodiment of the present invention provides a system for facilitating quantum key distribution. During operation, the system receives, from a requester, a first request for a first key, wherein the first request indicates a requested length for the first key and identifying information of the requester. The system determines whether a subset pool of a general pool of keys is allocated to the requester based on the identifying information of the requester, wherein the keys in the general pool are generated by a quantum engine. In response to determining that a subset pool is not allocated to the requester, the system allocates a subset pool to the requester. The system obtains from the allocated subset pool a second key with a length matching the requested length, and returns the obtained second key to the requester.

[0005] In some embodiments, in response to determining that a subset pool is allocated to the requester based on the identifying information of the requester, and in response to determining that the second key does not exist in the allocated subset pool, the system applies from the general pool for a third key with a length greater than or equal to the requested length. The system obtains the third key and adds the third key to the allocated subset pool of the requester.

[0006] In some embodiments, allocating the subset pool to the requester further comprises: creating a plurality of subset pools as part of an initialization process; and selecting the subset pool from the plurality of subset pools.

[0007] In some embodiments, allocating the subset pool to the requester further comprises: applying from the general pool for a third key of the requested length or of a predetermined length, wherein the requested length is less than or equal to the predetermined length; obtaining the third key; and constructing the subset pool using the third key.

[0008] In some embodiments, allocating the subset pool to the requester further comprises applying for the second key. In response to identifying the second key in a recycled key pool, the system obtains the second key from the recycled key pool. In response to not identifying the second key in the recycled key pool, the system applies from the general pool for the second key. In response to not obtaining the second key from the general pool, the system returns a failure message to the requester.

[0009] In some embodiments, in response to receiving a message from the requester to terminate a TCP connection or in response to determining that a second request from the requester for a third key is not received within a predetermined period of time, the system performs the following: in response to determining any remaining keys in the allocated subset pool, the system adds the remaining keys to a recycled key pool; and the system releases the allocated subset pool. [0010] In some embodiments, the method is performed by a first module on a same or a different device as the requester. The requester is a first requester. The first module

communicates with a second module on a second device, and the second module communicates with a second requester on a same or a different device as the second module, wherein a requester is an application. The general pool is a first general pool maintained by the first module, and the allocated subset pool is a first allocated subset pool maintained by the first module. A second general pool is maintained by the second module, and a second allocated subset pool is maintained by the second module. The system generates, by the first module, a synchronization message for the second module. The system receives, by the first module, an acknowledgment of the synchronization message from the second module.

[0011] In some embodiments, the system transmits, by the first requester to the second requester, a notification message which indicates parameters associated with the synchronization message, which causes the second requester to: transmit to the second module a second request for a third key, wherein the second request is based on the parameters indicated in the notification message; and receive a fourth key with a length matching the requested length, wherein the fourth key is obtained from the second allocated subset pool.

[0012] In some embodiments, the synchronization message indicates for the second module to perform one or more of: allocating the second subset pool to the second requester, wherein the second allocated subset pool includes keys which are the same as the keys in the first allocated subset pool; obtaining from the second allocated subset pool the fourth key; applying from the second general pool for a fifth key with a length greater than or equal to the requested length; in response to identifying the fourth key in a recycled key pool of the second module, obtaining the fourth key from the recycled key pool; in response to not identifying the fourth key in the recycled key pool, applying from the second general pool for the fourth key; releasing the second allocated subset pool; adding any remaining keys from the second allocated subset pool to the recycled key pool; and performing any method performed by the first module to provide a synchronization between the first module and the second module of the first general pool and the second general pool, the first allocated subset pool and the second allocated subset pool, and the obtained second key and the obtained fourth key.

BRIEF DESCRIPTION OF THE FIGURES

[0013] FIG. 1 illustrates an exemplary system that facilitates quantum key distribution, in accordance with an embodiment of the present application. [0014] FIG. 2A presents a flowchart illustrating a method by a key management module for facilitating quantum key distribution, in accordance with an embodiment of the present application.

[0015] FIG. 2B presents a flowchart illustrating a method by a key management module for allocating a subset pool to a requester, in accordance with an embodiment of the present application.

[0016] FIG. 3 presents a flowchart illustrating a method for applying for a key from a pool of keys, in accordance with an embodiment of the present application.

[0017] FIG. 4 presents a flowchart illustrating a method for releasing an allocated subset pool, in accordance with an embodiment of the present application.

[0018] FIG. 5 presents an exemplary communication between two applications and two key management modules for facilitating synchronization of allocated subset pools and requested keys, in accordance with an embodiment of the present application.

[0019] FIG. 6 illustrates an exemplary computer system that facilitates quantum key distribution, in accordance with an embodiment of the present application.

[0020] FIG. 7 illustrates an exemplary apparatus that facilitates quantum key distribution, in accordance with an embodiment of the present application.

[0021] In the figures, like reference numerals refer to the same figure elements. DETAILED DESCRIPTION

[0022] The following description is presented to enable any person skilled in the art to make and use the embodiments, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Overview

[0023] Embodiments of the present invention solve the problem of serial access to a shared pool of keys from concurrent key requests in a quantum distribution system by allocating dedicated subsets of the shared pool to requesters, which provides parallel access to the shared pool.

[0024] Because the single shared key pool can become a bottleneck, the typical quantum key distribution system can result in congestion. As the number of requests increases, so does the average waiting time for an application to obtain a response to its request. This may result in a marked decrease in the efficiency and quality of service of the quantum key distribution system.

[0025] Embodiments of the present invention address this inefficiency by providing parallel access to the keys in the shared key pool. The present system allocates a dedicated subset of the shared key pool to a requester, either upon initialization or dynamically in response to incoming requests.

[0026] The term "general pool" refers to a pool for storing keys to be distributed. The keys are generated and transferred by a quantum engine to a module that manages the general pool (e.g., a key management module). The term "subset pool" refers to a dedicated pool of keys which includes a subset of the keys in the general pool. A subset pool may be allocated to a requester based on methods as described below in relation to FIGs. 2B and 3.

[0027] A quantum key distribution system allows a first and a second requester to obtain the same key, where each requester sends a key request to its respective key management module. Typically the first requester is considered the active initiator, and the second requester is considered the passive initiator. The active initiator may use the obtained key to encrypt a subsequent message, while the passive initiator may use the obtained key to decrypt the encrypted message. Any entity can be an active initiator or a passive initiator. The key management procedure of an active initiator is described below in relation to FIGs. 2 A, 2B, and 3. An exemplary communication depicting synchronization between an active initiator and a passive initiator is described below in relation to FIG. 5.

[0028] Thus, the present system provides improvements to quantum key distribution, where the improvements are fundamentally technological. Embodiments of the present invention provide a technological solution (e.g., providing parallel access to a shared pool of keys by allocating dedicated subsets of keys from the shared pool to specific requesters) to the technological problem of efficient, secure, and effective quantum key distribution.

Exemplary System

[0029] FIG. 1 illustrates an exemplary system that facilitates quantum key distribution, in accordance with an embodiment of the present application. System 100 can include computing devices 110, 112, and 114, which are associated with users 120, 122, and 124, respectively. Computing devices 110-114 can include, for example, a tablet, a mobile phone, an electronic reader, a laptop computer, a desktop computer, or any other computing device. Computing devices 110-114 can communicate with servers 130 and 132 via a network 138. Server 130 can communicate with a storage device 131. In some embodiments, storage device 131 resides on server 130. Servers 130 and 132 can also include any other computing device. Computing device 114 can include a quantum key distribution system 140, which can include: an application 142; a key management module 150 which includes a (shared) key pool 152; and a quantum engine 160. Application 142, key management module 150, and quantum engine 160 can reside on the same device (such as device 114 as depicted in FIG. 1) or on different devices (not depicted).

[0030] Similarly, server 132 can include a quantum key distribution system 170, which can include: an application 172; a key management module 180 which includes a (shared) key pool 182; and a quantum engine 190. Application 172, key management module 180, and quantum engine 190 can reside on the same device (such as server 132 as depicted in FIG. 1) or on different devices (not depicted).

[0031] Applications 142 and 172 can communicate via a communication link 102. Key management modules 150 and 160 can communicate via a communication link 104. Quantum engines 160 and 190 can communicate via a communication link 106, which can be a quantum or photonic communication.

[0032] In a key request communication, module 150 can be an active initiator and module 180 can be a passive initiator. During operation, quantum engines 160 and 190 can negotiate and generate a set of keys, which are transmitted to and stored by, respectively, modules 150 and 180. Subsequently, application 142 can send a request to module 150 for a key of a specific length. Module 150 can obtain a key (or key sequence) matching the specific length from a subset pool allocated to the requester, as described below in relation to FIG. 2A. Module 150 can also determine whether a subset pool has been allocated to the requester, and if not, allocate a subset pool to the requester, as described below in relation to FIG. 2A. Module 150 can return the obtained key to application 142. Modules 150 and 180 can perform synchronization procedures, so that a subsequent request from application 172 can return the same obtained key, as described below in relation to FIG. 5. This allows device 114 and server 132 to use the obtained key to encrypt and decrypt subsequent communications.

Implementation of Subset Pools

[0033] The key management module can construct the subset pool in various ways. For example, the key management module may apply from the general pool for a key of a predetermined length, and part of the general pool that stores the key may be directly separated from the general pool to serve as the subset pool. Alternatively, the key management module may apply for additional memory based on the predetermined length to serve as the subset pool, such that the key management module may apply from the general pool for a key of a predetermined length, where the key may be copied into the subset pool.

[0034] Note that the requester may send multiple key requests over a certain period of time. This period of time can be referred to as the "key acquisition period." When the key management module receives a key request and determines that a subset pool has not yet been allocated to the requester, the key management module can determine that the requester is a new requester is at the start of a key acquisition period.

[0035] The subset pool may use a key bit as a basic unit, i.e., the subset pool can store an unstructured key bit stream. The subset pool may be implemented using a data structure of, e.g., a bit array or a queue. In the example of the bit array, the obtained key of the subset pool can be stored in the bit array where each member in the array stores a key bit of the key. In some embodiments, a requester may use a relatively fixed encryption and decryption algorithm, such that the key requests are for keys of a fixed length. That is, key requests from a requester during a key acquisition period may indicate keys of the same length, where the requested length is equal to the fixed length. Thus, the subset pool may also use a key block as a basic unit, where the length of a key contained in each key block is the same as the fixed length. This allows a key block to be directly obtained from the general pool each time a key is returned to the requester, which can improve the processing efficiency. For example, the key management module may apply from the general pool for a key of the fixed length, and the applied-for key may be segmented into key blocks of a corresponding length based on the fixed length. The key management module may then construct the subset pool using the segmented key blocks as basic units.

[0036] As discussed above, the subset pool may be implemented using a data structure such as a queue. In the example of the queue, the segmented data blocks may be added into the queue, i.e., each unit in the queue is a key block, and the subset pool is accessed through a read pointer and a write pointer of the queue. When the key management module obtains a key from the subset pool, a key block pointed to by the read pointer is directly returned. If a key block needs to be added into the subset pool, the key block is directly added into a unit pointed to by the write pointer.

Method for Facilitating Quantum Key Distribution (Active Initiator)

[0037] FIG. 2A presents a flowchart 200 illustrating a method by a key management module for facilitating quantum key distribution, in accordance with an embodiment of the present application. The key management module may be a host procedure running on a local device. During operation, the system receives, by a key management module from a requester or requesting device, a first request for a key, wherein the first request indicates a requested length for the key and identifying information of the requester (operation 202). The requester and the key management module can be entities that run on the same device or on different devices. If the requester and the key management module run on the same device, the entities may interface via an inter-process communication (IPC) mechanism. For example, the requester may send a message, and the key management module may receive and parse the message. If the requester and the key management module run on different devices, the entities may interact via a network connection. For example, the requester may establish a TCP data connection to the key management module, and send the first request as an HTTP packet to the key management module via the TCP connection, and the key management module may receive the HTTP packet via the TCP connection.

[0038] The key management module determines whether there is a subset pool allocated to the requester based on the requester's identifying information (decision 204). If there is no subset pool allocated to the requester (indicating that the first request is from a new requester and that the key management module has not yet allocated a subset pool to the requester), the key management module allocates a subset pool to the requester (operation 206), as described below in relation to FIG. 2B.

[0039] If there is a subset pool allocated to the requester (indicating that the first request is not from a new requester and that the key management module has already allocated a subset pool to the requester), the key management module determines whether a key with a length matching the requested length exists in the allocated subset pool (decision 212). As an example, if the subset pool is implemented using a bit array, the key management module can - upon obtaining a key from the subset pool - update a subscript value of a first key bit to be distributed and record the length of the key bits to be distributed. Thus, the key management module can determine whether a key of the matching length exists in the allocated subset pool based on the information related to the bit array.

[0040] Furthermore, if the subset pool is implemented using a key block as a basic unit, the key management module can determine whether a key block containing a key of the fixed length exists in the allocated subset pool. As another example, if the subset pool is implemented using a queue, the key management module can determine whether there is any distributable key block based on a positional relationship between read and write pointers. If there is no distributable key block (i.e., the queue is empty), the key management module can determine that a key with a length matching the requested length does not exist in the allocated subset pool. Also, if the queue is not empty but has only one incomplete key block containing a key whose length is less than the fixed length, the key management module can determine that a key with a length matching the requested length does not exist in the allocated subset pool. An incomplete key block can be, e.g., a fragment caused by the fact that the preset length is not an integer multiple of the fixed length.

[0041] If a key with the matching length exists in the allocated subset pool, the operation continues at operation 218. If a key with the matching length does not exist in the allocated subset pool, the key management module applies from the general pool for a key with a length greater than or equal to the requested length (operation 214). The key management module can also apply for a key with a length of a predetermined length which is greater than or equal to the requested length. The key management module adds the applied- for key to the allocated subset pool (operation 216). The key management module obtains from the allocated subset pool a key with a length matching the requested length (operation 218), and returns the obtained key to the requester (operation 220). The key management module may return the obtained key to the requester via an IPC (if the requester is on the same device as the key management module) or via a network transmission such as TCP (if the requester is on a different device than the key management module).

[0042] If the subset pool is implemented using a bit array, each key bit in a key applied for from the general pool may be stored in each member of the array. As a result, the key management module can update a subscript value of a first key bit to be distributed, and record the length of the distributable key bits. If the subset pool is implemented using a key block as a basic unit, the key management module may segment the applied-for key into key blocks of a corresponding length based on the fixed length, and add the segmented key blocks into the subset pool. If the subset pool is implemented using a queue, the key management module may sequentially add the segmented key blocks into the queue based on a write pointer, which may be accordingly updated.

[0043] If the subset pool is implemented using a key bit stream, the key of the requested length may be intercepted from a key bit stream to be distributed. If the subset pool is implemented using a bit array, key bits stored in corresponding array members may be sequentially read based on the requested length, beginning from a subscript value of a first key bit to be distributed. The key bits may be combined into the key. Subsequently, the subscript value of the first key bit to be distributed and the length of distributable key bits may be accordingly updated.

[0044] If the subset pool is implemented using a key block as a basic unit, a key block may be directly obtained from the allocated subset pool, and a key contained in the key block may be used as the key to be returned to the requester. If the subset pool is implemented using a queue, a key in a key block pointed to by a read pointer may be read as a key sequence to be returned, and then the read pointer may be made to point to a next key block in the queue to prepare for a subsequent reading of the key block. When the subset pool is implemented using a key block as a basic unit (i.e., structured storage), a key block can be directly read as a unit without the need to ready key bits one at a time while obtaining the key. As a result, the processing efficiency of the key distribution system can improve.

Allocation of Subset Pools to Requester: Upon Initialization and Dynamically

[0045] FIG. 2B presents a flowchart 230 illustrating a method by a key management module for allocating a subset pool to a requester, in accordance with an embodiment of the present application. During operation, the key management module can allocate a subset pool to a requester by allocating subset pools upon startup (e.g., a "pre-method" or as part of an initialization process) or based on a dynamic method (e.g., in response to incoming requests). During startup, the key management module can create a plurality of subset pools as part of an initialization process (operation 232). A created subset pool can contain keys of a specific or predetermined length. The key management module can set a state of these pools to "Allocated." The key management module can select a subset pool from the plurality of subset pools

(operation 234). The key management module can establish a correspondence or association between the requester's identifying information and the selected subset pool.

[0046] The key management module can also dynamically allocate a subset pool to a requester. The key management module can apply from the general pool for a key of the requested length or of a predetermined length which is greater than or equal to the requested length (operation 242). The key management module can obtain the applied-for key (operation 244), and construct a subset pool using the applied-for key (operation 246). The key

management module can construct the subset pool by applying for a large block of keys, where the length of a key is greater than the requested length. This allows the key management module to prepare for both this request and subsequent requests. Subset pools may be constructed or implemented as described above.

Recycled Key Pools

[0047] FIG. 3 presents a flowchart 300 illustrating a method for applying for a key from a pool of keys, in accordance with an embodiment of the present application. During operation, the key management module determines whether there is a key of the requested length in a recycled pool (decision 302). The key management module may have previously applied for memory to be allocated to a pool of recycled keys ("recycled pool"), such that keys which have been used and subsequently released may be added to the recycled pool to maximize and increase storage efficiency. If there is a key of the requested length in the recycled pool, the key management module obtains a key of the requested length from the recycled pool (operation 304). The key management module returns the obtained key to the requester (operation 308).

[0048] If there is not a key of the requested length in the recycled pool, the key management module applies from the general pool for a key of the requested length (operation 312). The key management module determines whether there is a key of the requested length in the general pool (decision 314). If there is, the key management module obtains a key of the requested length from the general pool (operation 306), and the key management module returns the obtained key to the requester (operation 308). If there is not a key of the requested length in the general pool, the key management module returns a failure message to the requester (operation 316).

Releasing an Allocated Subset Pool

[0049] FIG. 4 presents a flowchart 400 illustrating a method for releasing an allocated subset pool, in accordance with an embodiment of the present application. To ensure stable operation, the quantum key distribution system may include a post-processing operation to release an allocated subset pool. The system can determine that a requester has stopped requesting keys in various ways. When the requester and the key management module run on different devices, the key management module can determine whether it receives from the requester a message to terminate a TCP connection (decision 402). If the key management module does not receive such a message, the operation returns. If the key management module does receive such a message, the key management module can determine that the requester has stopped requesting keys (operation 406). When the requester and the key management module run on the same device, the key management module can determine whether it receives a request for a key from the requester within a predetermined period of time (decision 404). If it does, the operation returns. If it does not, the key management module can determine that the requester has stopped requesting keys (operation 406). In some embodiments, the system may set a timer for the subset pool based on the predetermined time period. The system may reset the timer upon receiving another key request from the requester. Thus, if the timer times out, the system can determine that the requester has stopped requesting keys.

[0050] In response to determining a previously created subset pool, the key management module can set the state of the previously created subset pool to "Unallocated" (operation 408), which allows the key management module to both fill the subset pool with keys to be distributed and allocate the subset pool to another requester. The key management module releases the subset pool allocated to the requester (operation 410). If additional memory space is allocated during the subset pool allocation, the memory space used by the subset pool may be released, which can reduce memory usage and avoid memory overflow. If the subset pool is a partial key pool separated from the general pool, the subset pool may be returned to the general pool for unified management. As a result, the general pool can maintain a relatively balanced size, instead of shrinking and failing to provide services externally.

[0051] The key management module can determine that memory space has previously been applied for as a recycled key pool during startup or initialization (operation 412). The key management module determines whether there are any remaining keys in the subset pool allocated to the requester (decision 414). If there are none, the key management module can release the subset pool allocated to the requester (operation 410). If there are remaining key in the allocated subset pool, the key management module can add the remaining keys to the recycled key pool (operation 416), and then release the allocated subset pool (operation 410).

[0052] If the subset pool is implemented using a bit array, a key bit stored in each array member may be sequentially read based on the recorded length of distributable key bits beginning from a subscript value of a first key bit to be distributed, which obtains the remaining key sequences to be added into the recycled key pool. If the subset pool is implemented using a key block as a basic unit, keys contains in the remaining key blocks may be added into the recycled key pool. If the subset pool is implemented using a queue, keys in key blocks between a read pointer and a write pointer may be sequentially read and then added into the recycled key pool.

[0053] Thus, for each subset pool allocated to a requester, when the key management module determines that the requester has stopped requesting keys, the key management module can add any remaining keys in the allocated subset pool to the recycled key pool. Subsequently, the key management module can apply to the recycled key pool first to obtain a key. As a result, idle key resources may still be effectively utilized.

Synchronization

[0054] Recall that in a quantum key distribution system, a first and a second requester may obtain the same key, where each requester sends a key request to its respective key management module. Typically the first requester is considered the active initiator, and the second requester is considered the passive initiator. The active initiator may use the obtained key to encrypt a subsequent message, while the passive initiator may use the obtained key to decrypt the encrypted message. Any entity can be an active initiator or a passive initiator. In order for each requester to obtain the same key, certain synchronization operations may be performed between the key management modules for each requester. [0055] Embodiments of the present invention include synchronization between the general pools managed by each key management module. FIG. 5 presents an exemplary communication 500 between two applications and two key management modules for facilitating synchronization of allocated subset pools and requested keys, in accordance with an embodiment of the present application. In communication 500, an Application ("App") A 502 can interact with an associated key management module ("Module") A 504. Module A can perform synchronization operations with a key management module ("Module") B 506, which is associated with an application ("App") B 508. In communication 500, App A is depicted as the active initiator, and App B is depicted as the passive initiator. Furthermore, Module A and Module B may communicate in advance via a quantum or photonic communication, such that each module includes the same set of keys that may be used as a general pool for subsequent quantum key distribution.

[0056] During operation, App A can send a key request 512 to Module A. Key request A can be, e.g., the first request as described in operation 202 of FIG. 2 A. Module A can determine whether an allocated subset pool exists for the requester (i.e., App A) (function 514). If an allocated subset pool does not exist for the requester (i.e., App A), Module A can allocate a subset pool to the requester (function 516), similar to operation 206 of FIG. 2 A. Module A can subsequently send a synchronization message 518 to Module B. Upon receiving message 518, Module B can perform a similar operation to allocate a subset pool to a requester (function 520). Message 518 can include information related to App A, which allows subsequent requesters (e.g., App B) to know that the subset pool allocated by Module B in function 520 corresponds to App A. Module B can then send a synchronization acknowledgment 522 back to Module A. Note that if an allocated subset pool does exists for App A (as determined by function 514), communication 500 can continue directly at function 524.

[0057] Module A can then determine a key from the allocated subset pool (function 524).

If a key cannot be determined from the allocated subset pool, Module A can apply for a key from the general pool (function 526), similar to operations 214, 216, and 218 of FIG. 2A. Module A can subsequently send a synchronization message 528 to Module B. Upon receiving message 528, Module B can perform a similar operation to apply for a key from the general pool (function 530). Message 528 can include information related to App A, which allows subsequent requesters (e.g., App B) to know that key applied for by Module 506 in function 530 corresponds to App A. Module B can then send a synchronization acknowledgment 532 back to Module A. Note that if a key can be determined from the allocated subset pool, communication 500 can continue directly at function 534. [0058] Subsequently, Module A can return the obtained and requested key 534 to App A. App A can send a notification message 542 to App B. Message 542 can include parameters for synchronization, i.e., which allow App B to know what information to include in a subsequent request for a key from Module B. Upon receiving message 542, App B can send a key request 544 to Module B. Key request 544 can be similar to key request 512, and can further indicate any relevant synchronization parameters, such as identifying information of App A or an allocated subpool for App A. Module B can receive key request 544 and any relevant synchronization parameters, and can return a requested key 546, which is the same as requested key 534. In this manner, App A and App B (via the synchronization functions performed respectively by Module A and Module B) can obtain the same key, and can use the same key to encrypt and decrypt subsequent communications.

[0059] Other methods for synchronization include splitting or combining the

aforementioned operations. For example, Module A may perform a synchronization operation with Module B only when obtaining a key from the subset pool, where Module A notifies Module B of allocating the subset pool and selecting the key in a single operation. Module A may also perform synchronization operations with Module B in the following instances: applying for a key from the general pool; adding a key to a subset pool; releasing an allocated subset pool; and adding remaining key sequences to a recycled key pool. These operations ensure that the key pools of both parties (including the general pool, the allocated subset pools, and the recycled key pool) remain synchronized.

Exemplary Computer System and Device

[0060] FIG. 6 illustrates an exemplary computer system 600 that facilitates quantum key distribution, in accordance with an embodiment of the present application. Computer system 600 includes a processor 602, a memory 604, a quantum engine 606, and a storage device 608.

Memory 604 can include a volatile memory (e.g., RAM) that serves as a managed memory, and can be used to store one or more memory pools. Furthermore, computer system 600 can be coupled to a display device 610, a keyboard 612, and a pointing device 614. Quantum engine 606 can generate quantum keys and communicate via a quantum or photonic communication with another system by distributing and maintaining a same pool of keys. Storage device 608 can store an operating system 616, a content-processing system 618, and data 632.

[0061] Content-processing system 618 can include instructions, which when executed by computer system 600, can cause computer system 600 to perform methods and/or processes described in this disclosure. Specifically, content-processing system 618 can include: a communication module 620 for transmitting and receiving keys via a quantum or photonic communication, and for sending and receiving key requests and keys; a general pool-managing module 622 for maintaining and processing key requests or applications for key requests; a subset pool-managing module 624 for determining allocated subset pools, allocating subset pools, and processing key requests or applications for key requests; a key-obtaining module 626 for obtaining a key from an allocated subset pool; a recycled pool-managing module 628 for maintaining and processing key requests or applications for key requests; and a synchronization module 630 for performing synchronization operations such as generating, processing, transmitting, and receiving synchronization messages and other related notifications or messages.

[0062] Data 632 can include any data that is required as input or that is generated as output by the methods and/or processes described in this disclosure. Specifically, data 932 can store at least: a request for a key; identifying information of a requester; a key; a pool of keys; an allocated subset pool of keys; a recycled key pool; an indicator of a predetermined length; keys of the predetermined length; an indicator of a TCP connection; a message; a message to terminate a TCP connection; a predetermined period of time; a set of remaining keys; a synchronization message; an acknowledgment of a synchronization message; a notification message; and synchronization parameters.

[0063] FIG. 7 illustrates an exemplary apparatus 700 that facilitates quantum key distribution, in accordance with an embodiment of the present application. Apparatus 700 can comprise a plurality of units or apparatuses which may communicate with one another via a wired, wireless, quantum light, or electrical communication channel. Device 700 may be realized using one or more integrated circuits, and may include fewer or more units or apparatuses than those shown in FIG. 7. Further, device 700 may be integrated in a computer system, or realized as a separate device which is capable of communicating with other computer systems and/or devices. Specifically, device 700 can comprise units 702-712 which perform functions or operations similar to modules 620-630 of computer system 600 of FIG. 6, including: a communication unit 700; a general pool-managing unit 704; a subset pool-managing unit 706; a key-obtaining unit 708; a recycled pool-managing unit 710; and a synchronization unit 712.

[0064] The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. The computer-readable storage medium includes, but is not limited to, volatile memory, non- volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed. [0065] The methods and processes described in the detailed description section can be embodied as code and/or data, which can be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and/or data stored on the computer-readable storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the computer-readable storage medium.

[0066] Furthermore, the methods and processes described above can be included in hardware modules. For example, the hardware modules can include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), and other programmable-logic devices now known or later developed. When the hardware modules are activated, the hardware modules perform the methods and processes included within the hardware modules.

[0067] The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.