Method and system for storing entropy

Abstract

A method for storing entropy, the method comprising: in a system comprising a plurality of nodes, at a hub node of the plurality of nodes, for each of one or more other nodes, obtaining two bit strings of random bits of equal length from a random number generator (RNG); at the hub node, pairing each two bit strings together so that each bit in one bit string has a corresponding bit in the other bit string, sending a pair of bit strings to each of the one or more other nodes, and storing a copy of each pair of bit strings together with the identity of the other node to which they were sent; at each of the one or more other nodes, producing a pair of bit strings by obtaining two bit strings of random bits of equal length from an RNG and pairing the two bit strings together so that each bit in one bit string has a corresponding bit in the other bit string; at each of the one or more other nodes, comparing each bit in a first string of the pair of bit strings received from the hub node to the corresponding bit in a first string of the pair of bit strings produced at the node; and either: in a first alternative, if these two bits have the same value, re-setting the value of the corresponding bit in the second string of the pair of bit strings produced at the node to be equal to the value of the corresponding bit in the second string of the pair of bit strings received from the hub node; and if these two bits have different values, leaving the value of the corresponding bit in the second string of the pair of bit strings produced at the node unchanged; or in a second alternative, if these two bits have the different values, re-setting the value of the corresponding bit in the second string of the pair of bit strings produced at the node to be equal to the value of the corresponding bit in the second string of the pair of bit strings received from the hub node; and if these two bits the same value, leaving the value of the corresponding bit in the second string of the pair of bit strings produced at the node unchanged; and at each of the one or more other nodes, when all of the bits in the first strings of the pairs of bit strings have been compared, deleting the pair of bit strings received from the hub node, and storing the pair of bit strings produced at the node and including the re-set values.

Description

059645.00198 Method and System for Storing Entropy Field of the Invention

[0001] The present application relates to methods and systems for storing entropy, and in particular for storing entropy and subsequently using the stored entropy to generate shared randomness at nodes at separated locations. Background to the Invention

[0002] Providing shared randomness, and particularly providing shared randomness at separated locations is a basic requirement to support encrypted communications. The shared randomness can, for example, be used to generate encryption keys, or one-time pads, or similar encrypted communication tools.

[0003] Following the arrival of large-scale quantum computers, classical encryption information exchange methods – such as factorisation or discrete-log based methods – used for encryption key agreement or the generation of one-time pads will be vulnerable and unable to provide security. This vulnerability may be avoided by basing encryption key or one-time pad generation for use for secure encrypted communications between two or more different locations on shared randomness shared between these different locations.

[0004] One method of sharing randomness between different locations is by protocols using a quantum (i.e., photonic) channel to generate the shared randomness shared by the different locations. Such protocols are commonly referred to as quantum key distribution (QKD). QKD is a secure communication method which implements a cryptographic QKD protocol involving components of quantum mechanics for distributing cryptographic keys or other security material between two communication parties in a quantum computing secure manner. Typically, such QKD approaches have used photonic qubit (quantum bit) transmission, together with the application of complementary measurement bases to exploit the uncertainty principle to allow the generation of shared randomness. However, such approaches are generally highly expensive, and in practice there have proved to be formidable technical challenges to large scale implementation.

[0005] The inventors have devised the claimed invention in light of the above problems.

[0006] The embodiments described below are not limited to implementations which solve any or all of the problems of the known approaches described above. Summary of Invention

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter; variants and alternative features059645.00198 which facilitate the working of the invention and / or serve to achieve a substantially similar technical effect should be considered as falling into the scope of the invention.

[0008] In a general sense, the present disclosure provides methods and systems for generating shared randomness, on demand, at separated locations without requiring the use of quantum communication channels, such as photonic communication channels..

[0009] The invention is defined as set out in the appended set of claims.

[0010] In a first aspect of the present invention, there is provided a method for storing entropy, the method comprising: in a system comprising a plurality of nodes, at a hub node of the plurality of nodes, for each of one or more other nodes, obtaining two bit strings of random bits of equal length from a random number generator (RNG); at the hub node, pairing each two bit strings together so that each bit in one bit string has a corresponding bit in the other bit string, sending a pair of bit strings to each of the one or more other nodes, and storing a copy of each pair of bit strings together with the identity of the other node to which they were sent; at each of the one or more other nodes, producing a pair of bit strings by obtaining two bit strings of random bits of equal length from an RNG and pairing the two bit strings together so that each bit in one bit string has a corresponding bit in the other bit string; at each of the one or more other nodes, comparing each bit in a first string of the pair of bit strings received from the hub node to the corresponding bit in a first string of the pair of bit strings produced at the node; and either: in a first alternative, if these two bits have the same value, re-setting the value of the corresponding bit in the second string of the pair of bit strings produced at the node to be equal to the value of the corresponding bit in the second string of the pair of bit strings received from the hub node; and if these two bits have different values, leaving the value of the corresponding bit in the second string of the pair of bit strings produced at the node unchanged; or in a second alternative, if these two bits have the different values, re-setting the value of the corresponding bit in the second string of the pair of bit strings produced at the node to be equal to the value of the corresponding bit in the second string of the pair of bit strings received from the hub node; and if these two bits the same value, leaving the value of the corresponding bit in the second string of the pair of bit strings produced at the node unchanged; and at each of the one or more other nodes, when all of the bits in the first strings of the pairs of bit strings have been compared, deleting the pair of bit strings received from the hub node, and storing the pair of bit strings produced at the node and including the re-set values.

[0011] In some embodiments, the method may further comprise at each of the one or more other nodes, after deleting the pair of bit strings received from the hub node, confirming this to the hub node; and at the hub node, storing the confirmation of deletion in association with the stored copy of the corresponding pair of bit strings.

[0012] In some embodiments, the method may further comprise wherein each of the one or more other nodes confirms the deletion to the hub node by sending a certificate of deletion.059645.00198

[0013] In some embodiments, the method may further comprise a plurality of RNGs.

[0014] In some embodiments, the method may further comprise wherein the hub node and each of the one or more other nodes randomly selects a RNG from which each respective two bit strings are obtained.

[0015] In some embodiments, the method may further comprise wherein the plurality of RNGs are grouped together in a RNG bank.

[0016] In some embodiments, the method may further comprise wherein each node of the plurality of nodes has an associated RNG.

[0017] In some embodiments, the method may further comprise wherein the one or more other nodes are a plurality of other nodes.

[0018] In some embodiments, the method may further comprise wherein each node of the plurality of nodes has an associated hardware security module (HSM) used for storage by that node.

[0019] In some embodiments, the method may further comprise wherein the nodes of the plurality of nodes are able to communicate using secure tunnels.

[0020] In some embodiments, the method may further comprise wherein the secure tunnels are Advanced Encryption Standard-256 (AES-256) tunnels.

[0021] In some embodiments, the method may further comprise wherein the method is repeated multiple times.

[0022] In some embodiments, the method may further comprise wherein the hub node is a different one of plurality of nodes for at least some of the times the method is repeated.

[0023] In some embodiments, the method may further comprise wherein the system defines a secure communications perimeter, and all of the plurality of nodes are inside this perimeter.

[0024] In some embodiments, the method may further comprise wherein one or more of the RNGs are quantum random number generators (QRNGs), and preferably wherein all of the RNGs are QRNGs.

[0025] In some embodiments, the method may further comprise a first node, which is one of the one or more other nodes, and a second node, which is one of the one or more other nodes, communicating and agreeing they wish to generate shared randomness; at least one of the first and second nodes sending a shared-randomness request to the hub node identifying the first and second nodes, and identifying which of the first and second nodes is to be the primary randomness sharer and which is to be the secondary randomness sharer; at the hub node, checking if there is sufficient059645.00198 entropy previously delivered to the first and second nodes, which has not been used, to fulfil the shared-randomness request.

[0026] In some embodiments, the method may further comprise wherein the first and second nodes agree a first number of bits of shared randomness they wish to generate, and the shared- randomness request identifies the first number of bits.

[0027] In some embodiments, the method may further comprise wherein a predetermined number of bits are to be generated in response to a shared-randomness request.

[0028] In some embodiments, the method may further comprise wherein only one of the first and second nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the primary randomness sharer and which is to be the secondary randomness sharer, wherein either: the one of the first and second nodes sending the shared-randomness request is identified as the primary randomness sharer and the other one of the first and second nodes is identified as the secondary randomness sharer; or the one of the first and second nodes sending the shared-randomness request is identified as the secondary randomness sharer and the other one of the first and second nodes is identified as the primary randomness sharer.

[0029] In some embodiments, the method may further comprise, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the first node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the second node; at the first node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the second node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the first node, and sending the first bit string of the second block to the second node; at the first node, sending the first bit string of the third block to the hub node; at the second node, sending the first bit string of the fourth block to the hub node; at each of the hub node and the first node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of the third block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the first node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at each of the hub node and the second node, comparing a value of each bit in the first bit string of the second block to the value of the corresponding bit in the first bit string of the fourth block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the second block, and placing the values at these positions in the second bit string into a third vector; at059645.00198 the second node, referring to the recorded position numbers in the second bit string of the fourth block, and placing the values at these positions in the second bit string into a fourth vector; at the hub node, comparing the length of the first vector and the third vector, and, if the first and third vectors have different lengths, truncating by removing a number of entries from the end of the longer one of the first and third vectors so that the first and third vectors have the same length, and either; if the first vector has a greater length, sending a truncation message to the first node to remove the number of entries from the end of the second vector; or if the third vector has a greater length, sending a truncation message to the second node to remove the number of entries from the end of the fourth vector; at the first node, if a truncation message is received, truncating by removing the number of entries from the end of the second vector; at the second node, if a truncation message is received, truncating by removing the number of entries from the end of the fourth vector; at the hub node, deriving a fifth vector which is the result of an XOR of the first and third vectors after any truncation, and sending the fifth vector to whichever one of the first and second nodes is the node identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a sixth vector which is the result of an XOR of the fifth vector with either the second vector, if the first node is the secondary randomness sharer, or the fourth vector, if the second node is the secondary randomness sharer, and storing the sixth vector; and at the node identified as the primary randomness sharer, storing either the second vector, if the first node is the primary randomness sharer, or the fourth vector, if the second node is the primary randomness sharer; whereby the first and second nodes have shared randomness represented by the sixth vector and the one of the second or fourth vector which was stored.

[0030] In some embodiments, the method may further comprise wherein each of the first to fourth blocks comprises (2*n)+β(n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

[0031] In some embodiments, the method may further comprise where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), where ^^ is the number of bits of shared randomness to be generated, and the ceiling function up to the nearest integer.

[0032] In some embodiments, the method may further comprise, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the first node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the second node; at the first node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the second node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the first node, and sending the first bit string of the second block to the second node; at the hub node, deriving a first vector which is the result of an XOR of the second bit string of the first block and the second bit string of the second059645.00198 block, and sending the first vector to whichever one of the first and second nodes is identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a second vector which is the result of an XOR of the first vector with either; the second bit string of the third block, if the first node is the secondary randomness sharer, or the second bit string of the fourth block, if the second node is the secondary randomness sharer; at the node identified as the primary randomness sharer, deriving a third vector which is either; the second bit string of the third block, if the first node is the primary randomness sharer, or the second bit string of the fourth block, if the second node is the primary randomness sharer; at the first node, deriving a fourth vector which is the result of an XOR of the first bit string of the first block with the first bit string of the third block; at the second node, deriving a fifth vector which is the result of an XOR of the first bit string of the second block with the first bit string of the fourth block; the first node and the second node communicate and identify the positions in the fourth vector and the fifth vector where the entries in both vectors are zero; at the node identified as the primary randomness sharer, referring to the positions in the third vector which correspond to the identified positions where the fourth and fifth vectors are both zero, and assigning the entries at these positions to a sixth vector; at the node identified as the secondary randomness sharer, referring to the positions in the second vector which correspond to the identified positions where the fourth and fifth vectors are both zero, and assigning the entries at these positions to a seventh vector; at the node identified as the primary randomness sharer, storing the sixth vector; and at the node identified as the secondary randomness sharer, storing the seventh vector; whereby the first and second nodes have shared randomness represented by the sixth vector and the seventh vector.

[0033] In some embodiments, the method may further comprise wherein each of the first to fourth blocks comprises (4*n)+β(2*n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

[0034] In some embodiments, the method may further comprise where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), and where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.

[0035] In some embodiments, the method may further comprise, if the check finds that there is sufficient entropy, generating shared randomness by: assigning one of the first node and the second node as the Side 1 participant node and the other as the Side 2 participant node; at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 1 participant node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 2 participant node; at the Side 1 participant node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the Side 2 participant node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the Side 1 participant node; at the Side 1059645.00198 participant node, sending the first bit string of the third block to the hub node; at each of the hub node and the Side 1 participant node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of the third block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the Side 1 participant node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at the hub node, comparing the length of the first vector and the second block, and, if the first vector and the second block have different lengths, truncating by removing a number of entries from the end of the longer one of the first vector and the second block so that the first vector and the second block have the same length, and, if the first vector was longer than the second block, sending a truncation message to the Side 1 participant node instructing it to remove the number of entries from the second vector, or, if the second block was longer than the first vector, sending a truncation message to the Side 2 participant node instructing it to remove the number of entries from the fourth block; at the Side 1 participant node, if the truncation message is received, removing the number of entries from the second vector; at the Side 2 participant node, if the truncation message is received, removing the number of entries from the fourth block; at the hub node, sending the first bit string of the second block to the Side 2 participant node; at the hub node, deriving a third vector which is the result of an XOR of the first vector with the second bit string of the second block; at the hub node, sending the third vector to the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, deriving a fourth vector which is the result of an XOR of the third vector with either; the second vector if the Side 1 participant node is identified as the secondary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the secondary randomness sharer; at the Side 2 participant node, comparing each entry in the first bit string of the second block with the corresponding entry in the first bit string of the fourth block, recording the position numbers for which these entries are the same, and sending the recorded position numbers to the Side 1 participant node; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, referring to the recorded position numbers in either; the second vector if the Side 1 participant node is identified as the primary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the primary randomness sharer, and assigning the entries at these positions to a fifth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, referring to the recorded position numbers in the fourth vector, and assigning the entries at these positions to a sixth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, storing the fifth vector; and at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, storing the sixth vector; whereby the first and second nodes have shared randomness represented by the fifth vector and the sixth vector.059645.00198

[0036] In some embodiments, the method may further comprise wherein the shared- randomness request identifies which of the first and second nodes is to be the Side 1 participant node and which is to be the Side 2 participant node.

[0037] In some embodiments, the method may further comprise, wherein only one of the first and second nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the Side 1 participant node and which is to be the Side 2 participant node, wherein either: the one of the first and second nodes sending the shared- randomness request is identified as the Side 1 participant node and the other one of the first and second nodes is identified as the Side 2 participant node; or the one of the first and second nodes sending the shared-randomness request is identified as the Side 2 participant node and the other one of the first and second nodes is identified as the Side 1 participant node.

[0038] In some embodiments, the method may further comprise wherein each of the first and third blocks comprises (4*n)+β(2*n)n pairs of bits and each of the second and fourth blocks comprises (2*n) + β(n) pairs of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

[0039] In some embodiments, the method may further comprise where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^) where the ceiling function rounds up to the nearest integer and x is the expected amount of shared randomness.

[0040] In some embodiments, the method may further comprise wherein the first node and the second node agree which of the methods is to be used, and the shared randomness request identifies which of these methods is to be used.

[0041] In some embodiments, the method may further comprise for a first node of the one or more other nodes, selecting a second node of the one or more other nodes; at the first node, selecting a block of unused corresponding bits of the stored pairs of bit strings produced at the node and including the re-set values, sending a copy of the selected block to the second node, and then deleting the selected block; at the second node, storing the received block; at the first node, sending a message to the hub node informing the hub node that the block has been sent from the first node to the second node; at the hub node, identifying the bits of the stored pairs of bit strings stored together with the identity of the first node which correspond to the bits of the block and storing the identified bits of the stored pairs of bit strings together with the identity of the second node.

[0042] In some embodiments, the method may further comprise wherein storing the identified bits of the stored pairs of bit strings together with the identity of the second node comprises storing the identified bits of the stored pairs of bit strings together with the identity of the second node, and deleting the copy of the identified bits of the stored pairs of bit strings stored together with the identity of the first node.059645.00198

[0043] In some embodiments, the method may further comprise wherein storing the identified bits of the stored pairs of bit strings together with the identity of the second node comprises replacing the identity of the first node stored together with the identified bits of the stored pairs of bit strings with the identity of the second node.

[0044] In some embodiments, the method may further comprise wherein the second node of the plurality of nodes is randomly selected.

[0045] In some embodiments, the method may further comprise wherein the first node confirms the deletion of the selected first block to the hub node by sending a certificate of deletion.

[0046] In some embodiments, the method may further comprise wherein the method is repeated multiple times.

[0047] In some embodiments, the method may further comprise wherein the first node and / or the second node is a different one of the one or more other nodes for at least some of the times the method is repeated.

[0048] In some embodiments, the method may further comprise a third node, which is one of the second nodes, and a fourth node, which is one of the second nodes, communicating and agreeing they wish to generate shared randomness; at least one of the third and fourth nodes sending a shared-randomness request to the hub node identifying the third and fourth nodes, and identifying which of the third and fourth nodes is to be the primary randomness sharer and which is to be the secondary randomness sharer; at the hub node, checking if there is sufficient entropy previously delivered to the third and fourth nodes, which has not been used, to fulfil the shared-randomness request.

[0049] In some embodiments, the method may further comprise wherein the third and fourth nodes agree a first number of bits of shared randomness they wish to generate, and the shared- randomness request identifies the first number of bits.

[0050] In some embodiments, the method may further comprise wherein a predetermined number of bits are to be generated in response to a shared-randomness request.

[0051] In some embodiments, the method may further comprise wherein only one of the third and fourth nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the primary randomness sharer and which is to be the secondary randomness sharer, wherein either: the one of the third and fourth nodes sending the shared-randomness request is identified as the primary randomness sharer and the other one of the third and fourth nodes is identified as the secondary randomness sharer; or the one of the third and fourth nodes sending the shared-randomness request is identified as the secondary randomness sharer and the other one of the third and fourth nodes is identified as the primary randomness sharer.059645.00198

[0052] In some embodiments, the method may further comprise, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the third node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the fourth node; at the third node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the fourth node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the third node, and sending the first bit string of the second block to the fourth node; at the third node, sending the first bit string of the third block to the hub node; at the fourth node, sending the first bit string of the fourth block to the hub node; at each of the hub node and the third node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of the third block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the third node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at each of the hub node and the fourth node, comparing a value of each bit in the first bit string of the second block to the value of the corresponding bit in the first bit string of the fourth block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the second block, and placing the values at these positions in the second bit string into a third vector; at the fourth node, referring to the recorded position numbers in the second bit string of the fourth block, and placing the values at these positions in the second bit string into a fourth vector; at the hub node, comparing the length of the first vector and the third vector, and, if the first and third vectors have different lengths, truncating by removing a number of entries from the end of the longer one of the first and third vectors so that the first and third vectors have the same length, and either; if the first vector has a greater length, sending a truncation message to the third node to remove the number of entries from the end of the second vector; or if the third vector has a greater length, sending a truncation message to the fourth node to remove the number of entries from the end of the fourth vector; at the third node, if a truncation message is received, truncating by removing the number of entries from the end of the second vector; at the fourth node, if a truncation message is received, truncating by removing the number of entries from the end of the fourth vector; at the hub node, deriving a fifth vector which is the result of an XOR of the first and third vectors after any truncation, and sending the fifth vector to whichever one of the third and fourth nodes is the node identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a sixth vector which is the result of an XOR of the fifth vector with either the second vector, if the third node is the secondary randomness sharer, or the fourth vector, if the fourth node is the secondary randomness sharer, and storing the sixth vector; and at the node identified as the primary randomness sharer, storing either the second vector, if the third node is the primary randomness sharer, or the fourth vector, if the fourth059645.00198 node is the primary randomness sharer; whereby the third and fourth nodes have shared randomness represented by the sixth vector and the second or fourth vector.

[0053] In some embodiments, the method may further comprise wherein each of the first to fourth blocks comprises (2*n)+β(n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

[0054] In some embodiments, the method may further comprise where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.

[0055] In some embodiments, the method may further comprise, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the third node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the fourth node; at the third node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the fourth node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the third node, and sending the first bit string of the second block to the fourth node; at the hub node, deriving a first vector which is the result of an XOR of the second bit string of the first block and the second bit string of the second block, and sending the first vector to whichever one of the third and fourth nodes is identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a second vector which is the result of an XOR of the first vector with either; the second bit string of the third block, if the third node is the secondary randomness sharer, or the second bit string of the fourth block, if the fourth node is the secondary randomness sharer; at the node identified as the primary randomness sharer, deriving a third vector which is either; the second bit string of the third block, if the third node is the primary randomness sharer, or the second bit string of the fourth block, if the fourth node is the primary randomness sharer; at the third node, deriving a fourth vector which is the result of an XOR of the first bit string of the first block with the first bit string of the third block; at the fourth node, deriving a fifth vector which is the result of an XOR of the first bit string of the second block with the first bit string of the fourth block; the third node and the fourth node communicate and identify the positions in the fourth vector and the fifth vector where the entries in both vectors are zero; at the node identified as the primary randomness sharer, referring to the positions in the third vector which correspond to the identified positions where the fourth and fifth vectors are both zero, and assigning the entries at these positions to a sixth vector; at the node identified as the secondary randomness sharer, referring to the positions in the second vector which correspond to the identified positions where the fourth and fifth vectors are both zero, and assigning the entries at these positions to a seventh vector; at the node identified as the primary randomness sharer, storing the sixth vector; and at the node identified as the secondary randomness sharer, storing the seventh vector; whereby059645.00198 the third and fourth nodes have shared randomness represented by the sixth vector and the seventh vector.

[0056] In some embodiments, the method may further comprise wherein each of the first to fourth blocks comprises (4*n)+β(2*n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

[0057] In some embodiments, the method may further comprise where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), and where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.

[0058] In some embodiments, the method may further comprise, if the check finds that there is sufficient entropy, generating shared randomness by: assigning one of the third node and the fourth node as the Side 1 participant node and the other as the Side 2 participant node; at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 1 participant node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 2 participant node; at the Side 1 participant node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the Side 2 participant node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the Side 1 participant node; at the Side 1 participant node, sending the first bit string of the third block to the hub node; at each of the hub node and the Side 1 participant node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of the third block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the Side 1 participant node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at the hub node, comparing the length of the first vector and the second block, and, if the first vector and the second block have different lengths, truncating by removing a number of entries from the end of the longer one of the first vector and the second block so that the first vector and the second block have the same length, and, if the first vector was longer than the second block, sending a truncation message to the Side 1 participant node instructing it to remove the number of entries from the second vector, or, if the second block was longer than the first vector, sending a truncation message to the Side 2 participant node instructing it to remove the number of entries from the fourth block; at the Side 1 participant node, if the truncation message is received, removing the number of entries from the second vector; at the Side 2 participant node, if the truncation message is received, removing the number of entries from the fourth block; at the hub node, sending the first bit string of the second block to the Side 2 participant node; at the hub node, deriving a third vector which is the result of an XOR of the first vector with the second bit string of the059645.00198 second block; at the hub node, sending the third vector to the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, deriving a fourth vector which is the result of an XOR of the third vector with either; the second vector if the Side 1 participant node is identified as the secondary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the secondary randomness sharer; at the Side 2 participant node, comparing each entry in the first bit string of the second block with the corresponding entry in the first bit string of the fourth block, recording the position numbers for which these entries are the same, and sending the recorded position numbers to the Side 1 participant node; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, referring to the recorded position numbers in either; the second vector if the Side 1 participant node is identified as the primary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the primary randomness sharer, and assigning the entries at these positions to a fifth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, referring to the recorded position numbers in the fourth vector, and assigning the entries at these positions to a sixth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, storing the fifth vector; and at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, storing the sixth vector; whereby the third and fourth nodes have shared randomness represented by the fifth vector and the sixth vector.

[0059] In some embodiments, the method may further comprise wherein the shared- randomness request identifies which of the third and fourth nodes is to be the Side 1 participant node and which is to be the Side 2 participant node.

[0060] In some embodiments, the method may further comprise wherein only one of the third and fourth nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the Side 1 participant node and which is to be the Side 2 participant node, wherein either: the one of the third and fourth nodes sending the shared- randomness request is identified as the Side 1 participant node and the other one of the third and fourth nodes is identified as the Side 2 participant node; or the one of the third and fourth nodes sending the shared-randomness request is identified as the Side 2 participant node and the other one of the third and fourth nodes is identified as the Side 1 participant node.

[0061] In some embodiments, the method may further comprise wherein each of the first and third blocks comprises (4*n)+β(2*n) pairs of bits and each of the second and fourth blocks comprises (2*n) + β(n) pairs of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.059645.00198

[0062] In some embodiments, the method may further comprise where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^) where the ceiling function rounds up to the nearest integer and x is the expected amount of shared randomness.

[0063] In some embodiments, the method may further comprise wherein the third node and the fourth node agree which of the methods is to be used, and the shared randomness request identifies which of these methods is to be used.

[0064] In some embodiments, the method may further comprise, when the first alternative was used: for a first node of the one or more other nodes, selecting a second node of the one or more other nodes; at the first node, selecting a block of unused corresponding bits of the stored pairs of bit strings produced at the node and including the re-set values, and sending a copy of the selected block to the second node; at the second node, temporarily storing the received block, obtaining two bit strings of random bits from a QRNG, each bit string being of equal length to the received block, and producing a pair of bit strings by pairing the two bit strings together so that each bit in one bit string has a corresponding bit in the other bit string; at the second node, comparing each bit in a first string of the block to the corresponding bit in a first string of the pair of bit strings produced at the second node; if these two bits have the same value, re-setting the value of the corresponding bit in the second string of the pair of bit strings produced at the node to be equal to the value of the corresponding bit in the second string of the block; or if these bits have different values, leaving the value of the corresponding bit in the second string of the pair of bit strings produced at the node unchanged; at the second node, when all of the bits in the first strings of the block and the pair of bit strings have been compared, deleting the block, and storing the pair of bit strings including the re-set values; at the first node, storing the bits of the block together with the identity of the second node, and sending a message to the hub node informing the hub node that the block is correlated with the pair of bit strings stored on the second node; at the hub node, identifying the bits of the stored pairs of bit strings stored together with the identity of the first node which correspond to the bits of the block, and storing the identified bits of the stored pairs of bit strings together with the identity of the second node.

[0065] In some embodiments, the method may further comprise wherein the second node is randomly selected.

[0066] In some embodiments, the method may further comprise wherein the second node randomly selects an RNG or QRNG from which the two bit strings are obtained.

[0067] In some embodiments, the method may further comprise repeating the method of claim 55 multiple times wherein different ones of the plurality of nodes are the first node and the second node for different repetitions, so that the system comprises a plurality of second nodes; a first endpoint node, which has previously acted as a second node, and a second endpoint node which has previously acted as a second node, communicating and agreeing they wish to generate shared randomness; at least one of the first and second endpoint nodes sending a shared-randomness request to the hub node identifying the first and second endpoint nodes, and identifying which of the059645.00198 first and second endpoint nodes is to be the primary randomness sharer and which is to be the secondary randomness sharer; at the hub node, checking if there is sufficient entropy previously indirectly delivered from first nodes to the first and second endpoint nodes, which has not been used, to fulfil the shared-randomness request; selecting a first intermediate node which has previously acted as a first node for the first endpoint node, and selecting a second intermediate node which has previously acted as a first node for the second endpoint node.

[0068] In some embodiments, the method may further comprise wherein the first and second endpoint nodes agree a first number of bits of shared randomness they wish to generate, and the shared-randomness request identifies the first number of bits.

[0069] In some embodiments, the method may further comprise wherein only one of the first and second endpoint nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the primary randomness sharer and which is to be the secondary randomness sharer, wherein either: the one of the first and second endpoint nodes sending the shared-randomness request is identified as the primary randomness sharer and the other one of the first and second endpoint nodes is identified as the secondary randomness sharer; or the one of the first and second endpoint nodes sending the shared-randomness request is identified as the secondary randomness sharer and the other one of the first and second endpoint nodes is identified as the primary randomness sharer.

[0070] In some embodiments, the method may further comprise wherein, if there is more than one node which has acted as a first node for the first endpoint node, the hub node randomly selects one of these nodes as the first intermediate node; and if there is more than one node which has acted as a first node for the second endpoint node, the hub node randomly selects one of these nodes as the second intermediate node.

[0071] In some embodiments, the method may further comprise, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the first endpoint node by the first intermediate node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the second endpoint node by the second intermediate node; at the first endpoint node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the second endpoint node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the first intermediate node, identifying a fifth block of unused corresponding bits of the stored pairs of bit strings which were sent to the first endpojnt node; at the second intermediate node, identifying a sixth block of unused corresponding bits of the stored pairs of bit strings which were sent to the second endpoint node; wherein each of the first to sixth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the first endpoint node, and sending the first bit string of the second block to the second endpoint node; at the first endpoint node, sending the first bit string of the third block to the hub node; at the second059645.00198 endpoint node, sending the first bit string of the fourth block to the hub node; at the first intermediate node, sending the first bit string of the fifth block to the hub node and to the first endpoint node; at the second intermediate node, sending the first bit string of the sixth block to the hub node and to the second endpoint node; at each of the hub node and the first endpoint node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of the third block, and to the value of the corresponding bit in the first bit string of the fifth block, and recording the position numbers for which all three of these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the first endpoint node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at each of the hub node and the second endpoint node, comparing a value of each bit in the first bit string of the second block to the value of the corresponding bit in the first bit string of the fourth block, and to the value of the corresponding bit in the first bit string of the sixth block, and recording the position numbers for which all three of these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the second block, and placing the values at these positions in the second bit string into a third vector; at the second endpoint node, referring to the recorded position numbers in the second bit string of the fourth block, and placing the values at these positions in the second bit string into a fourth vector; at the hub node, comparing the length of the first vector and the third vector, and, if the first and third vectors have different lengths, truncating by removing a number of entries from the end of the longer one of the first and third vectors so that the first and third vectors have the same length, and either; if the first vector has a greater length, sending a truncation message to the first endpoint node to remove the number of entries from the end of the second vector; or if the third vector has a greater length, sending a truncation message to the second endpoint node to remove the number of entries from the end of the fourth vector; at the first endpoint node, if a truncation message is received, truncating by removing the number of entries from the end of the second vector; at the second endpoint node, if a truncation message is received, truncating by removing the number of entries from the end of the second vector; at the hub node, deriving a fifth vector which is the result of an XOR of the first and third vectors after any truncation, and sending the fifth vector to whichever one of the first and second endpoint nodes is the node identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a sixth vector which is the result of an XOR of the fifth vector with either the second vector, if the first endpoint node is the secondary randomness sharer, or the fourth vector, if the second endpoint node is the secondary randomness sharer, and storing the sixth vector; and at the node identified as the primary randomness sharer, storing either the second vector, if the first endpoint node is the primary randomness sharer, or the fourth vector, if the second endpoint node is the primary randomness sharer; whereby the first and second endpoint nodes have shared randomness represented by the sixth vector and the one of the second or fourth vector which was stored.059645.00198

[0072] In some embodiments, the method may further comprise wherein each of the first to sixth blocks comprises (4*n)+β(2*n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

[0073] In some embodiments, the method may further comprise where ^^(^^)= ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.

[0074] In some embodiments, the method may further comprise, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the first endpoint node by the first intermediate node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the second endpoint node by the second intermediate node; at the first endpoint node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the second endpoint node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the first intermediate node, identifying a fifth block of unused corresponding bits of the stored pairs of bit strings which were sent to the first endpojnt node; at the second intermediate node, identifying a sixth block of unused corresponding bits of the stored pairs of bit strings which were sent to the second endpoint node; wherein each of the first to sixth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the first endpoint node, and sending the first bit string of the second block to the second endpoint node; at the first intermediate node, sending the first bit string of the fifth block to the first endpoint node, at the second intermediate node, sending the first bit string of the sixth block to the second endpoint node, at the hub node, deriving a first vector which is the result of an XOR of the second bit string of the first block and the second bit string of the second block, and sending the first vector to whichever one of the first and second endpoint nodes is identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a second vector which is the result of an XOR of the first vector with either; the second bit string of the third block, if the first endpoint node is the secondary randomness sharer, or the second bit string of the fourth block, if the second endpoint node is the secondary randomness sharer; at the node identified as the primary randomness sharer, deriving a third vector which is either; the second bit string of the third block, if the first endpoint node is the primary randomness sharer, or the second bit string of the fourth block, if the second endpoint node is the primary randomness sharer; at the first endpoint node, comparing each entry in the first bit string of the first block with the corresponding entries in the first bit string of the third block and the first bit string of the fifth block, and recording first position numbers for which these all three of these entries are the same; at the second endpoint node, comparing each entry in the first bit string of the second block with the corresponding entries in the first bit string of the fourth block and the first bit string of the sixth block, and recording second position numbers for which these all three of these entries are the same; the first endpoint node and the second endpoint node communicating and identifying position numbers for which both the first position numbers and the second position059645.00198 numbers indicate the respective three entries are all the same; at the node identified as the primary randomness sharer, referring to the entries in the third vector at positions corresponding to the identified position numbers and assigning the values at the identified position numbers to a fourth vector; at the node identified as the secondary randomness sharer, referring to the entries in the second vector at positions corresponding to the identified position numbers and assigning the values at the identified position numbers to a fifth vector; at the node identified as the primary randomness sharer, storing the fourth vector; and at the node identified as the secondary randomness sharer, storing the fifth vector; whereby the first and second endpoint nodes have shared randomness represented by the fourth vector and the fifth vector.

[0075] In some embodiments, the method may further comprise wherein each of the first to sixth blocks comprises (16*n)+β(8*n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

[0076] In some embodiments, the method may further comprise where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), and where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.

[0077] In some embodiments, the method may further comprise, if the check finds that there is sufficient entropy, generating shared randomness by: assigning one of the first endpoint node and the second endpoint node as the Side 1 participant node and the other as the Side 2 participant node; at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 1 participant node by the first intermediate node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 2 participant node by the second intermediate node; at the Side 1 participant node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the Side 2 participant node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the first intermediate node, identifying a fifth block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 1 participant node; at the second intermediate node, identifying a sixth block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 2 participant node; wherein each of the first to sixth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the Side 1 participant node; at the first intermediate node, sending the first bit string of the fifth block to the hub node and to the Side 1 participant node; at the Side 1 participant node, sending the first bit string of the third block to the hub node; at each of the hub node and the Side 1 participant node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in each of the first bit string of the third block and the first bit string of the fifth block, and recording as first position numbers the position numbers for which all three of these values are the same; at the hub node, referring to the recorded first position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the Side 1 participant node, referring to the059645.00198 recorded first position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at the hub node, comparing the length of the first vector and the second block, and, if the first vector and the second block have different lengths, truncating by removing a number of entries from the end of the longer one of the first vector and the second block so that the first vector and the second block have the same length, and, if the first vector was longer than the second block, sending a truncation message to the Side 1 participant node instructing it to remove the number of entries from the second vector, or, if the second block was longer than the first vector, sending a truncation message to the Side 2 participant node instructing it to remove the number of entries from the fourth block; at the Side 1 participant node, if the truncation message is received, removing the number of entries from the second vector; at the Side 2 participant node, if the truncation message is received, removing the number of entries from the fourth block; at the hub node, sending the first bit string of the second block to the Side 2 participant node; at the second intermediate node, sending the first bit string of the sixth block to the Side 2 participant node; at the hub node, deriving a third vector which is the result of an XOR of the first vector with the second bit string of the second block; at the hub node, sending the third vector to the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, deriving a fourth vector which is the result of an XOR of the third vector with either; the second vector if the Side 1 participant node is identified as the secondary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the secondary randomness sharer; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, deriving a fifth vector which is either: the second vector if the Side 1 participant node is identified as the primary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the primary randomness sharer: at the Side 2 participant node, comparing a value of each bit in the first bit string of the second block to the value of the corresponding bit in each of the first bit string of the fourth block and the first bit string of the sixth block, recording as second position numbers the position numbers for which all three of these values are the same, and sending the second position numbers to the Side 1 participant node; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, referring to the recorded second position numbers in the fifth vector, assigning the values at these positions to a sixth vector, and storing the sixth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, referring to the recorded second position numbers in the fourth vector, assigning the values at these positions to a seventh vector, and storing the seventh vector; whereby the first and second endpoint nodes have shared randomness represented by the sixth vector and the seventh vector.

[0078] In some embodiments, the method may further comprise wherein the shared- randomness request identifies which of the first and second endpoint nodes is to be the Side 1 participant node and which is to be the Side 2 participant node.059645.00198

[0079] In some embodiments, the method may further comprise wherein only one of the first and second endpoint nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the Side 1 participant node and which is to be the Side 2 participant node, wherein either: the one of the first and second endpoint nodes sending the shared-randomness request is identified as the Side 1 participant node and the other one of the first and second endpoint nodes is identified as the Side 2 participant node; or the one of the first and second endpoint nodes sending the shared-randomness request is identified as the Side 2 participant node and the other one of first and second endpoint nodes is identified as the Side 1 participant node.

[0080] In some embodiments, the method may further comprise wherein each of the first, third and fifth blocks comprises (16*n)+β(8*n) pairs of bits and each of the second, fourth and sixth blocks comprises (4*n) + β(2*n) pairs of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

[0081] In some embodiments, the method may further comprise where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^) where the ceiling function rounds up to the nearest integer and x is the expected amount of shared randomness.

[0082] In some embodiments, the method may further comprise wherein the first and second endpoint nodes agree which of the methods is to be used, and the shared randomness request identifies which of these methods is to be used.

[0083] In a second aspect of the present invention, there is provided a system comprising a plurality of nodes arranged to carry out the method of the first aspect.

[0084] In a third aspect of the present invention, there is provided a computer program comprising instructions which, when executed by processors of a plurality of nodes, cause the nodes to carry out the method of the first aspect.

[0085] The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

[0086] This application acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls "dumb" or standard hardware, to carry out the desired functions. It is also intended to encompass software which "describes" or defines the configuration of hardware, such as HDL (hardware059645.00198 description language) software, as is issued for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.

[0087] The features and embodiments discussed above may be combined as appropriate, as would be apparent to a person skilled in the art, and may be combined with any of the aspects of the invention except where it is expressly provided that such a combination is not possible or the person skilled in the art would understand that such a combination is self-evidently not possible. Brief Description of the Drawings

[0088] Embodiments of the present invention are described below, by way of example, with reference to the following drawings.

[0089] Figure 1 depicts a first example of a networked system according to an embodiment;

[0090] Figure 2 depicts a second example of a networked system according to an embodiment;

[0091] Figure 3 depicts a schematic diagram of a first stage of a first method of generating shared randomness at nodes at separated locations according to an embodiment;

[0092] Figure 4 depicts a flow chart of the first stage of the first method of figure 3;

[0093] Figure 5 depicts a flow chart of an initial part of a second stage of the first method;

[0094] Figure 6 depicts a schematic diagram of a first subvariant of the main part of the second stage of the first method of generating shared randomness at nodes at separated locations;

[0095] Figure 7 depicts a flow chart of a main part of the first subvariant of the second stage of the first method;

[0096] Figure 8 depicts a schematic diagram of the main part of the second subvariant of the second stage of the first method of generating shared randomness at nodes at separated locations;

[0097] Figure 9 depicts a flow chart of a main part of the second subvariant of the second stage of the first method;

[0098] Figure 10 depicts a schematic diagram of a main part of a third subvariant of the second stage of the first method of generating shared randomness at nodes at separated locations;

[0099] Figure 11 depicts a flow chart of a main part of the third subvariant of the second stage of the first method;059645.00198

[0100] Figure 12 depicts a schematic diagram of a first stage of a second method of generating shared randomness at nodes at separated locations according to an embodiment;

[0101] Figure 13 depicts a schematic diagram of a second stage of the second method of generating shared randomness at nodes at separated locations;

[0102] Figure 14 depicts a flow chart of the second stage of the second method;

[0103] Figure 15 depicts a schematic diagram of a first variant of a third stage of the second method of generating shared randomness at nodes at separated locations;

[0104] Figure 16 depicts a schematic diagram of a second variant of a third stage of the second method of generating shared randomness at nodes at separated locations;

[0105] Figure 17 depicts a schematic diagram of a third variant of a third stage of the second method of generating shared randomness at nodes at separated locations;

[0106] Figure 18 depicts a schematic diagram of a second stage of a third method of generating shared randomness at nodes at separated locations according to an embodiment;

[0107] Figure 19 depicts a flow chart of the second stage of the third method;

[0108] Figure 20 depicts a flow chart of an initial part of a third stage of the third method;

[0109] Figure 21 depicts a schematic diagram of a main part of a first subvariant of the third stage of the third method of generating shared randomness at nodes at separated locations;

[0110] Figure 22 depicts a flow chart of a main part of the first subvariant of the third stage of the third method;

[0111] Figure 23 depicts a schematic diagram of a main part of a second subvariant of the third stage of the third method of generating shared randomness at nodes at separated locations;

[0112] Figure 24 depicts a flow chart of a main part of the second subvariant of the third stage of the third method;

[0113] Figure 25 depicts a schematic diagram of a main part of a third subvariant of the third stage of the third method of generating shared randomness at nodes at separated locations;

[0114] Figure 26 depicts a flow chart of a main part of the third subvariant of the third stage of the third method; and

[0115] Figure 27 depicts an example of an entropy store used in the described methods.059645.00198

[0116] Common reference numerals are used throughout the figures to indicate the same or similar features. Detailed Description

[0117] Embodiments of the present invention are described below by way of example only. These examples represent the best mode of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0118] In broad terms, the present disclosure relates to systems and methods for generating shared randomness, on demand, at separated locations without requiring the use of quantum communication channels, such as photonic communication channels. The present approach uses Quantum Random Number Generators (QRNGs) to generate quantum-correlated entropy at two or more different locations. The entropy generated by QRNGs is derived from genuine quantum processes, and the systems and methods are arranged to provide simulated quantum channels between different locations, so that the present approach is able to generate quantum-correlated entropy, at different separated locations which is indistinguishable from the quantum-correlated entropy provided by the use of quantum channels, without the use of quantum communication channels and the associated costs and technical difficulties. The quantum-correlated entropy is subsequently used to generate shared randomness shared between the different locations, and the shared randomness at the different locations can then be used as encryption precursor material providing a basis for the generation of encryption materials, for example, encryption keys or one-time pad generation, for use for secure encrypted communications between the different locations.

[0119] As will be discussed in detail below, the general approach of the present disclosure is to set up entropy stores at separated locations storing quantum-correlated entropy. Once the entropy stores have been set up, shared randomness can be generated on-demand, at any time, between any two of the locations using the stored quantum-correlated entropy. The entropy stores are correlated in such a way that shared randomness can be generated between any pair of locations. However, each store’s contents considered in isolation don’t contain any information relating to the shared randomness, and so even if a store were to be hacked, and its content accessed, the shared randomness would not be compromised. To access the shared randomness an adversary would need to hack multiple entropy stores as well as having the facility to decrypt in real time the communications that are exchanged between the stores’ locations during the generation of shared randomness from the quantum-correlated entropy. Additionally or alternatively, each entropy store may be used in isolation as a standalone source of randomness.

[0120] Figure 1 depicts a schematic diagram of a first example of a networked system 100 according to a first embodiment. The networked system 100 comprises a plurality of nodes 102059645.00198 arranged to form a quantum cloud 104 having a secure communications perimeter 104a, and the networked system 100 is arranged to generate shared randomness, on demand, between different nodes 102 of the plurality of nodes 102. Each node 102 of the plurality of nodes 102 comprises, or is associated with, a hardware security module (HSM) (not shown), which can be used to securely store cryptographic precursor material and cryptographic material, among other things.

[0121] Each node 102 of the plurality of nodes 102 is provided with cryptographic keys so that all of the nodes 102 can be communicatively linked to one another by secure tunnels, enabling secure communications between the nodes 102 and so providing the secure communications perimeter 104a of the quantum cloud 104. In the illustrated example, each node 102 is a datacentre. However, this is not essential, and the networked system 100 may comprise other types of node 102.

[0122] In the illustrated example, the nodes 102 are pre-loaded with Advanced Encryption Standard-256 (AES-256) keys, so that the nodes 102 can be securely communicatively linked by AES-256 tunnels. In other examples different keys and tunnels, or other forms of secure communications channels may be used.

[0123] The networked system 100 also comprises a plurality of Quantum Random Number Generators (QRNGs) 106. In the illustrated example of figure 1, each node 102 of the plurality of nodes 102 comprises a QRNG 106. It will be understood that QRNGs use quantum processes to generate random numbers, so that a QRNG can generate a string of random numbers, such as a string of random bits, which are truly random.

[0124] Figure 2 depicts a schematic diagram of a second example of a networked system 200 according to the first embodiment. The networked system 200 comprises a plurality of nodes 202 arranged to form a quantum cloud 204 having a secure communications perimeter 204a, similarly to the first example of figure 1. The networked system 200 also comprises a plurality of Quantum Random Number Generators (QRNGs) 206. In the illustrated example of figure 2, instead of each node of the plurality of nodes comprising a QRNG in the same manner as the first example of figure 1, the plurality of QRNGs 206 are grouped together in a QRNG bank 208. The QRNG bank 208 is provided with cryptographic keys in a similar manner to the nodes 202, so that the QRNG bank 208 and the other nodes 202 can be communicatively linked to one another by secure tunnels. In some examples the QRNG bank 208 may also be able to operate as a node 202, for example being a datacentre in addition to operating as a QRNG bank 208.

[0125] It will be understood that the first and second examples of figures 1 and 2 are only examples of possible arrangements of the networked system. For example, the QRNGs 206 of the second example may be arranged in several different QRNG banks 208 instead of a single QRNG bank 208. In other examples the networked system may comprise both QRNGs 206 in one or more QRNG banks 208 and QRNGs 106 comprised in at least some of the nodes 102. Although the first example of figure 1 has a QRNG 106 comprised in each node 102, so that the number of QRNGs 106 and nodes 102 are equal, this is not essential, the number of QRNGs and nodes may be different. In059645.00198 particular, in the second example of figure 2, the number of QRNGs 206 in the QRNG bank 208 may be different from the number of nodes 202.

[0126] Figure 3 is a schematic diagram of a first stage of a first method of generating shared randomness at two nodes at different locations via a single link to each of a plurality of endpoint nodes, with no chaining of links, according to an embodiment. This first stage of the first method involves the distribution of quantum-correlated entropy. The initial entropy loading is illustrated in figure 3. The example of figure 3 shows the method as used in the second example of the networked system 200 according to figure 2, the method may also be used with other arrangements of the networked system, and in particular, can be used in the first example of the networked system 100 according to figure 1.

[0127] As can be seen in figure 3, one of the nodes 202c (denoted QCH) takes on the role of the “hub” and is responsible for distributing the initial entropy to a plurality of endpoint nodes 202n, where the quantum-correlated entropy is to be generated. Any of the nodes 202 can act as the hub node 202c, and different ones of the nodes 202 will act as the hub node 202c for different instances of generating.

[0128] In the illustrated example of figure 3, all the QRNGs are situated in a single QRNG Bank 208. A brief explanation of a first stage of the first method is that the entropy at each endpoint node 202n is correlated with the entropy at the hub node 202c with the help of the QRNGs 206 of the node 208. There may be any number of endpoint nodes 202n up to a maximum of one less than the total number of nodes 202 (since one node 202 must take the role of hub node 202c). However, it is not essential that the hub node 202c in each instance of entropy distribution distributes entropy to every other node 202.

[0129] For each endpoint node 202n, the hub node 202c obtains two bit strings of random bits of equal length, via a call 310c to a randomly selected QRNG 206 within QRNG Bank node 208, which randomly selected QRNG 206 generates the requested random bit strings and sends them to the hub node 202c. The hub node 202c then pairs these bit strings together so that each bit in one, first, bit string has a corresponding bit in the other, second, bit string. Typically, for simplicity, the corresponding bits in the different first and second bit strings of a pair are the bits having corresponding numbers counted from a specific end of each bit string, although more complex correspondences could be used if desired. We call the bits of the first bit string B-bits and the bits of the second bit string M-bits, signifying that they are intended to simulate the Basis bits and Measurement bits that would have been obtained in a transmission of photonic qubits using complementary measurement bases. Accordingly, the pair of a first bit string of B-bits and a second bit string of M-bits may be regarded as a string of B-bit / M-bit pairs. The hub node 202c sends 312n a respective pair of these first (B-bit) and second (M-bit) bit strings to each endpoint node 202n, and also makes copies of the pair of bit strings, tagged with the identity of the respective endpoint node 202n to which they were sent.059645.00198

[0130] On receipt of its respective pair of bit strings from the hub node 202c, each endpoint node 202n separately obtains, via a respective call 310n to a randomly selected QRNG 206 within QRNG Bank node 208, its own two bit strings of random bits of equal length to the B-bit / M-bit strings received from the hub node 202c, and pairs these two bit strings in the same way as the pairing by the hub (QCH) node 202c. These pairs of first and second bit strings are also called B-bits and M- bits. The QRNGs 206 used to service the calls 310c and 310n by providing bit strings are randomly selected, so that these may be the same or different QRNGs 206.

[0131] Each endpoint node 202n then compares each bit in its own first (B-bit) string with the corresponding bit in the first (B-bit) string that it received from the hub node 202c. In a first option, if these two B-bits have the same value (i.e. both 0 or both 1), then the endpoint node 202n re-sets the corresponding M-bit in its own second (M-bit) string to be equal to the corresponding M-bit in the second (M-bit) string received from the hub node 202c, while if these two B-bits have different values, the endpoint node 202n instead leaves the corresponding M-bit in its own second (M-bit) string unchanged. Alternatively, in a second option, if these two B-bits have the different values, then the endpoint node 202n re-sets the corresponding M-bit in its own second (M-bit) string to be equal to the corresponding M-bit in the second (M-bit) string received from the hub node 202c, while if these two B-bits have the same value, the endpoint node 202n instead leaves the corresponding M-bit in its own second (M-bit) string unchanged.

[0132] Once this process has been completed for all the received bits in the pairs of bit strings, each endpoint node 202n deletes all record of the B-bits and M-bits it received from the hub node 202c. Each endpoint node 202n will then have a respective set of M-bits that are correlated with the M-bits of the hub node 202c in a way that is indistinguishable from the correlations that would be obtained in a photonic transmission manifesting the effects of Heisenberg’s Uncertainty Principle. Hence, we can describe each second (M-bit) string at an end point node 202n as being quantum- correlated with the corresponding second (M-bit) string stored at the hub node 202c.

[0133] As is mentioned above, each node 202 has an associated HSM for secure data storage. The QCH hub node 202c copies all of the B-bit / M-bit pairs (i.e., all of the pairs of bit strings) that it has sent to the other nodes 202n and stores this data in its HSM. Conveniently, the B-bit / M-bit pairs may be stored as a list, with each B-bit / M-bit pair having a reference number according to its position in the list. The full list of bit pairs for a specific endpoint node 202n is tagged with the identifier for that endpoint node 202n. Each endpoint node 202n, having derived its own list of B-bit / M-bit pairs from those received from QCH hub node 202c, stores this list in its own HSM, tagged with the identifier of the QCH hub node 202c. Each of these lists stored in the HSMs of the respective endpoint nodes 202n will be the same length as the corresponding list stored in the HSM of QCH node 202c, and can be referenced in a similar way such that each B-bit / M-bit pair in the list has a reference number according to its position in the list.

[0134] As soon as the endpoint node 202n has deleted the B-bits and M-bits received from the QCH node 202c, it produces a certificate of deletion confirming that this has been completed, and059645.00198 it sends this certificate to QCH node 202c. QCH node 202c then tags the equivalent bit-pairs in its own HSM as having been certified deleted by the endpoint node 202n.

[0135] Figure 4 shows a more detailed flow chart of the first stage of the first method for the QCH node 202c to provide entropy to a plurality of endpoint nodes 202n. In the first stage 400 of the first method, the total number of nodes 202 in the system 204 is N, including the QCH node 202c. Accordingly, the endpoint nodes 202n may be denoted as (QCN)i, where i goes from 1 to N-1. Further, there are R QRNGs within the QRNG bank node 208, and an individual QRNG is labelled (QRNG)j, where j goes from 1 to R.

[0136] In the illustrated example of figure 4, the QCH node 202c is to provide entropy to a number of endpoint nodes 202n, each denoted as (QCN)i, with a different value of i. In a first select QRNG block 402 of the first stage method 400, for each of the endpoint nodes 202n, the QCH node 202c randomly selects an integer x between 1 and R. This selection can be done with any local random number generator or pseudorandom number generator that QCH node 202c has access to. It is not essential that a QRNG is used.

[0137] Then, in a first obtain random bitstrings block 404, for each of the endpoint nodes 202n, the QCH node 202c sends a message to QRNG Bank node 208, requesting that(^^ ^^ ^^ ^^)௫be used to generate and send back two random bitstrings, each of length ^^^bits. The parameter ^^^, which determines the amount of entropy that QCH node 202c will send to a specific endpoint node 202n ( ^^ ^^ ^^)^, could be set in advance or chosen by QCH node 202c at the time of the request to QRNG Bank node 208. ^^^could be different for each endpoint node 202n ( ^^ ^^ ^^)^, or set as the same value for all of the endpoint nodes 202n ( ^^ ^^ ^^)^. In response to each of these messages, the requested(^^ ^^ ^^ ^^)௫206 of the QRNG bank node 208 generates two random bitstrings of length ^^^bits, and the QRNG bank node 208 sends these two random bitstrings back to the QCH node 202c.

[0138] Then, in a concatenate bitstrings block 406, for each of the endpoint nodes 202n, the QCH node 202c concatenates the two bitstrings it received back from QRNG Bank node 208 into an ^^^x 2 sized hub-entropy matrix [ ^^ு]^of B-bit / M-bit pairs, with the B-bits placed in the first column and the M-bits in the second column. Each row in[^^ு]^is also tagged with a reference number. The first column of the hub-entropy matrix [ ^^ு]^may be regarded as a first (B-bit) string of B-bits, while the second column may be regarded as a second (M-bit) string of M-bits.

[0139] Then, in a distribution block 408, the QCH node 202c distributes the [ ^^ு]^to the endpoint nodes 202n, so that for every i ∈ [1, N-1], QCH node 202c sends[^^ு]^to node202n ( ^^ ^^ ^^)^. In a copying and storing block 410, the QCH node 202c copies each [ ^^ு]^and stores them in its HSM, tagging each[^^ு]^with the identifier i for the relevant endpoint node 202n ( ^^ ^^ ^^)^.

[0140] Accordingly, it will be understood that the QCH node 202c carries out each of the blocks 402 to 410 once for each of the endpoint nodes 202n.059645.00198

[0141] Then, in a temporary storage block 412, when the[^^ு]^data has been received, each endpoint node 202n ( ^^ ^^ ^^)^temporarily stores its received [ ^^ு]^data in its own HSM.

[0142] Then, in a second select QRNG block 414, each endpoint node 202n ( ^^ ^^ ^^)^selects a random number y between 1 and R, using any local random number generator that it has access to. This selection can be done with any local random number generator or pseudorandom number generator that the endpoint node 202n has access to. It is not essential that a QRNG is used.

[0143] Then, in a second obtain random bit string block 416, each endpoint node 202n ( ^^ ^^ ^^)^sends a message to QRNG Bank node 208, requesting that ( ^^ ^^ ^^ ^^)௬be used to generate and send back two random bit strings, each of length ^^^bits. In response to each of these messages, the requested(^^ ^^ ^^ ^^)௬206 of the QRNG bank node 208 generates two random bitstrings of length ^^^bits, and the QRNG bank node 208 sends these two random bitstrings back to the requesting endpoint node 202n(^^ ^^ ^^)^.

[0144] Then, in a label bit strings block 418, each endpoint node 202n ( ^^ ^^ ^^)^labels its respective two received bit strings as first (B-bit) bitstring [ ^^]^and second (M-bit) bitstring [ ^^]^.

[0145] Then, in a compare basis bits block 420, each endpoint node 202n ( ^^ ^^ ^^)^sequentially compares each entry in [ ^^]^with the corresponding entry in the first column of [ ^^ு]^. In a first alternative, if the two entries are equal, the endpoint node 202n ( ^^ ^^ ^^)^sets the corresponding entry in [ ^^]^to be the same value as that of the corresponding entry in the second column of [ ^^ு]^, that is, the entry at the same row position as that of the B-bit being compared. Otherwise, if the two entries differ, the endpoint node 202n ( ^^ ^^ ^^)^instead leaves the corresponding entry in [ ^^]^unchanged. In a second alternative, if the two entries differ, the endpoint node 202n(^^ ^^ ^^)^sets the corresponding entry in [ ^^]^to be the same value as that of the corresponding entry in the second column of [ ^^ு]^, that is, the entry at the same row position as that of the B-bit being compared. Otherwise, if the two entries are equal, the endpoint node 202n ( ^^ ^^ ^^)^instead leaves the corresponding entry in [ ^^]^unchanged. Either alternative may be used, as convenient in any specific application.

[0146] Then, in a deletion block 422, when each endpoint node 202n ( ^^ ^^ ^^)^has completed the process of the compare basis bits block 420 for all the entries in [ ^^]^, the endpoint node 202n ( ^^ ^^ ^^)^deletes [ ^^ு]^and sends a certificate of deletion to QCH node 202c confirming that the deletion has taken place.

[0147] Then, in a first tagging block 424, when the QCH node 202c receives each certificate of deletion from an endpoint node 202n ( ^^ ^^ ^^)^, the QCH node tags [ ^^ு]^as having been deleted by that endpoint node 202n(^^ ^^ ^^)^. In the illustrated example, this tagging is achieved via a new column that is added to [ ^^ு]^, but this is not essential, and other tagging methods may be used. It will be059645.00198 understood that the QCH node 202c carries out the block 424 once for each of the endpoint nodes 202n.

[0148] When block 422 has been completed, in a second tagging block 426, each endpoint node 202n ( ^^ ^^ ^^)^creates a new ^^^x 2 matrix [ ^^^] , with a first column consisting of the entries in [ ^^]^, and a second column consisting of the entries in [ ^^]^. The first column of the matrix [ ^^^] may be regarded as a first (B-bit) string of B-bits, while the second column may be regarded as a second (M-bit) string of M-bits. Each row in [ ^^^] is also tagged with a reference number, enabling the rows in [ ^^ு]^and the rows in [ ^^^] to be matched with each other. Conveniently, each row in [ ^^^] is tagged with the same reference number as the row in [ ^^ு]^used to generate it in blocks 422 and 426.

[0149] Accordingly, each endpoint node 202n ( ^^ ^^ ^^)^will then have a second (M-bit) string comprising a set of M-bits stored in matrix [ ^^^] that are correlated with the second (M-bit) string comprising a set of M-bits of [ ^^ு]^stored at the QCH node 202c in a way that is indistinguishable from the correlations that would be obtained in a photonic transmission manifesting the effects of Heisenberg’s Uncertainty Principle. Hence, the set of M-bits at an endpoint node 202n(^^ ^^ ^^)^are quantum-correlated with the corresponding set of M-bits stored at the QCH hub node 202c. Thus, the set of M-bits of [ ^^^] stored at each endpoint node 202n ( ^^ ^^ ^^)^are a store of quantum-correlated entropy.

[0150] It will be understood that blocks 412 to 422 and 426 are carried out separately for each of the endpoint nodes 202n.

[0151] As is explained above with reference to figures 3 and 4, the first stage of the first method stores entropy at each of the endpoint nodes 202n. The contents of the entropy stores at each of the endpoint nodes 202n, and the correlations between them, are indistinguishable from those that would have been brought about had photonic qubit transmission been used with the application of complementary measurement bases to exploit the uncertainty principle. If photonic methods had been used, it would be necessary to apply error correction and privacy amplification as part of the shared randomness creation process, but these will not be required in the present method. Nor does the present method have the very high expense, formidable technical challenges, or side- channel vulnerabilities that are all unavoidable when photonic methods are used. Accordingly, the disclosed method allows replication of the effects of quantum communication protocols without the need for any photonic links and with none of the drawbacks of photonic transmission.

[0152] The stored entropy at each of the endpoint nodes 202n can then be used to generate shared randomness between any two endpoint nodes 202n on demand at any time. The entropy stores are quantum-correlated in such a way that shared randomness can be generated between any pair of endpoint node 202n locations.

[0153] The first stage of the first method described above with reference to figures 3 and 4 is a single instance of the distribution of stored entropy to endpoint nodes 202n from a hub node 202c.059645.00198 This first stage may be carried out for any necessary number of instances, with any selected node 202 acting as the hub node 202c, and for any selected endpoint nodes 202n, as required to store a desired amount of entropy at any and each node 202, and as required to replace previously distributed entropy used to generate shared randomness.

[0154] The stored entropy at a node 202 which has been distributed to the node 202 by the first method described above may be used as a standalone source of randomness for use by the node 202, as an alternative to being used to generate shared randomness. Such standalone randomness may be used in various cryptographic and security applications by the node 202. For example, in the event that the distribution of entropy to the different nodes 202 and the generation of shared randomness by the different nodes 202 results in a node 202 having surplus stored entropy which cannot be used to generate shared randomness, this surplus stored entropy may be used as standalone randomness.

[0155] In a second stage of the first method, any pair of endpoint nodes 202n can derive shared randomness with each other from the stored entropy previously stored in instances of the first stage, via communication with each other and with the QCH hub node 202c. As is explained above, any node 202 may act as a hub node 202c. However, the QCH hub node 202c in the second stage must be a node 202 which has acted as the QCH hub node 202c for one or more instances of the first stage of the first method which have distributed the stored entropy to each of the pair of endpoint nodes 202n. However, it is not essential that the node 202 acted as the QCH hub node 202c to distribute the stored entropy to both of the pair of endpoint nodes 202n in the same instance of the first stage of the first method.

[0156] Examples of such processes are shown in in Figures 5 to 11, which illustrate different variants of the second stage of the first method. As will be explained below, these different variants can be described as trusted or trustless, according to whether or not the hub QCH node 202c gains knowledge of the randomness shared by the endpoint nodes 202n.

[0157] A brief explanation of the second stage of the first method is that shared randomness shared between two different endpoint nodes 202n is created with the help of XOR operations carried out by the QCH hub node 202c and one of the endpoints 202n. The QCH hub node 202c XORs together the two second (M-bit) strings it holds that are referenced to the two endpoint nodes 202. Before this, the QCH hub node 202c and one or both of the endpoint nodes 202n may or may not carry out sifting operations on these M-bits, depending on which subvariant is being applied. The QCH hub node 202c then sends the result of this XOR operation to one of the endpoint nodes 202n, which then XORs it with its own second (M-bit) string of M-bits. If a trustless subvariant is applied, a sifting process is carried out between the endpoints to complete the shared randomness generation process. In this context sifting simply means comparing B-bits and retaining or discarding the corresponding M-bits according to whether or not the B-bits are equal. In examples where the first alternative was followed, M-bits are retained when the B-bits are equal, and discarded when the B-059645.00198 bits are different, whereas in examples where the second alternative was followed, M-bits are retained when the B-bits are different, and discarded when the B-bits are the same.

[0158] The resulting generated shared randomness, shared between the two endpoint nodes 202 may be used, for example, to generate cryptographic material, such as encryption keys, and one-time pads.

[0159] Figure 5 shows a more detailed flow chart of an initial part of the second stage of the first method to generate shared randomness between two endpoint nodes 202 using the entropy stored in the two endpoint nodes 202 in the first stage. It will be understood that the first stage and the second stage of the first method are asynchronous. Although the two endpoint nodes must have stored entropy delivered by the first stage in order to be able to carry out the subsequent second stage, there is no requirement for any specific time relationship between these stages.

[0160] The initial part of the second stage 500 is carried out when a first endpoint node 202a and a second endpoint node 202b of the network 200 wish to generate shared randomness with each other. These first and second endpoint nodes 202a and 202b may be referred to as ( ^^ ^^ ^^)^and ( ^^ ^^ ^^)^respectively. As shown in figure 5, the initial part of the second stage 500 begins with an agreement block 502, in which the first endpoint node 202a ( ^^ ^^ ^^)^and the second endpoint node 202b ( ^^ ^^ ^^)^communicate with one another, via an authenticated AES-256 tunnel they share, and agree on the number of bits ^^^^of shared randomness they wish to generate, the protocol subvariant ^^^they wish to use, and which out of the first endpoint node 202a ( ^^ ^^ ^^)^and the second endpoint node 202b(^^ ^^ ^^)^is the “primary” and which the “secondary” randomness sharer, and the identity of the QCH node 202c to be used. The QCH hub node 202c must have previously acted as the hub node providing entropy to the first and second endpoint nodes 202a and 202b during one or more instances of the first stage.

[0161] The protocol subvariant ^^^is selected from three possible options: ^^^is “Trusted”, ^^ଶis “Trustless Symmetric”, and ^^ଷis “Trustless Asymmetric".

[0162] Then, in a request block 504, one endpoint node 202 out of the two endpoint nodes 202a(^^ ^^ ^^)^and 202b(^^ ^^ ^^)^sends a shared-randomness request to the agreed QCH node 202c, consisting of the identities of the two endpoint nodes 202a ( ^^ ^^ ^^)^and 202b ( ^^ ^^ ^^)^, the value of the number of bits ^^^^of shared randomness to be generated, the identity of the selected subvariant ^^^, and which out of the endpoint nodes 202a ( ^^ ^^ ^^)^and 202b ( ^^ ^^ ^^)^is the primary and which the secondary randomness sharer. If the Trustless Asymmetric subvariant ^^ଷis selected, the communicating endpoint node 202 will also need to include in the request an indicator as to which out of the two endpoint nodes 202a(^^ ^^ ^^)^and 202b(^^ ^^ ^^)^is the “Side 1” and which the “Side 2” participant.

[0163] In some examples, the identity of the one endpoint node 202 out of the two endpoint nodes 202a ( ^^ ^^ ^^)^and 202b ( ^^ ^^ ^^)^sending the shared-randomness request may be used to059645.00198 determine which out of the endpoint nodes 202a(^^ ^^ ^^)^and 202b(^^ ^^ ^^)^is the primary and which the secondary randomness sharer and / or which of the two endpoint nodes 202a ( ^^ ^^ ^^)^and 202b(^^ ^^ ^^)^is the “Side 1” and which the “Side 2” participant. For example, the endpoint node sending the shared-randomness request may be identified as the primary randomness sharer and the other endpoint node identified as the secondary randomness sharer, or alternatively, the endpoint node sending the shared-randomness is identified as the secondary randomness sharer and the other endpoint node is identified as the primary randomness sharer. Similarly, in examples where the Trustless Asymmetric subvariant ^^ଷis selected, the endpoint node sending the shared-randomness request may be identified as the Side 1 participant and the other endpoint node identified as the Side 2 participant, or alternatively, the endpoint node sending the shared-randomness is identified as the Side 2 participant and the other endpoint node is identified as the Side 1 participant. In such examples, the shared-randomness request will not need to include any identifier which the endpoint nodes 202a ( ^^ ^^ ^^)^and 202b ( ^^ ^^ ^^)^is the primary and which the secondary randomness sharer, or which of the two endpoint nodes 202a ( ^^ ^^ ^^)^and 202b ( ^^ ^^ ^^)^is the “Side 1” and which the “Side 2” participant.

[0164] The illustrated embodiments allow the endpoint nodes 202a and 202b to select any of the three protocol subvariants. However, this is not essential, and in some examples the method may only allow two, or only one, of the protocol subvariants to be used. In examples where only one protocol subvariant can be used it is not necessary for the endpoint nodes 202a and 202b to select a protocol subvariant, or for the shared-randomness request to identify a selected protocol subvariant. In general, the choice of which protocol subvariant to use involves a trade-off between three different aspects / features of the protocol: (1) Efficiency - i.e. the number of entropy bits that are used up to generate a given amount of shared randomness; (2) the need for trust - i.e. whether or not the hub node can gain knowledge of the endpoint nodes’ shared entropy and hence needs to be trusted by them; and (3) whether or not the endpoint nodes are treated equally -i.e. whether or not one of them has to use more of its stored entropy than the other in generating shared randomness between them. The Trusted subvariant is the most efficient, and treats the endpoint nodes equally, but requires the endpoint nodes to trust the hub node. The Trustless Symmetric subvariant doesn't require the endpoint nodes to trust the hub node, and treats the endpoint nodes equally, but is the least efficient of the three subvariants. The Trustless Asymmetric subvariant doesn't require the endpoint nodes to trust the hub node, and has an efficiency in between the efficiencies of the Trusted and Trustless Asymmetric subvariants, but it doesn't treat the endpoint nodes equally. The decision which protocol subvariant to use may be made by an operator / provider of the method deciding which subvariants are available for the endpoint nodes 202a and 202b to select, and / or by the endpoint nodes 202a and 202b deciding between available subvariants.

[0165] The illustrated embodiments allow the number of bits of shared randomness to be generated to be agreed between the two endpoint nodes 202a ( ^^ ^^ ^^)^and 202b ( ^^ ^^ ^^)^. In other examples, the number of bits of shared randomness to be generated may be predetermined, for example by being a fixed value. In such examples it is not necessary for the two endpoint nodes 202a059645.00198(^^ ^^ ^^)^and 202b(^^ ^^ ^^)^to agree the number of bits ^^^^of shared randomness they wish to generate, or for the request to comprise the value of the number of bits ^^^^of shared randomness to be generated.

[0166] After receiving the shared-randomness request, in a check entropy block 506, the QCH node 202c checks to see if there is sufficient unused entropy, that is, entropy that has been previously delivered to the two endpoint nodes 202a(^^ ^^ ^^)^and 202b(^^ ^^ ^^)^, which has not been used up in previous instances of the method to fulfil the request. The QCH node 202c checks this by checking whether the amount of unused bits in [ ^^ு]^and [ ^^ு]^(that is, the [ ^^ு]^stored at the QCH node 202c for each of the endpoint nodes 202a ( ^^ ^^ ^^)^and 202b ( ^^ ^^ ^^)^) is sufficient to fulfil the request.

[0167] If QCH node 202c finds that there is sufficient entropy available to fulfil the request, the QCH node 202c proceeds to carry out the main part of the second stage of the method using the requested option, as will be discussed below. Alternatively, if the QCH node 202c finds that there is insufficient entropy available, in a message block 508, it sends a message to the endpoint node 202 that submitted the request, asking it to resubmit the request with a reduced value for ^^^^, the QCH node 202c also specifies in this message the maximum value for ^^^^that can be accommodated by the available entropy.

[0168] During the randomness generation process of the main part of the second stage of the method some of the entropy previously delivered stored at the endpoint nodes 202a(^^ ^^ ^^)^and 202b ( ^^ ^^ ^^)^in the first stage of the method and corresponding to the rows within [ ^^ு]^, [ ^^ு]^, [ ^^^], and[^^^]will be used. These rows will then be tagged as “used” and will not be available for use in subsequent instances of the second stage of the method. The amount of row usage will depend on the subvariant of the second stage selected, as follows:

[0169] In a case 1, where the Trusted subvariant has been selected, where ^^^= ^^^, QCH node 202c will use ൫(2 ∗ ^^^^) + ^^( ^^^^)൯ rows from [ ^^ு]^and ൫(2 ∗ ^^^^) + ^^( ^^^^)൯ rows from [ ^^ு]^, endpoint node 202a(^^ ^^ ^^)^will use ൫(2 ∗ ^^^^)+ ^^(^^^^)൯ rows from[^^^]and endpoint node 202b ( ^^ ^^ ^^)^will use ൫(2 ∗ ^^^^) + ^^( ^^^^)൯ rows from [ ^^^].

[0170] ^^(^^)is a buffer function and is calculated as ^^(^^)= ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^) , where ^^ is the expected amount of generated shared randomness, expressed in bits and the ceiling function simply rounds up to the nearest integer. (Setting the buffer at this level equates to 6 standard deviations from the mean ^^, meaning that the probability that insufficient shared randomness will be generated is less than 10ିଽ.) Alternative buffer functions may be used in other examples, depending on the requirements of specific implementations.

[0171] The buffer function ^^( ^^) is included because the exact amount of shared randomness generated cannot be guaranteed; because of the statistical nature of the process, there will be a small059645.00198 variation around a central expected value. This means that, if the buffer were not included, then in some instances of the protocol the amount of shared randomness generated by the endpoint nodes 202a and 202b would be slightly more than the amount requested, and in some instances slightly less. By including the buffer, we can ensure that the endpoints generate, in almost all instances of the protocol, at least the requested amount of randomness.

[0172] In a case 2, where the Trustless Symmetric subvariant has been selected, where ^^^= ^^ଶ, QCH node 202c will use൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯rows from [ ^^ு]^and൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯rows from[^^ு]^, endpoint node 202a(^^ ^^ ^^)^will use ൫(4 ∗ ^^^^)+ ^^(2 ∗ ^^^^)൯ rows from[^^^]and endpoint node 202b ( ^^ ^^ ^^)^will use ൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯ rows from [ ^^^].

[0173] In a casehas been selected, where ^^^= ^^ଷ, QCH node 202c will use ൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯ rows from [ ^^ு]ௌ^and ൫(2 ∗ ^^^^) + ^^( ^^^^)൯ rows from [ ^^ு]ௌଶ, where S1 and S2 denote which out of endpoint node 202a ( ^^ ^^ ^^)^and endpoint node 202b ( ^^ ^^ ^^)^has been designated the Side 1 and which the Side 2 participant. ( ^^ ^^ ^^)ௌ^will use ൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯ rows from [ ^^ௌ^] and ( ^^ ^^ ^^)ௌଶwill use ൫(2 ∗ ^^^^) + ^^( ^^^^)൯ rows from [ ^^ௌଶ]. It will be noted that the Side 1 and Side 2 participants use different amounts of stored entropy. Accordingly, in some examples, when the Trustless Asymmetric subvariant is selected, the decision which of the endpoint nodes 202a and 202b is designated as the Side 1 participant and the Side 2 participants may take into account the respective amounts of stored entropy available to the respective endpoint nodes 202a and 202b.

[0174] As is explained above, if QCH node 202c finds that there is sufficient entropy available to fulfil the request in the check entropy block 506, the system 200 proceeds to the main part of the second stage of the method, for the requested subvariant.

[0175] Figure 6 is a schematic diagram of a main part of the second stage of the first method in a case 1, where the Trusted subvariant has been selected, where ^^^= ^^^. Figure 7 is a corresponding flowchart of the main part of the second stage 700 of the first method in the case 1, where the Trusted subvariant has been selected.

[0176] In a first check entropy stores block 702, the QCH node 202c, the first endpoint node 202a(^^ ^^ ^^)^, and the second endpoint node 202b(^^ ^^ ^^)^refer to their respective stored entropy matrices [ ^^ு]^, [ ^^ு]^, [ ^^^], and [ ^^^], and each identify the next block of unused rows – i.e. those that have not already been tagged as “used” – in these stores. Each block should be of the appropriate size as set out above for the requested value of ^^^^, for this Trusted subvariant, QCH node 202c will require a block of൫(2 ∗ ^^^^) + ^^( ^^^^)൯rows from [ ^^ு]^and a block of൫(2 ∗ ^^^^) + ^^( ^^^^)൯rows from[^^ு]^, endpoint node 202a(^^ ^^ ^^)^will require a block of ൫(2 ∗ ^^^^)+ ^^(^^^^)൯ rows from[^^^]and endpoint node 202b(^^ ^^ ^^)^will require a block of ൫(2 ∗ ^^^^)+ ^^(^^^^)൯ rows from[^^^]. These blocks059645.00198 from matrices[^^ு]^,[^^ு]^,[^^^], and[^^^], are then copied by the respective nodes 202a-202c and stored as ^^ ^^ு]^, [ ^^ ^^ு]^, [ ^^ ^^^], and [ ^^ ^^^] respectively.

[0177] Then, in a send copies block 704, QCH node 202c sends a copy of the first column of [ ^^ ^^ு]^to first endpoint node 202a ( ^^ ^^ ^^)^. This column contains B-bits, that is, bits of the first (B-Bit) bit string, and we refer to the column as[^^ு]^. Further, QCH node 202c sends a copy of the first column of [ ^^ ^^ு]^to second endpoint node 202b ( ^^ ^^ ^^)^. This column contains B-bits, that is, bits of the first (B-bit) bit string, and we refer to the column as [ ^^ு]^. Further, first endpoint node 202a ( ^^ ^^ ^^)^sends a copy of the first column of [ ^^ ^^^] to 202c. This column contains B-bits, that is, bits of the first (B-bit) bit string, and we refer to theas [ ^^^]. Finally, second endpoint node 202a ( ^^ ^^ ^^)^sends a copy of the first column of [ ^^ ^^^] to QCH. This column contains B-bits, that is, bits of the first (B-bit) bit string, and we refer to the column as [ ^^^].

[0178] Then, in a comparison block 706, QCH node 202c and the first endpoint node 202a ( ^^ ^^ ^^)^both compare each entry in [ ^^ு]^with the entry at the corresponding position in [ ^^^], and determine whether each pair of entries are the same or different. In examples where the first alternative was used, the QCH node 202c and the first endpoint node 202a(^^ ^^ ^^)^record the position numbers for which the entries are the same. QCH node 202c then refers to these position numbers within the second column of [ ^^ ^^ு]^, and places the second-column entries, that is, the values of the second (M-bit) bit string, for these positions in a new vector [ ^^ு^]. First endpoint node 202a(^^ ^^ ^^)^likewise refers to these position numbers within the of ^^ ^^^, and places[ ]the second-column entries, that is, the values of the second (M-bit) bit for these positions in a new vector [ ^^^ு]. Alternatively, in examples where the second alternative was used, the QCH node 202c and endpoint node 202a ( ^^ ^^ ^^)^record the position numbers for which the entries are different. node 202c then refers to these position numbers within the second column of[^^ ^^ு]^, and places the second-column entries, that is, the values of the second (M-bit) bit string, for these positions in a new vector [ ^^ு^]. First endpoint node 202a ( ^^ ^^ ^^)^likewise refers to these position numbers within the column of ^^ ^^^, and places the second-column entries, that is, the values of the second (M-[ ]string, for these positions in a new vector [ ^^^ு]. In both alternatives, if the method has been carried out correctly, then[^^ு^]=[

[0179] Further, in the comparison block 706, QCHthe second endpoint node 202b(^^ ^^ ^^)^each compare each entry in[^^ு]^with the entry at the corresponding position in[^^^], and determine whether each pair of entries are the same or different. In examples where the first alternative was used, the QCH node 202c and the second endpoint node 202b ( ^^ ^^ ^^)^each record the position numbers for which the entries are the same. QCH node 202c then refers to these position numbers within the second column of [ ^^ ^^ு]^, and places the second-column entries, that is, the values of the second (M-bit) bit string, for these positions in a new vector[^^ு^]. Second endpoint node 202b ( ^^ ^^ ^^)^likewise refers to these position numbers within the second column of [ ^^ ^^^], and places the second-column entries, that is, the values of the second (M-bit) bit string, for these positions in a new vector [ ^^^ு]. In examples where the second alternative was used, the QCH node059645.00198 202c and the second endpoint node 202b(^^ ^^ ^^)^each record the position numbers for which the entries are different. QCH node 202c then refers to these position numbers within the second column of [ ^^ ^^ு]^, and places the second-column entries, that is, the values of the second (M-bit) bit string, for these positions in a new vector [ ^^ு^]. Second endpoint node 202b ( ^^ ^^ ^^)^likewise refers to these position numbers within the column of [ ^^ ^^^], and places the second-column entries, that is, the values of the second (M-string, for these positions in a new vector [ ^^^ு]. In both alternatives, if the method has been carried out correctly, then [ ^^ு^] = [ ^^^ு].

[0180] Then, in a truncation block 708, QCH node 202c compares the lengths of [ ^^ு^] and [ ^^ு^]. If ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^]) > ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^]), QCH node 202c truncates [ ^^ு^], removing the ( ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^]) − ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^])) entries in [ ^^ு^], and then sends a truncation messageendpoint node 202b ( ^^ ^^ ^^)^instructing it to remove the last ( ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^]) − ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^])) entries in [ ^^^ு]. Alternatively, if ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^]) > ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^]), QCH node 202c truncates [ ^^ு^], removing the last ( ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^]) − ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^])) entries in [ ^^ு^], and then sends a to the first endpoint node 202a ( ^^ ^^ ^^)^instructing it to remove the last ( ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^]) −^^ℎ([ ^^ு^])) entries in [ ^^^ு]. Alternatively, if ^^ ^^ ^^ ^^ ^^ℎ([ ^^ு^]) =^^ℎ([ ^^ு^]), no truncation is carried out.

[0181] Then, in a derive column vector block 710, QCH node 202c derives a new column vector [ ^^^^], given by [ ^^^^] = ^^ ^^ ^^([ ^^ு^], [ ^^ு^]), where [ ^^ு^] and [ ^^ு^] now refer to the versions following any truncation

[0182] Then, in a send column vector block 712, QCH node 202c sends [ ^^^^] to whichever out of endpoint node 202a(^^ ^^ ^^)^and endpoint node 202b(^^ ^^ ^^)^has been assigned to be the secondary randomness sharer. One of the endpoint nodes 202a ( ^^ ^^ ^^)^and 202b ( ^^ ^^ ^^)^is assigned to be the primary randomness sharer, and the other is assigned to be the secondary randomness sharer. In this example, it is assumed that the first endpoint node 202a is assigned to be the primary randomness sharer and the second endpoint node 202b is assigned to be the secondary randomness sharer, but in other examples this could be reversed.

[0183] The secondary randomness sharer, in this example the second endpoint node 202b, derives a new column vector [ ^^ௌ^], given by [ ^^ௌ^] = ^^ ^^ ^^([ ^^^^], [ ^^ௌு]), where [ ^^ௌு] = [ ^^^ு]. In the general case, [ ^^ௌு] = [ ^^^ு] if the first endpoint node 202a ( ^^ ^^ ^^)^is the randomness sharer, or [ the second endpoint node 202b ( ^^ ^^ ^^)^ is the randomness sharer.[to the versions following any truncation in the truncation block 708. If the protocol has been carried out correctly, then [ ^^ௌ^] = [ ^^^ு]. In this example, where the first endpoint node 202a ( ^^ ^^ ^^)^is assigned to be the primary sharer [ ^^^ு] = [ ^^ ]. In the ge [ ] [ ] (^ுneral case, ^^^ு= ^^^ுif the first endpoint node 202a^is the primary if the second endpoint node 202b ( ^^ ^^ ^^)^is the primaryto the versions following any truncation in the truncation block 708.059645.00198

[0185] The first endpoint node 202a(^^ ^^ ^^)^and the second endpoint node 202b(^^ ^^ ^^)^will now be in possession of an amount of shared randomness represented by the column vector [ ^^^^], where[^^^^]=[^^ௌ^]=[^^^ு]. As is explained above,[^^^ு]is at the primary randomness this secondary randomness sharer (in.

[0186] Then, in a storage block 714, the first endpoint node 202a ( ^^ ^^ ^^)^and the second endpoint node 202b ( ^^ ^^ ^^)^store their identical copies of [ ^^^^] in their respective HSMs as their shared randomness resource. This stored shared randomness is then available for use as encryption precursor material providing a basis for the generation ofmaterials, for example, encryption keys or one-time pad generation, for use for secure encrypted communications between the first endpoint node 202a and the second endpoint node 202b.

[0187] Figure 8 is a schematic diagram of a main part of the second stage of the first method in a case 2, where the Trustless Symmetric subvariant has been selected, where ^^^= ^^ଶ. Figure 9 is a corresponding flowchart of the main part of the second stage 900 of the first method in the case 2, where the Trustless Symmetric subvariant has been selected.

[0188] In a first check entropy stores block 902, the QCH node 202c, the first endpoint node 202a ( ^^ ^^ ^^)^, and the second endpoint node 202b ( ^^ ^^ ^^)^refer to their respective stored entropy matrices [ ^^ு]^, [ ^^ு]^, [ ^^^], and [ ^^^], and each identify the next block of unused rows – i.e. those that have not tagged as “used” – in these stores. Each block should be of the appropriate size as setfor the requested value of ^^^^, for this Trustless Symmetric subvariant, QCH node 202c will require a block of ൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯ rows from [ ^^ு]^and a block of ൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯ rows from [ ^^ு]^, endpoint node 202a ( ^^ ^^ ^^)^will require a block of ൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯rows from [ ^^^] and endpoint node 202b ( ^^ ^^ ^^)^will require a block of ൫(4 ∗ ^^^^)+ ^^(2 ∗ ^^^^)൯ rows from[^^^]. These blocks from matrices[^^ு]^,[^^ு]^,[^^^], and[^^^], are then copied by the respective nodes 202a-202c and stored as new ^^ ^^ு]^, [ ^^ ^^ு]^, [ ^^ ^^^], and[ ^^ ^^^]respectively.

[0189] Then, in a send copies block 904, QCH node 202c sends a copy of the first column of [ ^^ ^^ு]^to first endpoint node 202a(^^ ^^ ^^)^. This column contains B-bits, that is, bits of the first bit string, and we refer to the column as [ ^^ு]^. Further, QCH node 202c sends a copy of the first column of[^^ ^^ு]^to second endpoint node 202b(^^ ^^ ^^)^. This column contains B-bits, that is, bits of the first (B-bit) bit string, and we refer to the column as [ ^^ு]^.

[0190] Then, in a first deriveblock 906, QCH node 202c derives a new column vector [ ^^^^], given by the XOR of the second column, that is, bits of the second (M-bit) bit string, of[^^ ^^ு]^with the second column, that is, bits of the second (M-bit) bit string, of[^^ ^^ு]^.059645.00198

[0191] Then, in a send column vector block 908, QCH node 202c sends[^^^^]to whichever out of the first endpoint node 202a ( ^^ ^^ ^^)^and the second endpoint node 202b ( ^^ ^^ ^^)^has been designated as the secondary randomness sharer. In this example, it is assumed that the first endpoint node 202a is assigned to be the primary randomness sharer and the second endpoint node 202b is assigned to be the secondary randomness sharer, but in other examples this could be reversed.

[0192] Then, in a second derive column vector block 910, the secondary randomness sharer, in this example the second endpoint node 202b ( ^^ ^^ ^^)^, derives a new column vector, given by the XOR of [ ^^^^] with the second column, that is, bits of the second (M-bit) bit string, of the block of [ ^^ ^^^]. In the general case, the new column vector is derived from [ ^^ ^^^] if the first endpoint node 202a ( ^^ ^^ ^^)^is the secondary randomness sharer, and is derived from [ ^^ ^^^] if the second endpoint node 202b ( ^^ ^^ ^^)^is the secondary randomness sharer. We refer to this new column vector as [ ^^ௌ].

[0193] Then, in a third derive column vector block 912, the primary randomness sharer, in this example the first endpoint node 202a ( ^^ ^^ ^^)^, identifies the second column, that is, bits of the second (M-bit) string, of[^^ ^^^]. In the general case, if the primary randomness sharer is first endpoint node 202a ( ^^ ^^ ^^)^, it identifies the second column of [ ^^ ^^^], or if the primary randomness sharer is second endpoint node 202b(^^ ^^ ^^)^, it identifies the second column of[^^ ^^^]. This column vector is referred to as [ ^^^].

[0194] Then, in a fourth derive column vector block 914, the first endpoint node 202a ( ^^ ^^ ^^)^XORs each entry in [ ^^ு]^with the entry at the corresponding position in the first column of[^^ ^^^], to derive a new column vector[^^^]. Further, the second endpoint node 202b(^^ ^^ ^^)^XORs each entry in [ ^^ு]^with the entry at the corresponding position in the first column of [ ^^ ^^^], to derive a new column vector [ ^^^].

[0195] Then, in a comparing step 916,(^^ ^^ ^^)^and(^^ ^^ ^^)^communicate with each other via an authenticated AES-256 tunnel they share and identify the positions within [ ^^^] and [ ^^^] for which both entries are 0. The primary randomness sharer, in this example the first endpoint node 202a( ^^ ^^ ^^)^, refers to those positions, identified in the previous step, within [ ^^^], and assigns the entries at these positions to a new vector which we call [ ^^^ௌ]. The secondary randomness sharer, in this example the second endpoint node 202b ( ^^ ^^ ^^)^, refers to those positions, identified in the previous step, within [ ^^ௌ], and assigns the entries at these positions to a new vector which we call [ ^^ௌ^]. If the method has been carried out correctly [ ^^^ௌ] = [ ^^ௌ^].

[0196] The first endpoint node 202a ( ^^ ^^ ^^)^and the second endpoint node 202b ( ^^ ^^ ^^)^will now be in possession of an amount of shared randomness represented by the column vector [ ^^^^], where [ ^^^^] = [ ^^^ௌ] = [ ^^ௌ^]. As is explained above, [ ^^^ௌ] is at the primary randomness sharer this first endpoint node 202a), and [ ^^ௌ^] is at the secondary randomness sharer (insecond endpoint node 202b).059645.00198

[0197] Then, in a storage block 918, the first endpoint node 202a(^^ ^^ ^^)^and the second endpoint node 202b ( ^^ ^^ ^^)^store their identical copies of [ ^^^^] in their respective HSMs as their shared-randomness resource. This stored shared is then available for use as encryption precursor material providing a basis for the generation of materials, for example, encryption keys or one-time pad generation, for use for secure encrypted communications between the first endpoint node 202a and the second endpoint node 202b.

[0198] Figure 10 is a schematic diagram of a main part of the second stage of the first method in a case 3, where the Trustless Asymmetric subvariant has been selected, where ^^^= ^^ଷ. Figure 11 is a corresponding flowchart of the main part of the second stage 1100 of the first method in the case 3, where the Trustless Asymmetric subvariant has been selected.

[0199] In a first check entropy stores block 1102, the QCH node 202c, the first endpoint node 202a(^^ ^^ ^^)^, and the second endpoint node 202b(^^ ^^ ^^)^refer to their respective stored entropy matrices [ ^^ு]^, [ ^^ு]^, [ ^^^], and [ ^^^], and each identify the next block of unused rows – i.e. those that have not already been tagged as “used” – in these stores. Each block should be of the appropriate size as set out above for the requested value of ^^^^, for this Trustless Asymmetric subvariant, QCH node 202c will require a block of ൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯ rows from [ ^^ு]ௌ^and a block of൫(2 ∗ ^^^^) + ^^( ^^^^)൯rows from [ ^^ு]ௌଶ, where S1 and S2 denote which out of endpoint node 202a ( ^^ ^^ ^^)^and endpoint node 202b ( ^^ ^^ ^^)^has been designated the Side 1 participant and which the Side 2 participant. The endpoint node 202 designated as the side 1 participant will require a block of൫(4 ∗ ^^^^) + ^^(2 ∗ ^^^^)൯rows from [ ^^ௌ^] and the endpoint node 202 designated as the side 2 participant will require a block of ൫(2 ∗ ^^^^)+ ^^(^^^^)൯ rows from[^^ௌଶ]. These blocks from matrices [ ^^ு]^, [ ^^ு]^, [ ^^^], and [ ^^^], are then copied by the respective nodes 202a-202c and stored as new matrices[^^ ^^ு]^,[^^ ^^ு]^,[^^ ^^^], and[^^ ^^^]respectively.

[0200] One of the endpoint nodes 202a(^^ ^^ ^^)^and 202b(^^ ^^ ^^)^is assigned to be the Side 1 participant, and the other is assigned to be the Side 2 participant. In this example, the first endpoint node 202a ( ^^ ^^ ^^)^is designated the Side 1 participant and the second endpoint node 202b ( ^^ ^^ ^^)^is designated the Side 2 participant, but in other examples this could be reversed.

[0201] Then, in a first send copies block 1104, QCH node 202c sends a copy of the first column of [ ^^ ^^ு]ௌ^to the Side 1 participant ( ^^ ^^ ^^)ௌ^. This column contains B-bits, that is, the first (B- bit) bit string, and we refer to the column as [ ^^ு]ௌ^. Here S1 denotes which out of first endpoint node 202a ( ^^ ^^ ^^)^and second endpoint node 202b ( ^^ ^^ ^^)^has been designated the Side 1 participant (In this example, this is the first endpoint node 202a ( ^^ ^^ ^^)^, so that [ ^^ு]ௌ^is a copy of the first column of[^^ ^^ு]^and is sent to first endpoint node 202a(^^ ^^ ^^)^). Further, the Side 1 participant endpoint node 202 ( ^^ ^^ ^^)ௌ^(In this example, first endpoint node 202a) sends a copy of the first column, that is, the first (B-bit) bit string, of[^^ ^^ௌ^]to QCH. This column contains B-bits and we refer to the column as [ ^^ௌ^].059645.00198

[0202] Then, in a first compare block 1106, QCH node 202c and the Side 1 participant endpoint node 202 ( ^^ ^^ ^^)ௌ^(In this example, first endpoint node 202a) both compare each entry in [ ^^ு]ௌ^with the entry at the corresponding position in [ ^^ௌ^], and determine whether each pair of entries are the same or different. In examples where the first alternative was used, the QCH node 202c and the Side 1 participant endpoint node 202 ( ^^ ^^ ^^)^each record the position numbers for which the entries are the same. QCH node 202c then refers to these position numbers within the second column, that is, the second (M-bit) bit string, of [ ^^ ^^ு]ௌ^, and places the second-column entries for these positions in a new vector [ ^^ுௌ^]. The Side 1 participant endpoint node 202 ( ^^ ^^ ^^)ௌ^likewise refers to these position the second column, that is, the second (M-bit) bit string, of [ ^^ ^^ௌ^], and places the second-entries for these positions in a new vector [ ^^ௌ^ு]. Alternatively, in examples where the second alternative was used, the QCH node 202c and the Side 1 participant endpoint node 202 ( ^^ ^^ ^^) ea^ ch record the position numbers for which the different. QCH node 202c then refers to these position numbers within the second column, that is, the second (M-bit) bit string, of[^^ ^^ு]ௌ^, and places the second-column entries for these positions in a new vector[^^ுௌ^]. The Side 1 participant endpoint node 202 ( ^^ ^^ ^^)ௌ^likewise refers to these position numbers within the second column, that is, the second (M-bit) bit string, of[^^ ^^ௌ^], and places the second-columnfor these positions in a new vector [ ^^ௌ^ு]. In both alternatives, if the method has been carried out correctly,[^^ுௌ^]=[^^ௌ^ு].

[0203] a truncation block 1108, QCH node 202c compares the length of[^^ுௌ]with the length of (i.e. the number of rows in) [ ^^ ^^ு]ௌଶ. Here S2 denotes whichever out of firstnode 202a(^^ ^^ ^^)^and second endpoint node 202b(^^ ^^ ^^)^has been designated the participant (In this example, the second endpoint node 202b). If ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுௌ^]) > ^^ ^^ ^^ ^^ ^^ℎ([ ^^ ^^ு]ௌଶ), QCH node 202a truncates[^^ுௌ], removing the last ( ^^ ^^ ^^ ^^ ^^ℎ([^^ுௌ])− ^^ ^^ ^^ ^^ ^^ℎ([^^ ^^ு]ௌଶ)) entries in [ ^^ுௌ], and then sends a message to the endpoint node 202 ( ^^ ^^ ^^)ௌ^designated as the 1 participantit to remove the last ( ^^ ^^ ^^ ^^ ^^ℎ([^^ுௌ^])− ^^ ^^ ^^ ^^ ^^ℎ([^^ ^^ு]ௌଶ)) entries in . Alternatively, if ^^ ^^ ^^ ^^ ^^ℎ([ ^^ ^^ு]ௌଶ) > ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுௌ^]), the QCH node 202c truncates [ ^^ ^^ு]ௌଶ, the last ( ^^ ^^ ^^ ^^ ^^ℎ([ ^^ ^^ு]ௌଶ) − ^^ ^^ ^^ ^^ ^^ℎ( ^^ுௌ)) rows in [ ^^ ^^ு]ௌଶ, and then sends a to the endpoint node 202 ( ^^ ^^ ^^) designated as the Side 2 participanௌଶt to remove the last ( ^^ ^^ ^^ ^^ ^^ℎ([ ^^ ^^ு]ௌଶ) − ^^ ^^ ^^ ^^ ^^ℎ( ^^ுௌ^)) rows in [ ^^ ^^ௌଶ]. Alternatively, if ^^ ^^ ^^ ^^ ^^ℎ([ ^^ ^^ு]ௌଶ) = ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுௌ]), no truncation is carried out.

[0204] Then, in a second send copies block 1110, QCH node 202c sends a copy of the first column of [ ^^ ^^ு]ௌଶto the endpoint node 202 designated the Side 2 participant ( ^^ ^^ ^^)ௌଶ(In this case, second endpoint node 202b ( ^^ ^^ ^^)^)). This column contains B-bits, that is, the first (B-bit) bit string, and we refer to the column as [ ^^ு]ௌଶ. Here S2 denotes which out of the first endpoint node 202a ( ^^ ^^ ^^)^and the second endpoint node 202b ( ^^ ^^ ^^)^has been designated the Side 2 participant.

[0205] Then, in a derive first column vector block 1112, QCH node 202c derives a new column vector [ ^^^ଶ], given by the XOR of [ ^^ுௌ^] with the second column, that is, the second (M-bit) bit string, of[^^ ^^ு]ௌଶ.059645.00198

[0206] Then, in a send vector block 1114, QCH node 202c sends[^^^ଶ]to whichever out of the two endpoint nodes 202 ( ^^ ^^ ^^)ௌ^and ( ^^ ^^ ^^)ௌଶhas been designated as the secondary randomness sharer. One of the endpoint nodes 202a(^^ ^^ ^^)^and 202b(^^ ^^ ^^)^is assigned to be the secondary randomness sharer, and the other is assigned to be the primary randomness sharer. In this example, it is assumed that the first endpoint node 202a is assigned to be the primary randomness sharer and the second endpoint node 202b is assigned to be the secondary randomness sharer, but in other examples this could be reversed. In this example, the secondary randomness sharer is the endpoint node 202 designated the Side 2 participant ( ^^ ^^ ^^)ௌଶ, the second endpoint node 202b(^^ ^^ ^^)^. However, it is not essential that the Side 2 participant is the secondary randomness sharer, and in other examples the Side 1 participant may be the secondary randomness sharer.

[0207] Then, in a derive second column vector block 1116, the secondary randomness sharer derives a new column vector. If the Side 1 participant endpoint node 202 ( ^^ ^^ ^^)ௌ^is the secondary randomness sharer, the Side 1 participant endpoint node 202 ( ^^ ^^ ^^)ௌ^derives a new column vector, given by the XOR of [ ^^^ଶ] with [ ^^ௌ^ு]. Alternatively, if the Side 2 participant endpoint node 202 ( ^^ ^^ ^^)ௌଶis the secondary the Side 2 participant endpoint node 202 ( ^^ ^^ ^^)ௌଶderives a new column vector, givenXOR of [ ^^^ଶ] with the second column, that is, the second (M-bit) bit string, of[^^ ^^ௌଶ]. In both cases we refer to the new column vector as[^^ௌ]. In this example, the second endpoint node 202b ( ^^ ^^ ^^)^is the Side 2 participant endpoint node 202(^^ ^^ ^^)ௌଶand the secondary randomness sharer.

[0208] Then, in a rename block 1118, whichever out of the two endpoint nodes 202 ( ^^ ^^ ^^)ௌ^and ( ^^ ^^ ^^)ௌଶhas been designated as the primary randomness sharer takes action. If the Side 1 participant endpoint node 202(^^ ^^ ^^)ௌ^is the primary randomness sharer, the Side 1 participant endpoint node 202 ( ^^ ^^ ^^)ௌ^renames [ ^^ௌ^ு] as [ ^^^]. Alternatively, if the Side 2 participant endpoint node 202(^^ ^^ ^^)ௌଶis the primary sharer, the Side 2 participant endpoint node 202 ( ^^ ^^ ^^)ௌଶrenames the secondis, the second (M-bit) bit string, of [ ^^ ^^ௌଶ] as [ ^^^].

[0209] Then, in a second compare block 1120, the Side 2 participant endpoint node 202 ( ^^ ^^ ^^)ௌଶcompares each entry in the first column, that is, the first (B-bit) bit string, of [ ^^ு]ௌଶwith the entry at the corresponding position in the first column, that is, the first (B-bit) bit string, of[^^ ^^ௌଶ]and determines whether each pair of entries are the same or different. In examples where the first alternative was used, the Side 2 participant endpoint node 202 ( ^^ ^^ ^^)ௌଶrecords the position numbers for which the entries are the same, and sends the Side 1 participant endpoint node 202 ( ^^ ^^ ^^)ௌ^these position numbers. In some examples, this could be achieved by the Side 2 participant calculating the XOR of the first column of[^^ு]ௌଶwith the first column of[^^ ^^ௌଶ], and sending the resulting vector to the Side 1 participant. The relevant position numbers would then be those positions in this vector that have a value equal to 0. Alternatively, in examples where the second alternative was used, the Side 2 participant endpoint node 202 ( ^^ ^^ ^^)ௌଶrecords the position numbers for which the entries are different, and sends the Side 1 participant endpoint node 202 ( ^^ ^^ ^^)ௌ^these position numbers. In some examples, this could be achieved by the Side 2 participant calculating the XOR of059645.00198 the first column of[^^ு]ௌଶwith the first column of[^^ ^^ௌଶ], and sending the resulting vector to the Side 1 participant. The relevant position numbers would then be those positions in this vector that have a value equal to 1.

[0210] Then, in a referring block 1122, whichever out of the two endpoint nodes 202 ( ^^ ^^ ^^)ௌ^and ( ^^ ^^ ^^)ௌଶhas been designated as the primary randomness sharer refers to those positions, identified in the second compare block 1120, within[^^^], and assigns the entries at these positions to a new vector which we call [ ^^^ௌ]. Further, whichever out of the two endpoint nodes 202(^^ ^^ ^^)ௌ^and(^^ ^^ ^^)ௌଶhas been designated as the secondary randomness sharer refers to those positions, identified in the previous step, within [ ^^ௌ], and assigns the entries at these positions to a new vector which we call[^^ௌ^]. If the method has been carried out correctly,[^^^ௌ]=[^^ௌ^].

[0211] The first endpoint node 202a(^^ ^^ ^^)^and the second endpoint node 202b(^^ ^^ ^^)^will now be in possession of an amount of shared randomness represented by the column vector [ ^^^^], where[^^^^]=[^^^ௌ]=[^^ௌ^]. As is explained above,[^^^ௌ]is at the primary randomness sharer (in this example the first endpoint node 202a), and [ ^^ௌ^] is at the secondary randomness sharer (in this example the second endpoint node 202b).

[0212] Then, in a storage block 1124, the first endpoint node 202a ( ^^ ^^ ^^)^and the second endpoint node 202b(^^ ^^ ^^)^store their identical copies of[^^^^]in their HSMs as their shared- randomness resource. This stored shared randomness is then available for use as encryption precursor material providing a basis for the generation of encryption materials, for example, encryption keys or one-time pad generation, for use for secure encrypted communications between the first endpoint node 202a and the second endpoint node 202b.

[0213] Throughout the method of the example described above, the communications between the different nodes 202 and 208 are protected by AES-256 tunnels within the Quantum Cloud perimeter 204a. In other examples, different communications security protocols may be used.

[0214] As is explained above, in each of the three subvariants, the two participating endpoint nodes 202a and 202b can generate shared randomness between them on-demand, at any time. The entropy stores of the endpoint nodes 202n are correlated in such a way that shared randomness can be generated between any pair of nodes 202n. However, the entropy store’s contents at each node 202n, considered in isolation, does not contain any information relating to the generated shared randomness, and so even if an entropy store at a node 202n were to be hacked, and its content accessed, the subsequently generated shared randomness would not be compromised. To access the shared randomness an adversary would need to hack multiple entropy stores in multiple nodes 202n as also have the facility to decrypt in real time the communications that are exchanged between a pair of nodes 202a and 202b during the generation of shared randomness.

[0215] In the example described above with reference to figures 3 to 11, the networked system is arranged according to the example of figure 2, with the QRNGs arranged into a QRNG059645.00198 bank. In alternative examples, some, or all, QRNGs may be comprised in the nodes, for example according to the example of figure 1. In such examples, nodes which comprise a QRNG may use this local QRNG, or they may request random bitstrings from a QRNG comprised in another node. If a node requested random bitstrings from a QRNG comprised in another node, the requesting node would have to trust the another node. However, making such a request may be desirable in some circumstances, for example if a QRNG comprised in the requesting node is not functioning correctly, or is unavailable, and the networked system does not comprise any QRNG bank.

[0216] The examples of the method described above generate shared randomness between two different locations / nodes. As is well understood in the field of cryptography, once shared randomness has been generated between different pairs of locations, it is straightforward to extend the process and use this shared randomness to enable more than two locations of the different pairs of locations share the same randomness. This can be extended indefinitely as required. There is no limit to the number of locations that can share the same randomness.

[0217] The first and second stages of the first method described above are asynchronous. The first stage may be carried out any required number of times before the second stage is carried out. It will be understood that the intermediate stage must be carried out before the second stage is carried out in order to determine whether the second stage can be carried out.

[0218] As is explained above, the designation of different nodes 202 as endpoint nodes and hub nodes is based on their current function, and each node 202 can operate as an endpoint node or a hub node at different times. In the illustrated embodiments, the endpoint nodes and hub nodes which cooperate to store entropy at the endpoint nodes in the first stage of the method must operate in the same roles in the second stage of the method in order to generate shared randomness based on the entropy stored in the first stage. However, this may not be the case in other examples.

[0219] The protocols for carrying out the disclosed method for sharing randomness within Quantum Cloud can be set up in a peer-to-peer framework in such a way that none of the Quantum Cloud nodes has a privileged status and all nodes have the same functionality. This may provide additional flexibility and resilience for the networked system.

[0220] The disclosed system and method use multiple QRNGs 206 within the Quantum Cloud perimeter, either distributed around the nodes as shown in figure 1, or located at a single dedicated QRNG bank node 208 as shown in figure 2. This allows several different brands and models of QRNG to be used simultaneously in the system. If any specific brand or model of QRNG is found to be deficient or inferior, QRNGs of this type can easily and quickly be replaced with a better functioning QRNG.

[0221] As is explained above, the different subvariants of the method allow different amounts of knowledge regarding the shared randomness generated between two nodes to be permitted to other nodes (in particular the hub node). Accordingly, the method can be varied by selection of059645.00198 appropriate subvariants to control whether or not any additional nodes are allowed to have knowledge of the shared randomness generated between two nodes. Without wishing to be bound by theory, in general there is a trade off between increasing security by minimising the knowledge of the shared randomness generated between two nodes available to other nodes and increasing the amount of stored entropy at the two nodes which must be used to generate an amount of shared randomness between the two nodes.

[0222] In a second, more complex, approach, the disclosed method can be expanded so that entropy loading to endpoints is carried out via intermediate nodes. Adding intermediate nodes will increase the complexity of the method. However, it may also increase the overall level of security. The use of intermediate nodes may increase security by allowing channel randomization and so making it more difficult for an adversary who is trying to track the transmission of entropy from hub node to endpoint node, as is discussed in more detail below.

[0223] In a first stage of this second method, an initial distribution of entropy is carried out in the same manner as in the first stage of the first method, as discussed above with reference to figures 3 and 4. However, in the second method it is intended to further transfer this entropy and load the entropy into further nodes. Accordingly, in the second method the endpoint nodes 202 ( ^^ ^^ ^^)^of the first method are instead referred to as intermediate nodes 202 ( ^^ ^^ ^^ ^^)^, to indicate their intermediate status in the second method, as opposed to their final endpoint status in the first method.

[0224] Figure 12 is a schematic diagram of a first stage of the second method of generating quantum-correlated entropy at two nodes at different locations according to an embodiment. This second method involves the distribution of quantum-correlated entropy via a single link to each of a plurality of intermediate nodes. This initial entropy loading to the intermediate nodes is illustrated in figure 12. The example of figure 12 shows the method as used in the second example of the networked system 200 according to figure 2, the method may also be used with other arrangements of the networked system.

[0225] As can be seen in figure 12, one of the nodes 202c (denoted QCH) takes on the role of the “hub” and is responsible for distributing the initial correlated entropy to a plurality of intermediate nodes QCIN 202m, where the quantum-correlated entropy is to be generated. Any of the nodes 202 can act as the hub node QCH 202c, and different ones of the nodes 202 will act as the hub node QCH 202c for different instances of generating. In the illustrated example of figure 12, all the QRNGs are situated in a single QRNG Bank 208.

[0226] The initial distribution of entropy to each of the plurality of intermediate nodes QCIN 202m in the first stage of the second method is carried out in the same manner as the first stage of the first method, as described above with reference to figures 3 and 4. This first stage may be carried out for any necessary number of instances, with any selected node 202 acting as the hub node 202c, and for any selected intermediate nodes 202m, as required to store a desired amount of entropy at059645.00198 any and each intermediate node 202m, and as required to replace entropy subsequently used to generate shared randomness.

[0227] Figure 13 is a schematic diagram of a second stage of the second method of generating quantum-correlated entropy at two nodes at different locations.

[0228] In brief, in the second stage of the second method, endpoint nodes QCEN 202n simply receive and store the entropy sent from the intermediate nodes QCIN 202m, the endpoint nodes QCIN 202n don’t themselves create any new QRNG-generated randomness. The intermediate nodes QCIN 202m delete entropy from their stores as soon as it has been sent to the endpoint nodes QCEN 202n, and they send a message to the hub node QCH 202c informing it of which bits have been sent and to which endpoint node QCEN 202n. The correlated bits at the hub node QCH 202c are then tagged identifying the relevant endpoint node QCEN 202n.

[0229] The expanded architecture of the second method introduces the potential for channel randomization, as there will be multiple possible links from the intermediate nodes QCIN 202m to the different endpoint nodes QCEN 202n.

[0230] Figure 14 shows a flow chart of the second stage of the second method for an intermediate node 202m to provide entropy to an endpoint node 202n. In order to carry out this second stage method 1400, the intermediate node 202m must have stored entropy stored in one or more previous instances of the first stage. The second stage of the second method may be carried out as convenient in any specific implementation. For example, the second stage may be carried out and the entropy sent on from an intermediate node 202m to a randomly selected endpoint node 202n immediately after the entropy is received by the intermediate node 202m, or after a predetermined time interval, or at random times, or according to some other algorithm. In some examples, an intermediate node 202m having stored entropy may be randomly selected to send entropy to a particular endpoint node 202n in response to that endpoint node 202n requesting entropy.

[0231] First, in a node selection block 1402, an intermediate node 202p ( ^^ ^^ ^^ ^^)^randomly selects an endpoint node 202q ( ^^ ^^ ^^ ^^)^to which it will be transmitting entropy from among the endpoint nodes 202 which have requested entropy. The random selection may be based on a random output of a QRNG provided in response to a call to the QRNG bank 208 by the intermediate node 202p. Alternatively, in systems where the intermediate node 202p comprises a QRNG, the random selection may be based on the random output of this QRNG. In an alternative arrangement, an endpoint node 202q ( ^^ ^^ ^^ ^^)^could instead request entropy from a randomly selected intermediate node 202p ( ^^ ^^ ^^ ^^)^. In this arrangement, random selection may be based on a random output of a QRNG provided in response to a call to the QRNG bank 208 by the endpoint node 202q. Alternatively, in systems where the endpoint node 202q comprises a QRNG, the random selection may be based on the random output of this QRNG.059645.00198

[0232] Then in a block selection block 1404, the intermediate node 202p(^^ ^^ ^^ ^^)^refers to its entropy store ^ ^^^൧ and identifies the first set of rows that have not been tagged as “used", and selects a block of these unused rows (which will include reference numbers for the rows in the block). This block is referred to as ^ ^^ ^^^൧. These unused rows must all have been transferred in the same instance of the first stage, or in different instances of the first stage having the same node 202 acting as the hub.

[0233] Then, in a sending block 1406, the intermediate node 202p ( ^^ ^^ ^^ ^^)^sends a copy of^^^ ^^^൧to the selected endpoint node 202q ( ^^ ^^ ^^ ^^)^and then immediately deletes it from^^^^൧.

[0234] Then, in a storing block 1408, the endpoint node 202q ( ^^ ^^ ^^ ^^)^copies ^ ^^ ^^^൧ into its entropy store^^^^൧.

[0235] Then, in a reporting block 1410, the intermediate node 202p ( ^^ ^^ ^^ ^^)^sends a message to a QCH hub node 202c informing it that ^ ^^ ^^^൧ has been sent to endpoint node 202q ( ^^ ^^ ^^ ^^)^, and giving the reference numbers within ^ ^^ ^^^൧. It will be understood that the QCH hub node 202c is the node 202 which acted as the hub in the instance of the first stage which loaded the block of unused rows making up ^ ^^ ^^^൧ into the intermediate block 202p ( ^^ ^^ ^^ ^^)^. The intermediate node 202p ( ^^ ^^ ^^ ^^)^also sends a certificate of deletion, referencing ^ ^^ ^^^൧, to QCH hub node 202c.

[0236] Then, in a recordal block 1412, QCH hub node 202c identifies the block within [ ^^ு]^that has the same reference numbers as ^ ^^ ^^^൧. We refer to this block as[^^ ^^ு]^. QCH hub node 202c copies [ ^^ ^^ு]^into [ ^^ு]^and then immediately deletes it from [ ^^ு]^.

[0237] The stored entropy at the endpoint node 202q can then be used in combination with the stored entropy at any other endpoint node 202n to generate shared randomness between these two endpoint nodes 202n and 202q on demand at any time, provided that the two endpoint nodes 202n / 202q have stored entropy ultimately distributed from the same node 202 acting as a hub node 202c in the first stage of the first or second method. This can be done regardless of whether the endpoint node 202n / 202q is an endpoint node 202n which has received the entropy directly from a hub node 202c using the first stage of the first method, or is an endpoint node 202q which has received entropy indirectly from a hub node 202c via an intermediate node 202p using the first stage and second stage of the second method. The entropy stores are correlated in such a way that shared randomness can be generated between any pair of endpoint node 202n and 202q locations.

[0238] The second stage of the second method described above with reference to figures 13 and 14 is a single instance of the distribution of stored entropy from a single intermediate node 202p to a single endpoint node 202q. This second stage may be carried out for any necessary number of instances, with any selected node 202 acting as the intermediate node 202p, and for any selected059645.00198 endpoint node 202q, as required to store a desired amount of entropy at any and each node 202, and as required to replace entropy subsequently used to generate shared randomness.

[0239] The second stage of the second method described above with reference to figures 13 and 14 randomly selects which intermediate nodes 202p provide entropy to which endpoint nodes 202q. This is not essential. However, this may be preferred in order to provide additional security, as is discussed below.

[0240] Thus, once entropy has been distributed from the intermediate node 202p to the endpoint node 202q, shared randomness can be generated between any two endpoint nodes 202n / 202q in a third stage of the second method.

[0241] The third stage of the second method is identical to the second stage of the first method at described above, except that one or both of the nodes(^^ ^^ ^^)^and(^^ ^^ ^^)^in the description of the first method are respectively replaced by the nodes ( ^^ ^^ ^^ ^^)^and ( ^^ ^^ ^^ ^^)^, signifying that these are endpoint nodes which may have obtained their stored entropy from an intermediate node, as opposed to directly from a hub node.

[0242] In the third stage of the second method, it may be preferred to generate shared randomness between endpoint nodes which have obtained their stored entropy from an intermediate node, and not directly from a hub node. This may provide security enhancement through randomization of channels. This method can offer the facility of randomizing the channels of communication between locations (i.e., between nodes), which adds an additional layer of security, as it will be impossible for an adversary to know in advance which channels will be used in the entropy loading and shared randomness generation processes for any particular nodes.

[0243] Further, the use of multiple nodes connected by randomized channels means that there is no single-point failure risk. Even if several nodes are compromised the remaining network of nodes can still function perfectly. This allows the network to be effectively self-healing, and means that there is no vulnerability to a denial-of-service attack.

[0244] In an initial part of the third stage of the second method, similarly to the initial part of the second stage of the first method described above, and as shown in figure 5, the endpoint nodes 202n / 202q agree the number of bits of shared randomness they wish to generate, the protocol subvariant to be used, which node is to be the primary, and which the secondary randomness sharer, and the identity of the hub node 202c to be used.

[0245] Figure 15 is a schematic diagram of a main part of the third stage of the second method in a case 1, where the Trusted subvariant has been selected. This corresponds to the main part of the second stage of the first method in the case 1, as shown in figure 6, except that the method is carried out between endpoint nodes 202q which have obtained their respective stored entropy from one or more intermediate nodes 202p.059645.00198

[0246] Figure 16 is a schematic diagram of a main part of the third stage of the second method in a case 2, where the Trustless Symmetric subvariant has been selected. This corresponds to the main part of the second stage of the first method in the case 2, as shown in figure 8, except that the method is carried out between endpoint nodes 202q which have obtained their respective stored entropy from one or more intermediate nodes 202p.

[0247] Figure 17 is a schematic diagram of a main part of the third stage of the second method in a case 3, where the Trustless Asymmetric subvariant has been selected. This corresponds to the main part of the second stage of the first method in the case 3, as shown in figure 10, except that the method is carried out between endpoint nodes 202q which have obtained their respective stored entropy from one or more intermediate nodes 202p.

[0248] Following the third stage of the second method, the resulting generated shared randomness, shared between the two endpoint nodes 202 may be used, for example, to generate cryptographic material, such as encryption keys, and one-time pads.

[0249] The stored entropy at an endpoint node 202q which has been distributed to the endpoint node 202q by the second method described above may be used as a standalone source of randomness for use by the endpoint node 202q, as an alternative to being used to generate shared randomness. Such standalone randomness may be used in various cryptographic and security applications by the endpoint node 202q. For example, in the event that the distribution of entropy to the different nodes 202 and the generation of shared randomness by the different nodes 202 results in an endpoint node 202 having surplus stored entropy which cannot be used to generate shared randomness, this surplus stored entropy may be used as standalone randomness.

[0250] In a third method of generating quantum-correlated entropy at two nodes at different locations, instead of just transferring the entropy directly from intermediate nodes to endpoint nodes, an alternative method is used in which entropy is generated at the endpoint nodes that is correlated with the entropy at the intermediate nodes, in the same way that the entropy at the intermediate nodes is correlated with the entropy at the hub. Generating new entropy at the endpoint nodes provides additional security as the stored entropy will then not be the same as the entropy that was transmitted from the intermediate nodes.

[0251] The first stage of the third method comprises the initial distribution of quantum- correlated entropy via a single link to each of a plurality of intermediate nodes. The initial distribution of entropy to each of the plurality of intermediate nodes in the first stage of the third method is carried out in the same manner as the first stage of the first method, as described above with reference to figures 3 and 4, but using the first alternative only. This first stage may be carried out for any necessary number of instances, with any selected node 202 acting as the hub node, and for any selected intermediate nodes, as required to store a desired amount of entropy at any and each intermediate node, and as required to replace entropy subsequently used to generate shared randomness.059645.00198

[0252] The second stage of the third method involves a similar randomization of channel links to that described for the second stage of the second method. However, unlike the second method, in the third method the endpoint nodes need to access the QRNG Bank, or any QRNGs comprised in the endpoint nodes, so that they can generate new entropy that is correlated with that received from the intermediate nodes, rather than simply using the entropy received from the intermediate nodes unchanged.

[0253] Figure 18 is a schematic diagram of a second stage of the third method of generating quantum-correlated entropy at two nodes at different locations. Figure 19 shows a flow chart of the second stage of the third method for an intermediate node 202s to provide entropy to an endpoint nodes 202t. In order to carry out this second stage method 1900, the intermediate node 202s must have stored entropy stored in one or more previous instances of the first stage. The second stage of the third method may be carried out as convenient in any specific implementation. For example, the second stage may be carried out and the entropy sent on from an intermediate node 202s to a randomly selected endpoint node 202t immediately after the entropy is received by the intermediate node 202s, or after a predetermined time interval, or at random times, or according to some other algorithm. In some examples, an intermediate node 202s having stored entropy may be randomly selected to send entropy to a particular endpoint node 202t in response to that endpoint node 202t requesting entropy.

[0254] First, in a node selection block 1902, an intermediate node 202s ( ^^ ^^ ^^ ^^)^randomly selects an endpoint node 202t(^^ ^^ ^^ ^^)௧to which it will be transmitting entropy. In an alternative arrangement, an endpoint node 202t ( ^^ ^^ ^^ ^^)௧could request entropy from a randomly selected intermediate node 202s(^^ ^^ ^^ ^^)^.

[0255] Then in a block selection block 1904, the intermediate node 202s ( ^^ ^^ ^^ ^^)^refers to its entropy store [ ^^^] and identifies the first set of rows that have not been tagged as “used", and selects a block of these unused rows (which will include reference numbers for the rows in the block). This block is referred to as[^^ ^^^]. These unused rows must all have been transferred in the same instance of the first stage, or in different instances of the first stage having the same node 202 acting as the hub.

[0256] Then, in a sending block 1906, the intermediate node 202s ( ^^ ^^ ^^ ^^)^sends a copy of[^^ ^^^]to the selected endpoint node 202t(^^ ^^ ^^ ^^)௧. The endpoint node 202t(^^ ^^ ^^ ^^)௧temporarily stores the received copy of [ ^^ ^^^], in its associated HSM.

[0257] Then, in a first messaging block 1908, the endpoint node 202t ( ^^ ^^ ^^ ^^)௧selects a random number z between 1 and R, using any local random number generator that it has access to. This random number generator does not need to be a QRNG. The endpoint node 202t(^^ ^^ ^^ ^^)௧then sends a message to QRNG Bank, requesting that ( ^^ ^^ ^^ ^^)௭be used to generate and send back two random bitstrings, each of length equal to the number of rows in[^^ ^^^].059645.00198

[0258] Then, in an obtain bitstring block 1910, the selected QRNG 206(^^ ^^ ^^ ^^)௭sends the requested two random bitstrings to the endpoint node 202t ( ^^ ^^ ^^ ^^)௧. The endpoint node 202t(^^ ^^ ^^ ^^)^then creates two column vectors from the two received bitstrings, which it labels as[^^]௧and [ ^^]௧; these represent B-bits of the first (B-bit) bitstring and M-bits of the second (M-bit) bitstring respectively.

[0259] Then, in a comparison block 1912, the endpoint node 202t ( ^^ ^^ ^^ ^^)௧sequentially compares each entry in [ ^^]௧, that is, the first (B-bit) bitstring, with the corresponding entry in the first column, that is, the first (B-bit) bitstring, of [ ^^ ^^^]. If the entries are equal, the endpoint node 202t ( ^^ ^^ ^^ ^^)௧resets the corresponding entry in [ ^^]௧, that is, the second (M-bit) bitstring, to have the same value as that in the second column, that is, the second (M-bit) bitstring, of [ ^^ ^^^], at the same row position as that of the B-bit being compared; if the entries differ, the endpoint node 202t ( ^^ ^^ ^^ ^^)௧instead leaves the corresponding entry in [ ^^]௧unchanged.

[0260] When this process has been completed for all the entries in [ ^^]௧, in a storing block 1914, the endpoint node 202t(^^ ^^ ^^ ^^)௧deletes[^^ ^^^]and sends a certificate to intermediate node 202s ( ^^ ^^ ^^ ^^)^confirming that this deletion has taken place. The endpoint node 202t ( ^^ ^^ ^^ ^^)௧concatenates [ ^^]௧with the [ ^^]௧prepared in the comparison block 1912, and stores the resulting new block of rows within its entropy store, [ ^^௧]. The endpoint node 202t ( ^^ ^^ ^^ ^^)௧also tags the rows of this block as being correlated with the matching rows in [ ^^ ^^^]. We refer to this tagged block as [ ^^ ^^௧]^, and the aggregation of all such blocks as [ ^^௧]^.

[0261] Then, in a first tagging block 1916, on receipt of the certificate of deletion from the endpoint node 202t ( ^^ ^^ ^^ ^^)௧, the intermediate node 202s ( ^^ ^^ ^^ ^^)^tags the rows of [ ^^ ^^^] (within [ ^^^]) as being correlated with the matching rows in [ ^^ ^^௧]. The intermediate node 202s ( ^^ ^^ ^^ ^^)^also tags these rows as having been certified deleted by the endpoint node 202t ( ^^ ^^ ^^ ^^)௧. We refer to this tagged block as [ ^^ ^^^]௧, and the aggregation of all such blocks as [ ^^^]௧.

[0262] Then, in a second messaging block 1918, the intermediate node 202s ( ^^ ^^ ^^ ^^)^sends a message to the hub node 202c QCH which previously distributed the entropy to the intermediate node 202s stating that[^^ ^^^]௧is now correlated with[^^ ^^௧]^.

[0263] Then, in a second tagging block 1920, the hub node 202c QCH adds an additional tag to the block within its entropy store that was previously tagged as being correlated to the intermediate node 202s ( ^^ ^^ ^^ ^^)^. The additional tag indicates that, as well as being directly correlated to [ ^^ ^^^]௧, the block is indirectly correlated to [ ^^ ^^௧]^. We refer to this re-tagged block as [ ^^ ^^ு]^௧, and the aggregation of all such blocks as [ ^^ு]^௧.

[0264] The secondthird method described above with reference to figures 18 and 19 is a single instance of the generation of stored entropy at a single endpoint node 202t based on stored entropy from an intermediate node 202s. This second stage may be carried out for any necessary number of instances, with any selected node 202 acting as the intermediate node 202s,059645.00198 and for any selected endpoint node 202t, as required to store a desired amount of entropy at any and each node 202, and as required to replace entropy subsequently used to generate shared randomness.

[0265] The stored entropy at the endpoint node 202t can then be used to generate shared randomness between any two endpoint nodes on demand at any time, provided that the two endpoint nodes have stored entropy ultimately distributed from the same node 202 acting as a hub node 202c in the first stage of the first to third methods. This can be done regardless of whether the endpoint node is an endpoint node 202n which has received the entropy directly from a hub node 202c using the first stage of the first method, or is an endpoint node 202q or 202t which has received entropy indirectly from a hub node 202c via an intermediate node 202p or 202s using the first stage and second stages of the second or third methods. The entropy stores are correlated in such a way that shared randomness can be generated between any pair of endpoint node locations.

[0266] The second stage of the third method described above with reference to figures 18 and 19 randomly selects which intermediate nodes 202s provide entropy to which endpoint nodes 202t. This is not essential. However, this may be preferred in order to provide additional security.

[0267] Thus, once entropy has been distributed from the intermediate node 202s to the endpoint node 202t, shared randomness can be generated between any two endpoint nodes 202t in a third stage of the third method. In order to create shared randomness in this third method, a pair of endpoint nodes will, in general need to communicate, for XOR operations and sifting, with the relevant intermediate nodes, as well as with the hub, in the final, third, stage of the process.

[0268] In a third stage of the third method, any pair of endpoint nodes 202t can derive shared randomness with each other from this stored entropy, via communication with each other, with the relevant intermediate nodes 202s, and with the QCH hub node 202c. As is explained above, any node 202 may act as a hub node 202c. However, the QCH hub node 202c in the third stage must be a node 202 which has acted as the QCH hub node 202c for one or more instances of the first stage of the third method which have distributed the stored entropy to the intermediate nodes 202s which in turn used this to generate the stored entropy at each of the pair of endpoint nodes 202t. However, it is not essential that the node 202 acted as the QCH hub node 202c to distribute the stored entropy to both of the pair of intermediate nodes 202s in the same instance of the first stage of the third method. In addition to the use of intermediate nodes increasing security by allowing channel randomization and so making it more difficult for an adversary who is trying to track the transmission of entropy from hub node to endpoint node, as is discussed above, in the third stage of the third method, by making the shared randomness generated at the endpoint nodes dependent on entropy stores at intermediate nodes as well as hub nodes, security may be further improved, because an adversary attempting to obtain prior knowledge of the shared randomness by hacking the entropy stores at different nodes would have to hack a greater number of entropy stores than would be the case if intermediate nodes were not used.059645.00198

[0269] Figure 20 shows a flow chart of an initial part of the third stage of the third method to generate shared randomness between two endpoint nodes 202t using the entropy stored in the two endpoint nodes 202t in the second stage. It will be understood that the first stage to third stages of the third method are asynchronous. Although the two endpoint nodes 202t must have stored entropy generated in the second stage in order to be able to carry out the subsequent third stage, there is no requirement for any specific time relationship between these stages.

[0270] The initial part of the third stage 2000 is carried out when a first endpoint node 202f and a second endpoint node 202g of the network 200 wish to generate shared randomness with each other. These first and second endpoint nodes 202f and 202g may be referred to as(^^ ^^ ^^)^and ( ^^ ^^ ^^)^respectively. As shown in figure 20, the initial part of the third stage 2000 begins with an agreement block 2002. In the agreement block 2002, the first and second endpoint nodes 202f ( ^^ ^^ ^^)^and 202g ( ^^ ^^ ^^)^communicate with each other, via an authenticated AES-256 tunnel they share, and agree on the number of bits ^^^^of shared randomness they wish to generate, the method subvariant ^^^they wish to use, and which out of first endpoint node 202f ( ^^ ^^ ^^ ^^)^and second endpoint node 202g ( ^^ ^^ ^^ ^^)^is the “primary” and which the “secondary” randomness sharer. Similarly to the first method described above, the method subvariant is selected from three possible options: ^^^is “Trusted”, ^^ଶis “Trustless Symmetric”, and ^^ଷis “Trustless Asymmetric”.

[0271] Then, in a request block 2004, one out of the first and second endpoint nodes 202f ( ^^ ^^ ^^ ^^)^and 202g ( ^^ ^^ ^^ ^^)^sends a shared-randomness request to hub node 202c QCH, consisting of the identities of first endpoint node 202f(^^ ^^ ^^ ^^)^and second endpoint node 202g(^^ ^^ ^^ ^^)^, the value of ^^^^, the selected ^^^, and which out of first endpoint node 202f ( ^^ ^^ ^^ ^^)^and second endpoint node 202g ( ^^ ^^ ^^ ^^)^is the primary and which the secondary randomness sharer. If subvariant ^^ଷis selected, the communicating node will also need to include in the request an indicator as to which out of the first endpoint node 202f ( ^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^is the “Side 1” and which the “Side 2” participant.

[0272] Then, in a check entropy block 2008, the hub node 202c QCH checks to see if there is sufficient unused entropy, that is, entropy that has been previously indirectly correlated with blocks in the entropy stores of the first and second endpoint nodes 202f ( ^^ ^^ ^^)^and 202g ( ^^ ^^ ^^)^, which has not been used up in previous instances of the method to fulfil the request. In general, the hub node 202c QCH will be able to find blocks within its entropy stores that have been indirectly correlated with blocks in a given endpoint node’s entropy store via different intermediate nodes. For example, with regard to the first endpoint node 202f ( ^^ ^^ ^^ ^^)^, hub node 202c QCH’s entropy store may contain the block [ ^^ ^^ு]ௗ^that has been indirectly correlated with the block ^ ^^ ^^^൧ௗwithin first endpoint node 202f ( ^^ ^^ ^^ ^^)^’s entropy store via the intermediate node 202d ( ^^ ^^ ^^ ^^)ௗ, as well as the block [ ^^ ^^ு]^^that has been indirectly correlated with the block ^ ^^ ^^^൧^within first endpoint node 202f(^^ ^^ ^^entropy store via the intermediate node 202e (^.059645.00198

[0273] In cases where there is more than one intermediate node correlating hub node 202c QCH’s entropy stores with those of first endpoint node 202f ( ^^ ^^ ^^ ^^)^^and / or second endpoint node 202g ( ^^ ^^ ^^ ^^)^, hub node 202c QCH chooses randomly between those intermediate nodes for which it has sufficient unused entropy in its entropy stores to fulfil the request. We label these intermediate nodes as first intermediate node 202i ( ^^ ^^ ^^ ^^)^and second intermediate node 202j ( ^^ ^^ ^^ ^^)^, where first intermediate node 202i ( ^^ ^^ ^^ ^^)^is the intermediate node via which hub node 202c QCH’s entropy is indirectly correlated with that of first endpoint node 202f ( ^^ ^^ ^^ ^^)^, and second intermediate node 202j ( ^^ ^^ ^^ ^^)^is the intermediate node via which hub node 202c QCH’s entropy is indirectly correlated with that of second endpoint node 202g ( ^^ ^^ ^^ ^^)^. In some alternative examples, where there is more than one intermediate node correlating hub node 202c QCH’s entropy stores with those of first endpoint node 202f(^^ ^^ ^^ ^^)^^and / or second endpoint node 202g(^^ ^^ ^^ ^^)^, hub node 202c QCH chooses in some deterministic manner between those intermediate nodes for which it has sufficient unused entropy in its entropy stores to fulfil the request, instead of randomly. This may be desirable in some circumstances, for example to ensure efficient use of the distributed entropy stored at the endpoint nodes, but may provide a reduced degree of security compared to random selection.

[0274] If hub node 202c QCH finds that there is sufficient entropy available to fulfil the request, in a first messaging block 2008, hub node 202c QCH sends a message to first endpoint node 202f ( ^^ ^^ ^^ ^^)^informing it that first intermediate node 202i ( ^^ ^^ ^^ ^^)^’s entropy store will be used, and sends a message to second endpoint node 202g(^^ ^^ ^^ ^^)^informing it that second intermediate node 202j ( ^^ ^^ ^^ ^^)^’s entropy store will be used, in fulfilling the request. The QCH node 202c proceeds to carry out the main part of the third stage of the third method using the requested option, as will be discussed below.

[0275] Alternatively, if the hub node 202c OCH finds that there is insufficient entropy available with respect to all of the intermediate nodes, in a second messaging block 2010, it sends a message to the endpoint node 202f or 202g that submitted the request, asking it to resubmit the request with a reduced value for ^^^^. The hub node 202c QCH also specifies in this message the maximum value for ^^^^that can be accommodated.

[0276] The number of rows required to fulfil the request is as follows:

[0277] In a case 1, where the Trusted subvariant has been selected, where ^^^= ^^^, hub node 202c QCH will use ^൫4 ∗ ^^^^൯ + ^^൫2 ∗ ^^^^൯^ rows from [ ^^ு]^^and ^൫4 ∗ ^^^^൯ + ^^൫2 ∗ ^^^^൯^ rows from [ ^^ு]^^, first intermediate node 202i^will use ^൫4 ∗ ^^^^൯+ ^^൫2 ∗ ^^^^൯^ rows^^^]^, second intermediate node 202j(^^ ^^ ^^ ^^)^will use ^൫4 ∗ ^^^^൯ + ^^൫2^ ^^^൧^, first endpoint node 202f ( ^^ ^^ ^^ ^^)^will use ^൫4 ∗ ^^^^൯ + ^^൫2 ∗ ^^^^൯^^ ^^^൧^, and second endpoint node 202g ( ^^ ^^ ^^ ^^)^will use ^൫4 ∗ ^^^^൯ + ^^൫2 ∗ ^^^^൯^ ^ ^^^൧^.059645.00198

[0278] In a case 2, where the Trustless Symmetric subvariant has been selected, where ^^^= ^^ଶ, hub node 202c QCH will use ^൫16 ∗ ^^^^൯ + ^^൫8 ∗ ^^^^൯^ rows from [ ^^ு]^^and ^൫16 ∗ ^^^^൯ + ^^൫8 ∗ ^^^^൯^ rows from[^^ு]^^, first intermediate(^^ ^^ ^^ ^^)^will use ^൫16 ∗ ^^^^൯ + ^^൫8 ∗ ^^^^൯^[ ^^^]^, second intermediate node 202j ( ^^ ^^ ^^ ^^)^will use ^൫16 ∗ ^^^^൯ + ^^൫8 ∗ ^^^^൯^^ ^^^൧^, first endpoint node 202f ( ^^ ^^ ^^ ^^)^will use^൫16 ∗ ^^^^൯+ ^^൫8 ∗ ^^^^൯^rowsand second endpoint node 202g(^^ ^^ ^^ ^^)^will use ^൫16 ∗ ^^^^൯ + ^^൫8 ∗ ^^^^൯^^ ^^^൧^.

[0279] In a case 3, where the Trustlesssubvariant has been selected, where ^^^= ^^ଷ, hub node 202c QCH will use^൫16 ∗ ^^^^൯+ ^^൫8 ∗ ^^^^൯^rows from [ ^^ு](^,^)ௌ^and denote whichever out of first and been designated the Side 1 and whichof the first and second intermediate nodes has entropy correlated with the indicated endpoint node. (For example, if Side 1 = f, then [ ^^ு](^,^)ௌ^= [ ^^ு]^^.) Intermediate node ( ^^ ^^ ^^ ^^)(^,^)ௌ^will use ^൫16 ∗ ^^^^൯+ ^^൫8 ∗ ^^^^൯^ rows from ^ ^^(^,^)൧ௌ^and intermediate node(^^ ^^ ^^ ^^)(^,^)ௌଶwill use ^൫4 ∗ ^^^^൯ +from ^ ^^(^,^)൧ௌଶ. Endpoint node ( ^^ ^^ ^^ ^^)ௌ^will use ^൫16 ∗ ^^^^൯ + ^^൫8 ∗ ^^^^൯^ rows from [ ^^ௌ^](^,^), and endpoint node ( ^^ ^^ ^^ ^^)ௌଶwill use^൫4 ∗ ^^^^൯+ ^^൫2 ∗ ^^^^൯^rows(^,^).

[0280] QCH node 202c finds that there is sufficient entropy available to fulfil the request in the check entropy block 2006, the system 200 proceeds to the main part of the third stage of the third method, for the requested subvariant.

[0281] Figure 21 is a schematic diagram of a main part of the third stage of the third method in a case 1, where the Trusted subvariant has been selected, where ^^^= ^^^. Figure 22 is a corresponding flowchart of the main part of the third stage 2200 of the third method in the case 1, where the Trusted subvariant has been selected.

[0282] Firstly, in a check entropy stores block 2202, hub node 202c QCH, first endpoint node 202f ( ^^ ^^ ^^ ^^)^, second endpoint node 202g ( ^^ ^^ ^^ ^^)^, first intermediate node 202i ( ^^ ^^ ^^ ^^)^and second intermediate node 202j(^^ ^^ ^^ ^^)^each refer to their respective entropy stores[^^ு]^^,[^^ு]^^, ^ ^^^൧^, ^ ^^^൧^, [ ^^^]^and ^ ^^^൧^, and identify the next blocks of unused rows – i.e. those that have not already been tagged as “used” – in these stores. Each block should be of the appropriate size for the requested value of ^^௫௬as set out above. These blocks are then copied by the respective participants and stored as new matrices [ ^^ ^^ு]^^, [ ^^ ^^ு]^^, ^ ^^ ^^^൧^, ^ ^^ ^^^൧^, [ ^^ ^^^]^and ^ ^^ ^^^൧^.059645.00198

[0283] Then, in a send copies block 2204, hub node 202c QCH sends a copy of the first column of [ ^^ ^^ு]^^to first endpoint node 202f ( ^^ ^^ ^^ ^^)^. This column contains B-bits, that is, the first (B-bit) bit and we refer to the column as [ ^^ு]^^. Further, hub node 202c QCH sends a copy of the first of [ ^^ ^^ு]^^to second 202g ( ^^ ^^ ^^ ^^)^. This column contains B-bits, thatis the first (B-bit) bit string, and we refer to as [ ^^ு]^^. Further, first endpoint node 202f ( ^^ ^^ ^^ ^^)^sends a copy of the first column of ^ ^^ ^^^൧^to hub node 202c QCH. This column contains B- bits, that is, the first (B-bit) bit string, and we refer to the column as ^ ^^^൧^. Further, second endpoint node 202g ( ^^ ^^ ^^ ^^)^sends a copy of the first column of ^ ^^ ^^^൧^to hub node 202c QCH. This column contains B-bits, that is, the first (B-bit) bit string, and we refer to the column as ^ ^^^൧^. Further, first intermediate node 202i ( ^^ ^^ ^^ ^^)^sends a copy of the first column of [ ^^ ^^^]^to hub node 202c QCH and to first endpoint node 202f ( ^^ ^^ ^^ ^^)^. This column contains B-bits, that is, the first (B-bit) bit string, and we refer to the column as [ ^^^]^. Finally, second intermediate node 202j ( ^^ ^^ ^^ ^^)^sends a copy of the first column of ^ ^^ ^^^൧^to the hub node 202c QCH and to second endpoint node 202g ( ^^ ^^ ^^ ^^)^. This column contains B-bits, that is, the first (B-bit) bit string, and we refer to the column as ^ ^^^൧^.

[0284] Then, in a comparison block 2206, hub node 202c QCH and first endpoint node 202f ( ^^ ^^ ^^ ^^)^both compare each entry in [ ^^ு]^^with the entries at the corresponding positions in ^ ^^^൧^and [ ^^^]^. They each record the position numbers for which all three entries are the same. Hub node 202c QCH then refers to these position numbers within the second column of [ ^^ ^^ு]^^, that is, the second (M-bit) bit string, and places the second-column entries for these positions in a new vector [ ^^ுி]. The first endpoint node 202f ( ^^ ^^ ^^ ^^)^likewise refers to these position numbers within the second column of ^ ^^ ^^^൧^, that is, the second (M-bit) bit string, and places the second-column entries for these positions in a new vector [ ^^ிு]. If the method has been carried out correctly, [ ^^ுி] = [ ^^ிு].

[0285] Further, the hub node 202c QCH and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^each compare each entry in[^^ு]^^with the entries at the corresponding positions in ^ ^^^൧^and ^ ^^^൧^, and they each record the position numbers for which all three entries are the same. Hub node 202c QCH then refers to these position numbers within the second column of [ ^^ ^^ு]^^, that is, the second (M-bit) bit string, and places the second-column entries for these positions in a new vector [ ^^ுீ]. The second endpoint node 202g ( ^^ ^^ ^^ ^^)^likewise refers to these position numbers within the second column of ^ ^^ ^^^൧^, that is, the second (M-bit) bit string, and places the second-column entries for these positions in a new vector [ ^^ீு]. If the method has been carried out correctly, [ ^^ுீ] = [ ^^ீு].

[0286] Then, in a truncation block 2208, hub node 202c QCH compares the lengths of [ ^^ுி] and[^^ுீ]. If ^^ ^^ ^^ ^^ ^^ℎ([^^ுீ])> ^^ ^^ ^^ ^^ ^^ℎ([^^ுி]), hub node 202c QCH truncates[^^ுீ], removing the last ( ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுீ]) − ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுி])) entries in [ ^^ுீ], and then sends a message to the second endpoint node 202g(^^ ^^ ^^ ^^)^instructing it to remove the last ( ^^ ^^ ^^ ^^ ^^ℎ([^^ுீ])− ^^ ^^ ^^ ^^ ^^ℎ([^^ுி])) entries in[^^ீு].059645.00198 Alternatively, if ^^ ^^ ^^ ^^ ^^ℎ([^^ுி])> ^^ ^^ ^^ ^^ ^^ℎ([^^ுீ]), hub node 202c QCH truncates[^^ுி], removing the last ( ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுி]) − ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுீ])) entries in [ ^^ுி], and then sends a message to the first endpoint node 202f(^^ ^^ ^^ ^^)^instructing it to remove the last ( ^^ ^^ ^^ ^^ ^^ℎ([^^ுி])− ^^ ^^ ^^ ^^ ^^ℎ([^^ுீ])) entries in[^^ிு]. Alternatively, if ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுி]) = ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுீ]), no truncation is carried out.

[0287] Then, in a derive column vector block 2210, hub node 202c QCH derives a new column vector [ ^^ிீ], given by [ ^^ிீ] = ^^ ^^ ^^([ ^^ுி], [ ^^ுீ]), where [ ^^ுி] and [ ^^ுீ] now refer to the versions following any truncation in the truncation block 2208.

[0288] Then, in a send column vector block 2212, hub node 202c QCH sends [ ^^ிீ] to whichever out of the first and second endpoint nodes 202f ( ^^ ^^ ^^ ^^)^and 202g ( ^^ ^^ ^^ ^^)^has been designated as the secondary randomness sharer.

[0289] Then, in a derive new column vector block 2214, the endpoint node 202 designated as the secondary randomness sharer derives a new column vector [ ^^ௌி], given by [ ^^ௌி] = ^^ ^^ ^^([ ^^ிீ], [ ^^ௌு]), where [ ^^ௌு] = [ ^^ிு] or [ ^^ீு], according to whether first endpoint node 202f ^^ ^^ ^^^node 202g ( ^^ ^^ ^^ ^^)^is the secondary randomness sharer, and [ ^^ிு]following any truncation in the truncation block 2208.

[0290] If the method has been carried out correctly, then we will have [ ^^ௌி] = [ ^^^ு], where [ ^^^ு] = [ ^^ிு] or [ ^^ீு], according to whether the first endpoint node 202f ( ^^ ^^ ^^ ^^)^or the second endpoint node 202g ( ^^ ^^ ^^ ^^)^is the primary randomness sharer, and [ ^^ிு] and [ ^^ீு] refer to the versions following any truncation in the truncation block 2208.

[0291] The first endpoint node 202f ( ^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^will now be in possession of an amount of shared randomness represented by the column vector [ ^^ிீ], where [ ^^ிீ] = [ ^^ௌி] = [ ^^^ு]

[0292] Then, in a storage block the first endpoint node 202f ( ^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^now store [ ^^ிீ] in their respective associated HSMs as their shared- randomness resource. This stored shared randomness is then available for use as encryption precursor material providing a basis for the generation of encryption materials, for example, encryption keys or one-time pad generation, for use for secure encrypted communications between the first endpoint node 202f and the second endpoint node 202g.

[0293] Figure 23 is a schematic diagram of a main part of the third stage of the third method in a case 2, where the Trustless Symmetric subvariant has been selected, where ^^^= ^^ଶ. Figure 24 is a corresponding flowchart of the main part of the third stage 2400 of the third method in the case 2, where the Trustless Symmetric subvariant has been selected.

[0294] In a first check entropy stores block 2402, hub node 202c QCH, first endpoint node 202f ( ^^ ^^ ^^ ^^)^, second endpoint node 202g ( ^^ ^^ ^^ ^^)^, first intermediate node 202i ( ^^ ^^ ^^ ^^)^and059645.00198 second intermediate node 202j ( ^^ ^^ ^^ ^^)^refer to their respective entropy stores [ ^^ு]^^, [ ^^ு]^^,^^^^൧^, ^ ^^^൧^, [ ^^^]^and^^^^൧^, and identify the next blocks of unused rows – i.e. thoseas “used” – in these stores. Each block should be of the appropriate size as set outrequested value of ^^^^, for this Trustless Symmetric subvariant. These blocks are then copied by the respective nodes and stored as new matrices [ ^^ ^^ு]^^, [ ^^ ^^ு]^^,^^^ ^^^൧^,^^^ ^^^൧^, [ ^^ ^^^]^and ^ ^^ ^^^൧^. Then, in a send copies block 2404, hub node 202c QCH sends sends a copy of the first column of[^^ ^^ு]^^, that is, the first bit string, to first endpoint node 202f(^^ ^^ ^^ ^^)^. This column contains B-bits and we refer to the column as [ ^^ு]^^. Further, hub node 202c QCH sends a copy of the first column of [ ^^ ^^ு]^^, that is, the first (B-bit) bit string, to second endpoint node 202g ( ^^ ^^ ^^ ^^)^. This column contains B-bits and we refer to the column as [ ^^ு]^^. Further, the first intermediate node 202i ( ^^ ^^ ^^ ^^)^sends a copy of the first column of [ ^^ ^^^]^, that is, the first (B-bit) bit string, to first endpoint node 202f ( ^^ ^^ ^^ ^^)^. This column bits and we refer to the column as [ ^^^]^.Further, the second intermediate node 202j^a copy of the first column of ^ ^^ ^^^൧^, that is, the first (B-bit) bit string, to the second endpoint node 202g ( ^^ ^^ ^^ ^^)^. This column B-bits andwe refer to the column as ^ ^^^൧^.

[0296] Then, in a first derive column vector block 2406, hub node 202c QCH derives a new column vector [ ^^ிீ], given by the XOR of the second column, that is, the second (M-bit) bit string, of [ ^^ ^^ு]^^with the second column, that is, the second (M-bit) bit string, of[^^ ^^ு]^^.

[0297] Then, in a send column vector block 2408, hub node 202c QCH sends [ ^^ிீ] to whichever one out of first endpoint node 202f ( ^^ ^^ ^^ ^^)^and second endpoint node 202g ( ^^ ^^ ^^ ^^)^has been designated as the secondary randomness sharer.

[0298] Then, in a second derive column vector block 2410, the secondary randomness sharer endpoint node derives a new column vector, given by the XOR of [ ^^ிீ] with the second column, that is, the second (M-bit) bit string, of the block of ^ ^^ ^^^൧^or ^ ^^ ^^^൧^, according to whether the first endpoint node 202f ( ^^ ^^ ^^ ^^)^or the second endpoint node 202g ( ^^ ^^ ^^ ^^)^respectively is the secondary randomness sharer. We refer to this column vector as [ ^^ௌ]. The primary randomness sharer endpoint node identifies the second column, that is, the second (M-bit) bit string, of ^ ^^ ^^^൧^or ^ ^^ ^^^൧^, according to whether the first endpoint node 202f ( ^^ ^^ ^^ ^^)^or the second endpoint node 202g ( ^^ ^^ ^^ ^^)^respectively is the primary randomness sharer. This column vector is referred to as[^^^].

[0299] Then, in a comparison block 2412, the first endpoint node 202f ( ^^ ^^ ^^ ^^)^compares each entry in the first column, that is, the first (B-bit) bit string, of ^ ^^ ^^^൧^with the entries in the corresponding positions in [ ^^ு]^^and in [ ^^^]^, and records those positions for which all three entries059645.00198 are equal, and records these positions in a new column vector ^ ^^^൧ by placing a 1 in those positions for which all three of these entries are equal, and a 0 in the remaining positions. Further, the second endpoint node 202g ( ^^ ^^ ^^ ^^)^compares each entry in the first column, that is, the first (B-bit) bit string, of ^ ^^ ^^^൧^with the entries in the corresponding positions in [ ^^ு]^^and in ^ ^^^൧^, and records those for which all three entries are equal, and records these positions in a new column vector^placing a 1 in those positions for which all three of these entries are equal, and a 0 in the remaining positions.

[0300] Then, in a identify block 2414, the first endpoint node 202f ( ^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^communicate with each other via an authenticated AES-256 tunnel they share and identify the positions for which both ^ ^^^൧ and ^ ^^^൧ have an entry equal to 1.

[0301] Then, in a new vector block 2416, the primary randomness sharer endpoint node refers to those positions, identified in the identify block 2414, within[^^^], and assigns the entries at these positions to a new vector which we call [ ^^^ௌ]. The secondary randomness sharer refers to those positions, identified in the previous step, within[^^ௌ], and assigns the entries at these positions to a new vector which we call [ ^^ௌ^]. If the method has been carried out correctly, [ ^^^ௌ] = [ ^^ௌ^].

[0302] The first endpoint node 202f ( ^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^will now be in possession of an amount of shared randomness represented by the column vector [ ^^ிீ], where [ ^^ிீ] = [ ^^^ௌ] = [ ^^ௌ^].

[0303] Then, in a storage block 2418, the first endpoint node 202f(^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^store their identical copies of [ ^^ிீ] in their respective HSMs as their shared-randomness resource. This stored shared randomness is then available for use as encryption precursor material providing a basis for the generation of encryption materials, for example, encryption keys or one-time pad generation, for use for secure encrypted communications between the first endpoint node 202f and the second endpoint node 202g.

[0304] Figure 25 is a schematic diagram of a main part of the third stage of the third method in a case 3, where the Trustless Asymmetric subvariant has been selected, where ^^^= ^^ଷ. Figure 26 is a corresponding flowchart of the main part of the third stage 2600 of the third method in the case 3, where the Trustless Asymmetric subvariant has been selected.

[0305] In a first check entropy stores block 2602, the hub node 202c QCH, first endpoint node 202f ( ^^ ^^ ^^ ^^)^, second endpoint node 202g ( ^^ ^^ ^^ ^^)^, first intermediate node 202i ( ^^ ^^ ^^ ^^)^and second intermediate node 202j ( ^^ ^^ ^^ ^^)^refer to their respective entropy stores [ ^^ு]^^, [ ^^ு]^^,^^^^൧^, ^ ^^^൧^, [ ^^^]^and ^ ^^^൧^, and identify the next blocks of unused rows – i.e. those alreadyas “used” – in these stores. Each block should be of the appropriate size as set outrequested value of ^^^^, for this Trustless Asymmetric subvariant. These blocks are then059645.00198 copied by the respective participating nodes and stored as new matrices [ ^^ ^^ு]^^, [ ^^ ^^ு]^^,^^^ ^^^൧^, ^ ^^ ^^^൧^, [ ^^ ^^^]^and^^^ ^^^൧^respectively.in a send copies block 2604, the hub node 202c QCH sends a copy of the first column, that is, the first (B-bit) bit string, of [ ^^ ^^ு](^,^)ௌ^to the designated Side 1 participant endpoint node ( ^^ ^^ ^^ ^^)ௌ^. This column contains B-bits and we refer to the column as [ ^^ு](^,^)ௌ^. Here S1 denotes which out of the first endpoint node 202f(^^ ^^ ^^ ^^)^and the node 202g( ^^ ^^ ^^ ^^)^has been designated the Side 1 participant and the bracket (i,j) whichever of the intermediate nodes has entropy correlated with the Side 1 participant endpoint node ( ^^ ^^ ^^ ^^)ௌ^. Further, the intermediate node ( ^^ ^^ ^^ ^^)(^,^)ௌ^having entropy correlated with the Side 1 participant endpoint node sends a copy of the first column, that is the first (B-bit) bit string, of ^ ^^ ^^(^,^)൧ௌ^to the hub node 202c QCH and to the Side 1 participant endpoint node ( ^^ ^^ ^^ ^^)ௌ^.. This column contains B-bits and we refer to the column as^ ^^(^,^)൧ௌ^. Further, the Side 1 participant endpoint node(^^ ^^ ^^ ^^)ௌ^sends a copy of the first column to the hub node 202c QCH.. This column contains B-bits and werefer to the column as[(^,^).

[0307] Then, in a comparison block 2606, the hub node 202c QCH and the Side 1 participant endpoint node ( ^^ ^^ ^^ ^^)ௌ^each compare each entry in [ ^^ு](^,^)ௌ^with the entries at the corresponding positions in [ ^^ௌ^](^,^)and ^ ^^(^,^)൧ௌ^, and they position numbers for whichall three entries are the

[0308] Then, in a new vector block 2608, the hub node 202c QCH refers to these position numbers for which all three entries are the same within the second column, that is, the second (M-bit) bit string, of [ ^^ ^^ு](^,^)ௌ^, and places the second-column entries for these positions in a new vector [ ^^ுௌ^]. Further, the Side 1 participant endpoint node ( ^^ ^^ ^^ ^^)ௌ^likewise refers to these position for which all three entries are the same within the second column, that is, the second (M-bit) of [ ^^ ^^ௌ^](^,^), and places the second-column entries for these positions in a new vector [ ^^ௌ^ு]. If the method has been carried out correctly,[^^ுௌ^]=[^^ௌ^ு]. Then, in a truncation block 2610,node 202c QCH compares the length of [ ^^ுௌ^]with the length of (i.e. the number of rows in)[^^ ^^ு](^,^)ௌଶ. Here S2 denotes whichever out of the endpoint node 202f ( ^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^has been designated 2 participant and the bracket (i,j) represents whichever of the intermediate nodes has entropy correlated with the Side 2 participant endpoint node ( ^^ ^^ ^^ ^^)ௌଶ. If ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுௌ^]) > ^^ ^^ ^^ ^^ ^^ℎ൫[^^ ^^ு](^,^)ௌଶ൯, the hub node 202c QCH truncates[^^ுௌ], removing the last ( ^^ ^^ ^^ ^^ ^^ℎ([^^ுௌ])− ^^ ^^ ^^ ^^ ^^ℎ൫[ ^^ ^^ு](^,^)ௌଶ൯) entries in [ ^^ுௌ], and then sends to the Side 1 participant endpointnode ( ^^ ^^ ^^ ^^)ௌ^instructing ([ ]) [ ]the last ( ^^ ^^ ^^ ^^ ^^ுௌ^− ^^ ^^ ^^ ^^ ^^ℎ൫ ^^ ^^ு (^,^)ௌଶ൯) entries in [ ^^ௌ^ு]. Alternatively, if ^^ ^^ ^^ ^^ [ ^^ ^^ு](^,^)ௌଶ൯> ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுௌ^]), the hub node 202c QCH truncates059645.00198 [ ^^ ^^ு](^,^)ௌଶ, removing the last ( ^^ ^^ ^^ ^^ ^^ℎ൫[ ^^ ^^ு](^,^)ௌଶ൯− ^^ ^^ ^^ ^^ ^^ℎ( ^^ுௌ^)) rows in [ ^^ ^^ு](^,^)ௌଶ, and then sends a message to the side 2 participant endpoint node ( ^^ ^^ ^^ ^^)ௌଶinstructing it to remove the last ( ^^ ^^ ^^ ^^ ^^ℎ൫[^^ ^^ு](^,^)ௌଶ൯ − ^^ ^^ ^^ ^^ ^^ℎ(^^ுௌ)) rows in[^^ௌଶ](^,^). Here S2 denotes whichever out of the first endpoint node 202f ( ^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^has been designated the Side 2 participant. Alternatively, if ^^ ^^ ^^ ^^ ^^ℎ൫[ ^^ ^^ு](^,^)ௌଶ൯ = ^^ ^^ ^^ ^^ ^^ℎ([ ^^ுௌ]), no truncation is carried out.

[0310] Then in a first sending block 2612, the hub node 202c QCH sends a copy of the first column, that is, the first (B-bit) bit string, of [ ^^ ^^ு](^,^)ௌଶto the Side 2 participant endpoint node ( ^^ ^^ ^^ ^^)ௌଶ. This column contains B-bits and we refer to the column as [ ^^ு](^,^)ௌଶ. Here S2 denotes which out of the first endpoint node 202f(^^ ^^ ^^ ^^)^and the second endpoint node 202g(^^ ^^ ^^ ^^)^has been designated the Side 2 participant and the bracket (i,j) represents whichever of the intermediate nodes has entropy correlated with the Side 2 endpoint node(^^ ^^ ^^ ^^)ௌଶ. Further, the intermediate node ( ^^ ^^ ^^ ^^)(^,^)ௌଶsends a copy of the first column, that is, the first (B-bit) bit string, of ^ ^^ ^^(^,^)൧ௌଶto the Side 2 participant endpoint node ( ^^ ^^ ^^ ^^)ௌଶ. This column contains B-bits and we column as ^^^,^)൧(^ ௌଶ.

[0311] Then, in a first derive column vector block 2614, the hub node 202c QCH derives a new column vector [ ^^^ଶ], given by the XOR of [ ^^ுௌ^] with the second column, that is, the second (M- bit) bit string, of [ ^^ ^^ு](^,^)ௌଶ.

[0312] Then, in a second sending block 2616, the hub node 202c QCH sends [ ^^^ଶ] to whichever out of the Side 1 and Side 2 endpoint nodes ( ^^ ^^ ^^ ^^)ௌ^and ( ^^ ^^ ^^ ^^)ௌଶhas been designated as the secondary randomness sharer.

[0313] Then, in a second derive column vector block 2618, if Side 1 endpoint node ( ^^ ^^ ^^ ^^)ௌ^is the secondary randomness sharer,(^^ ^^ ^^ ^^)ௌ^derives a new column vector, given by the XOR of [ ^^^ଶ] with [ ^^ௌ^ு]. Alternatively, if Side 2 endpoint node ( ^^ ^^ ^^ ^^)ௌଶis the secondary ^^ ^^ ^^ ^^)ௌଶderives a new column vector, given by the XOR of[^^^ଶwith the]the second (M-bit) bit string, of [ ^^ ^^ௌଶ](^,^). In both cases we refer to the new column vector as [ ^^ௌ]. Further, if Side 1 endpoint node ( ^^ ^^ ^^ ^^)ௌ^is the primary randomness sharer, ( ^^ ^^ ^^ ^^)ௌ^renames[^^ௌ^ு]as[^^^]. Alternatively, if Side 2 endpoint node(^^ ^^ ^^ ^^)ௌଶis the primary randomness ^^ ^^ ^^ ^^)ௌଶrenames the second column, that is, the second (M-bit) bit string, of [ ^^ ^^ௌଶ](^,^)as[^^^].

[0314] Then, in a comparing block 2620, Side 2 endpoint node(^^ ^^ ^^ ^^)ௌଶcompares each entry in [ ^^ு](^,^)ௌଶand each entry in ^ ^^(^,^)൧ௌଶwith the entry at the corresponding position in the first column, that is, the first (B-bit) bit string, of [ ^^ ^^ௌଶ](^,^), and records the position numbers for which all three entries are equal. Side 2 endpoint node ( ^^ ^^ ^^ ^^)ௌଶalso sends Side 1 endpoint node ( ^^ ^^ ^^ ^^)ௌ^these position numbers.059645.00198

[0315] Then, in a second new vector block 2622, the primary randomness sharer endpoint node refers to those positions, identified in the comparing block 2620 for which all three entries are equal, within [ ^^^], and assigns the entries at these positions to a new vector which we call [ ^^^ௌ]. The secondary randomness sharer endpoint node refers to those positions, identified in the comparing block 2620 for which all three entries are equal, within [ ^^ௌ], and assigns the entries at these positions to a new vector which we call [ ^^ௌ^]. If the method has been carried out correctly [ ^^^ௌ] = [ ^^ௌ^].

[0316] The first endpoint node 202f ( ^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^will now be in possession of an amount of shared randomness represented by the column vector [ ^^ிீ], where [ ^^ிீ] = [ ^^^ௌ] = [ ^^ௌ^].block 2624, the first endpoint node 202f ( ^^ ^^ ^^ ^^)^and the second endpoint node 202g ( ^^ ^^ ^^ ^^)^now store their identical copies of [ ^^ிீ] in their respective HSMs as their shared-randomness resource. This stored shared randomness is then available for use as encryption precursor material providing a basis for the generation of encryption materials, for example, encryption keys or one-time pad generation, for use for secure encrypted communications between the first endpoint node 202f and the second endpoint node 202g.

[0318] Throughout the method of the examples described above, the communications between the different nodes are protected by AES-256 tunnels within the Quantum Cloud perimeter 204a. In other examples, different communications security protocols may be used.

[0319] As is explained above, in each of the three subvariants, the two participating endpoint nodes 202 can generate shared randomness between them on-demand, at any time. The entropy stores of the endpoint nodes 202 are correlated in such a way that shared randomness can be generated between any pair of nodes 202. However, the entropy store’s contents at each node 202, considered in isolation, does not contain any information relating to the generated shared randomness, and so even if an entropy store at a node 202 were to be hacked, and its content accessed, the subsequently generated shared randomness would not be compromised. To access the shared randomness an adversary would need to hack multiple entropy stores in multiple nodes 202 and also have the facility to decrypt in real time the communications that are exchanged between the nodes 202 during the generation of shared randomness.

[0320] The disclosed second and third methods can also provide security enhancement through randomization of channels. As is explained above, the QRNGs used may be randomly selected. Further, these methods can offer the facility of randomizing the channels of communication between locations (i.e., between nodes), which adds an additional layer of security, as it will be impossible for an adversary to know in advance which channels will be used in the entropy loading and shared randomness generation processes for any particular nodes.

[0321] In the disclosed second and third methods, the use of multiple nodes connected by randomized channels means that there is no single-point failure risk. Even if several nodes are059645.00198 compromised the remaining network of nodes can still function perfectly. The network is effectively self-healing and there is no vulnerability to a denial-of-service attack.

[0322] It is possible to implement any of the methods described above within a decentralized structure, such that any Quantum Cloud node can act as hub, intermediate node, or endpoint node, in different instances of the methods. An example of how a Quantum Cloud node’s overall entropy store might look, for a single node within such a decentralized structure, is shown as a table in Figure 27.

[0323] The methods described above allow for the number of nodes and intermediate channel links within the Quantum Cloud to be increased without limit. In general, increasing the number of intermediate links enables a greater degree of randomization of the paths from the hub node to the endpoint nodes in each instance, making it still more difficult for an eavesdropper trying to access the transmissions.

[0324] It can be understood from the above disclosure that the different methods use quantum-inspired methods to provide several applications for creating shared randomness at separated locations, with a variety of use cases. These offer many advantages in terms of security enhancement, operational flexibility, and scalability, whist avoiding all the technical challenges, side- channel vulnerabilities, and very high costs associated with photonic transmission. The present disclosure has described methods that generate shared randomness inside a Quantum Cloud.

[0325] As will be apparent to the skilled person, the operations of the methods shown in figures 4, 5, 7, 9, 11, 14, 19, 20, 22, 24 and 26 need not necessarily be performed in the order depicted in said figures. The skilled person will understand that, except where specifically prohibited or evidently impossible, the different operations may be performed in any suitable order.

[0326] The embodiments set out above describe the methods as carried out by a system as shown in figure 2, having QRNGs arranged in one or more QRNG banks. The methods may alternatively be caried out by a system as shown in figure 1, where each node has an associated QRNG. When the methods are carried out by the system of figure 1, instead of randomly selecting a QRNG, each node will instead use its associated QRNG.

[0327] The embodiments set out above describe methods in which the QRNG used to provide bit strings of random bits to a node is randomly selected. In alternative methods, the QRNG used to provide bit strings of random bits to a node may be selected in a non-random manner, or may be fixed. However, without wishing to be bound by theory, it is expected that random selection of a QRNG will provide improved security.

[0328] The embodiments set out above describe the methods as carried out by a system having multiple QRNGs. In alternative examples, the system may comprise only a single QRNG. However, without wishing to be bound by theory, it is expected that the use of multiple QRNGs will059645.00198 provide improved security by enabling random selection of a QRNG to provide a random bit string from among the plurality of QRNGs, and will be simpler to operate.

[0329] The embodiments set out above use one or more QRNGs. In other examples, random number generators (RNGs) which are not QRNGs may be used instead, instead of some, or all, of the QRNGs. This may be done, for example, to reduce costs and / or complexity. Without wishing to be bound by theory, it is expected that the use of RNGs instead of QRNGs may reduce the degree of security provided because it is only QRNGs that can provide genuinely unpredictable sources of randomness. However, the advantages of providing entropy stores that reveal nothing about the shared randomness, and the facility for on-demand generation of shared randomness, would be retained, albeit possibly with a reduced degree of security.

[0330] The embodiments described above are fully automatic. In some examples a user or operator of the system may manually instruct some steps of the method to be carried out.

[0331] In the described embodiments of the invention the system and nodes may be implemented as any form of a computing and / or electronic device. Such a device may comprise one or more processors which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to gather and record routing information. In some examples, for example where a system on a chip architecture is used, the processors may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method in hardware (rather than software or firmware). Platform software comprising an operating system or any other suitable platform software may be provided at the computing-based device to enable application software to be executed on the device.

[0332] Various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media may include, for example, computer-readable storage media. Computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. A computer-readable storage media can be any available storage media that may be accessed by a computer. By way of example, and not limitation, such computer- readable storage media may comprise RAM, ROM, EEPROM, flash memory or other memory devices, CD-ROM or other optical disc storage, magnetic disc storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disc and disk, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray (RTM) disc (BD). Further, a propagated signal is not included within the scope of computer- readable storage media. Computer-readable media also includes communication media including any medium that facilitates transfer of a computer program from one place to another. A connection, for059645.00198 instance, can be a communication medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of communication medium. Combinations of the above should also be included within the scope of computer-readable media.

[0333] Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, hardware logic components that can be used may include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System- on-a-chip systems (SOCs). Complex Programmable Logic Devices (CPLDs), etc.

[0334] Although illustrated as a single system, it is to be understood that the computing device may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device.

[0335] Although illustrated as a local device it will be appreciated that any of the computing devices may be located remotely and accessed via a network or other communication link (for example using a communication interface).

[0336] The term 'computer' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realise that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, mobile telephones, personal digital assistants and many other devices.

[0337] Those skilled in the art will realise that storage devices utilised to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realise that by utilising conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

[0338] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. Variants should be considered to be included into the scope of the invention.059645.00198

[0339] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method steps or elements identified, but that such steps or elements do not comprise an exclusive list and a method or apparatus may contain additional steps or elements.

[0340] As used herein, the terms "component" and "system" are intended to encompass computer-readable data storage that is configured with computer-executable instructions that cause certain functionality to be performed when executed by a processor. The computer-executable instructions may include a routine, a function, or the like. It is also to be understood that a component or system may be localized on a single device or distributed across several devices.

[0341] Further, as used herein, the term "exemplary" is intended to mean "serving as an illustration or example of something".

[0342] Further, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

[0343] Moreover, the acts described herein may comprise computer-executable instructions that can be implemented by one or more processors and / or stored on a computer-readable medium or media. The computer-executable instructions can include routines, sub-routines, programs, threads of execution, and / or the like. Still further, results of acts of the methods can be stored in a computer- readable medium, displayed on a display device, and / or the like.

[0344] The order of the steps of the methods described herein is exemplary, but the steps may be carried out in any suitable order, or simultaneously where appropriate. Additionally, steps may be added or substituted in, or individual steps may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

[0345] It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable modification and alteration of the above devices or methods for purposes of describing the aforementioned aspects, but one of ordinary skill in the art can recognize that many further modifications and permutations of various aspects are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the scope of the appended claims.

Claims

059645.00198 Claims 1. A method for storing entropy, the method comprising: in a system comprising a plurality of nodes, at a hub node of the plurality of nodes, for each of one or more other nodes, obtaining two bit strings of random bits of equal length from a random number generator (RNG); at the hub node, pairing each two bit strings together so that each bit in one bit string has a corresponding bit in the other bit string, sending a pair of bit strings to each of the one or more other nodes, and storing a copy of each pair of bit strings together with the identity of the other node to which they were sent; at each of the one or more other nodes, producing a pair of bit strings by obtaining two bit strings of random bits of equal length from an RNG and pairing the two bit strings together so that each bit in one bit string has a corresponding bit in the other bit string; at each of the one or more other nodes, comparing each bit in a first string of the pair of bit strings received from the hub node to the corresponding bit in a first string of the pair of bit strings produced at the node; and either: in a first alternative, if these two bits have the same value, re-setting the value of the corresponding bit in the second string of the pair of bit strings produced at the node to be equal to the value of the corresponding bit in the second string of the pair of bit strings received from the hub node; and if these two bits have different values, leaving the value of the corresponding bit in the second string of the pair of bit strings produced at the node unchanged; or in a second alternative, if these two bits have the different values, re-setting the value of the corresponding bit in the second string of the pair of bit strings produced at the node to be equal to the value of the corresponding bit in the second string of the pair of bit strings received from the hub node; and if these two bits the same value, leaving the value of the corresponding bit in the second string of the pair of bit strings produced at the node unchanged; and at each of the one or more other nodes, when all of the bits in the first strings of the pairs of bit strings have been compared, deleting the pair of bit strings received from the hub node, and storing the pair of bit strings produced at the node and including the re-set values.

2. The method according to claim 1, and further comprising: at each of the one or more other nodes, after deleting the pair of bit strings received from the hub node, confirming this to the hub node; and at the hub node, storing the confirmation of deletion in association with the stored copy of the corresponding pair of bit strings.

3. The method according to claim 2, wherein each of the one or more other nodes confirms the deletion to the hub node by sending a certificate of deletion.

4. The method according to any preceding claim, wherein the system comprises a plurality of RNGs.059645.00198 5. The method according to claim 4, wherein the hub node and each of the one or more other nodes randomly selects a RNG from which each respective two bit strings are obtained.

6. The method according to claim 4 or claim 5, wherein the plurality of RNGs are grouped together in a RNG bank.

7. The method according to claim 4, wherein each node of the plurality of nodes has an associated RNG.

8. The method according to any preceding claim, wherein the one or more other nodes are a plurality of other nodes.

9. The method according to any preceding claim, wherein each node of the plurality of nodes has an associated hardware security module (HSM) used for storage by that node.

10. The method according to any preceding claim, wherein the nodes of the plurality of nodes are able to communicate using secure tunnels.

11. The method according to claim 10, wherein the secure tunnels are Advanced Encryption Standard-256 (AES-256) tunnels.

12. The method according to any preceding claim, wherein the method is repeated multiple times.

13. The method according to claim 12, wherein the hub node is a different one of plurality of nodes for at least some of the times the method is repeated.

14. The method according to any preceding claim, wherein the system defines a secure communications perimeter, and all of the plurality of nodes are inside this perimeter.

15. The method according to any preceding claim, wherein one or more of the RNGs are quantum random number generators (QRNGs), and preferably wherein all of the RNGs are QRNGs.

16. The method according to any preceding claim, and further comprising: a first node, which is one of the one or more other nodes, and a second node, which is one of the one or more other nodes, communicating and agreeing they wish to generate shared randomness; at least one of the first and second nodes sending a shared-randomness request to the hub node identifying the first and second nodes, and identifying which of the first and059645.00198 second nodes is to be the primary randomness sharer and which is to be the secondary randomness sharer; at the hub node, checking if there is sufficient entropy previously delivered to the first and second nodes, which has not been used, to fulfil the shared-randomness request.

17. The method according to claim 16, wherein the first and second nodes agree a first number of bits of shared randomness they wish to generate, and the shared-randomness request identifies the first number of bits.

18. The method according to claim 16, wherein a predetermined number of bits are to be generated in response to a shared-randomness request.

19. The method according to any one of claims 16 to 18, wherein only one of the first and second nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the primary randomness sharer and which is to be the secondary randomness sharer, wherein either: the one of the first and second nodes sending the shared-randomness request is identified as the primary randomness sharer and the other one of the first and second nodes is identified as the secondary randomness sharer; or the one of the first and second nodes sending the shared-randomness request is identified as the secondary randomness sharer and the other one of the first and second nodes is identified as the primary randomness sharer.

20. The method according to any one of claims 16 to 19, and further comprising, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the first node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the second node; at the first node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the second node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the first node, and sending the first bit string of the second block to the second node; at the first node, sending the first bit string of the third block to the hub node; at the second node, sending the first bit string of the fourth block to the hub node; at each of the hub node and the first node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of the third block, and recording the position numbers for which these values are the same;059645.00198 at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the first node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at each of the hub node and the second node, comparing a value of each bit in the first bit string of the second block to the value of the corresponding bit in the first bit string of the fourth block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the second block, and placing the values at these positions in the second bit string into a third vector; at the second node, referring to the recorded position numbers in the second bit string of the fourth block, and placing the values at these positions in the second bit string into a fourth vector; at the hub node, comparing the length of the first vector and the third vector, and, if the first and third vectors have different lengths, truncating by removing a number of entries from the end of the longer one of the first and third vectors so that the first and third vectors have the same length, and either; if the first vector has a greater length, sending a truncation message to the first node to remove the number of entries from the end of the second vector; or if the third vector has a greater length, sending a truncation message to the second node to remove the number of entries from the end of the fourth vector; at the first node, if a truncation message is received, truncating by removing the number of entries from the end of the second vector; at the second node, if a truncation message is received, truncating by removing the number of entries from the end of the fourth vector; at the hub node, deriving a fifth vector which is the result of an XOR of the first and third vectors after any truncation, and sending the fifth vector to whichever one of the first and second nodes is the node identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a sixth vector which is the result of an XOR of the fifth vector with either the second vector, if the first node is the secondary randomness sharer, or the fourth vector, if the second node is the secondary randomness sharer, and storing the sixth vector; and at the node identified as the primary randomness sharer, storing either the second vector, if the first node is the primary randomness sharer, or the fourth vector, if the second node is the primary randomness sharer; whereby the first and second nodes have shared randomness represented by the sixth vector and the one of the second or fourth vector which was stored.

21. The method of claim 20, wherein each of the first to fourth blocks comprises (2*n)+β(n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared- randomness request, and β(x) is a buffer function.

22. The method of claim 21, where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.059645.00198 23. The method according to any one of claims 16 to 19, and further comprising, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the first node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the second node; at the first node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the second node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the first node, and sending the first bit string of the second block to the second node; at the hub node, deriving a first vector which is the result of an XOR of the second bit string of the first block and the second bit string of the second block, and sending the first vector to whichever one of the first and second nodes is identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a second vector which is the result of an XOR of the first vector with either; the second bit string of the third block, if the first node is the secondary randomness sharer, or the second bit string of the fourth block, if the second node is the secondary randomness sharer; at the node identified as the primary randomness sharer, deriving a third vector which is either; the second bit string of the third block, if the first node is the primary randomness sharer, or the second bit string of the fourth block, if the second node is the primary randomness sharer; at the first node, deriving a fourth vector which is the result of an XOR of the first bit string of the first block with the first bit string of the third block; at the second node, deriving a fifth vector which is the result of an XOR of the first bit string of the second block with the first bit string of the fourth block; the first node and the second node communicate and identify the positions in the fourth vector and the fifth vector where the entries in both vectors are zero; at the node identified as the primary randomness sharer, referring to the positions in the third vector which correspond to the identified positions where the fourth and fifth vectors are both zero, and assigning the entries at these positions to a sixth vector; at the node identified as the secondary randomness sharer, referring to the positions in the second vector which correspond to the identified positions where the fourth and fifth vectors are both zero, and assigning the entries at these positions to a seventh vector; at the node identified as the primary randomness sharer, storing the sixth vector; and at the node identified as the secondary randomness sharer, storing the seventh vector; whereby the first and second nodes have shared randomness represented by the sixth vector and the seventh vector.059645.00198 24. The method of claim 23, wherein each of the first to fourth blocks comprises (4*n)+β(2*n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

25. The method of claim 24, where ^^(^^)= ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), and where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.

26. The method according to any one of claims 16 to 19, and further comprising, if the check finds that there is sufficient entropy, generating shared randomness by: assigning one of the first node and the second node as the Side 1 participant node and the other as the Side 2 participant node; at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 1 participant node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 2 participant node; at the Side 1 participant node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the Side 2 participant node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the Side 1 participant node; at the Side 1 participant node, sending the first bit string of the third block to the hub node; at each of the hub node and the Side 1 participant node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of the third block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the Side 1 participant node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector;059645.00198 at the hub node, comparing the length of the first vector and the second block, and, if the first vector and the second block have different lengths, truncating by removing a number of entries from the end of the longer one of the first vector and the second block so that the first vector and the second block have the same length, and, if the first vector was longer than the second block, sending a truncation message to the Side 1 participant node instructing it to remove the number of entries from the second vector, or, if the second block was longer than the first vector, sending a truncation message to the Side 2 participant node instructing it to remove the number of entries from the fourth block; at the Side 1 participant node, if the truncation message is received, removing the number of entries from the second vector; at the Side 2 participant node, if the truncation message is received, removing the number of entries from the fourth block; at the hub node, sending the first bit string of the second block to the Side 2 participant node; at the hub node, deriving a third vector which is the result of an XOR of the first vector with the second bit string of the second block; at the hub node, sending the third vector to the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, deriving a fourth vector which is the result of an XOR of the third vector with either; the second vector if the Side 1 participant node is identified as the secondary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the secondary randomness sharer; at the Side 2 participant node, comparing each entry in the first bit string of the second block with the corresponding entry in the first bit string of the fourth block, recording the position numbers for which these entries are the same, and sending the recorded position numbers to the Side 1 participant node; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, referring to the recorded position numbers in either; the second vector if the Side 1 participant node is identified as the primary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the primary randomness sharer, and assigning the entries at these positions to a fifth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, referring to the recorded position numbers in the fourth vector, and assigning the entries at these positions to a sixth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, storing the fifth vector; and059645.00198 at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, storing the sixth vector; whereby the first and second nodes have shared randomness represented by the fifth vector and the sixth vector.

27. The method of claim 26, wherein the shared-randomness request identifies which of the first and second nodes is to be the Side 1 participant node and which is to be the Side 2 participant node.

28. The method according to claim 27, wherein only one of the first and second nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the Side 1 participant node and which is to be the Side 2 participant node, wherein either: the one of the first and second nodes sending the shared-randomness request is identified as the Side 1 participant node and the other one of the first and second nodes is identified as the Side 2 participant node; or the one of the first and second nodes sending the shared-randomness request is identified as the Side 2 participant node and the other one of the first and second nodes is identified as the Side 1 participant node.

29. The method of any one of claims 26 to 28, wherein each of the first and third blocks comprises (4*n)+β(2*n)n pairs of bits and each of the second and fourth blocks comprises (2*n) + β(n) pairs of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

30. The method of claim 29, where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^) where the ceiling function rounds up to the nearest integer and x is the expected amount of shared randomness.

31. The method of any one of claims 15 to 30, wherein the first node and the second node agree which of the methods of claims 20, 23 and 26 is to be used, and the shared randomness request identifies which of these methods is to be used.

32. The method according to any one of claims 1 to 15, and further comprising: for a first node of the one or more other nodes, selecting a second node of the one or more other nodes;059645.00198 at the first node, selecting a block of unused corresponding bits of the stored pairs of bit strings produced at the node and including the re-set values, sending a copy of the selected block to the second node, and then deleting the selected block; at the second node, storing the received block; at the first node, sending a message to the hub node informing the hub node that the block has been sent from the first node to the second node; at the hub node, identifying the bits of the stored pairs of bit strings stored together with the identity of the first node which correspond to the bits of the block and storing the identified bits of the stored pairs of bit strings together with the identity of the second node.

33. The method according to claim 32, wherein storing the identified bits of the stored pairs of bit strings together with the identity of the second node comprises storing the identified bits of the stored pairs of bit strings together with the identity of the second node, and deleting the copy of the identified bits of the stored pairs of bit strings stored together with the identity of the first node.

34. The method according to claim 32, wherein storing the identified bits of the stored pairs of bit strings together with the identity of the second node comprises replacing the identity of the first node stored together with the identified bits of the stored pairs of bit strings with the identity of the second node.

35. The method according to any one of claims 32 to 34, wherein the second node of the plurality of nodes is randomly selected.

36. The method according to any one of claims 32 to 35, wherein the first node confirms the deletion of the selected first block to the hub node by sending a certificate of deletion.

37. The method according to any one of claims 32 to 36, wherein the method is repeated multiple times.

38. The method according to claim 37, wherein the first node and / or the second node is a different one of the one or more other nodes for at least some of the times the method is repeated.059645.00198 39. The method according to any one of claims 32 to 38, and further comprising: a third node, which is one of the second nodes, and a fourth node, which is one of the second nodes, communicating and agreeing they wish to generate shared randomness; at least one of the third and fourth nodes sending a shared-randomness request to the hub node identifying the third and fourth nodes, and identifying which of the third and fourth nodes is to be the primary randomness sharer and which is to be the secondary randomness sharer; at the hub node, checking if there is sufficient entropy previously delivered to the third and fourth nodes, which has not been used, to fulfil the shared-randomness request.

40. The method according to claim 39, wherein the third and fourth nodes agree a first number of bits of shared randomness they wish to generate, and the shared-randomness request identifies the first number of bits.

41. The method according to claim 39, wherein a predetermined number of bits are to be generated in response to a shared-randomness request.

42. The method according to any one of claims 39 to 41, wherein only one of the third and fourth nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the primary randomness sharer and which is to be the secondary randomness sharer, wherein either: the one of the third and fourth nodes sending the shared-randomness request is identified as the primary randomness sharer and the other one of the third and fourth nodes is identified as the secondary randomness sharer; or the one of the third and fourth nodes sending the shared-randomness request is identified as the secondary randomness sharer and the other one of the third and fourth nodes is identified as the primary randomness sharer.

43. The method according to any one of claims 39 to 42, and further comprising, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the third node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the fourth node; at the third node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the fourth node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the third node, and sending the first bit string of the second block to the fourth node;059645.00198 at the third node, sending the first bit string of the third block to the hub node; at the fourth node, sending the first bit string of the fourth block to the hub node; at each of the hub node and the third node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of the third block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the third node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at each of the hub node and the fourth node, comparing a value of each bit in the first bit string of the second block to the value of the corresponding bit in the first bit string of the fourth block, and recording the position numbers for which these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the second block, and placing the values at these positions in the second bit string into a third vector; at the fourth node, referring to the recorded position numbers in the second bit string of the fourth block, and placing the values at these positions in the second bit string into a fourth vector; at the hub node, comparing the length of the first vector and the third vector, and, if the first and third vectors have different lengths, truncating by removing a number of entries from the end of the longer one of the first and third vectors so that the first and third vectors have the same length, and either; if the first vector has a greater length, sending a truncation message to the third node to remove the number of entries from the end of the second vector; or if the third vector has a greater length, sending a truncation message to the fourth node to remove the number of entries from the end of the fourth vector; at the third node, if a truncation message is received, truncating by removing the number of entries from the end of the second vector; at the fourth node, if a truncation message is received, truncating by removing the number of entries from the end of the fourth vector; at the hub node, deriving a fifth vector which is the result of an XOR of the first and third vectors after any truncation, and sending the fifth vector to whichever one of the third and fourth nodes is the node identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a sixth vector which is the result of an XOR of the fifth vector with either the second vector, if the third node is the secondary randomness sharer, or the fourth vector, if the fourth node is the secondary randomness sharer, and storing the sixth vector; and at the node identified as the primary randomness sharer, storing either the second vector, if the third node is the primary randomness sharer, or the fourth vector, if the fourth node is the primary randomness sharer; whereby the third and fourth nodes have shared randomness represented by the sixth vector and the second or fourth vector.059645.00198 44. The method of claim 43, wherein each of the first to fourth blocks comprises (2*n)+β(n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared- randomness request, and β(x) is a buffer function.

45. The method of claim 44, where ^^(^^)= ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.

46. The method according to any one of claims 39 to 42, and further comprising, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the third node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the fourth node; at the third node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the fourth node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the third node, and sending the first bit string of the second block to the fourth node; at the hub node, deriving a first vector which is the result of an XOR of the second bit string of the first block and the second bit string of the second block, and sending the first vector to whichever one of the third and fourth nodes is identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a second vector which is the result of an XOR of the first vector with either; the second bit string of the third block, if the third node is the secondary randomness sharer, or the second bit string of the fourth block, if the fourth node is the secondary randomness sharer; at the node identified as the primary randomness sharer, deriving a third vector which is either; the second bit string of the third block, if the third node is the primary randomness sharer, or the second bit string of the fourth block, if the fourth node is the primary randomness sharer; at the third node, deriving a fourth vector which is the result of an XOR of the first bit string of the first block with the first bit string of the third block; at the fourth node, deriving a fifth vector which is the result of an XOR of the first bit string of the second block with the first bit string of the fourth block; the third node and the fourth node communicate and identify the positions in the fourth vector and the fifth vector where the entries in both vectors are zero; at the node identified as the primary randomness sharer, referring to the positions in the third vector which correspond to the identified positions where the fourth and fifth vectors are both zero, and assigning the entries at these positions to a sixth vector; at the node identified as the secondary randomness sharer, referring to the positions in the second vector which correspond to the identified positions where the fourth and fifth vectors are both zero, and assigning the entries at these positions to a seventh vector;059645.00198 at the node identified as the primary randomness sharer, storing the sixth vector; and at the node identified as the secondary randomness sharer, storing the seventh vector; whereby the third and fourth nodes have shared randomness represented by the sixth vector and the seventh vector.

47. The method of claim 46, wherein each of the first to fourth blocks comprises (4*n)+β(2*n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

48. The method of claim 47, where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), and where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.

49. The method according to any one of claims 39 to 42, and further comprising, if the check finds that there is sufficient entropy, generating shared randomness by: assigning one of the third node and the fourth node as the Side 1 participant node and the other as the Side 2 participant node; at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 1 participant node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 2 participant node; at the Side 1 participant node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the Side 2 participant node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; wherein each of the first to fourth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the Side 1 participant node; at the Side 1 participant node, sending the first bit string of the third block to the hub node; at each of the hub node and the Side 1 participant node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of the third block, and recording the position numbers for which these values are the same;059645.00198 at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the Side 1 participant node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at the hub node, comparing the length of the first vector and the second block, and, if the first vector and the second block have different lengths, truncating by removing a number of entries from the end of the longer one of the first vector and the second block so that the first vector and the second block have the same length, and, if the first vector was longer than the second block, sending a truncation message to the Side 1 participant node instructing it to remove the number of entries from the second vector, or, if the second block was longer than the first vector, sending a truncation message to the Side 2 participant node instructing it to remove the number of entries from the fourth block; at the Side 1 participant node, if the truncation message is received, removing the number of entries from the second vector; at the Side 2 participant node, if the truncation message is received, removing the number of entries from the fourth block; at the hub node, sending the first bit string of the second block to the Side 2 participant node; at the hub node, deriving a third vector which is the result of an XOR of the first vector with the second bit string of the second block; at the hub node, sending the third vector to the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, deriving a fourth vector which is the result of an XOR of the third vector with either; the second vector if the Side 1 participant node is identified as the secondary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the secondary randomness sharer; at the Side 2 participant node, comparing each entry in the first bit string of the second block with the corresponding entry in the first bit string of the fourth block, recording the position numbers for which these entries are the same, and sending the recorded position numbers to the Side 1 participant node; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, referring to the recorded position numbers in either; the second vector if the Side 1 participant node is identified as the primary randomness sharer, or059645.00198 the second bit string of the fourth block if the Side 2 participant node is identified as the primary randomness sharer, and assigning the entries at these positions to a fifth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, referring to the recorded position numbers in the fourth vector, and assigning the entries at these positions to a sixth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, storing the fifth vector; and at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, storing the sixth vector; whereby the third and fourth nodes have shared randomness represented by the fifth vector and the sixth vector.

50. The method of claim 49, wherein the shared-randomness request identifies which of the third and fourth nodes is to be the Side 1 participant node and which is to be the Side 2 participant node.

51. The method according to claim 50, wherein only one of the third and fourth nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the Side 1 participant node and which is to be the Side 2 participant node, wherein either: the one of the third and fourth nodes sending the shared-randomness request is identified as the Side 1 participant node and the other one of the third and fourth nodes is identified as the Side 2 participant node; or the one of the third and fourth nodes sending the shared-randomness request is identified as the Side 2 participant node and the other one of the third and fourth nodes is identified as the Side 1 participant node.

52. The method of any one of claims 49 to 51, wherein each of the first and third blocks comprises (4*n)+β(2*n) pairs of bits and each of the second and fourth blocks comprises (2*n) + β(n) pairs of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

53. The method of claim 52, where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√ ^^) where the ceiling function rounds up to the nearest integer and x is the expected amount of shared randomness.059645.00198 54. The method of any one of claims 32 to 53, wherein the third node and the fourth node agree which of the methods of claims 43, 46 and 49 is to be used, and the shared randomness request identifies which of these methods is to be used.

55. The method of any one of claims 1 to 15, in which the first alternative was used, and further comprising: for a first node of the one or more other nodes, selecting a second node of the one or more other nodes; at the first node, selecting a block of unused corresponding bits of the stored pairs of bit strings produced at the node and including the re-set values, and sending a copy of the selected block to the second node; at the second node, temporarily storing the received block, obtaining two bit strings of random bits from a QRNG, each bit string being of equal length to the received block, and producing a pair of bit strings by pairing the two bit strings together so that each bit in one bit string has a corresponding bit in the other bit string; at the second node, comparing each bit in a first string of the block to the corresponding bit in a first string of the pair of bit strings produced at the second node; if these two bits have the same value, re-setting the value of the corresponding bit in the second string of the pair of bit strings produced at the node to be equal to the value of the corresponding bit in the second string of the block; or if these bits have different values, leaving the value of the corresponding bit in the second string of the pair of bit strings produced at the node unchanged; at the second node, when all of the bits in the first strings of the block and the pair of bit strings have been compared, deleting the block, and storing the pair of bit strings including the re-set values; at the first node, storing the bits of the block together with the identity of the second node, and sending a message to the hub node informing the hub node that the block is correlated with the pair of bit strings stored on the second node; at the hub node, identifying the bits of the stored pairs of bit strings stored together with the identity of the first node which correspond to the bits of the block, and storing the identified bits of the stored pairs of bit strings together with the identity of the second node.

56. The method according to claim 55, wherein the second node is randomly selected.059645.00198 57. The method according to claim 55 or claim 56, wherein the second node randomly selects an RNG or QRNG from which the two bit strings are obtained. 58 The method according to any one of claims 55 to 57, and further comprising: repeating the method of claim 55 multiple times wherein different ones of the plurality of nodes are the first node and the second node for different repetitions, so that the system comprises a plurality of second nodes; a first endpoint node, which has previously acted as a second node, and a second endpoint node which has previously acted as a second node, communicating and agreeing they wish to generate shared randomness; at least one of the first and second endpoint nodes sending a shared-randomness request to the hub node identifying the first and second endpoint nodes, and identifying which of the first and second endpoint nodes is to be the primary randomness sharer and which is to be the secondary randomness sharer; at the hub node, checking if there is sufficient entropy previously indirectly delivered from first nodes to the first and second endpoint nodes, which has not been used, to fulfil the shared-randomness request; selecting a first intermediate node which has previously acted as a first node for the first endpoint node, and selecting a second intermediate node which has previously acted as a first node for the second endpoint node.

59. The method according to claim 58, wherein the first and second endpoint nodes agree a first number of bits of shared randomness they wish to generate, and the shared-randomness request identifies the first number of bits.

60. The method according to claim 58 or claim 59, wherein only one of the first and second endpoint nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the primary randomness sharer and which is to be the secondary randomness sharer, wherein either: the one of the first and second endpoint nodes sending the shared-randomness request is identified as the primary randomness sharer and the other one of the first and second endpoint nodes is identified as the secondary randomness sharer; or the one of the first and second endpoint nodes sending the shared-randomness request is identified as the secondary randomness sharer and the other one of the first and second endpoint nodes is identified as the primary randomness sharer.059645.00198 61. The method according to any one of claims 58 to 60, wherein, if there is more than one node which has acted as a first node for the first endpoint node, the hub node randomly selects one of these nodes as the first intermediate node; and if there is more than one node which has acted as a first node for the second endpoint node, the hub node randomly selects one of these nodes as the second intermediate node.

62. The method according to any one of claims 58 to 61, and further comprising, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the first endpoint node by the first intermediate node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the second endpoint node by the second intermediate node; at the first endpoint node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the second endpoint node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the first intermediate node, identifying a fifth block of unused corresponding bits of the stored pairs of bit strings which were sent to the first endpojnt node; at the second intermediate node, identifying a sixth block of unused corresponding bits of the stored pairs of bit strings which were sent to the second endpoint node; wherein each of the first to sixth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the first endpoint node, and sending the first bit string of the second block to the second endpoint node; at the first endpoint node, sending the first bit string of the third block to the hub node; at the second endpoint node, sending the first bit string of the fourth block to the hub node; at the first intermediate node, sending the first bit string of the fifth block to the hub node and to the first endpoint node; at the second intermediate node, sending the first bit string of the sixth block to the hub node and to the second endpoint node; at each of the hub node and the first endpoint node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in the first bit string of059645.00198 the third block, and to the value of the corresponding bit in the first bit string of the fifth block, and recording the position numbers for which all three of these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector; at the first endpoint node, referring to the recorded position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at each of the hub node and the second endpoint node, comparing a value of each bit in the first bit string of the second block to the value of the corresponding bit in the first bit string of the fourth block, and to the value of the corresponding bit in the first bit string of the sixth block, and recording the position numbers for which all three of these values are the same; at the hub node, referring to the recorded position numbers in the second bit string of the second block, and placing the values at these positions in the second bit string into a third vector; at the second endpoint node, referring to the recorded position numbers in the second bit string of the fourth block, and placing the values at these positions in the second bit string into a fourth vector; at the hub node, comparing the length of the first vector and the third vector, and, if the first and third vectors have different lengths, truncating by removing a number of entries from the end of the longer one of the first and third vectors so that the first and third vectors have the same length, and either; if the first vector has a greater length, sending a truncation message to the first endpoint node to remove the number of entries from the end of the second vector; or if the third vector has a greater length, sending a truncation message to the second endpoint node to remove the number of entries from the end of the fourth vector; at the first endpoint node, if a truncation message is received, truncating by removing the number of entries from the end of the second vector; at the second endpoint node, if a truncation message is received, truncating by removing the number of entries from the end of the second vector; at the hub node, deriving a fifth vector which is the result of an XOR of the first and third vectors after any truncation, and sending the fifth vector to whichever one of the first and second endpoint nodes is the node identified as the secondary randomness sharer;059645.00198 at the node identified as the secondary randomness sharer, deriving a sixth vector which is the result of an XOR of the fifth vector with either the second vector, if the first endpoint node is the secondary randomness sharer, or the fourth vector, if the second endpoint node is the secondary randomness sharer, and storing the sixth vector; and at the node identified as the primary randomness sharer, storing either the second vector, if the first endpoint node is the primary randomness sharer, or the fourth vector, if the second endpoint node is the primary randomness sharer; whereby the first and second endpoint nodes have shared randomness represented by the sixth vector and the one of the second or fourth vector which was stored.

63. The method of claim 62, wherein each of the first to sixth blocks comprises (4*n)+β(2*n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared- randomness request, and β(x) is a buffer function.

64. The method of claim 63, where ^^(^^)= ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), where ^^ is the number of bits of shared randomness to be generated, and the ceiling function up to the nearest integer.

65. The method according to any one of claims 57 to 60, and further comprising, if the check finds that there is sufficient entropy, generating shared randomness by: at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the first endpoint node by the first intermediate node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the second endpoint node by the second intermediate node; at the first endpoint node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the second endpoint node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the first intermediate node, identifying a fifth block of unused corresponding bits of the stored pairs of bit strings which were sent to the first endpojnt node; at the second intermediate node, identifying a sixth block of unused corresponding bits of the stored pairs of bit strings which were sent to the second endpoint node; wherein each of the first to sixth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the first endpoint node, and sending the first bit string of the second block to the second endpoint node;059645.00198 at the first intermediate node, sending the first bit string of the fifth block to the first endpoint node, at the second intermediate node, sending the first bit string of the sixth block to the second endpoint node, at the hub node, deriving a first vector which is the result of an XOR of the second bit string of the first block and the second bit string of the second block, and sending the first vector to whichever one of the first and second endpoint nodes is identified as the secondary randomness sharer; at the node identified as the secondary randomness sharer, deriving a second vector which is the result of an XOR of the first vector with either; the second bit string of the third block, if the first endpoint node is the secondary randomness sharer, or the second bit string of the fourth block, if the second endpoint node is the secondary randomness sharer; at the node identified as the primary randomness sharer, deriving a third vector which is either; the second bit string of the third block, if the first endpoint node is the primary randomness sharer, or the second bit string of the fourth block, if the second endpoint node is the primary randomness sharer; at the first endpoint node, comparing each entry in the first bit string of the first block with the corresponding entries in the first bit string of the third block and the first bit string of the fifth block, and recording first position numbers for which these all three of these entries are the same; at the second endpoint node, comparing each entry in the first bit string of the second block with the corresponding entries in the first bit string of the fourth block and the first bit string of the sixth block, and recording second position numbers for which these all three of these entries are the same; the first endpoint node and the second endpoint node communicating and identifying position numbers for which both the first position numbers and the second position numbers indicate the respective three entries are all the same; at the node identified as the primary randomness sharer, referring to the entries in the third vector at positions corresponding to the identified position numbers and assigning the values at the identified position numbers to a fourth vector; at the node identified as the secondary randomness sharer, referring to the entries in the second vector at positions corresponding to the identified position numbers and assigning the values at the identified position numbers to a fifth vector; at the node identified as the primary randomness sharer, storing the fourth vector; and at the node identified as the secondary randomness sharer, storing the fifth vector; whereby the first and second endpoint nodes have shared randomness represented by the fourth vector and the fifth vector.059645.00198 66. The method of claim 65, wherein each of the first to sixth blocks comprises (16*n)+β(8*n) pair of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared- randomness request, and β(x) is a buffer function.

67. The method of claim 66, where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√^^), and where ^^ is the number of bits of shared randomness to be generated, and the ceiling function rounds up to the nearest integer.

68. The method according to any one of claims 58 to 61, and further comprising, if the check finds that there is sufficient entropy, generating shared randomness by: assigning one of the first endpoint node and the second endpoint node as the Side 1 participant node and the other as the Side 2 participant node; at the hub node, identifying a first block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 1 participant node by the first intermediate node, and identifying a second block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 2 participant node by the second intermediate node; at the Side 1 participant node, identifying a third block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the Side 2 participant node, identifying a fourth block of unused corresponding bits of the stored pairs of bit strings including the re-set values; at the first intermediate node, identifying a fifth block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 1 participant node; at the second intermediate node, identifying a sixth block of unused corresponding bits of the stored pairs of bit strings which were sent to the Side 2 participant node; wherein each of the first to sixth blocks comprises sufficient corresponding bits to fulfil the shared randomness request; at the hub node, sending the first bit string of the first block to the Side 1 participant node; at the first intermediate node, sending the first bit string of the fifth block to the hub node and to the Side 1 participant node; at the Side 1 participant node, sending the first bit string of the third block to the hub node; at each of the hub node and the Side 1 participant node, comparing a value of each bit in the first bit string of the first block to the value of the corresponding bit in each of the first bit string of the third block and the first bit string of the fifth block, and recording as first position numbers the position numbers for which all three of these values are the same; at the hub node, referring to the recorded first position numbers in the second bit string of the first block, and placing the values at these positions in the second bit string into a first vector;059645.00198 at the Side 1 participant node, referring to the recorded first position numbers in the second bit string of the third block, and placing the values at these positions in the second bit string into a second vector; at the hub node, comparing the length of the first vector and the second block, and, if the first vector and the second block have different lengths, truncating by removing a number of entries from the end of the longer one of the first vector and the second block so that the first vector and the second block have the same length, and, if the first vector was longer than the second block, sending a truncation message to the Side 1 participant node instructing it to remove the number of entries from the second vector, or, if the second block was longer than the first vector, sending a truncation message to the Side 2 participant node instructing it to remove the number of entries from the fourth block; at the Side 1 participant node, if the truncation message is received, removing the number of entries from the second vector; at the Side 2 participant node, if the truncation message is received, removing the number of entries from the fourth block; at the hub node, sending the first bit string of the second block to the Side 2 participant node; at the second intermediate node, sending the first bit string of the sixth block to the Side 2 participant node; at the hub node, deriving a third vector which is the result of an XOR of the first vector with the second bit string of the second block; at the hub node, sending the third vector to the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, deriving a fourth vector which is the result of an XOR of the third vector with either; the second vector if the Side 1 participant node is identified as the secondary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the secondary randomness sharer; at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, deriving a fifth vector which is either: the second vector if the Side 1 participant node is identified as the primary randomness sharer, or the second bit string of the fourth block if the Side 2 participant node is identified as the primary randomness sharer: at the Side 2 participant node, comparing a value of each bit in the first bit string of the second block to the value of the corresponding bit in each of the first bit string of the fourth block and the first bit string of the sixth block, recording as second position numbers the position numbers for which all three of these values are the same, and sending the second position numbers to the Side 1 participant node;059645.00198 at the one of the Side 1 participant node and the Side 2 participant node identified as the primary randomness sharer, referring to the recorded second position numbers in the fifth vector, assigning the values at these positions to a sixth vector, and storing the sixth vector; at the one of the Side 1 participant node and the Side 2 participant node identified as the secondary randomness sharer, referring to the recorded second position numbers in the fourth vector, assigning the values at these positions to a seventh vector, and storing the seventh vector; whereby the first and second endpoint nodes have shared randomness represented by the sixth vector and the seventh vector.

69. The method of claim 68, wherein the shared-randomness request identifies which of the first and second endpoint nodes is to be the Side 1 participant node and which is to be the Side 2 participant node.

70. The method according to claim 69, wherein only one of the first and second endpoint nodes sends the shared-randomness request to the hub node, and the identity of the sending node is used to identify which node is to be the Side 1 participant node and which is to be the Side 2 participant node, wherein either: the one of the first and second endpoint nodes sending the shared-randomness request is identified as the Side 1 participant node and the other one of the first and second endpoint nodes is identified as the Side 2 participant node; or the one of the first and second endpoint nodes sending the shared-randomness request is identified as the Side 2 participant node and the other one of first and second endpoint nodes is identified as the Side 1 participant node.

71. The method of any one of claims 68 to 70, wherein each of the first, third and fifth blocks comprises (16*n)+β(8*n) pairs of bits and each of the second, fourth and sixth blocks comprises (4*n) + β(2*n) pairs of bits, where n is the number of bits of shared randomness to be generated to fulfil the shared-randomness request, and β(x) is a buffer function.

72. The method of claim 71, where ^^( ^^) = ^^ ^^ ^^ ^^ ^^ ^^ ^^(3√ ^^) where the ceiling function rounds up to the nearest integer and x is the expected amount of shared randomness.

73. The method of any one of claims 61 to 72, wherein the first and second endpoint nodes agree which of the methods of claims 62, 65 and 68 is to be used, and the shared randomness request identifies which of these methods is to be used.059645.00198 74. A system comprising a plurality of nodes arranged to carry out the method of any preceding claim.

75. A computer program comprising instructions which, when executed by processors of a plurality of nodes, cause the nodes to carry out the method of any one of claims 1 to 73.

Images