Secure Key Generation

Abstract

A key updater for a first party operating on the network generates a mutually distilled key for communications between the first party and a second party. The key updater determines a set of verification parties operating on the network that are required to authenticate the mutually distilled key, each verification party of the set of verification parties operating on the network. The key updater iteratively performs key equality tests for each verification party in the set of verification parties to determine a nonce sum until it is determined that a key equality test has been performed for each verification party in the set of verification parties or it is determined that at least one node on the network has been compromised. The key updater generates a final key for communications between the first party and the second party based on the nonce sum and the mutually distilled key.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE This disclosure relates to computer security, and more particularly to systems and methods for securely generating keys. [Background technology]

[0002] In cryptography, quantum key distribution (QKD) is a secure communication method that implements encryption protocols that include elements of quantum mechanics. QKD allows two parties to generate a shared random secret key known only to the two parties, which can be used to encrypt and decrypt messages. QKD allows two communicating users to detect the presence of a third party attempting to obtain knowledge of the key. This advantage comes from a fundamental aspect of quantum mechanics: the process of measuring a quantum system generally perturbs the system. A third party attempting to eavesdrop on the key would need to measure the key in some way, resulting in a detectable anomaly. By utilizing quantum superposition or quantum entanglement to transmit information in a quantum state, a communication system that detects eavesdropping can be implemented. If the level of eavesdropping falls below a certain threshold, a key that is guaranteed to be secure can be generated (e.g., the eavesdropper has no knowledge of the key), otherwise a secure key is not feasible and communication is interrupted.

[0003] A hash function is a function that can be used to map data of any size into a fixed-size value. The value returned by a hash function is called a hash value, hash code, digest, or simply hash. These values ​​are typically used to index a fixed-size table called a hash table. Using a hash function to index a hash table is called hashing or distributed storage addressing. Summary of the Invention

[0004] One example relates to a non-transitory machine-readable medium having machine-executable instructions comprising a key updater for a first party operating on a network. The key updater generates a mutually distilled key for communications between the first party and a second party and determines a set of verification parties operating on the network that are required to authenticate the mutually distilled key. Each verification party in the set of verification parties operates on the network. The key updater iteratively performs key equality tests to determine a nonce sum for each verification party in the set of verification parties until it is determined that a key equality test has been performed for each verification party in the set of verification parties or at least one node on the network has been compromised. The key updater generates a final key for communications between the first party and the second party based on the nonce sum and the mutually distilled key if a key equality test has been successfully performed for each verification party in the set of verification parties.

[0005] Another example relates to a system for updating a key. The system includes a non-transitory memory having machine-readable instructions and a processing unit for accessing the machine-readable instructions. The machine-readable instructions include a key authenticator for a verifying party to verify a mutually distilled key generated for communication between a first party and a second party. The key authenticator receives from the first party a first encrypted hash of the mutually distilled key that is decryptable only with a first key of a key set for communication between the first party and the verifying party. The authenticator also receives from the second party a second encrypted hash of the mutually distilled key that is decryptable only with the first key of a key set for communication between the verifying party and the second party. The key authenticator decrypts the first encrypted hash of the mutually distilled key to reveal the first hash of the mutually distilled key. The key authenticator further decrypts the second encrypted hash of the mutually distilled key to reveal the second hash of the mutually distilled key, and if the first hash of the mutually distilled key equals the second hash of the mutually distilled key, encrypts the nonce value with a different key to provide a first encrypted nonce value decryptable only with a second key of the set of keys for communications between the verifying party and the first party and a second encrypted nonce value decryptable only with the second key of the set of keys for communications between the verifying party and the second party. The key authenticator sends a notification to the first party and the second party that at least one node on the network has been compromised if the first hash of the mutually distilled key does not equal the second hash of the mutually distilled key.

[0006] Yet another example relates to a method for verifying a key, the method including a first computing device for a first party and a second computing device for a second party generating a mutually distilled key for communication between the first party and the second party, and the method also includes a step of the first computing device and the second computing device determining a plurality of verification parties operating on a network required to authenticate the mutually distilled key, each verification party of the plurality of verification parties operating on the network. The method further includes a step of iteratively performing a key equality test for each of the plurality of verification parties to determine a nonce sum until it is determined that a key equality test has been performed for each of the plurality of verification parties or it is determined that at least one node on the network has been compromised. In each iteration of the key equality test, the first computing device and the second computing device select one verification party of the plurality of verification parties, provide the selected verification party, and receive a first encrypted nonce value from the selected verification party. The first encrypted nonce value received at the first computing device is decryptable only with a first key of a set of keys for communications between the first party and the selected verification party, and the first encrypted nonce value received at the second computing device is decryptable only with a first key of a set of keys for communications between the second party and the verification party. The first computing device and the second computing device receive encrypted hashes of the nonce values, where the encrypted hash of the nonce value received at the first computing device is decryptable only with the first key of the set of keys for communications between the first party and the second party, and the encrypted hash of the nonce value received at the second computing device is decryptable only with a second key of the set of keys for communications between the first party and the second party.The first computing device and the second computing device also decrypt the nonce value and the encrypted hash of the nonce value to reveal a hash of the first nonce value and the second nonce value, and hash the first nonce value to provide a hash of the first nonce value. The first computing device and the second computing device add the first nonce value to a nonce sum if the hash of the first nonce value equals the hash of the second nonce value, or determine that at least one node on the network has been compromised if the hash of the first nonce value does not equal the hash of the second nonce value. The method further includes the first computing device and the second computing device generating a final key for communications between the first party and the second party based on the nonce sum if the key equality test for each of the multiple verifying parties is successfully performed. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 illustrates a system for securely authenticating cryptographic keys. [Diagram 2] FIG. 2 illustrates an example of an architecture for cryptographic keys. [Diagram 3] FIG. 2 illustrates an example of an iteration of a key equivalency test (KET). [Figure 4] FIG. 13 illustrates the generation of a final key. [Diagram 5] FIG. 1 illustrates an example of a computing platform for generating and authenticating cryptographic keys. [Figure 6] 1 is a flowchart of an exemplary method for generating a final key for communications between a first party (eg, "Alice") and a second party (eg, "Bob"). [Figure 7] 11 is a flowchart of an example sub-method representing a single iteration of KET. [Figure 8]1 is a flowchart of an example sub-method that can be employed to perform mutually distilled key authentication at one verifying party for an iteration of a KET. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] This specification relates to securely authenticating and generating cryptographic keys in a network environment. The process begins after a mutually distilled key is generated between two parties, which are operating nodes of the network and are referred to as "Alice" and "Bob" (consistent with industry standard nomenclature). Alice and Bob represent computing devices that operate as communication endpoints. Alice and Bob can operate as user workstations, servers, mobile devices, Internet of Things (IoT) devices, etc. The mutually distilled key exchanged between Alice and Bob can be a symmetric or asymmetric key. In some examples, the mutually distilled key can be generated using quantum key distribution (QKD) between Alice and Bob.

[0009] To initially authenticate the mutually distilled key, Alice and Bob each perform a hash function on the mutually distilled key and encrypt the resulting hash using another key (previously authenticated) of the mutually-established keys. Alice and Bob then decrypt the encrypted hash and compare the decrypted version with the version sent to the other party to verify that Alice and Bob have the same mutually distilled key. In summary, Alice (i) hashes the mutually distilled key, (ii) encrypts the hash, and (iii) sends the encrypted hash to Bob. Alice (iv) receives the encrypted hash from Bob, and (v) decrypts the encrypted hash to reveal the decrypted hash. Thus, Alice (vi) compares the hash (performed on the mutually distilled key) with the decrypted hash, and if the hash and the decrypted hash are equal, Alice can be confident that Bob has a copy of the mutually distilled key.

[0010] Assuming that Alice and Bob can verify that both parties possess the mutually distilled key, Alice and Bob perform a key equality test (KET) on the mutually distilled key. In KET, Alice and Bob each perform a hash on the mutually distilled key, encrypt the hash using a previously authenticated key, and send the encrypted hash to a third party operating a node (communication endpoint) in the network called "Charlie." That is, both Alice and Bob have different keys authenticated for communication with Charlie, and these keys are used to encrypt a hash of the mutually distilled key. Charlie decrypts the encrypted hashes sent by both Alice and Bob and compares the decrypted hashes. If the hashes are equal, the KET for the verification process continues.

[0011] Assuming the KET continues, Charlie generates a nonce value (a random number) and encrypts it using the key previously authenticated to Alice and Bob. Charlie sends the encrypted nonce value to both Alice and Bob. Alice and Bob decrypt the nonce value to reveal the decrypted nonce value. Alice and Charlie then hash the decrypted nonce value, then encrypt the hash of the decrypted nonce value, and send the encrypted hash to each other for comparison. In summary, Alice (i) receives the encrypted nonce value from Charlie, and (ii) decrypts the encrypted nonce value to reveal the decrypted nonce value. In response, Alice (iii) hashes the decrypted nonce value, (iv) encrypts the resulting hash, and (v) sends the encrypted hash to Bob. Alice also (vi) receives the encrypted hash from Bob, and (vii) decrypts the encrypted hash to reveal the decrypted hash. Alice can then (viii) compare the decrypted hash to the hash of the decrypted nonce value. If these values ​​are equal, the KET for the mutually distilled key is complete, and so is the key verification. After completing the KET for the mutually distilled key, Alice and Bob can calculate the nonce sum of the decrypted nonce values. Alice and Bob can apply the mutually distilled key and the nonce sum to a key derivation function to obtain a final key. This final key can be stored and used for subsequent communications (e.g., overhead such as network traffic or further key authentication). By using the KET, a third party, namely Charlie, authenticates Alice and Bob to prevent spoofing of Alice or Bob's identity. Furthermore, in many situations, a fourth party (often called "David") operating a node on the network (e.g., another communication endpoint) can operate in the same manner as Charlie to further prevent spoofing of such identity. Furthermore, in the example provided, Alice, Bob, Charlie, and David are each peers in the network.That is, Alice, Bob, Charlie, and / or David do not need to have special privileges and / or hardware to execute the KET. Furthermore, the KET can be used for almost any type of encryption scheme, including one-time pads (OTPs) and / or conventional symmetric algorithms.

[0012] 1 illustrates a system 100 for securely authenticating cryptographic keys (hereafter simply "keys"). System 100 includes nodes communicating over a network 104 (e.g., a network). Network 104 can be, for example, a public network (e.g., the Internet), a private network (e.g., a local area network or a cellular network), or a combination thereof (e.g., a virtual private network).

[0013] In FIG. 1, there are five nodes on the network 104. However, in other examples, there may be more or fewer nodes on the network 104. The communication on the network 104 represents classical channels (e.g., electrical and / or optical communication channels) between the nodes. Each node on the network 104 is a communication endpoint, such as a computing device. More specifically, each node on the network 104 represents a non-transitory machine-readable memory that stores machine-executable instructions and a processing unit that accesses the non-transitory memory and executes the machine-executable instructions. In the example provided, the nodes include a first node, “Alice” 108, and a second node, “Bob” 112, which refer to fictional characters consistent with standard industry nomenclature. The nodes on the network 104 also include K verifying parties 116, where K is an integer equal to or greater than 1. Each verifying party includes an index number i. Thus, the first verifying party 116-1 is referred to as the fictional character “Charlie” (e.g., Charlie 116-1) for ease of explanation. Similarly, the second verifying party 116-2 is referred to as the fictional character "David" (eg, David 116-2), and the Kth verifying party 116-K is referred to as the fictional character "Kevin" (eg, Kevin 116-K).

[0014] Alice 108 and Bob 112 each include a quantum key distribution (QKD) module 120 running on Alice 108 and Bob 112. The QKD module 120 of Alice 108 and the QKD module 120 of Bob 112 work in concert to establish a quantum channel 124 between Alice 108 and Bob 112. The quantum channel 124 can be used to leverage quantum technology to generate a mutually distilled key (or multiple mutually distilled keys) between Alice 108 and Bob 112 that cannot be determined by an eavesdropper (often called "Eve") due to the laws of physics. That is, both Alice 108 and Bob 112 are assured that the mutually distilled key is owned only by Alice 108 and Bob 112. To initially authenticate the mutually distilled key, Alice 108 and Bob 112 each perform a hash function on the mutually distilled key and encrypt the resulting hash using another key (previously authenticated) of the mutually established key. Alice 108 and Bob 112 then decrypt the encrypted hash and compare the decrypted version with the version sent to the other party to verify that Alice 108 and Bob 112 have the same mutually distilled key. However, traditionally there is no way to verify that the first node 108 or the second node 112 have been spoofed by a hacker. Stated another way, traditional systems have no way to determine whether a hacker operating a node called "Fake Bob" is spoofing the identity of the second node 112.

[0015] To address this issue, Alice 108 and Bob 112 execute a key updater 128 (e.g., a software module) that employs a key equality test (KET) 132 to leverage trusted communications with a selected number of verifying parties 116 to authenticate mutually distilled keys and generate a final key 138 that can be used to communicate over the network 104 (e.g., a classical channel). Unless otherwise stated, the keys described herein are symmetric encryption keys. That is, a given key can be used to encrypt data that is only decryptable with the given key. Thus, the final key 138 can be used to encrypt or decrypt data, and the final key 138 is a symmetric encryption key.

[0016] Figure 2 shows a chart 200 illustrating the key architecture employed by the system 100 of Figure 1. For ease of explanation, the same nomenclature (e.g., Alice, Bob, and Charlie) is used to indicate the same nodes in Figures 1 and 2. Chart 200 shows the naming convention for a key 204 labeled "CAT3."

[0017] The chart 200 includes a column labeled "Node" that identifies each node on a network (e.g., network 104 of FIG. 1). The selected node (Alice) is highlighted. The chart 200 includes a column labeled "Link" with highlighted text boxes that identify the selected node (Alice) and the node (Charlie in the illustrated example) with which the selected node is communicating regarding the key 204. Additionally, the chart 200 includes a column labeled "Task" with highlighted boxes to identify the task (traffic in the illustrated example) designated for the key 204. Additionally, the chart 200 includes a highlighted text box that describes the communication direction for the key 204 (Charlie to Alice in the illustrated example). Additionally, the chart 200 includes a column labeled "Key Index" that contains the key index number for the key 204.

[0018] Thus, in the illustrated example, the term CAT3 uniquely describes the third key (CAT3's "3") held by Alice for communicating traffic (CAT3's "T") sent from Charlie to Alice (CAT3's "CA"). Conversely, the complement of the key set at Alice for sending traffic from Alice to Charlie is ACT3.

[0019] As another example, a second of the keys at Bob for communicating overhead from Alice to Bob is ABO2. Similarly, the complementary key at Bob for communicating overhead from Bob to Alice is BAO2. Thus, as shown, the key names (such as key 204) can be used as shorthand to understand how the keys work. Each of these keys, ABO2 and BAO2, are symmetric encryption keys that can be used as examples of final key 138 in FIG. 1.

[0020] 1, as previously described in response to the generation of the mutually distilled key, the key updater 128 uses the KET module 132 to authenticate the mutually distilled key to generate the final key 138. The key updater 128 determines a set of verification parties 116 required to authenticate the mutually distilled key, with each verification party 116 of the set of verification parties 116 operating on the network 104. The KET module 132 iteratively executes the KET for each of the determined set of verification parties 116 to determine a nonce sum until it is determined that the KET has been successfully executed for each of the set of verification parties 116 or that at least one node on the network 104 has been compromised. During each iteration of the KET, the key updaters 128 of Alice 108 and Bob 112 communicate with a key authenticator 142 executing on the corresponding verification party 116. The key authenticator 142 may be, for example, a key updater module similar to the key updater 128 of Alice 108 and Bob 112, or a separate module.

[0021] In a first example (hereinafter "first example"), assume that the key updater 128 determines that the first and second verifying parties 116, namely Charlie 116-1 and David 116-2, need to verify a mutually distilled key. In the first example, the KET module 132 performs a KET on the mutually distilled key with both Charlie 116-1 and David 116-2, either sequentially or in parallel.

[0022] FIG. 3 illustrates a diagram of a system 300 performing a method illustrating operation during a first example, where KET iterations are performed by KET modules 132 of Alice 304 (e.g., Alice 108 in FIG. 1) and Bob 308 (112 in FIG. 1). In this method, assume that key updaters of Alice 304 and Bob 308 select Charlie 312 (e.g., Charlie 116-1 in FIG. 1) for KET iterations. At 400, Alice 304 (e.g., KET module 132 of Alice 108 in FIG. 1) performs a hash function on a mutually distilled key (labeled MDK in FIG. 3) between Alice 304 and Bob 308 to provide a first hash of the mutually distilled key. As used herein, hash refers to a particular one-way encryption function (e.g., a non-decryptable function). Stated differently, throughout this disclosure, each reference to a hash function, or "hashing," and its derivatives, is presumed to refer to the same hash function, such that the same input to the hash function results in the same output. At 405, Alice 304 (e.g., KET module 132 of Alice 108 in FIG. 1) encrypts the first hash of the mutually distilled key with key ACO1 to provide a first encrypted hash of the mutually distilled key. Alice 304 sends the first encrypted hash of the mutually distilled key to Charlie 312. With reference to FIG. 2, key identifier ACO1 refers to Alice's key that can be used to communicate overhead to Charlie 312 with key index 1. Thus, the encrypted hash of the mutually distilled key can only be decrypted with key ACO1.

[0023] At 410, Bob 308 hashes the mutually distilled key using a hash function to provide a second hash of the mutually distilled key. At 415, Bob 308 encrypts the second hash of the mutually distilled key with key BCO1 to provide a second encrypted hash of the mutually distilled key that is decryptable only with key BCO1. The second encrypted hash of the mutually distilled key is sent to Charlie 312.

[0024] At 420, Charlie (running a key authenticator, such as key authenticator 142 of FIG. 1) decrypts the first encrypted hash of the mutually distilled key provided by Alice 304 using key ACO1 to reveal the first hash of the mutually distilled key. At 425, Charlie (again running a key authenticator) decrypts the second hash of the mutually distilled key using key BCO1 to reveal the second hash of the mutually distilled key. At 430, Charlie's key authenticator compares the first hash of the mutually distilled key to the second hash of the mutually distilled key. If the first hash of the mutually distilled key equals the second hash of the mutually distilled key, KET continues. Conversely, if the first hash of the mutually distilled key does not match the second hash of the mutually distilled key, Charlie 312 provides notification to Alice 304 and Bob 308 (and / or another node) that one or more nodes of the network may have been compromised, and the KET iteration fails.

[0025] If KET continues (successful comparison at 430), at 435, Charlie's 312's key authenticator generates a nonce value (e.g., a cryptographic nonce value such as an integer value). At 440, Charlie's 312's key authenticator encrypts the nonce value using key CAO1 (Charlie's 312's first key for transmitting overhead data to Alice 304) to provide a first encrypted nonce value that is decryptable only with key CAO1. Charlie sends the first encrypted nonce value to Alice 304. At 445, Charlie's 312's key authenticator encrypts the nonce value using key CBO1 (Charlie's 312's first key for transmitting overhead data from Charlie 312 to Bob 308) to provide a second encrypted nonce value. Charlie 312 sends the second encrypted nonce value to Bob 308.

[0026] At 450, Alice's 304 KET module decrypts the first encrypted nonce value using key CAO1 to reveal a first nonce value (which should be equal to the nonce value generated by Charlie 312 at 435 before encryption). At 455, the first nonce value is hashed with a hash function to provide a first hash of the nonce value. At 460, the first hash of the nonce value is encrypted with key ABO4 (Alice's 304 fourth key for communicating overhead data from Alice 304 to Bob 308) to provide a first encrypted hash of the nonce value. Alice's 304 KET module sends the first encrypted hash of the nonce value to Bob 308. Similarly, at 465, Bob's KET module decrypts the second encrypted nonce value to reveal a second nonce value (which should be equal to the nonce value generated by Charlie 312 at 435 before encryption). At 470, the KET module of Bob 308 hashes the second nonce value with a hash function to provide a second hash of the nonce value. At 475, the second hash of the nonce value is encrypted with key BAO4 (Bob's 308 fourth key for communicating overhead data from Bob 308 to Alice 304) to provide a second encrypted hash of the nonce value.

[0027] At 480, Alice's 304's KET module decrypts the second encrypted hash of the nonce value using key BAO4 to reveal the second hash of the nonce value. At 485, Bob's 308's KET module decrypts the first encrypted hash of the nonce value to reveal the first hash of the nonce value. At 490, Alice's 304's KET module compares the first hash of the nonce value to the second hash of the nonce value. If the first hash of the nonce value equals the second hash of the nonce value, the KET iteration has passed for Alice 304 and the first hash of the nonce value (or, since they are equal, the second hash of the nonce value) is added to the nonce sum value. Conversely, if the first hash of the nonce value does not match the second hash of the nonce value, Alice 304 generates a notification that at least one node on the network may have been compromised and the KET iteration fails. The notification may be provided to Bob 308, Charlie 312, and / or other nodes in the network.

[0028] Similarly, at 495, the KET module of Bob 308 compares the first hash of the nonce value to the second hash of the nonce value. If the first hash of the nonce value equals the second hash of the nonce value, the KET iteration passes for Bob 308 and the nonce value is added to the nonce sum value. Conversely, if the first hash of the nonce value does not match the second hash of the nonce value, Bob 308 generates a notification that at least one node on the network may have been compromised and the KET iteration fails. The notification may be provided to Alice 304, Charlie 312, and / or another node in the network.

[0029] Referring back to Figure 1, the KET module 132 performs an iteration of the KET for each determined verifying party 116-1 using a method similar to that shown in Figure 3. If each iteration of the KET is successful, the key updaters 128 of Alice 108 and Bob 112 both have equal nonce sums. That is, the nonce sum of the key updater 128 of Alice 108 is equal to the nonce sum of the key updater 128 of Bob 112. In response to generating the nonce sums, the key updaters 128 of Alice 108 and Bob 112 use the nonce sums and the mutually distilled key to generate a final key 138. Figure 4 illustrates this process. More specifically, Figure 4 illustrates a system 500 performing the method for the first example, where the key updaters (e.g., key updater 128 of Figure 1) of Alice 504 (e.g., Alice 108 of Figure 1) and Bob 508 (e.g., Bob 112 of Figure 1) have successfully performed each iteration of the KET to generate a nonce sum. At 600, the key updater of Alice 504 combines the mutually distilled key (labeled "MDK") and the nonce sum with an XOR function to provide a combination of the nonce sum and the mutually distilled key. At 605, the key updater of Alice 504 performs a key derivation function (KDF) to convert the combination of the nonce sum and the mutually distilled key into a final key (e.g., final key 138 of Figure 1). Similarly, at 610, Bob's 508 key updater combines the mutually distilled key (labeled "MDK") and the nonce sum with an XOR function to provide a combination of the nonce sum and the mutually distilled key. At 615, Alice's 504 key updater runs a KDF to convert the combination of the nonce sum and the mutually distilled key into a final key (e.g., final key 138 of FIG. 1). The KDF may be a one-time-pad (OTP) algorithm or a conventional symmetric algorithm. Thus, in various examples, the final key provided by the KDF for both Alice 504 and Bob 508 may be an OTP key or a conventional symmetric encryption key. Because both Alice 504 and Bob 508 have the mutually distilled key and the same nonce sum (as described herein), Alice's 504 and Bob's 508 key updaters generate the same final key.

[0030] Referring back to FIG. 1, as previously mentioned, in some examples, the final key 138 can be used to encrypt and decrypt data transmitted between Alice 108 and Bob 112 over the network 104. That is, the final key 138 can be used to encrypt and decrypt data passing through a classical channel. Furthermore, the same mutually distilled key can be used to generate multiple instances of the final key 138. Such a key can be used to encrypt overhead data or traffic for transmission over the network 104. Furthermore, the generation of the final key 138 does not require that either the final key 138 or the mutually distilled key (used to generate the final key 138) be transmitted over a channel (either the quantum channel 124 or the classical channel over the network 104). In other words, the final key 138 is generated without transmitting an encrypted version of the key (including the final key 138 or the mutually distilled key) or an unencrypted version of the key between the two parties of the network 104. Instead, the key updaters 128 of both Alice 108 and Bob 112 use a systematic procedure (method) for generating the final key 138. Furthermore, no elevated privileges are required to generate the final key 138, i.e., each node on the network 104 may be a peer with the same privileges (although in some instances, some nodes on the network 104 may be permitted to have elevated privileges).

[0031] Furthermore, the generation of the final key 138 depends on the existence of pre-existing relationships between the nodes of the network 104. More specifically, as shown in FIG. 3, the KET module 132 performs iterations of the KET. Each iteration of the KET requires both Alice 108 and Bob 112 to communicate securely with a particular verifying party 116. Thus, in a situation where the mutually distilled key was generated using a spoofer (e.g., a "fake Bob"), the spoofer will not be able to establish secure communication with the verifying party 116 during an iteration of the KET. Thus, the spoofer (e.g., a compromised node of the network 104) will be detected and the final key 138 will not be generated.

[0032] 5 illustrates an example of a computing platform 700 for generating and authenticating a cryptographic key, such as the final key 138 of FIG. 1. The computing platform 700 can be used to implement a node on a network 716, such as the first node 108 (Alice) of FIG. 1, the second node 112 (Bob) of FIG. 1, or one of the verifying parties 116 of FIG. 1. The computing platform 700 can include a memory 704 for storing machine-readable instructions and data, and a processing unit 708 for accessing the memory 704 and executing the machine-readable instructions. The memory 704 represents a non-transitory machine-readable memory (or other medium), such as a random access memory (RAM), a solid-state drive, a hard disk drive, or a combination thereof. The processing unit 708 can be implemented as one or more processor cores. Computing platform 700 may include a network interface 712 (e.g., a network interface card) configured to communicate with other computing platforms over a network 716, such as a public network (e.g., the Internet), a private network (e.g., a local area network (LAN)), or a combination thereof (e.g., a virtual private network). Computing platform 700 may also include a quantum channel interface 720 for communicating with an external node 724 over a quantum channel 728.

[0033] Computing platform 700 may be implemented within a computing cloud. In such a situation, the functionality of computing platform 700, such as processing unit 708, network interface 712, and memory 704, may represent a single instance of hardware or may represent multiple instances of hardware where an application runs across multiple (e.g., distributed) instances of hardware (e.g., computers, routers, memory, processors, or combinations thereof). Alternatively, computing platform 700 may be implemented on a single dedicated server or workstation.

[0034] The memory 704 includes software modules that can be used to manage (e.g., generate and authenticate) cryptographic keys. More specifically, as previously described, the computing platform 700 can be used as Alice 108, Bob 112, or the verifying party 116 of FIG. 1. The memory 704 includes an initial key generator 730 that can cooperate with an external node 724 to generate a mutually distilled key 732.

[0035] In a second example (hereafter referred to as “second example”), assume that the initial key generator 730 generated the mutually distilled key 732. In some examples, the mutually distilled key 732 is generated using QKD techniques through the use of the quantum channel 728. In other examples, the mutually distilled key 732 is generated using other techniques, such as through a classical channel. In any such example, both the computing platform 700 and the external node 724 have a copy of the mutually distilled key 732. To initially authenticate the mutually distilled key, the computing platform 700 and the external node 724 each perform a hash function on the mutually distilled key and encrypt the resulting hash using another one of the mutually established keys (previously authenticated). The computing platform 700 and the external node 724 then decrypt the encrypted hash and compare the decrypted version with the version sent to the other party to verify that the computing platform 700 and the external node 724 have the same mutually distilled key 732. The mutually distilled key 732 can be stored in a key storage 736. Key storage 736 may be implemented as a data structure, such as a table or database. Key storage 736 also includes keys, such as overhead keys 740 and traffic keys 744. Overhead keys 740 can be used to encrypt and decrypt data used for network overhead tasks, such as key verification. Conversely, traffic keys 744 can be used to encrypt and decrypt general purpose data.

[0036] In a second example, periodically and / or asynchronously, the key updater 748 determines that a new key (a new traffic key or a new overhead key) is needed for communicating with the external node 724. Thus, in this situation, the key updater 748 obtains a mutually distilled key 732 that can be used for communications between the computing platform 700 (e.g., a first party) and the external node 724 (e.g., a second party).

[0037] In response to obtaining the mutually distilled key 732, the key updater 748 determines a set of verification parties operating on the network 716 that are required to authenticate the mutually distilled key 732. Each verification party may be configured in a manner similar to the computing platform 700 such that each verification party in the set of verification parties may be implemented as an instance of the verification party 116 of Figure 1. In addition, the key updater 748 employs a KET module 752 that iteratively performs a KET to determine a nonce sum for each verification party in the set of verification parties until it is determined that a key equality test has been performed for each of the verification parties or at least one node on the network has been compromised.

[0038] Each execution of the KET is similar to the method described with respect to FIG. 3. More specifically, in the second example, the key updater 748 (executing the KET module 752) performs operations similar to Alice 304 or Bob 308 of FIG. 3 and Alice 504 and Bob 508 of FIG. 4. More specifically, during each execution of the KET in the second example, the KET module 752 of the key updater 748 selects one of the set of validation parties to provide the selected validation party. The KET module 752 hashes the mutually distilled key to provide a hash of the mutually distilled key and encrypts the hash of the mutually distilled key 732 with a first key of the set of keys retrieved from the key storage 736 for communication between the computing platform 700 operating on the network 716 and the selected validation party to provide an encrypted hash of the mutually distilled key 732. The key updater 748 transmits the encrypted hash of the mutually distilled key 732 to the selected validation party. The selected validating party decrypts the encrypted hash of the mutually distilled key 732 and compares the (decrypted) hash of the mutually distilled key 732 with the (decrypted) hash of the mutually distilled key 732 received from the external node 724. If the selected validating party determines that the two (decrypted) hashes of the mutually distilled keys are equal, the validating party generates a nonce value and provides the encrypted first nonce value to a key updater 748 of the computing platform 700.

[0039] The key updater 748 receives an encrypted first nonce value from the selected validation party. The encrypted first nonce value is decryptable only with a second key of a set of keys for communication between the first party and the selected validation party, obtained from the overhead key 740 of the key storage 736. The key updater 748 also receives an encrypted hash of the second nonce value from the external node 724. The encrypted hash of the second nonce value is decryptable only with a first key of a set for communication between the computing platform 700 and the external node 724. In response, the key updater 748 obtains a first key of a set for communication between the computing platform 700 and the external node 724 from the overhead key 740 of the key storage 736 of the key updater 748. The key updater 748 also decrypts the encrypted hash of the encrypted first nonce value and the second nonce value to reveal the hash of the first nonce value and the second nonce value. Additionally, the KET module 752 of the key updater 748 hashes the first nonce value with a hash function to provide a hash of the first nonce value.

[0040] The key updater 748 retrieves a second key of the key set for communications between the computing platform 700 and the external node 724 from the overhead keys 740 in the key storage 736. In response, the KET module 752 encrypts a hash of the first nonce value to provide an encrypted first nonce value that is decryptable only with the second key of the key set for communications between the computing platform 700 and the external node 724. The key updater 748 transmits the encrypted hash of the first nonce value to the external node 724.

[0041] The KET module 752 compares the hash of the first nonce value to the hash of the second nonce value. If the hash of the first nonce value equals the hash of the second nonce value, the KET module 752 of the key updater 748 adds the first nonce value to the nonce sum. If the hash of the first nonce value does not equal the hash of the second nonce value, the KET module 752 determines that at least one node on the network 716 has been compromised. In such a situation, the key updater 748 can provide a notification to another node on the network 716, which can include the external node 724 and / or one or more validating parties.

[0042] If each iteration of the KET is executed successfully, the nonce value from each of the set of validating parties is added to the nonce sum. In response, the key updater 748 generates a final key for communications between the computing platform 700 and the external node 724 based on the nonce sum and the mutually distilled key 732. More specifically, in some examples, the key updater 748 performs an XOR operation to combine the nonce sum and the mutually distilled key 732 and provides the result of this combination of the nonce sum and the mutually distilled key 732 to the KDF 756 (key derivation function) to generate the final key.

[0043] In some examples, the KDF 756 includes a conventional symmetric key generator 764 that generates a conventional encryption key as the final key. Additionally or alternatively, the KDF 756 includes an OTP key generator 766 that generates an OPT encryption key as the final key. In still other examples, the KDF 756 can be used to generate and / or alternatively generate other types of encryption keys (including, but not limited to, asymmetric encryption keys). The final key is stored in the key storage 736 as one of the overhead keys 740 or as one of the traffic keys 744.

[0044] The computing platform 700 also includes a key authenticator 770 (e.g., an instance of the key authenticator 142 of FIG. 1) stored in the memory 704. The key authenticator 770 is usable to enable the computing platform 700 to act as a verifying party (e.g., the verifying party 116 of FIG. 1) during an iteration of the KET for a mutually distilled key generated for another party, i.e., the second mutually distilled key. More specifically, in a third example (hereinafter, "third example"), the computing platform 700 acts as a verifying party to authenticate a second mutually distilled key generated for communication between another party, i.e., the first party and the second party. In such a situation, the second mutually distilled key may be generated using QKD techniques over a quantum channel between the first party and the second party. For security purposes, the second mutually distilled key is not transmitted to the computing platform 700.

[0045] In the third example, the key authenticator 770 performs operations similar to Charlie 312 of FIG. 3. More specifically, in the third example, the key authenticator 770 receives a first encrypted hash of a second mutually distilled key from the first party via the network 716. The first encrypted hash of the second mutually distilled key is decryptable only with a first key of a set of keys for communications between the first party and the computing platform 700. The key authenticator 770 receives a second encrypted hash of the second mutually distilled key from the second party, the second encrypted hash of the second mutually distilled key being decryptable only with a first key of a set of keys for communications between the verifying party and the second party. In response to receiving the first encrypted hash of the second mutually distilled key, the key authenticator 770 retrieves from the key storage 736 (e.g., from the overhead keys 740) a first key of a set of keys for communications between the first party and the computing platform 700. Accordingly, the key authenticator 770 decrypts the first encrypted hash of the second mutually distilled key to reveal the first hash of the second mutually distilled key. Similarly, in response to receiving the second encrypted hash of the second mutually distilled key, the key authenticator 770 obtains from the key storage 736 (e.g., from the overhead keys 740) a first key of a key set for communications between the second party and the computing platform 700. Accordingly, the key authenticator 770 decrypts the second encrypted hash of the mutually distilled key to reveal the second hash of the second mutually distilled key.

[0046] The key authenticator 770 compares the first hash of the second mutually distilled key to the second hash of the second mutually distilled key. If the first hash of the second mutually distilled key is equal to the second hash of the second mutually distilled key, the key authenticator 770 generates a nonce value. Conversely, if the first hash of the second mutually distilled key is not equal to the second hash of the second mutually distilled key, the key authenticator 770 generates and sends a notification to other nodes on the network 716 that at least one node on the network 716 has been compromised. These other nodes may include the first party, the second party, and / or another entity.

[0047] Continuing with the third example, assuming that the first hash of the second mutually distilled key is equal to the second hash of the second mutually distilled key, the key authenticator 770 obtains a second set of keys for communications between the computing platform 700 and the first party from the overhead keys 740 of the key storage 736. Similarly, the key authenticator 770 obtains a second set of keys for communications between the computing platform 700 and the second party from the overhead keys 740 of the key storage 736. The key authenticator 770 encrypts the nonce values ​​with the obtained keys to provide a first encrypted nonce value that is decryptable only with the second key of the key set for communications between the verification party and the first party and a second encrypted nonce value that is decryptable only with the second key of the key set for communications between the verification party and the second party. The key authenticator 770 transmits the first encrypted nonce value to the first party and transmits the second encrypted nonce value to the second party. At this point in the third example, the first and second parties can continue the key authentication process without further communication with computing platform 700.

[0048] As mentioned above, the final key generated in the key authentication process is stored in the overhead keys 740 or traffic keys 744. Thus, the final key is then available for use by the data encryptor 774 to encrypt or decrypt traffic or overhead data, and only the external node 724 possesses a copy of the final key necessary to ensure secure communications. Furthermore, by using the key management process described herein, the key burn rate can be reduced to approximately 10% of the overhead required to generate the keys. That is, by using the key management system described herein, the need to newly generate mutually distilled keys is reduced compared to conventional key management systems.

[0049] In view of the above structural and functional features, the exemplary method will be better understood by referring to Figures 6-8. For ease of explanation, the exemplary method of Figures 6-8 is shown and described as executing sequentially, however, it should be understood and appreciated that the present example is not limited by the order shown, since in other examples, some operations may be performed multiple times and / or simultaneously in a different order than the order shown and described herein. Moreover, not all described operations need to be performed to implement the method. The exemplary method of Figures 6-8 may be implemented as instructions stored on a non-transitory machine-readable medium. The instructions may be accessed by a processing resource (e.g., one or more processor cores) and executed to perform the methods disclosed herein.

[0050] 6 shows a flowchart of an example method 800 for generating a final key for communication between a first party (e.g., “Alice”) and a second party (e.g., “Bob”). In such a situation, both the first party and the second party represent nodes (e.g., computing devices) on a network, such as instances of computing platform 700 communicating on network 716 of FIG. 5. At 805, the first party and the second party generate a mutually distilled key for communication between the first party and the second party. At 810, the first party and the second party determine a set of verification parties operating on the network that are required to authenticate the mutually distilled key, where each verification party of the set of verification parties operates on the network.

[0051] At 815, the first party and the second party iteratively perform key equality tests for each of the set of verifying parties to determine a nonce sum until it is determined that a key equality test has been performed for each verifying party in the set of verifying parties or until it is determined that at least one node on the network has been compromised.

[0052] At 820, the first party and the second party make a determination as to whether the mutually distilled key is authenticated from the iterative execution of the KET. If the determination at 820 is negative (e.g., no), the method 800 proceeds to 825. If the determination at 820 is positive (e.g., yes), the method 800 proceeds to 830. At 825, the first party and / or the second party generate a notification that at least one node on the network may have been compromised. At 830, the first party and the second party generate a final key based on the nonce sum and the mutually distilled key.

[0053] Figure 7 shows a flowchart of an example sub-method 900 that represents a single iteration of a KET, such as operation 810 of Figure 6. More specifically, the sub-method 900 is performed between a first party, a second party, and one of the set of validation parties described with respect to Figure 6.

[0054] At 905, the first and / or second party key updater selects a verification party from the set of verification parties to provide the selected verification party. At 910, the first and second party key updaters hash the mutually distilled key using a hash function.

[0055] At 913, the first party and the second party encrypt the hash of the mutually distilled key with different keys to provide (two different) encrypted hashes of the mutually distilled key. More specifically, at 913, the first party key updater encrypts the hashed mutually distilled key with a first key of a set of keys for communication between the first party and the selected verification party to provide a first encrypted hash of the mutually distilled key. Similarly, the second party key updater encrypts the hash of the mutually distilled key with a first key of a set of keys for communication between the second party and the selected party to provide a second encrypted hash of the mutually distilled key. At 915, the first party key updater sends the first encrypted hash of the mutually distilled key to the selected verification party, and the second party key updater sends the second encrypted hash of the mutually distilled key to the selected verification party.

[0056] At 920, the verifying party authenticates the first and second encrypted hashes of the mutual distilled keys. Assuming the authentication is successful, at 925, the first party key updater receives a first encrypted nonce value from the selected verifying party. The first encrypted nonce value received at the key updater of the first party device is decryptable only with a second key of the key set for communication between the first party and the selected verifying party. Also at 925, the second party key updater receives a second encrypted nonce value that is decryptable only with a second key of the key set for communication between the selected party and the second party. Also at 925, the first party and second party key updaters decrypt the first and second encrypted nonce values ​​to reveal the first and second nonce values ​​(which are equal if no node on the network has been compromised).

[0057] At 930, the first party key updater hashes the first nonce value and the second party key updater hashes the second nonce value. Also at 930, the first party key updater encrypts the hash of the first nonce value with a first key of a key set for communications between the first party and the second party to provide a first encrypted hash of the nonce value. Also at 930, the second party key updater encrypts the hash of the second nonce value with a second key of a key set for communications between the first party and the second party to provide a second encrypted hash of the nonce value.

[0058] At 935, the first party and the second party exchange and decrypt the first encrypted hash and the second encrypted hash of the nonce value. More specifically, the first party transmits the first encrypted hash of the nonce value to the second party, and the second party transmits the second encrypted hash of the nonce value to the first party. Also at 935, the first party receives the second encrypted hash of the nonce value and decrypts the hash of the nonce value to reveal the hash of the second nonce value. Similarly, at 935, the second party receives the first encrypted hash of the nonce value and decrypts the hash of the nonce value to reveal the hash of the first nonce value.

[0059] At this point, both the first and second party key updaters possess the hash of the first nonce value and the hash of the second nonce value. Thus, at 940, the first and second party key updaters make a determination as to whether the hash of the first nonce value and the hash of the second nonce value are equal. If the key updaters at either (or both) of the first and second parties determine that the hash of the first nonce value is not equal to the hash of the second nonce value, sub-method 900 proceeds to 950 and, since the determination at 940 is negative (e.g., no), sub-method 900 proceeds to 945. If the key updaters at both the first and second parties determine that the hash of the first nonce value is equal to the hash of the second nonce value, then sub-method 900 proceeds to 950.

[0060] At 945, the first and / or second party key updaters generate a notification that at least one node on the network may have been compromised, which may be sent to other nodes on the network, and sub-method 900 ends. At 950, the first and second party key updaters add the first nonce value or the second nonce value (since they are equal) to the nonce sum, and sub-method 900 ends. Performance of the operation at 950 indicates successful completion of one iteration of the KET.

[0061] Figure 8 shows a flowchart of an example sub-method 1000 that can be employed to perform authentication of the mutually distilled key at 920 of Figure 7. The operations of sub-method 1000 are performed by a key authenticator at one verifying party (e.g., a computing device) selected during an iteration of the KET, such as an instance of verifying party 116 of Figure 1.

[0062] At 1005, the verifying party receives and decrypts the first and second encrypted hashes of the mutually distilled key from both the first party and the second party. More specifically, at 1005, the verifying party's key authenticator receives and decrypts the first encrypted hash of the mutually distilled key from the first party to reveal the first hash of the mutually distilled key. Additionally, at 1005, the verifying party's key authenticator receives and decrypts the second encrypted hash of the mutually distilled key from the second party to reveal the second hash of the mutually distilled key.

[0063] At 1005, the validating party's key authenticator compares the first hash of the mutually distilled key to the second hash of the mutually distilled key to make a determination. If the first hash of the mutually distilled key does not equal the second hash of the mutually distilled key, the determination at 1010 is negative (e.g., no) and submethod 1000 proceeds to 1020. If the first hash of the mutually distilled key equals the second hash of the mutually distilled key, the determination at 1010 is positive (e.g., yes) and submethod 1000 proceeds to 1025. At 1020, the validating party's key authenticator generates a notification that at least one node on the network may have been compromised and sends the notification to another node on the network, and submethod 1000 ends.

[0064] At 1025, the key authenticator generates a nonce value. At 1030, the key authenticator encrypts the nonce value with a different key. More specifically, at 1030, the key authenticator of the verification party encrypts the nonce value with a key of a key set for communication between the first party and the verification party to provide a first encrypted nonce value. Additionally, at 1030, the key authenticator of the verification party encrypts the nonce value with a key of a key set for communication between the second party and the verification party to provide a second encrypted nonce value. At 1035, the key authenticator transmits the first encrypted nonce value to the first party and transmits the second encrypted nonce value to the first party. Performance of the operation at 1035 indicates that authentication of the mutually distilled key was successful from the perspective of the verification party.

[0065] The above description is an example. Of course, it is not possible to describe every conceivable combination of components or methods, but one of ordinary skill in the art will recognize that many more combinations and permutations are possible. Accordingly, this disclosure is intended to embrace all such changes, modifications, and variations that are within the scope of this application, including the appended claims. As used herein, the term "comprises" means including, without limitation. The term "based on" means based at least in part on. Furthermore, when a disclosure or claim recites "a," "first," or "another" element, or the equivalent thereof, it should be construed as including one or more such elements, and does not require or exclude two or more such elements.

Claims

1. 1. A non-transitory machine-readable medium having machine-executable instructions comprising a key updater for a first party operating on a network, the key updater comprising: generating a mutually distilled key for communications between the first and second parties; determining a set of verification parties operating on the network required to authenticate the mutually distilled key, where each verification party of the set of verification parties operates on the network; performing a key equality test iteratively for each verification party in the set of verification parties to determine a nonce sum until it is determined that a key equality test has been performed for each verification party in the set of verification parties or until it is determined that at least one node on the network has been compromised; a non-transitory machine-readable medium that generates a final key for communications between the first party and the second party based on the nonce sum and the mutually distilled key if the key equality test is successfully performed for each verification party in the set of verification parties.

2. In each iterative performance of the key equality test, the key updater selecting a validation party from the set of validation parties and providing the selected validation party; receiving a first encrypted nonce value from the selected verification party, where the first encrypted nonce value is decryptable only using a first key of a key set for communications between the first party and the selected verification party; receiving an encrypted hash of a nonce value from the second party, where the encrypted hash of the nonce value is decryptable only using a first key of a key set for communications between the first party and the second party; decrypting the first nonce value and the encrypted hash of said nonce value to reveal the first nonce value and the hash of the second nonce value; hashing the first nonce value to provide a hash of the first nonce value; 2. The non-transitory machine-readable medium of claim 1, further comprising: adding the first nonce value to the nonce sum if a hash of the first nonce value equals a hash of the second nonce value; or determining that at least one node on the network has been compromised if a hash of the first nonce value does not equal a hash of the second nonce value.

3. The key updater for the first party comprises: hashing the mutually distilled key to provide a hash of the mutually distilled key; wherein, in each iteration of the key equality test, the key updater for the first party: encrypting the hash of the mutually distilled key with a second key of a set of keys for communications between the first party and the selected verification party operating on the network to provide an encrypted hash of the mutually distilled key; 3. The non-transitory machine-readable medium of claim 2, further comprising: transmitting an encrypted hash of the mutually distilled key to the selected validating party.

4. In each iteration of the key equality test, the key updater for the first party: encrypting a hash of the first nonce value to provide an encrypted first nonce value that is decryptable only with a second key of a key set for communications between the first party and the second party; 4. The non-transitory machine-readable medium of claim 3, further comprising: transmitting to the second party a hash of an encrypted first nonce value that is decryptable only with the key set for communication between the first party and the second party.

5. 5. The non-transitory machine-readable medium of claim 4, wherein the final key is generated without transmitting an encrypted or unencrypted version of a key between two parties in the network.

6. 2. The non-transitory machine-readable medium of claim 1, wherein the mutually distilled key is generated using quantum key distribution (QKD) techniques over a quantum channel between the first party and the second party.

7. The machine readable instructions include a data encryptor, the data encryptor comprising: encrypting data using the final key to provide encrypted data; 7. The non-transitory machine-readable medium of claim 6, further comprising: transmitting the encrypted data to the second party via a classical channel between the first party and the second party.

8. The non-transitory machine-readable medium of claim 1 , wherein there are at least three different verifying parties in the set of verifying parties.

9. 10. The non-transitory machine-readable medium of claim 1, wherein the first party, the second party, and each of the verifying parties of the set of verifying parties operate on a computing device.

10. 1. A system for updating a key, comprising: a non-transitory memory having machine-readable instructions; a processing unit for accessing the machine-readable instructions, the machine-readable instructions comprising: A key authenticator for a verifying party to verify a mutually distilled key generated for communication between a first party and a second party, the key authenticator comprising: receiving from the first party a first encrypted hash of the mutually distilled key that is decryptable only using a first key of a key set for communications between the first party and the verifying party; receiving from the second party a second encrypted hash of the mutually distilled key that is decryptable only using a first key of a key set for communications between the verifying party and the second party; decrypting the first encrypted hash of the mutually distilled key to reveal the first hash of the mutually distilled key; decrypting the second encrypted hash of the mutually distilled key to reveal a second hash of the mutually distilled key; if the first hash of the mutually distilled key is equal to the second hash of the mutually distilled key, encrypting a nonce value with a different key to provide a first encrypted nonce value that is decryptable only with a second key of the key set for communications between the verifying party and the first party and a second encrypted nonce value that is decryptable only with a second key of the key set for communications between the verifying party and the second party; If the first hash of the mutually distilled key is not equal to the second hash of the mutually distilled key, the system sends a notification to the first party and the second party that at least one node on a network has been compromised.

11. 11. The system of claim 10, wherein the key authenticator for the verifying party transmits the first encrypted nonce value to the first party and transmits the second encrypted nonce value to the second party.

12. The system of claim 10 , wherein the mutually distilled key is generated using quantum key distribution (QKD) techniques over a quantum channel between the first party and the second party.

13. 11. The system of claim 10, wherein the mutually distilled key is verified without transmitting an encrypted version of the key or an unencrypted version of the key between two parties in the network.

14. 12. The system of claim 11, wherein the first key and the second key of the key set for communication between the verifying party and the first party are symmetric keys.

15. 1. A method for verifying a key, comprising: a first computing device for a first party and a second computing device for a second party generating a mutually distilled key for communications between the first and second parties; determining a plurality of verification parties operating on a network required for the first computing device and the second computing device to authenticate the mutually distilled key, where each verification party of the plurality of verification parties operates on the network; performing the key equality test iteratively for each of the plurality of validation parties to determine a nonce sum until the first computing device and the second computing device determine that a key equality test has been performed for each of the plurality of validation parties or until it is determined that at least one node on the network has been compromised, wherein in each iteration of the key equality test, the first computing device and the second computing device: selecting a verification party from the plurality of verification parties and providing the selected verification party; receiving a first encrypted nonce value from the selected verification party, wherein the first encrypted nonce value received at the first computing device is decryptable only using a first key of a set of keys for communications between the first party and the selected verification party, and the first encrypted nonce value received at the second computing device is decryptable only using a first key of a set of keys for communications between the second party and the verification party; receiving an encrypted hash of a nonce value, where the encrypted hash of the nonce value received at the first computing device is decryptable only using a first key of a set of keys for communications between the first party and the second party and the encrypted hash of the nonce value received at the second computing device is decryptable only using a second key of a set of keys for communications between the first party and the second party; decrypting the encrypted nonce value and the encrypted hash of the nonce value to reveal a first nonce value and a hash of a second nonce value; hashing the first nonce value to provide a hash of the first nonce value; and iteratively performing the key equality test to determine a nonce sum, adding the first nonce value to the nonce sum if a hash of the first nonce value equals a hash of the second nonce value, or determining that at least one node on the network has been compromised if the hash of the first nonce value does not equal the hash of the second nonce value; and the first computing device and the second computing device generating a final key for communications between the first party and the second party based on the nonce sum if the key equality tests for each of the plurality of verification parties are successfully performed.

16. 16. The method of claim 15, wherein the final key is generated using a combination of the nonce sum and the mutually distilled key.

17. During each iteration of the key equality test, the first computing device and the second computing device further hashing the mutually distilled key to provide a hash of the mutually distilled key; In each iteration of testing the key authenticator, the first computing device and the second computing device further encrypting the hash of the mutually distilled key to provide an encrypted hash of the mutually distilled key; 16. The method of claim 15, further comprising transmitting an encrypted hash of the mutually distilled key to the selected validating party.

18. In each iteration of the key equality test, the first computing device further encrypting a hash of the first nonce value to provide an encrypted first nonce value that is decryptable only using the second key of the key set for communication between the first party and the second party; sending a hash of the encrypted first nonce value to the second party, the hash being decryptable only using the second key of the key set for communications between the first party and the second party; In each iteration of the key equality test, the second computing device further encrypting a hash of the first nonce value to provide an encrypted first nonce value that is decryptable only using the first key of the key set for communication between the first party and the second party; 20. The method of claim 17, further comprising sending to the first party a hash of the encrypted first nonce value that is decryptable only using the first key of the key set for communication between the first and second parties.

19. 16. The method of claim 15, wherein the final key is generated without transmitting an encrypted or unencrypted version of the key between two parties in the network.

20. 16. The method of claim 15, wherein the mutually distilled key is generated using quantum key distribution (QKD) techniques over a quantum channel between the first party and the second party.

Images