Post-quantum cryptography encryption key delivery

Abstract

Aspects of the disclosure are directed to out-of-band generation of a session key using a post-quantum cryptography (PQC) key encapsulation method (KEM). Out-of-band generation of the session key can include generating a public / private keypair comprising a public key and a private key using the PQC KEM. The public key can be transmitted from one node to another. The node that receives the public key may generate the session key and a ciphertext. The node that generates the ciphertext may transmit the ciphertext to the node that transmitted the public key. The node that receives the cipher text may decode the session key using the received ciphertext.

Description

QXC-001POST-QUANTUM CRYPTOGRAPHY ENCRYPTION KEY DEEIVERYCROSS-REFERENCE TO RELATED APPLICATION

[0001] The present application claims the benefit of the filing date of U.S. Provisional Application No. 63 / 684,037, filed August 16, 2024, the disclosure of which is hereby incorporated herein by reference.BACKGROUND

[0002] As post-quantum cryptography (PQC) key encapsulation method (KEM) algorithms begin to be implemented in real-world settings, existing protocols will likely require modification. For instance, software stacks and protocols like Internet Protocol Security (IPSec) and Transport Layer Security (TLS) will need to be modified to embed new PQC KEM algorithms alongside existing algorithms, such as Diffie-Hellman. Thus, significant development will be needed to integrate new PQC KEM algorithms.

[0003] PQC KEM algorithms generally remain untested in the real world, and often vary in performance and amount of intermediate data they generate. Thus, when implementing PQC KEM algorithms, vendors and others will likely choose a single PQC KEM algorithm, as the development and integration of many PQC KEM algorithms can be costly and timeconsuming, as well as potentially disruptive to the vendors’ systems. However, given that the performance of PQC KEM algorithms remains untested, the selection of a weak or less performant PQC KEM algorithm by a vendor may result in security risks and additional costs to replace the selected PQC KEM algorithm.

[0004] Some PQC KEM algorithms have different groups of authors and are developed using a rapid development approach, such as Rapid Application Development (RAD). While these regular (e.g., weekly, monthly, etc.) updates of PQC KEM algorithms may offer improved performance and security, the updated PQC KEM algorithms are often backward incompatible. Thus, updating a weak or less performant PQC KEM algorithm may require significant integration time and costs, given the risk of backward incompatibility of many updated PQC KEM algorithms.BRIEF SUMMARY

[0005] One aspect of the disclosure is directed to methods, systems, and computer-readable medium for out-of-band generation of a session key using a post-quantum cryptography (PQC) key encapsulation method (KEM). The method may comprise generating, by a first node, a public / private keypair comprising a public key and a private key using the PQC KEM;QXC-001 transmitting, by the first node to a second node, the public key; generating, by the second node, the session key and a ciphertext; transmitting, by the second node to the first node, the ciphertext; and decoding, by the first node, the session key using the ciphertext.

[0006] In some embodiments, the public key and the private key are generated using a deterministic random bit generator.

[0007] In some embodiments, the first node is connected to a first client device and the second node is connected to a second client device. In some examples, prior to generating the public / private keypair, the first node receives a request for the session key from the first client device. In some examples, the first node provides the session key to the first client device and the second node provides the session key to the second client device for in-band communication.

[0008] In some embodiments, generating the session key and the ciphertext comprises executing an encapsulation algorithm where the public key and a randomly generated number are inputs to the encapsulation algorithm and the session key and the ciphertext are outputs of the encapsulation algorithm.

[0009] In some embodiments, decoding the session key comprises executing a decapsulation algorithm where the private key and the ciphertext are inputs to the decapsulation algorithm and the session key is the output of the decapsulation algorithm.

[0010] Another aspect of the disclosure is directed systems, methods, and computer-readable mediums for generation of a session key using multiple post-quantum cryptography (PQC) key encapsulation methods (KEMs). The method may comprise generating, by a first node, public / private keypairs, each public / private keypair comprising a public key and a private key, wherein each public / private / keypair is generated using a PQC KEM; transmitting, by the first node to a second node, each public key of each public / private keypair; generating, by the second node, for each public key of each public / private keypair, a session key and a ciphertext; transmitting, by the second node to the first node, the ciphertext generated from each public key; decoding, by the first node, the session key for each public / private keypair using the ciphertext generated from each public key; deriving, by the first node, a final session key using the decoded session keys; and deriving, by the second node, another final session key using the generated session keys, wherein the final session key and the other final session key are the same keys.QXC-001

[0011] In some embodiments, prior to deriving the final session key and the other final session key, the first node concatenates the decoded session keys into a buffer and the second node concatenates the generated session keys into another buffer. In some examples, deriving the final session key and the other final session key comprises executing a key derivation function on the final session key and the other final session key, the key derivation function generating the final session key and the final session key having a predefined length.

[0012] In some embodiments, generating the session key and the ciphertext for each public key of each public / private keypair, comprises executing an encapsulation algorithm where each of the public keys and a randomly generated number are inputs to the encapsulation algorithm and the session keys and the ciphertexts of each of the public keys are outputs of the encapsulation algorithm.

[0013] In some embodiments, decoding the session key for each public / private keypair comprises executing a decapsulation algorithm where the private key and the ciphertexts generated from each public key are inputs to the decapsulation algorithm and the session key of each of the public keys is the output of the decapsulation algorithm.

[0014] Another aspect of the disclsoure is directed to systems, methods, and computer-readable medium for generating a session key using multiple post-quantum cryptography (PQC) key encapsulation methods (KEMs), the method comprising: generating, by one or more processors, for each PQC KEM a session key; concatenating, by the one or more processors, each generated session key into a buffer; and deriving, by the one or more processors from the concatenated session keys, a final session key.

[0015] In some embodiments, generating each session key further comprises generating a corresponding ciphertext.

[0016] In some examples, the method further comprises transmitting, by the one or more processors, each ciphertext to one or more other processors.

[0017] In some examples, the method further comprises decoding, by the one or more other processors, each session key corresponding to each ciphertext.

[0018] In some examples, the method further comprises concatenating, by the one or more other processors, each decoded session key into another buffer; and deriving, by the one or more other processors from the concatenated session keys in the other buffer, another final session key, the another final session key being the same as the final session key.QXC-001

[0019] Another aspect of the disclosure is directed to a system comprising a plurality of nodes of a network of nodes; and a first node of the plurality of nodes. The first node is configured to: generate, a public / private keypair comprising a public key and a private key using a post-quantum cryptography (PQC) key encapsulation method (KEM): transmit, to a second node of the plurality of nodes, the public key; receive, from the second node, a ciphertext; and decode the session key using the ciphertext.

[0020] In some instances, the public key and the private key are generated using a deterministic random bit generator.

[0021] In some instances, the first node is connected to a first client device and the second node is connected to a second client device.

[0022] In some instances, prior to generating the public / private keypair, the first node receives a request for the session key from the first client device.

[0023] In some instances, the first node provides the session key to the first client device and the second node provides the session key to the second client device for in-band communication.

[0024] In some instances, the session key and the ciphertext are generated by executing an encapsulation algorithm where the public key and a randomly generated number are inputs to the encapsulation algorithm and the session key and the ciphertext are outputs of the encapsulation algorithm.

[0025] In some instances, the system further comprises the second node, wherein the second node is configured to generate the session key and the ciphertext.

[0026] In some instances, decoding the session key comprises executing a decapsulation algorithm where the private key and the ciphertext are inputs to the decapsulation algorithm and the session key is the output of the decapsulation algorithm.

[0027] Another aspect of the disclosure is directed to a non-transitory computer- readable medium containing instructions, the instructions, when executed by one or more computing devices, cause one or more computing devices to: generate a public / private keypair comprising a public key and a private key using a post-quantum cryptography (PQC) key encapsulation method (KEM); transmit, by a first computing device of the one or more computing devices, to a second computing device of the one or more computing devices, the public key; recive, by the first computing device, a session key and a ciphertext; and decode, by the first computing device, the session key using the ciphertext.QXC-001

[0028] In some instances, the session key and the ciphertext are generated by executing an encapsulation algorithm where the public key and a randomly generated number are inputs to the encapsulation algorithm and the session key and the ciphertext are outputs of the encapsulation algorithm.

[0029] In some instances, the session key and the ciphertext are generated by the second computing device.

[0030] In some instances, decoding the session key comprises executing a decapsulation algorithm where the private key and the ciphertext are inputs to the decapsulation algorithm and the session key is the output of the decapsulation algorithm.

[0031] In some instances, the public key and the private key are generated using a deterministic random bit generator.BRIEF DESCRIPTION OF THE DRAWINGS

[0032] FIG. 1 illustrates a system for out-of-band generation and delivery of cryptographic session keys in accordance with aspects of the disclosure.

[0033] FIG. 2 illustrates an example of out-of-band generation and delivery of cryptographic session keys to client devices in accordance with aspects of the disclosure.

[0034] FIG. 3 illustrates a flow diagram for out-of-band generation and delivery of a cryptographic session key generated using a post-quantum cryptography (PQC) key encapsulation method (KEM) algorithm in accordance with aspects of the disclosure.

[0035] FIG. 4 illustrates a flow diagram for out-of-band generation and delivery of a cryptographic session key generated using multiple post-quantum cryptography (PQC) key encapsulation method (KEM) algorithms in accordance with aspects of the disclosure.

[0036] FIG. 5 illustrates a flow diagram for in-band generation and delivery of a cryptographic session key generated using multiple post-quantum cryptography (PQC) key encapsulation method (KEM) algorithms in accordance with aspects of the disclosure.

[0037] FIG. 6 depicts a block diagram of an example system for implementing PQC KEM algorithms as described herein.DETAILED DESCRIPTION

[0038] FIG. 1 illustrates a system for out-of-band generation and delivery of symmetric cryptographic session keys, also referred to as session keys herein. The system includes a Hive 110 of Trusted Xchange Nodes and Client Devices connected to the Hive 110. Hive 110, which may also be referred to as a Trusted Exchange, includes nine Trusted Xchange Nodes, includingQXC-001Trusted Xchange Nodes TX_1 121, TX_2 122, TX_3 123, TX_4 124, TX_5 125, TX_6 126, TX_7 127, TX_8 128, TX_9 129. Although FIG. 1 illustrates Hive 110 as having nine Trusted Xchange Nodes, a hive may include one or more Trusted Xchange Nodes, which may also be referred to as TX Nodes herein.

[0039] The system illustrated in FIG. 1 further includes Client Devices U1 101, U2 102, and U3 103. The Client Devices also referred to herein as client devices, are connected to a respective TX Node of the Hive 110. As further shown in FIG. 1, Client Devices U1 101, U2 102, and U3 103 are connected to the TX_1 121, TX_3 123, and TX_7 127, respectively. Although only a single Client Device is shown as being connected to a TX Node in FIG. 1, any number of Client Devices may be connected to each TX Node. Moreover, although FIG. 1 illustrates three Client Devices, U1 101, U2 102, and U3 103, any number of Client Devices may be connected to a Hive.

[0040] A Hive, such as Hive 110, may be a peer-to-peer and / or mesh network made up of any number of TX Nodes. The TX Nodes of Hive 110, including TX_1 — TX_9, are communicating in peer-to-peer mode. In this regard, the TX Nodes are configured to talk only to neighboring TX Nodes which were configured by a system administrator, as described further herein, and which belong to the same Certificate Authority (CA). When more than two TX Nodes are in a Hive, they can form a mesh network.

[0041] Communication between neighboring TX Nodes may be encrypted by TLS with both client-server and server-client certificate validation. In this regard, the TX Nodes in a Hive may connect with neighboring TX Nodes via Transport Layer Security (TLS) with encryption and mutual certificates. For each pair of TX Nodes, one TX Node may be considered a client and the other TX Node may be considered the server. Which TX Node is the server and which TX Node is the client may be defined per TLS communications. For instance, the TX Node that initiates communication with another paired TX Node may be considered the client, and the other, paired TX Node may be considered the server.

[0042] Some TX Nodes may not have a Client Device attached. For example, as illustrated in FIG. 1, TX Nodes TX_2 122, TX_4 124, TX_5 125, TX_6 126, TX_8 128, and TX_9 129 have no Client Devices directly connected to them. Such TX Nodes, as well as those TX Nodes connected to Client Devices, may function as transition nodes that can be used for forwarding or routing. Forwarding and routing functions provide the Hive 110 with fault tolerance in case one or more TX Nodes fail and allow for secondary encryption performedQXC-001 with external keys from limited-range QKD Alice / Bob pairs. Such external keys are labeled as Additional Keys 140 in FIG.l. The TX Nodes of a Hive, such as TX Nodes (TX_1 121 — TX_9 129) of Hive 110, may perform a process to deliver cryptographic session keys between any given pair of Client Devices, such as Client Devices U1 101, U2 102, and U3 103.

[0043] Connections between TX Nodes in a Hive may be one-to-one, many-to-one, or many-to-many, in various embodiments.

[0044] Each TX Node may periodically communicate with its pre-configured neighboring TX Nodes to gather information about the configuration of the Hive. This information-gathering process may provide each TX Node with an overview of the entire Hive, including what TX Nodes are in the Hive and the connections of each TX Node, including which TX Nodes are connected to Client Devices. From this information, each TX Node may determine what Client Devices are connected to the Hive.

[0045] For example, TX_1 121 be pre-configured to connect with neighboring nodes TX_2 122 and TX_4 124, as illustrated by the double arrows between TX_1 121 and TX_2 122 and TX_1 121 and TX_4 124. In this regard, a double arrow between neighboring nodes in FIG. 1 indicates a connection between the neighboring nodes. During the informationgathering process, TX_1 121 may request, retrieve, or otherwise receive connection information from both TX_2 122 and TX_4 124. TX_2 122 may provide TX_1 121 with information corresponding to other nodes it gathers information from. For instance, TX_2 122 may receive information from TX_3 indicating that TX_3 is only connected to TX_2 123 and Client Device U3 103. Eikewise, TX_4 124 may provide TX_1 121 with information corresponding to other nodes it gathers information from. As TX_4 124 is only a connected neighbor with TX_5 125 (ignoring TX_1 121, as TX_1 121 is performing the information gathering and knows its own information), TX_4 124 may provide TX_1 121 with information received from TX_5 125. As TX_2 122 is also a connected neighbor with TX_5 125, TX_2 122 may also provide TX_1 121 with information received from TX_5 125. In situations where a TX Node receives duplicated data, the TX Node may ignore the duplicated data or overwrite the stored data with the newer duplicated data.

[0046] The information received from TX_5 125 may include information TX_5 125 received from its connected neighbor nodes including TX_8 128, which in turn may include information received from its respective connected neighbor nodes TX_7 127 and TX_9 129.QXC-001This process may continue for TX_9 129, which may receive information from TX_6 126 and TX_7 127.

[0047] A similar information-gathering process may be performed by each TX Node so that each TX Node receives information providing an overview of the entire Hive, including what TX Nodes are in the Hive and the connections between the TX Nodes. The information may also include what TX Nodes are connected to Client Devices and identifying information of the Client Devices. For instance, and with reference to Hive 100 of FIG. 1, TX_6 126 may receive information from TX_9 129, which may receive information from the other TX Nodes through TX_8 128, including information that TX_1 is connected to U1 101, TX_7 is connected to U2 102, and TX_3 is connected to U3 103.

[0048] Depending on the frequency of receiving information from neighboring TX Nodes, each TX Node may maintain a near-real-time mapping of TX nodes in the Hive and active Client Devices connected to the Hive while only requesting the information from its connected neighbors. The mapping stored by each TX Node may automatically change if new TX Nodes are added to or removed from the Hive by a system administrator or Client Devices are connected or disconnected from the Hive. The mapping stored by each TX Node may change if one or more TX Node becomes inaccessible, such as due to a TX Node failure, connection loss, etc. In this regard, as TX Nodes or Client Devices are added, removed, connected, disconnected, or otherwise become inaccessible, such information will propagate to each TX Node of the Hive during the information-gathering process. In some embodiments, information-gathering may be performed each time a Client Device requests a key to ensure the most up-to-date mapping of the Hive. In some examples, TX Nodes may delete mappings after a key transaction is completed, thereby only storing mappings during the key transaction process.

[0049] Each TX Node in the Hive should have a unique name, which may be assigned by a system administrator or automatically by a configuration device, such as a controller or processor. The system administrator or configuration device may configure the connections of TX Nodes. For instance, and with reference to FIG. 1, TX_1 121 is configured to connect with TX_4 124 and TX_2 122. Similarly, TX_3 is configured to connect with TX_2 and U3 102. Communication between TX Nodes and between TX Nodes and Client Devices may be implemented via REST API over TLS with both client- server and server-client certificate validation.QXC-001Key Exchange

[0050] A Hive may provide Client Device pairs with cryptographic session keys via out-of-band delivery. In this regard, Client Devices engage in in-band cryptographic communication with each other using cryptographic session keys received through out-of-band delivery. Stated another way, the Hive provides cryptographic session keys to Client Device pairs over a different communication channel than the channel the Client Device pairs communicate on.

[0051] In operation, the Hive may receive a request for session keys from a Client Device over an out-of-band channel for use in securing in-band communication between the Client Device and another Client Device. In Response, the Hive may generate and provide session keys to each Client Device.

[0052] FIG. 2 illustrates an example of a Hive 210 providing symmetric session keys to Client Devices U1 201 and U2 202. Hive 210 may be compared to Hive 110 and Client Devices U1 201, U2202 may be compared to any combination of Client Devices U1 101 - U3 103. In the example illustrated in FIG. 2, U1 201 requests a session key from Hive 210. The request may specify the counterparty to receive the same session key, which in this example is U2 202. The request for the session keys is sent by U1 201 to TX_1 221, which is the TX Node connected to U1 201. Although FIG. 2 illustrates U1 201 requesting a single session key, a Client Device may request any number of session keys.

[0053] The session key request may be performed in accordance with mutually agreed specifications. Such specifications may include TLS encryption and certificate validation and may be performed, for example, via REST API (Representational State Transfer Application Programming Interface). As another variant, the session key request can be performed via serial communication in a format a Client Device and connected TX Node agree upon.

[0054] Upon receiving the request, TX_1 221 may generate the requested session key. Such key generation may include PQC KEM offloading and multiple PQC KEM Offloading as further described herein.

[0055] After generating the session key, TX_1 221 may begin the process of delivering the session key to U2 202. The session key may first be provided to the counterparty Client Device (U2 202) before the session key is returned to the requesting Client Device (U1 201), although in some embodiments the session key may be returned to the requesting Client Device before or simultaneously with the counterparty Client Device. To deliver the session key toQXC-001 the counterparty, the TX Node that generates the session key may look up the name of the TX Node that is connected to the counterparty Client Device within its internally stored mapping of the Hive 210. In this example, TX_1’ s internal mapping of the Hive 210 would indicate that TX_7 227 is connected to Client Device 202.

[0056] As each TX Node TX_1 221 is only configured to talk to its pre-configured neighbors, of which TX_7 227 is not, TX_1 must determine the next hop based on its current mapping, with the goal of transmitting the session key across the shortest and / or quickest path possible, referred to herein as the optimal path. In this example TX_1 221 will see several equal-length paths to TX_7. That is, the number of hops to TX_7 227 from TX_1 221 would be the same if TX_1 221 transmits to neighboring TX Nodes TX_2 222 or TX_4 224. Specifically, TX_2 222 and TX_4 224 may both transmit the session key to TX_5 225 which in turn may transmit to TX_8, which in turn may complete the path to TX_7 227. Thus, both TX_2 222 and TX_4 224 may be given equal weight, and both may be considered part of an optimal path. Thus, TX_1 221 may transmit to TX_2 222 or TX_4 224 based on alternative criteria, such as predefined preferences defined by the System Administrator (e.g., selecting one TX Node over the other) or load-balancing, such as alternating between using TX_2 222 and TX_224 for transmitting a session key. In other examples, alternative criteria could be used to determine an optimal path. For instance, an optimal path may be based on one criterion or a combination of criteria, including the number of hops that would be required to reach a destination TX Node, reliability of inter- TX Node connections, transmission speed across TX Node connections, etc. In some examples, a combination of alternative criteria can be provided weightings, and the optimal path may be considered the path with the lowest or highest weighting, depending on the values assigned to weightings.

[0057] In some embodiments, the Hive can be configured such that paths between TX Nodes with additional encryption keys receive path priority, for example, by giving greater weight to such paths when determining an optimal path. In the case of Additional Keys, for example from a QKD Alice / Bob pair, TX Nodes additionally encrypt / decrypt the Parcel using those keys on both sides of that particular hop. Such quantum key encryption and decryption can occur on one hop, two or more hops, or each and every hop of the Parcel along a path, in various embodiments.

[0058] Transmitting session keys across TX Nodes may present a security vulnerability. Thus, in some examples, session keys are not transmitted across TX Nodes.QXC-001Rather, data containing key material (e.g., public key), which can be used to generate session keys, may be transmitted through a Hive. Such key material may be called a Parcel. The Parcel may have a destination TX Node label attached or otherwise embedded in it. When a TX Node receives a Parcel, the TX Node may perform a similar calculation to determine what the next hop of the path should be along the Parcel’s path to the destination TX Node. In the given example, the Parcel may be transmitted by TX_1 221 to TX_4224, with a destination TX Node label indicating TX Node TX_7 227 as the destination TX Node. Upon receiving the Parcel, TX_4224 may determine the only possible next hop is to TX_5 225. Thus, TX_4 may transmit the Parcel to TX_5 225. In this regard, the determination of an optimal path calculation and, in some instances, alternative criteria (e.g., load-balancing) is performed on every transitional TX Node (hop) until the Parcel reaches its destination TX Node, which in this example is TX_7 227. The path the Parcel follows in FIG. 2 is illustrated by the solid black double arrows.

[0059] Each TX Node in the path keeps the connection from the previous peer TX Node open in a transaction so any potential error is immediately returned within the context of this transaction. Upon successful delivery of the Parcel to the destination TX Node, the destination TX Node may return additional key material (e.g., public key, cyphertext, etc.) necessary to derive the final session key on the source TX Node and close the connection. (Each previous TX Node may do the same until the additional key material reaches the source TX Node that received the request. With reference to FIG. 2, TX_7 207, after receiving the Parcel, may generate the session key and return additional key material to TX_8 228, which may in turn return additional key material to TX_5 225, which returns additional key material to TX_4224 which then returns additional key material to TX_1 221. As each TX Node returns additional key material it may subsequently close the transaction.

[0060] Upon receiving the additional key material, the TX Node that received the request may also generate the session key (also called the final session key) and return the generated session key to the requesting Client Device. In the example of FIG. 2, TX_1 may return the generated session key to U1 201. Each session key may be associated with a randomly generated ID. The session key and randomly generated ID may be invariant and unique. The randomly generated ID may be provided to the requesting Client Device, which in turn may pass the randomly generated ID to the counterparty Client Device.

[0061] With the session key successfully delivered to the requesting Client Device, the counterparty Client Device can request the session key from the destination TX Node. ForQXC-001 instance, and continuing with the example illustrated in FIG. 2, U1 201 may pass the randomly generated ID to counterparty U2 202. U2 202 may request the session key from TX_7 207 using the randomly generated ID. TX_7 207 may then provide the session to U2202. In some instances, TX_7 207 may verify the randomly generated ID and / or U2 202 before providing the session key to U2 202.

[0062] After the session key is provided to a Client Device, it may be immediately erased from the memory of the TX Node that delivered the session key. For instance, TX_1 201 may delete the session key from its internal memory after providing the session key to U1 201 and TX_7 207 may delete the session key from its internal memory after U2202 retrieves the session key. There is no storage of the delivered keys in transitional TX Nodes beyond the time of the Parcel delivery transaction.PQC KEM Offloading

[0063] The keys provided by the Hive may be generated using post-quantum cryptography (PQC) key encapsulation method (KEM) algorithms. In this regard, instead of implementing and re-implementing a particular PQC KEM algorithm directly on a Client Device, an API can be implemented for communicating with the Hive, which in turn may provide ready-to-use session keys for use by Client Devices, such as routers or other computing devices. In operation, the Hive may choose the PQC KEM algorithm and handle sending ciphertexts. Alternatively, the Client Device can request a particular PQC KEM algorithm be used by the Hive to generate the session key. Such a request for a particular PQC KEM algorithm may be provided to the Hive when a session key is requested by the Client Device.

[0064] FIG. 3 is a diagram illustrating an example process for generating and providing a session key generated using a PQC KEM algorithm. As shown in 310, a client device, Client_A 301, requests a session key from a Hive, such as Hive 110 or Hive 210, for use in communication with client device Client_B 302. The request for the session key may be transmitted to a TX Node within the Hive that Client_A 301 is connected to, which in the example of FIG. 3 is TX Node_l 321.

[0065] TX Node_A 321, upon receiving the request from Client_A 301, generates an ephemeral keypair using a PQC KEM, as shown in 311. The ephemeral keypair may be a public / private pair generated using a key generation sub-algorithm of a PQC KEM algorithm. In cryptography, a key encapsulation mechanism is a public -key cryptosystem that allows a sender to generate a secret key, also referred to as a session key, and transmit it to a receiverQXC-001 securely, despite possible eavesdropping and intercepting adversaries. A PQC KEM algorithm allows a sender who knows a public key to simultaneously generate a short random session key and an encapsulation or ciphertext of the session key by the PQC KEM's encapsulation algorithm. The receiver who knows the private key corresponding to the public key can recover the same (symmetric) random secret key from the encapsulation by the PQC KEM's decapsulation algorithm.

[0066] A PQC KEM algorithm generally consists of three sub-algorithms. These subalgorithms include key generation, encapsulation, and decapsulation:

[0067] Key generation (pub_k, priv_k) generates a public / private keypair, where pub_k is the public key and priv_k is the private key. To generate pub_k and priv_k, an algorithm gen_keypair(DRBG_X) may be used. gen_keypair(DRBG_X) takes no inputs except DRBG_X, which is a randomly generated number, such as a number generated by a deterministic random bit generator. Using DRBG_X, the gen_keypair function returns a public k, pub_k, and a private key, priv_k.

[0068] Encapsulation (k, c), generates a session key and encapsulates it with a ciphertext, where k is a session key and c is ciphertext. To generate and encapsulate the session key k, an algorithm such as encapsulate(pub_k, DRBG_Y) may be used. encapsulate(pub_k, DRBG_Y) takes the public key pub_k, and a randomly generated number DRBG_Y to generate a session key k along with its encapsulation c (also referred to as a ciphertext). Preferably, DRBG_Y is a different number than DRBG_X, but they can be the same numbers.

[0069] Decapsulation k generates the session key using the private key and ciphertext. To generate the session key, the algorithm decapsulate(priv_k, c) may be used. decapsulate(priv_k, c) takes the private key priv_k generated by the key generation algorithm, and the ciphertext c generated by the encapsulation algorithm with matching pub_k, and either returns the session key k or fails.

[0070] After generating the ephemeral keypair, including the public key (pub_k) and private key (priv_k), TX Node_A 321 may send the public key (pub_k) to TX Node_B 322 via intervening TX Node(s)_x 323, as shown at 312. Transmission of pub_k may be across the Hive using an optimal path, determined using the techniques described herein. Thus, the number of intervening TX Node(s)_x 323 is dependent on the number of TX Nodes in the optimal path. TX Node_A 321 may store the private key in RAM or other such memory and maintain an open transaction with TX Node_B 322 while awaiting a response.QXC-001

[0071] After receiving the pub_k, TX Node_B 322 generates the session key k and ciphertext c, as shown in 313. To generate the session key k and ciphertext c, TX Node_B 322 may execute an encapsulation sub-algorithm, as described herein.

[0072] TX Node_B 322 may respond to TX Node_A 321 with the ciphertext c. Transmission of the ciphertext c may proceed in reverse along the same TX Node(s)_x 323 used to transmit pub_k from TX Node_A 321 to TX Node_B 322.

[0073] TX Node_A 321 may then execute the decapsulation sub-algorithm using the received ciphertext and private key (of the ephemeral keypair) to decode the session key, as shown in 315. TX Node_A 321 may transmit the deciphered session key to Client_A 301, as illustrated by 316 and 318. TX Node_B 322 may provide the session key to Client_B 302, as illustrated by 317 and 319. Although Fig. 3 illustrates TX Node_B 322 transmitting the session key to Client_B 302, Client_B 302 may retrieve the session key consistent with previous examples described with reference to FIGs. 1 and 2. In some embodiments, Client_A may request TX Node_B 322 provide the session key to Client_B 302.

[0074] In instances where a Hive has a single TX Node the process illustrated in FIG. 3 may be performed by the single TX node, excluding the transmission steps between nodes.Multiple PQC KEM Offloading

[0075] To further strengthen the level of security of PQC KEM algorithms, and avoid potentially weak PQC KEMs from being used, a multiple PQC KEM process may be used to generate session keys. The multiple PQC KEM process may include generating multiple session keys using PQC KEM algorithms. These session keys may then be combined into a final session key of a requested length. By using several PQC KEMs, the risk of using a single weak PQC KEM is reduced. Moreover, even if the multiple PQC KEM process is implemented by repetitively using the same weak PQC KEM, security is increased relative to using the weak PQC KEM one time to generate a session key. Additionally, vendors and other such users will benefit from the increased security of the multiple PQC KEM process provided via a Hive without the time and effort required to implement the multiple PQC KEM process on their own systems.

[0076] FIG. 4 is a diagram illustrating an example process for generating a session key using a multiple PQC KEM process. As shown in 410, a client device, Client_A 401, requests a session key from a Hive, such as Hive 110 or Hive 210, for use in communication with client device Client_B 402. The request for the session key may be transmitted to a TX Node withinQXC-001 a Hive that Client_A 401 is connected to, which in the example of FIG. 4 is TX Node_l 421. The request may include parameter(s), such as a parameter defining a length of the requested session key, referred to as the the requested length herein. Other parameters may include defining what PQC KEM algorithms to use to generate the session keys and the number of session keys that should be generated and combined into one session key.

[0077] TX Node_A 421, upon receiving the request from Client_A 401, generates ephemeral keypairs using the multiple PQC KEM algorithms, as shown in 411. The ephemeral keypairs may be a public / private pair generated using a key generation sub-algorithm of the respective PQC KEM algorithms. Each public / private keypair may include a public key pub_k and private key priv_k. For example, TX Node_A 421 may generate three public / private keypairs using three different PQC KEM algorithms. In other embodiments, TX Node_A 421 may generate the number of public / private keypairs as defined in the request parameters using PQC KEM algorithms further defined in the request parameters.

[0078] After generating the ephemeral keypairs, TX Node_A 421 may send the public keys (pub_ks) to TX Node_B 422 via intervening TX Node(s)_x 423, as shown at 412. Transmission of the pub_ks may be across the Hive using an optimal path, determined using the techniques described herein. Thus, the number of intervening TX Node(s)_x 423 is dependent on the number of TX Nodes in the optimal path. TX Node_A 421 may store the private keys in RAM or other such memory and maintain an open transaction with TX Node_B 422 while awaiting a response.

[0079] After receiving the pub_ks, TX Node_B 422 generates session keys KEM_sh_k and ciphertexts KEM_c, for each PQC KEM algorithm, as shown in 413. To generate the session keys and ciphertexts, TX Node_B 422 may run the encapsulate sub-algorithms of the PQC KEM algorithms using the received public key pub_ks. TX Node_B 422 may then concatenate all resulting shared keys KEM_sh_k into a disposable RAM buffer.

[0080] TX Node_B 422 may then respond to TX Node_A 421 with the generated ciphertexts KEM_c for each of the PQC KEM algorithms, as shown in 414. Transmission of the ciphertexts KEM_c may proceed in reverse along the same TX Node(s)_x 423 used to transmit the pub_ks from TX Node_A 421 to TX Node_B 422.

[0081] TX Node_A 421 may execute the decapsulation sub-algorithm using the received ciphertexts and the stored private keys (of the ephemeral keypairs) to generate the session keys for each PQC KEM, as shown in 415.QXC-001

[0082] Before, during, or after transmitting the ciphertexts to TX Node_A 421, TX Node_B 422 may execute a key derivation function on the concatenated session keys in the RAM buffer, as shown in 416A, resulting in the final session key of a requested length, wherein the final session key = KDF(concatenated KEM_sh_k ..., requested_key_length)), where KDF is a key derivation function, concatenated KEM_sh_k is the concatenated session keys, and requested_key_length is the requested length of the final session key. By executing the KDF, a final session key (key_final) is generated having the requested length. The key_final is a combination of the session keys generated by the respective PQC KEMs using the multiple PQC KEM process. TX Node_B 422 may store the final session key (key_final) in consecutive or non-consecutive RAM for retrieval.

[0083] TX Node_A 421 may also concatenate all resulting session keys KEM_sh_k into a RAM buffer. TX Node_A 421 may then execute a key derivation function, such as defined by RFC 2898, on the concatenated shared keys in RAM buffer, resulting in the final session key having the requested length as shown in 416A, wherein the final session key = KDF(concatenated KEM_sh_k ..., requested_key_length). The final session key derived by TX Node_A should be exactly the same as used in the final session key derived by TX Node_B 422.

[0084] TX Node_A 421 may transmit the final session key to Client_A 401, as illustrated by 417A and 418A. TX Node_B 422 may provide the final session key to Client_B 402, as illustrated by 417B and 418B. Although Fig. 4 illustrates TX Node_B 422 transmitting the final session key to Client_B 402, Client_B 402 may retrieve the final session key consistent with previous examples described with reference to FIGs. 1 and 2. In some embodiments, Client_A 401 may request TX Node_B 422 provide the final session key to Client_B 402.

[0085] As in PQC KEM Offloading, after the session keys are provided to Client_A 401 and Client_B 402, the session keys and keypairs may be wiped from the memory (e.g., RAM) of the TX Nodes in the Hive. Thus, session keys and keypairs cannot be retrieved after Client_A 401 and Client_B 402 receive the final session key.

[0086] In instances where a Hive has a single TX Node the process illustrated in FIG. 4 may be performed by the single TX node, excluding the transmission steps between nodes.Multiple PQC KEM In-Band

[0087] Although there are security benefits to implementing the multiple PQC KEM process on a Hive, Multiple PQC KEM Offloading may be implemented in-band, by devicesQXC-001 outside of a Hive. In PQC KEM Offloading and Multiple PQC KEM Offloading, the Hive implements session key generation by generating public / private key pairs for each request. However, when implementing a PQC KEM off Hive, it is not necessary to continually generate public / private keypairs. Rather, clients that are forming a communication channel with a PQC KEM session key or Multiple PQC KEM session key may have private keys, priv_k, preinstalled on each client and public keys, pub_k, stored on opposite clients. The public and private keys may be installed in advance by calling a gen_keypair() algorithm, as described herein, and storing the matching private keys, priv_k, on both clients and the public keys pub_k on opposite clients. For instance, a first client, Client A may generate a public / private keypair with private key priv_a and public key pub_a. Client A may store private key priv_a and share public key pub_a with Client B. Client B may also generate a public / private keypair with private key priv_b and public key pub_b. Client B may store private key priv_b and share public key pub_b with Client A. Thus, Client A may have pub_b and priv_a, and Client B may have pub_a and priv_b.

[0088] The process for generating a session key for in-band between two clients using multiple PQC KEM, including Client Devices Client_A 501 and Client_B 502, is illustrated in Fig. 5. To generate the session key, the Local Client_A 501 may receive a request for a session key for communication with Remote Client 502, as shown in 510. Client_A 501 may generate the session keys KEM_sh_k and ciphertexts KEM_c, for each PQC KEM algorithm, as shown in 513. To generate the session keys and ciphertexts, Client_A 501 may run the encapsulate sub-algorithms of the PQC KEM algorithms using the pub_k.

[0089] Client_A 501 may transmit the generated ciphertexts KEM_c to Client_B 502, as shown in 512. Client_B may then execute the decapsulate() sub-algorithm using the preinstalled private key, priv_k, to generate the session keys KEM_sh_k, as shown in 515. Client_A 501 and Client_B 502 may concatenate the resulting shared keys KEM_sh_k into respective disposable RAM buffers.

[0090] Client_A 501 and Client_B may each execute a key derivation function, such as defined by RFC 2898, on the concatenated shared keys in their respective RAM buffers, to derive the final session key having the requested length as shown in 516A and 516B, respectively. The final session key can be output for use during communication between Client_A 501 and Client_B 502, as shown in 518A and 518B, respectively.QXC-001Example System

[0091] FIG. 6 illustrates an example system 600 in which the features described herein may be implemented. It should not be considered limiting the scope of the disclosure or usefulness of the features described herein. In this example, system 600 includes client devices 601, 602, hive 610 comprising nodes, and network 650. Although FIG. 6 illustrates only two client devices, one Hive, and one network, a system may include any number of client devices, hives, and networks.

[0092] Client devices 601, 602 may be any computing device capable of communicating over a network, including routers, switches, personal computing devices intended for use by a respective user, and all other such devices. Client devices 601, 602 may include any combination of components normally used in connection with a computing device. For instance, client devices 601, 602 include one or more processors 602, memory 603 (e.g., RAM and internal hard drives) for storing data 604 and instructions 605, and communication interface 608 for communicating with other devices and / or the hive 610. Client device 602 has additional computing components including outputs 607, such as a display (e.g., a monitor having a screen, a touch-screen, a projector, a television, etc.) and inputs 606 (e.g., a mouse, keyboard, touchscreen or microphone). The configurations of client devices 601, 602 are merely illustrative and are not meant to be limiting. Each client device may be capable of exchanging and / or obtaining data over the network 650, wirelessly and / or through a wired connection.

[0093] The one or more processors 602 may be any conventional processors, such as commercially available microprocessors. Alternatively, the one or more processors may be a dedicated device such as an application- specific integrated circuit (ASIC) or other hardwarebased processor. Although Figure 1 functionally illustrates the processor, memory, and other elements of client devices 601, 602 as being within the same block, it will be understood by those of ordinary skill in the art that the processor, computing device, or memory may actually include multiple processors, computing devices, or memories that may or may not be stored within the same physical housing. Similarly, the memory may be a hard drive or other storage media located in a housing different from that of the client devices 601, 602. Accordingly, references to a processor or computing device will be understood to include references to a collection of processors or computing devices or memories that may or may not operate in parallel or in a distributed fashion.QXC-001

[0094] Memory 603 may store information that is accessible by the processors 602, including instructions 604 that may be executed by processor 602, and data 605. The memory 603 may be any type of memory operative to store information accessible by the processors 602, including a non-transitory computer-readable medium, or other medium that stores data that may be read with the aid of an electronic device, such as a hard-drive, memory card, readonly memory (“ROM”), random access memory (“RAM”), optical disks, as well as other write- capable and read-only memories. The subject matter disclosed herein may include different combinations of the foregoing, whereby different portions of instructions 604 and data 605 are stored on different types of media.

[0095] Data 605 may be retrieved, stored, and modified by processors 602 in accordance with instructions 604. For instance, although the present disclosure is not limited by a particular data structure, the data 605 may be stored in computer registers, in a relational database as a table having a plurality of different fields and records, XML documents, in RAM, or flat files. The data 605 may also be formatted in a computer-readable format such as, but not limited to, binary values, ASCII, or Unicode. Moreover, data 605 may comprise information sufficient to identify the relevant information, such as numbers, descriptive text, proprietary codes, pointers, references to data stored in other memories (including other network locations) or information that is used by a function to calculate the relevant data.

[0096] The instructions 604 can be any set of instructions to be executed directly, such as machine code, or indirectly, such as scripts, by the processor 602. In that regard, the terms “instructions,” “application,” “steps,” “algorithms,” and “programs” can be used interchangeably herein. The instructions can be stored in object code format for direct processing by the processor, or in any other computing device language including scripts or collections of independent source code modules that are interpreted on demand or compiled in advance. Functions, methods, algorithms, and routines of the instructions are explained in more detail herein.

[0097] The client devices 601, 602 may be at various nodes of a network 650 and capable of directly and indirectly communicating with other nodes of network 650. Although two client devices are depicted in FIG. 6, it should be appreciated that a typical system 600 can include more than two client devices, with each client device being at a different node of network 650. The network 650 and intervening nodes described herein can be interconnected using various protocols and systems, such that the network can be part of the Internet, WorldQXC-001Wide Web, specific intranets, wide area networks, or local networks. The network 650 can utilize standard communications protocols, such as WiFi, that are proprietary to one or more companies. Although certain advantages are obtained when information is transmitted or received as noted above, other aspects of the subject matter described herein are not limited to any particular manner of transmission.

[0098] Hive 610 includes nodes (611-615), also referred to as TX Nodes herein. A hive may include any number of nodes. The nodes 611-615 of the Hive 610 may be distributed across the network 650 and / or be connected via a local network. The nodes 611-615 are configured to receive, process, and transmit data to and from other nodes and client devices. As shown in FIG. 6, Node 1 611 includes one or more processors 642, memory 643, instructions 644, and data 645, which may be compared to one or more processors 602, memory 603, instructions 604, and data 605.

[0099] Although the technology herein has been described with reference to particular embodiments, it is to be understood that these embodiments are merely illustrative of the principles and applications of the present technology. It is therefore to be understood that numerous modifications may be made to the illustrative embodiments and that other arrangements may be devised without departing from the spirit and scope of the present technology as defined by the appended claims.

Claims

QXC-001CLAIMS1. A method for out-of-band generation of a session key using a post-quantum cryptography (PQC) key encapsulation method (KEM), the method comprising: generating, by a first node, a public / private keypair comprising a public key and a private key using the PQC KEM; transmitting, by the first node to a second node, the public key; generating, by the second node, the session key and a ciphertext; transmitting, by the second node to the first node, the ciphertext; and decoding, by the first node, the session key using the ciphertext.

2. The method of claim 1, wherein the public key and the private key are generated using a deterministic random bit generator.

3. The method of claim 1, wherein the first node is connected to a first client device and the second node is connected to a second client device.

4. The method of claim 3, wherein prior to generating the public / private keypair, the first node receives a request for the session key from the first client device.

5. The method of claim 3, wherein the first node provides the session key to the first client device and the second node provides the session key to the second client device for in-band communication.

6. The method of claim 1 , wherein generating the session key and the ciphertext comprises executing an encapsulation algorithm where the public key and a randomly generated number are inputs to the encapsulation algorithm and the session key and the ciphertext are outputs of the encapsulation algorithm.

7. The method of claim 1, wherein decoding the session key comprises executing a decapsulation algorithm where the private key and the ciphertext are inputs to the decapsulation algorithm and the session key is the output of the decapsulation algorithm.QXC-0018. A method for generation of a session key using multiple post-quantum cryptography (PQC) key encapsulation methods (KEMs), the method comprising: generating, by a first node, public / private keypairs, each public / private keypair comprising a public key and a private key, wherein each public / private / keypair is generated using a PQC KEM; transmitting, by the first node to a second node, each public key of each public / private keypair; generating, by the second node, for each public key of each public / private keypair, a session key and a ciphertext; transmitting, by the second node to the first node, the ciphertext generated from each public key; decoding, by the first node, the session key for each public / private keypair using the ciphertext generated from each public key; deriving, by the first node, a final session key using the decoded session keys; and deriving, by the second node, another final session key using the generated session keys, wherein the final session key and the other final session key are the same keys.

9. The method of claim 8, wherein prior to deriving the final session key and the other final session key, the first node concatenates the decoded session keys into a buffer and the second node concatenates the generated session keys into another buffer.

10. The method of claim 9, wherein deriving the final session key and the other final session key comprises executing a key derivation function on the final session key and the other final session key, the key derivation function generating the final session key and the final session key having a predefined length.

11. The method of claim 8, wherein generating the session key and the ciphertext for each public key of each public / private keypair, comprises executing an encapsulation algorithm where each of the public keys and a randomly generated number are inputs to the encapsulation algorithm and the session keys and the ciphertexts of each of the public keys are outputs of the encapsulation algorithm.QXC-00112. The method of claim 8, wherein decoding the session key for each public / private keypair comprises executing a decapsulation algorithm where the private key and the ciphertexts generated from each public key are inputs to the decapsulation algorithm and the session key of each of the public keys is the output of the decapsulation algorithm.

13. A method for generating a session key using multiple post-quantum cryptography (PQC) key encapsulation methods (KEMs), the method comprising: generating, by one or more processors, for each PQC KEM a session key; concatenating, by the one or more processors, each generated session key into a buffer; and deriving, by the one or more processors from the concatenated session keys, a final session key.

14. The method of claim 13, wherein generating each session key further comprises generating a corresponding ciphertext.

15. The method of claim 14, further comprising: transmitting, by the one or more processors, each ciphertext to one or more other processors.

16. The method of claim 15, further comprising: decoding, by the one or more other processors, each session key corresponding to each ciphertext.

17. The method of claim 16, further comprising: concatenating, by the one or more other processors, each decoded session key into another buffer; and deriving, by the one or more other processors from the concatenated session keys in the other buffer, another final session key, the another final session key being the same as the final session key.QXC-00118. A non-transitory computer-readable medium containing instructions, the instructions, when executed by one or more computing devices, cause one or more computing devices to perform the method of one of the claims 1 to 17.

19. A system comprising one or more nodes configured to perform the method of one of claims 1 to 17.

Images