Distributed symmetric encryption

Abstract

Systems and methods for improved distributed symmetric cryptography are disclosed. A client computer can communicate with a number of cryptographic devices to encrypt or decrypt data. Each cryptographic device can possess a secret share and a verification share that can be used in a process of encrypting or decrypting data. The client computer can generate a commitment and send the commitment to the cryptographic devices. Each cryptographic device can generate a partial computation based on the commitment and the cryptographic device's respective secret share, and a partial signature based on the commitment and the cryptographic device's respective verification share. The partial computation and the partial signature can be sent to the client computer. The client computer can use the partial computation and the partial signature to generate a cryptographic key and a verification signature, respectively. The client computer can use the cryptographic key to encrypt or decrypt a message.

Description

[0001] Cross-referencing related applications

[0002] This application is an international patent application that claims the benefit of U.S. Patent Application No. 16 / 779,422, filed on January 31, 2020, which is incorporated herein by reference in its entirety for all purposes. Background Technology

[0003] "Cryptography as a Service" refers to the process by which one entity performs cryptographic operations on behalf of another. For example, a server computer can encrypt data (such as sensitive medical records or other private documents) on behalf of a client computer. Later, when the client computer wants to retrieve the encrypted data, it can communicate with the server computer to decrypt it. Alternatively, the client computer can send the encrypted data to another client computer. This other client computer can then communicate with the server computer to decrypt the encrypted data. Therefore, cryptography as a Service can be used to protect data across time or space. Cryptography as a Service can be desirable because servers may have a greater capacity to store sensitive cryptographic information, such as secret cryptographic keys.

[0004] Distributed cryptography using a shared secret is a technique that can be used to implement cryptography as a service. Rather than a single server computer performing cryptography against a client computer, a distributed network of cryptographic devices (e.g., server computers) can collectively perform cryptography against client computers. Cryptographic materials, such as a secret key or shared secret, can be divided into secret shares and distributed among the cryptographic devices. These parties can then collectively perform encryption or decryption using their respective secret shares. Distributed cryptography offers security benefits compared to conventional cryptography because it is much more difficult for an attacker to obtain the shared secret. An attacker must obtain multiple secret shares to reconstruct the secret key or shared secret or otherwise compromise the cryptographic system. In contrast, when performing cryptography using a non-shared secret, a hacker may only need to obtain the non-shared secret to compromise the cryptographic system.

[0005] Distributed or other cryptographic methods can be classified as symmetric or asymmetric. With symmetric cryptography, the same key can be used to encrypt and decrypt data. With asymmetric cryptography, two keys are used. Data encrypted with one key must be decrypted with the other, and vice versa. Asymmetric cryptography is typically much slower than symmetric cryptography, in some cases by three to five orders of magnitude. Therefore, symmetric cryptography is generally preferred for high-speed or high-throughput cryptography-as-a-service applications.

[0006] However, distributed symmetric cryptography-as-a-service has some undesirable characteristics. As an example, it can be difficult to determine whether a client computer is encrypting or decrypting data. Because both encryption and decryption use the same cryptographic key, a client computer could claim to be using the service to encrypt data when it is actually decrypting it. This can be problematic because it makes it difficult to log or otherwise record client computer activity. Malicious client computers could abuse the system, falsely claiming to perform encryption operations in order to, for example, secretly decrypt data that a malicious client does not have access to.

[0007] Therefore, there is a need to improve distributed symmetric encryption. Summary of the Invention

[0008] The embodiments relate to improved systems and methods for distributed symmetric cryptography. A client computer and multiple cryptographic devices from a network of cryptographic devices can work together to generate symmetric cryptographic keys and verify signatures. The client computer can use the cryptographic keys to encrypt messages and generate ciphertext.

[0009] The client computer (or receiving computer) and the cryptographic device can also work together to decrypt the ciphertext and generate the message. During decryption, the client computer can provide a verification signature to the cryptographic device. The cryptographic device can verify the verification signature. If the verification signature is valid, the cryptographic device can work with the client computer to generate the cryptographic key again. The client computer can then use the cryptographic key to decrypt the ciphertext. The cryptographic device can determine whether the client computer is encrypting the message or decrypting the ciphertext based on the verification signature, because the verification signature is generated during encryption and verified during decryption.

[0010] One embodiment relates to a method comprising, performed by a computer system: generating a commitment using a message and a random value; sending a request including the commitment to each of a plurality of cryptographic devices, the plurality of cryptographic devices storing a plurality of secret shares generated from a secret value and a plurality of verification shares generated from a verification value, the request instructing each of the plurality of cryptographic devices to perform a cryptographic function corresponding to encryption; receiving a plurality of partial computations from the plurality of cryptographic devices, wherein the plurality of partial computations are generated by the plurality of cryptographic devices using the plurality of secret shares and the commitment; receiving a plurality of partial signatures from the plurality of cryptographic devices, wherein the plurality of partial signatures are generated by the plurality of cryptographic devices using the plurality of verification shares and the commitment; generating a cryptographic key based on the plurality of partial computations; generating a verification signature based on the plurality of partial signatures; generating ciphertext by encrypting the message and the random value using the cryptographic key; and generating a payload including the ciphertext, the verification signature, and the commitment.

[0011] Another embodiment relates to a method comprising, performed by a computer system: sending a verification signature and a commitment to a plurality of cryptographic devices, wherein the plurality of cryptographic devices verify the verification signature using a verification key and the commitment; receiving a plurality of partial computations, wherein the plurality of partial computations are generated by the plurality of cryptographic devices using a plurality of secret shares and the commitment; generating a cryptographic key based on the plurality of partial computations; and using the cryptographic key to decrypt ciphertext to generate a message and a random value.

[0012] Another embodiment relates to a method comprising being performed by a cryptographic device: receiving a request from a client computer, the request including a commitment generated using a message and a random value; determining, based on the content of the request, that the client computer wants to encrypt the message; generating a partial computation based on a secret share and the commitment; generating a partial signature based on a verification share and the commitment; and sending the partial computation and the partial signature to the client computer, thereby enabling the client computer to: (1) generate a cryptographic key using the partial computation, (2) encrypt the message using the cryptographic key, thereby generating ciphertext, (3) generate a verification signature using the partial signature, and (4) generate a payload including the ciphertext, the verification signature, and the commitment.

[0013] These and other embodiments of this disclosure are described in detail below. For example, other embodiments relate to systems, apparatuses, and computer-readable media associated with the methods described herein.

[0014] Before discussing specific embodiments of the present invention, some terms may be described in detail.

[0015] the term

[0016] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can include a mainframe, a small cluster of computers, or a group of servers operating as a single unit. In one instance, a server computer can include a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0017] "Memory" can be any suitable device or devices capable of storing electronic data. Suitable memory can include non-transient computer-readable media whose storage can be executed by a processor to implement desired methods. Instances of memory can include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0018] "Processor" can refer to any suitable one or more data computing devices. A processor can include one or more microprocessors that work together to perform the desired function. A processor can include a CPU, which includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. The CPU can be a microprocessor such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0019] The term "cryptographic key" can include data used in encryption or decryption. For example, a cryptographic key can refer to the product of two large prime numbers. Cryptographic keys can be used in cryptosystems such as RSA (Rivest, Shamir, Adleman) or AES (Advanced Encryption Standard) and can be used to encrypt plaintext and produce ciphertext output, or to decrypt ciphertext and produce plaintext output. Cryptographic keys can be symmetric, in which case the same key is used for both encryption and decryption, or asymmetric, in which case different keys are used for both encryption and decryption.

[0020] The term "plaintext" can refer to unencrypted or plain text. For example, it can refer to text that can be read by humans or computers without any processing, such as the phrase "Hello, how have you been?" Numbers or other symbols are also suitable as plaintext.

[0021] The term "ciphertext" can refer to text in an encrypted form. For example, it can refer to text that must be decrypted before it can be read by a human or computer. Ciphertext can be generated using any cryptographic algorithm or cryptographic system, such as RSA or AES.

[0022] "Client computer" can refer to a computer that uses services from other computers or devices, such as server computers. Client computers can connect to these other computers or devices via a network, such as the Internet. For example, a client computer may include a laptop computer that connects to an image hosting server to view images stored on the image hosting server.

[0023] A “cryptographic device” can refer to any device capable of performing cryptographic operations, including encryption and decryption. Cryptographic devices can participate in distributed or multi-party cryptography. Examples of cryptographic devices include server computers, hardware security modules, desktop computers, laptops, smartphones, smartwatches, or other portable electronic devices. Cryptographic devices can possess a “secret” or a “secret share.”

[0024] A "proxy device" can refer to a device that acts as a proxy. A proxy device can perform operations on behalf of other devices. For example, a proxy device can receive and send messages or other data on behalf of other devices. A proxy device used to route communication between other devices in a device network can be called a "hub device".

[0025] The term "multi-party computation" refers to a computation performed by multiple parties. Each party, such as a computer, server, or cryptographic device, may have some computational inputs. The parties can use these inputs to collaboratively compute the output of the computation.

[0026] The term "secure multi-party computation" can refer to secure multi-party computation. In some cases, "secure multi-party computation" means multi-party computation in which the parties do not share information or other inputs with each other. An example is Yao's Millionaires' problem, in which two millionaires want to determine who is richer without revealing their wealth to each other.

[0027] A "secret value" or "secret" can refer to a value or thing that is hidden as part of a cryptographic process. The security of a cryptographic process may depend on the secrecy of the secret. A secret may include a cryptographic key or a "secret share." Exposure of a secret may allow parties other than the intended parties to encrypt or decrypt messages.

[0028] A "shared secret" can refer to a secret value or thing shared among multiple parties. For example, a shared secret could be a cryptographic key that is divided so that each of the multiple parties possesses a portion of the key. For instance, two parties could each possess 64 bits of a shared secret that includes a 128-bit cryptographic key.

[0029] A "secret share" can refer to a value derived from a shared secret. For example, a secret share can include the first 64 bits of a secret value. A secret share can also include a secret value combined with numbers or other data. In some cases, multiple secret shares can be combined to reproduce a shared secret.

[0030] A hash function can refer to any function that can be used to map data of arbitrary length or size to data of fixed length or size. Hash functions can also be used to obfuscate data by replacing it with its corresponding hash value. Hash functions can be used to generate "commitment" or "commitment message" data that can be used to assess the integrity of encrypted data.

[0031] A "commitment" or "commitment message" refers to data that can be used to verify that a certain action has been followed. In a cryptographic context, a commitment can refer to a message that can be used to verify that an encrypted message has not been tampered with. Before the message is encrypted, a commitment can be generated based on the message, for example, using a hash function. This commitment can be sent along with the encrypted message. After the message is decrypted, the recipient can use the same hash function to generate their own commitment message. The received commitment message and the generated commitment message can be compared to verify the integrity of the encrypted message.

[0032] A "pseudo-random function" can refer to a deterministic function that produces seemingly random outputs. Pseudo-random functions can include collision-resistant hash functions and elliptic curve cryptography. A pseudo-random function approximates a random oracle; it is an ideal cryptographic primitive that maps an input to a random output in its output domain. A pseudo-random function can be constructed from a pseudo-random number generator.

[0033] A "random temporary number" or "cryptographic temporary number" refers to a random value (e.g., a random number) that can be preferentially used a finite number of times during the cryptographic process. Random temporary numbers can be generated randomly or pseudo-randomly and can be used in conjunction with cryptographic hash functions. Random temporary numbers can prevent some cryptographic attacks, such as "replay attacks".

[0034] "Non-interactive zero-knowledge proofs of knowledge" refer to zero-knowledge proofs of knowledge that do not require interaction between the proving entity and the verifying entity. A "zero-knowledge proof of knowledge" is a method by which a proving entity can prove to a verifying entity that its statement about the secret is correct without revealing any additional information about the secret. Non-interactive zero-knowledge proofs of knowledge can be used to verify the accuracy or performance of computations.

[0035] A "verification value" can refer to data used to verify calculations, facts, or knowledge. An example of a verification value is a non-interactive zero-knowledge proof of knowledge, as discussed above. Another example of a verification value is a cryptographic key. For instance, a private cryptographic key can be used to verify the identity of a person or computer possessing that key by signing or encrypting data using that private cryptographic key. A verification value that includes a cryptographic key can be called a "verification key".

[0036] A "validation share" can refer to a portion of a validation value or data derived from a validation value. Multiple validation shares can be combined in a certain way to produce a corresponding validation value. For example, the product of a series of validation shares can equal the corresponding validation value.

[0037] "Signature," "digital signature," or "signature verification" can refer to data used to verify the authenticity of data using cryptography. A computer can digitally sign data by encrypting it using a cryptographic key (i.e., a private key) known only to that computer. Other computers can verify the signature by decrypting the data using a publicly known cryptographic key corresponding to that computer (i.e., a public key). Signature verification can be used to verify the origin or authenticity of signed data.

[0038] A "partial signature" can refer to a portion of a digital signature. A partial signature can be combined with other partial signatures to reproduce the digital signature. For example, the XOR of multiple partial signatures can be used to reproduce a digital signature.

[0039] "Partial computation" can refer to a portion of a computation. Multiple partial computations can be combined to produce the output of a computation. For example, the volumes of multiple solids can include partial computations of the total volume of those solids, and these partial computations can be combined by addition. Partial computations can be generated by multiple parties or cryptographic devices participating in a multi-party computation.

[0040] A "message" can refer to any data that can be sent between two entities. A message can include plaintext or encrypted data. A message can include alphanumeric sequences (e.g., "hello123") or any other data (e.g., an image or video file). Messages can be sent between computers or other entities.

[0041] "Payload" refers to the information in the sent message. The payload excludes automatically generated metadata. A payload may include multiple data elements. For example, a payload corresponding to human vital statistics may include three data values: weight, height, and age.

[0042] A "key generation seed" can refer to a value or other data used to generate a cryptographic key. For example, a key generation seed can be a number, such as "12034024". The key generation seed can be used as input to a random or pseudo-random function to generate a cryptographic key. The key generation function can be consistent; that is, the same key generation seed will generate the same cryptographic key. Attached Figure Description

[0043] Figure 1 A system block diagram of an exemplary distributed symmetric cryptography system according to some embodiments is shown.

[0044] Figure 2 A system block diagram of an exemplary client computer according to some embodiments is shown.

[0045] Figure 3 A system block diagram of an exemplary cryptographic device according to some embodiments is shown.

[0046] Figure 4 A system block diagram of an exemplary secret share and verification share pre-allocation system according to some embodiments is shown.

[0047] Figure 5 A sequence diagram illustrating an exemplary secret share and verification share pre-allocation process according to some embodiments is shown.

[0048] Figure 6 A hybrid sequence diagram illustrating an exemplary method of distributed symmetric encryption is shown.

[0049] Figure 7 A hybrid sequence diagram illustrating an exemplary method for distributed symmetric decryption is shown.

[0050] Figure 8 A hybrid sequence diagram illustrating exemplary methods for improved distributed symmetric encryption according to some embodiments is shown.

[0051] Figure 9 A hybrid sequence diagram illustrating exemplary methods for improved distributed symmetric decryption according to some embodiments is shown.

[0052] Figure 10 An exemplary computer system according to some embodiments is shown. Detailed Implementation

[0053] Some embodiments relate to improvements to distributed symmetric cryptography, which includes both distributed symmetric encryption and distributed symmetric decryption as services.

[0054] Client computers and multiple cryptographic devices in a network can work together to encrypt messages or decrypt ciphertext. Not all cryptographic devices in the network necessarily need to participate; only a threshold number are required. For example, in a network with ten cryptographic devices, perhaps only seven need to participate.

[0055] During distributed symmetric encryption, a client computer can generate a commitment to the message to be encrypted. This commitment may include a hash of the message. The client computer can then send the commitment to participating cryptographic devices.

[0056] The cryptographic device can store secret shares for encryption or decryption, as well as verification shares. Participating cryptographic devices can generate multiple partial computations using commitments and their corresponding secret shares. These secret shares may correspond to a shared secret. Threshold numbers of these secret shares can be combined in some way to reproduce the shared secret.

[0057] Similarly, multiple participating cryptographic devices can use the commitment and its corresponding verification shares to generate multiple partial signatures. These verification shares may correspond to verification values. A threshold number of these verification shares may be combined in some cases to reproduce the verification value. In some embodiments, the verification value may correspond to a verification key.

[0058] The participating cryptographic devices can send multiple parts of the computation and multiple parts of the signature to the client computer. The client computer can use the multiple parts of the computation to generate a cryptographic key and use the multiple parts of the signature to generate a verification signature. The client computer can use the cryptographic key to encrypt the message to produce ciphertext.

[0059] To decrypt the message, the client computer (which may be the same computer system used for encryption) may send the commitment and verification signature to multiple additional cryptographic devices. These additional cryptographic devices may include the same cryptographic devices used during distributed symmetric encryption, or multiple different cryptographic devices that store the corresponding secret and verification keys. The verification key may include a public key corresponding to the verification value, which may include a private key.

[0060] Multiple additional cryptographic devices can use a verification key to verify the verification signature. If the verification signature is valid, the multiple additional cryptographic devices can generate multiple additional partial computations and send these computations to the client computer. The client computer can use these computations to generate a cryptographic key, and then use the key to decrypt the message. In these ways, the client computer and cryptographic devices can perform distributed symmetric cryptography.

[0061] Some embodiments are described in more detail below with reference to the figures. Concepts such as secret sharing and distributed pseudo-random functions are described in Section I. See Section II for more details. Figure 1 Describe an exemplary distributed cryptographic network. See Section II for reference. Figure 2 An exemplary client computer is described. See Section II for reference. Figure 3 An exemplary cryptographic device is described. See Section III for reference. Figure 4 and 5 Exemplary systems and methods for the allocation of secret shares are described. See Sections IV and V for reference. Figure 6 and 7 Describe methods for distributed symmetric cryptography (without verifying signatures). See Sections VI and VII for reference. Figure 8 and 9 Describes improved methods for distributed symmetric cryptography (i.e., with verified signatures). See Section VIII for reference. Figure 10 Describe a computer system.

[0062] I. Overview of Distributed Symmetric Cryptography

[0063] Some embodiments may utilize secret sharing, pseudo-random functions, and distributed pseudo-random functions to implement distributed symmetric cryptography. These concepts are described in more detail below.

[0064] A. Secret Shares and Verified Shares

[0065] As mentioned above, secret shares can be derived from a shared secret. Both the shared secret and secret shares can be used to perform cryptographic operations. For example, a shared secret or secret shares can be used to generate a cryptographic key. Secret shares can be combined in some way to reproduce the shared secret from which those secret shares were derived. In some cryptographic applications, using secret shares may be preferable to using a non-shared secret because a malicious user must steal multiple secret shares to reproduce and obtain the shared secret. In contrast, in a non-distributed cryptographic system, a malicious user only needs to steal a single secret value to obtain the secret.

[0066] A verification share can be similar to a secret share. A verification share can correspond to a verification value, similar to how a secret share corresponds to a shared secret. Verification shares can be combined in some way to reproduce the verification value. In some embodiments, methods for generating, allocating, or combining verification shares can also be used to generate, allocate, or combine verification shares.

[0067] The verification share can be used to generate a verification signature, which can be used to verify distributed symmetric cryptographic operations. For example, in some embodiments, the cryptographic device verifies the verification signature during distributed symmetric decryption. The presence of the verification signature indicates to the cryptographic device that a client computer is performing a decryption operation.

[0068] Secret shares and verification shares can possess several useful optional properties. One such property is the "t out of n" property. This property indicates that taking t secret shares or verification shares out of a total of n secret shares or verification shares is sufficient to reproduce the shared secret or verification value. Furthermore, it may not matter which secret shares or verification shares are used to reproduce the shared secret, as long as at least t secret shares or verification shares are used.

[0069] Many techniques can be used to implement secret sharing, particularly the t-of-n secret sharing. The Shamir secret sharing scheme is a non-limiting example discussed below. However, other suitable secret sharing techniques are equally applicable.

[0070] In summary, Shamir secret sharing involves encoding a shared secret (or, a verification value) into a polynomial P(x) = a0 + a1x + a2x 2 +…+a k x kThe coefficients are in the formula. A secret share or a verification share can include distinct points on a polynomial (pairs of x, P(x) values). A shared secret or verification value can be obtained from a secret share or verification share by interpolating the polynomial using the secret share or verification share. Lagrange interpolation is one available method.

[0071] A polynomial of degree k may include k+1 coefficients a0, a1, ..., a k While a shared secret or verification value can be encoded as any coefficient, it is sometimes preferable to encode it as a zero-order coefficient a0. This can be achieved by converting the shared secret or verification value to a number and then using that number as a0. Other coefficients a1, a2, ..., a k The value of can be chosen in any appropriate way (e.g., randomly). If the shared secret S is encoded as zero-order coefficients a0, then the polynomial evaluated at x = 0 is equal to the shared secret, i.e., P(0) = a0 = S.

[0072] Shamir secret sharing utilizes the fact that k+1 unique points are needed to uniquely define a polynomial of degree k. k+1 is the minimum or threshold number of points required to interpolate the polynomial and determine the shared secret or verification value. Therefore, k+1 can be called the threshold number t. This property implements "threshold-authenticated cryptography." When a share of the secret is distributed among multiple cryptographic devices (e.g., one share per device) and those devices participate in distributed cryptographic operations, at least the threshold number of devices must participate to reach the threshold number of secret shares.

[0073] Furthermore, since the secret share (or verification share) comprises points on a polynomial (there are infinitely many), the Shamir secret share can provide an arbitrarily large number of secret shares for any given threshold. This means that a network of cryptographic devices can have an arbitrarily large number of cryptographic devices for any given threshold.

[0074] The polynomial P(x) and therefore the shared secret (or verification value) S can be determined using Lagrange interpolation, which can be used to include pairs of (x) j ,P(x j The secret share or verification share of the value is related to the polynomial P(x). The pair (x) j 、P(x j The j-th secret share corresponds to the 1 / j-th secret share. The Lagrange form of the polynomial is given by the following formula:

[0075]

[0076] Among them l j(x) is the j-th Lagrange polynomial (i.e., corresponding to the j-th secret share). Lagrange polynomial l j (x) is defined by the following formula:

[0077]

[0078] Where x j It is the x value corresponding to the j-th secret share (or verification value), and x p It is the x value of the p-th secret share (or verification value).

[0079] Since the zero-order coefficient a0 equals P(0) when the shared secret or verification value S is encoded as a zero-order coefficient a0, the aforementioned formula can be simplified by replacing x = 0:

[0080]

[0081]

[0082] Shamir secret shares can be used to assign secret shares or verification values ​​to a number of cryptographic devices. These secret shares or verification shares can include values ​​in pairs (x, y ... j ,P(x j The unique point given. As shown above, using the threshold number of these secret shares or verification values, the Lagrange coefficient l can be calculated. j and compare it with the value P(x) j Used together to determine the shared secret (or verification value) S.

[0083] It is worth noting that the shared secret or verification value can be reconstructed regardless of which secret or verification shares are used. Therefore, different cryptographic devices can participate in distributed cryptographic operations each time and will still produce the same shared secret or verification value. However, sometimes it is preferable to produce a value derived from the shared secret or verification value, rather than the shared secret or verification value itself. This can be achieved using distributed pseudo-random functions, as described below.

[0084] B. Pseudo-random and distributed pseudo-random functions

[0085] A pseudo-random function is a function that produces an output where the relationship between the input and the output appears random. The advantage of using pseudo-random functions is that the input is difficult to determine given the output, and therefore pseudo-random functions can be used with fuzzy inputs.

[0086] In a hypothetical cryptographic application, a shared secret S may include a cryptographic key. The shared secret S is defined by the fact that it comprises secret shares s0, s1, ..., s2. tThe shared secret can be used to encrypt or decrypt data during reconstruction. However, this may be undesirable because after reconstruction, the shared secret could be stolen and used by malicious actors (e.g., malicious client computers or malicious cryptographic devices). Instead, it might be preferable to use the shared secret as input to a pseudo-random function, and then use the output of the pseudo-random function as the cryptographic key, or use the output of the pseudo-random function to generate the cryptographic key. In this way, the shared secret S is not exposed.

[0087] A distributed pseudorandom function refers to a pseudorandom function that can be computed in a distributed manner. For example, multiple cryptographic devices can compute multiple parts of the computation. These parts can be combined to produce the output of a pseudorandom function. The combination of those parts is equivalent to the output of the corresponding non-distributed pseudorandom function.

[0088] Any seemingly random and consistent pseudo-random function can be used as the basis for a distributed pseudo-random function. Notable examples of pseudo-random functions are hash functions and cryptographic systems such as the Advanced Encryption Standard (AES) and elliptic curve cryptography. Elliptic curve cryptography will be described below for the purpose of illustrating some embodiments; however, it should be understood that embodiments can be practiced with any suitable pseudo-random function.

[0089] Elliptic curves are those that satisfy the equation y 2 =x 3 Any curve with the value +ax + b. Elliptic curve cryptography is typically performed using elliptic curves over finite fields. An example of a finite field is an integer mod p, where p is a prime number. A set of elliptic curves can be limited by its order q, which is the number of elements in the set. The decisional Diffie-Hellman assumption still holds under these sets of elliptic curves.

[0090] Like many other cryptosystems, elliptic curve cryptography relies on a mathematical problem for which computational solutions are infeasible. Currently, there is no efficient solution to the "elliptic curve discrete logarithm problem" in elliptic curve cryptography. Given an initial point A on an elliptic curve and a product point C on the elliptic curve, it is extremely difficult to determine the multiplicand B such that the dot product A*B = C holds. In practice, as long as B remains hidden, the message can be transformed into point A and multiplied by point B to produce the product point C.

[0091] The decisional Diffie-Hellman hypothesis states that in a multiplication group G of order p with generator g, for random and independent a and b, the value g a g b and g ab They all appear to be random elements selected from the set G. In other words, it is difficult to determine g. a g b and g abThe multiplication relationship between them (i.e., the multiplication relationship between g) ab equals g a and g b (product).

[0092] In fact, two points on an elliptic curve can be multiplied to produce a third point, and the relationship between the two points and the third point appears to be random. Therefore, if a value can represent a point, that value can be multiplied by another value to produce a third value, and the relationship between these three values ​​appears to be random. Thus, elliptic curves can be used as the basis for pseudo-random functions in distributed pseudo-random functions.

[0093] C. Application

[0094] In some embodiments, elliptic curve cryptography can be used to encrypt a commitment H(m) (i.e., a hash value corresponding to the input message m) using multiple secret shares. These encrypted commitments can be referred to as partial computations. As shown below, partial computations can be combined to produce a value equal to the commitment H(m) encrypted using a shared secret S, thus demonstrating that elliptic curve cryptography can be used as a distributed pseudo-random function.

[0095] Item H(m) S This can be used to represent a commitment H(m) encrypted using elliptic curve cryptography with a shared secret S. It can be used to represent including the use of secret shares. i The partial computation of the encrypted commitment H(m). In elliptic curve cryptography, this encryption is equivalent to multiplying the commitment H(m) itself by S or s. i times.

[0096] H(m) S and The relationship between them can be shown using formula (4):

[0097]

[0098] Where s i It is the i-th secret share, and λ i It corresponds to s i The i-th Lagrange coefficient (see Equation (3)). Therefore, the commitment encrypted using the shared secret S (i.e., H(m)) S This is equal to the product of commitments encrypted with secret shares and raised to the power of Lagrange coefficients. This illustrates one way that Shamir secret sharing and elliptic curve cryptography can be used together to implement a distributed pseudo-random function. In some embodiments, the output of the distributed pseudo-random function can be used to generate cryptographic keys that can be used for encryption and decryption (e.g., as a key generation seed, using a key generation function). As long as a consistent commitment H(m) is used, the cryptographic keys will be consistent, and thus the same cryptographic key can be generated and used to encrypt messages and decrypt corresponding ciphertexts.

[0099] In summary, in the context of some embodiments, each cryptographic device may possess a secret share s i A threshold number of cryptographic devices can participate in multi-party cryptographic operations. A client computer may possess a message m that the client computer wants to encrypt. The client computer may generate a promise H(m) for the message and send the promise to the participating cryptographic devices. Each participating cryptographic device may use its corresponding secret share s. i To encrypt the commitment m, thereby generating multiple parts of computation during the process. The participating cryptographic devices can compute multiple parts. Send to the client computer. The client computer can determine the calculation corresponding to multiple parts. Lagrange coefficient λ i The client computer can use its corresponding Lagrange coefficient λ. i Multiple parts are exponentially calculated to produce multiple intermediate calculations. The client computer can combine these intermediate calculations by calculating their product. The product of the intermediate calculations is equivalent to a commitment H(m) encrypted using a shared secret S (i.e., H(m)). S The intermediate product can be used as a seed for key generation to produce a cryptographic key. This cryptographic key can be used to encrypt messages on the client computer and generate ciphertext. The same process occurs when the ciphertext is to be decrypted, and the same cryptographic key is generated. The ciphertext can be decrypted using the cryptographic key, thereby generating message m.

[0100] In some embodiments, a similar method can be used to generate the verification signature. The client computer can send the commitment H(m) of message m to multiple cryptographic devices. The multiple cryptographic devices can use elliptic curve cryptography to encrypt the commitment H(m) using each of their respective verification shares to generate multiple partial signatures. The multiple cryptographic devices can then send the multiple partial signatures to the client computer. The client computer can determine multiple Lagrange coefficients λ corresponding to the multiple partial signatures. i Then, each partial signature is exponentially used with its corresponding Lagrange coefficient to generate multiple intermediate signatures. The client computer can generate a verification signature as the product of these intermediate signatures. The verification signature can be equivalent to a commitment H(m) encrypted using a verification value.

[0101] The verification value and verification key can include an asymmetric cryptographic key pair. That is, the verification value can include a secret or private cryptographic key, while the verification key can include a public cryptographic key, or vice versa. To verify the verification signature, the cryptographic device can use the verification key to decrypt the verification signature to generate a commitment H(m). If the commitment H(m) matches the commitment received from the client computer, the verification signature is valid.

[0102] The foregoing examples are intended as a non-limiting example of how shared secrets and distributed pseudo-random functions can be used to perform distributed symmetric cryptography according to some embodiments. Embodiments may use any suitable pseudo-random function (e.g., AES, hash functions, etc.) and any suitable secret-sharing technique (e.g., the Blakley scheme, the Chinese remainder theorem, etc.).

[0103] II. Distributed Cryptographic Networks

[0104] A. System Block Diagram

[0105] Figure 1 A system block diagram of an exemplary distributed cryptographic network 100 according to some embodiments is shown. The exemplary distributed cryptographic network may include cryptographic devices 102 to 108, client computers 110 and 112, an insecure network 114, and optionally, a proxy device 116.

[0106] Although only four cryptographic devices 102 to 108 are shown, the embodiment can be practiced with any number of cryptographic devices. Similarly, although only two client computers 110 and 112 are shown, the embodiment can be practiced with any number of client computers.

[0107] Figure 1 Computers and devices can communicate with each other via a communication network, which can take any suitable form and may include any and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a Node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.). Messages between computers and devices can be sent using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), and / or similar protocols.

[0108] A distributed cryptographic network enables client computers 110 and 112 to encrypt messages or decrypt ciphertext using cryptographic material (secret shares) securely stored by cryptographic devices 102 to 108. Client computers 110 and 112 can communicate directly with cryptographic devices 102 to 108 via a network (e.g., the Internet or an insecure network 114) or via an optional proxy device 116. Client computers 110 to 112 may possess the message to be encrypted (“plaintext message” or “plaintext”) or decrypted (“ciphertext message” or “ciphertext”), as well as the hardware, software, code, or instructions that enable client computers 110 to 112 to participate in the distributed symmetric cryptographic process.

[0109] Each cryptographic device 102 to 108 may have a secret share and a verification share. The secret share and verification share can be derived from a shared secret and a verification value. The shared secret and verification value can be shared among the cryptographic devices 102 to 108; for example, a single shared secret and verification value from which the secret share and verification share are derived may exist. The verification value corresponds to a verification key, which can be used by the cryptographic devices 102 to 108 to verify a verification signature generated using the verification share. A threshold number of secret shares allows for the reconstruction of the shared secret, and a threshold number of verification shares allows for the reconstruction of the verification value. The threshold number may be less than the total number of cryptographic devices 102 to 108. For example, if there are twenty cryptographic devices 102 to 108, the threshold number may be 14 cryptographic devices, or any other suitable number of cryptographic devices.

[0110] Cryptographic devices 102 to 108 may be organized into a cryptographic device network. This cryptographic device network may include a local area network connected to a larger computer network, such as the Internet or an insecure network 114. Communication between the cryptographic device network and external computers (e.g., client computers 110 and 112) may be mediated by a proxy device 116, which may include a network server that communicates with client computers 110 and 112 via any suitable component (e.g., an application programming interface, API).

[0111] A network of cryptographic devices can be organized into any suitable networking structure. For example, a network of cryptographic devices may include a “chain” structure, thereby organizing cryptographic devices into a linear sequence of cryptographic devices. Communication from client computer 110 to a cryptographic device (e.g., cryptographic device 108) may pass through all the aforementioned cryptographic devices (e.g., cryptographic devices 102 to 106) and proxy device 116 before reaching the cryptographic device. Alternatively, a network of cryptographic devices may include a “tree” structure, where different branches include different sets of cryptographic devices (e.g., one branch may include cryptographic devices 102 and 104, while another branch may include cryptographic devices 106 and 108). A network of cryptographic devices may include any number of proxy devices, which may act as proxies for cryptographic devices or other proxy devices.

[0112] Insecure network 114 may include a computer network through which client computers 110 and 112 communicate with each other. Insecure network 114 may include, for example, the Internet. For example, client computer 110 may communicate with cryptographic devices 102 to 108 to encrypt messages, so that the encrypted messages can be securely transmitted to client computer 112 via insecure network 114. Client computer 112 may then communicate with cryptographic devices 102 to 108 to decrypt the messages.

[0113] For example, client computers 110 and 112 may include medical record systems in different hospitals. These hospitals may not have the capability to encrypt medical records themselves. Therefore, to comply with patient confidentiality rules, these hospitals may use their respective client computers 110 or 112 and cryptographic devices 102 to 108 to encrypt the medical records and then store them in a medical record database. When the medical record needs to be decrypted (i.e., before the doctor and the patient corresponding to the medical record meet), client computer 110 or 112 may communicate with cryptographic devices 102 to 108 to decrypt the medical record. As another example, if a patient is being transferred from a first hospital to a second hospital, the client computer corresponding to the first hospital (e.g., client computer 110) may send the encrypted medical record to the client computer corresponding to the second hospital (e.g., client computer 112). The client computer corresponding to the second hospital may use a different set of cryptographic devices, either by communicating with cryptographic devices 102 to 108 or by using the same master key, to decrypt the medical record.

[0114] The following text is for reference only. Figure 2 An exemplary client computer is described in more detail.

[0115] B. Client Computer

[0116] As described above, a client computer may include a computer system that communicates with a distributed symmetric cryptographic system (e.g., a network of cryptographic devices) to encrypt messages or decrypt ciphertext. The client computer may include a personal computer or a communication device associated with a user. These devices may include, for example, laptops, desktop computers, smartphones, tablets, smartwatches, PDAs, etc. The client computer may also include a server computer or host computer associated with an organization (e.g., an enterprise).

[0117] An exemplary client computer 200 in Figure 2 As shown in the figure. The client computer 200 may include a processor 202, a communication interface 204, and a computer-readable medium 206.

[0118] 1. Processing, transmitting, and storing

[0119] Processor 202 may include any suitable one or more data computing devices. Processor 202 is capable of interpreting code and executing instructions stored on computer-readable medium 206. Processor 202 may include a central processing unit (CPU) operating on a reduced instruction set, and may include a single-core or multi-core processor. Processor 202 may include an arithmetic logic unit (ALU) and cache memory, which may be used by processor 202 to execute code or other functions.

[0120] Communication interface 204 may include any interface through which client computer 200 can communicate with other computers or devices. Examples of communication interfaces include wired interfaces such as USB, Ethernet, or FireWire. Examples also include interfaces for wireless communication, such as Bluetooth or Wi-Fi receivers. Client computer 200 may have multiple communication interfaces 204. For example, client computer 200, including a smartphone, may communicate via a micro USB port, a cellular receiver, a Bluetooth receiver, and a Wi-Fi receiver.

[0121] Client computer 200 can communicate with other devices or computers via communication interface 204 through one or more secure and authenticated peer-to-peer channels. These channels can use standard public key infrastructure. For example, client computer 200 and cryptographic devices can exchange symmetric keys and / or key shares through their communication interface. This key exchange may include a Diffie-Hellman key exchange. After exchanging cryptographic keys, client computer 200 and cryptographic devices can communicate using standard authenticated encryption schemes over public channels (e.g., insecure networks) to encrypt any message with the cryptographic keys. Other authentication methods, such as digital signatures, may also be used.

[0122] Computer-readable medium 206 may include hardware that may have code, data, or instructions that can be interpreted by processor 202. Computer-readable medium 206 may store or otherwise include a number of software modules, including a random number generation module 208, a selection module 210, a calculation module 212, and a key generation module 214.

[0123] 2. Random number generation module

[0124] The random number generation module 208 may include or contain code, instructions, routines, subroutines, etc., that can be used by the processor 202 to generate random or pseudo-random numbers. These random numbers may include cryptographically secure pseudo-random numbers, and the code may include one or more pseudo-random number generation algorithms that meet cryptographic security requirements. These requirements may include, for example, passing a "next-bit test" and a "state compromise extension test." Examples of cryptographically secure random number generators include the Yarrow, ChaCha20, and Fortuna algorithms.

[0125] The random number generation module 208 can communicate with other modules or hardware in the client computer 200 for the purpose of generating random or pseudo-random numbers. For example, the pseudo-random number generation module 208 can retrieve the system time (e.g., current year, month, day, and hour) to seed the pseudo-random number generation algorithm.

[0126] Random or pseudo-random numbers can be used to "blind" (i.e., obfuscate) messages for encryption or commitment generation purposes. A message can be combined with a random or pseudo-random number in some way to obfuscate it. For example, the message "hello" can be concatenated with the random number 12345 to produce the blinded message "hello12345". Alternatively, a bitwise XOR operation can be used to blind a message using a random number. By blinding the message with random numbers, the client computer 200 can protect itself from some cryptographic attacks, including replay attacks. Therefore, instead of generating a commitment H(m) based solely on the message m, the client computer 200 can generate a commitment based on the message and a random value (or a random temporary number). Furthermore, instead of encrypting the message m, the client computer 200 can encrypt the message m and the random value.

[0127] 3. Select Module

[0128] Selection module 210 may include code or instructions used by processor 202 for selecting a threshold number of cryptographic devices from the cryptographic device network. The threshold number of cryptographic devices may include the number of cryptographic devices necessary to reproduce a shared secret or verification value from secret shares and verification shares stored on those cryptographic devices. In some embodiments, client computer 200 may not select cryptographic devices from the cryptographic device network. Alternatively, client computer 200 may communicate with an agent device, and the agent device may perform the selection process. Thus, selection module 210 may be optional.

[0129] For example, selection module 210 may include code implementing a random selection algorithm. Selection module 210 may include a list of cryptographic devices in a network of cryptographic devices. Selection module 210 may select from the list without replacement until a threshold number of cryptographic devices are selected. Alternatively, selection module 210 may include code enabling rule-based selection of cryptographic devices. For example, selection module 210 may determine a threat score associated with each cryptographic device. The threat score may correspond to the probability that a given cryptographic device has been compromised by a hacker or malicious user. Selection module 210 may select a threshold number of cryptographic devices with the lowest threat score, or randomly select from cryptographic devices with threat scores below a certain value.

[0130] As an alternative, selection module 210 may include code that enables the selection of cryptographic devices based on computational load. Some cryptographic devices in a network may already be performing distributed symmetric cryptography on behalf of other client computers and may therefore have higher computational loads. Client computer 200 may use selection module 210 to select a threshold number of cryptographic devices with lower computational loads to improve the turnaround time and throughput of the distributed symmetric cryptography system.

[0131] 4. Calculation Module

[0132] The computation module 212 may include code or instructions that enable the processor 202 to perform various computations involved in distributed symmetric cryptography. These may include, for example, generating commitments based on messages and random values, combining partial computations, and combining partial signatures.

[0133] The computation module 212 may include code capable of generating commitments using any suitable function or algorithm. For example, the computation module 212 may include a hash function (e.g., secure hash algorithms SHA-256, SHA3, BLAKE2, etc.) that can be used to generate commitments. The message and a random value can be provided as input to the hash function, and the resulting hash value can be used as a commitment. As described above, the commitment can be used to verify that the message has been correctly encrypted and decrypted. A commitment can be generated based on the message before it is encrypted. After the message is encrypted and subsequently decrypted, another commitment can be generated based on the decrypted message. The commitments of the two messages should be the same as the original message, provided the decrypted message is identical.

[0134] The calculation module 212 may include code capable of combining partial calculations and partial signatures using any suitable method, function, or algorithm. For example, the partial calculations may be combined by calculating the sum or product of the partial calculations. The calculation module 212 may also include code capable of implementing polynomial interpolation, such as calculating Lagrange coefficients. These Lagrange coefficients may correspond to partial calculations. Additionally, the calculation module 212 may include code capable of implementing exponentiation and modular exponentiation operations.

[0135] For example, client computer 200 can use calculation module 212 to calculate multiple Lagrange coefficients corresponding to multiple partial calculations. Client computer 200 can then use calculation module 212 to exponentiate those partial calculations using the multiple Lagrange coefficients to generate multiple intermediate calculations. Client computer 200 can calculate the product of these intermediate calculations. The product of the intermediate calculations can be used as a key generation seed. Client computer 200 can use calculation module 212 to input this key generation seed into a key generation algorithm to generate a cryptographic key that can be used to encrypt or decrypt messages.

[0136] Similarly, the computation module 212 may include code that enables the client computer 200 to generate a verification signature from the partial signature using a technique similar to that used to generate a key generation seed (e.g., interpolation using Lagrange polynomials).

[0137] 5. Key Generation Module

[0138] The key generation module 214 may include code or instructions that enable the processor 202 to generate cryptographic keys. These cryptographic keys may be generated from a key generation seed. Key generation depends on the specific cryptographic system used to perform the cryptography. For example, for the "AES-128-CBC" cryptographic system (AES block cipher with a 128-bit key operating in cipher block chain mode), the key generation algorithm may accept a password or key generation seed as input and produce a 128-bit key for use in the AES block cipher.

[0139] Client computer 200 can use key generation module 214 to generate cryptographic keys for encrypting messages or decrypting ciphertext. The key generation seed, used as input to key generation module 214, can be derived wholly or partially from partial calculations received from a cryptographic device. The key generation seed may include a product of intermediate calculations generated by exponentiation of the corresponding Lagrange coefficients of the partial calculations. These partial calculations can be generated by the cryptographic device using a promise and secret share received from the client computer, as described in Section I above. Therefore, the key generation seed and cryptographic key can be indirectly derived from the secret share, since the secret share is used to generate partial calculations, which in turn generate intermediate calculations, which can then be combined and used as the key generation seed.

[0140] C. Cryptographic device

[0141] Figure 3An exemplary cryptographic device 300 according to some embodiments is shown. Cryptographic device 300 may include a computer or other device in a cryptographic device network. In some embodiments, cryptographic device 300 may include a server computer. Cryptographic device 300 may store a secret share and a verification share derived from a shared secret and a verification value, respectively. Additionally, cryptographic device 300 may store a verification key used to verify a verification signature. The shared secret and verification share may be used by the cryptographic device to generate a partial computation and a partial signature using a distributed pseudo-random function. The partial computation may be used by a client computer to generate a cryptographic key. The cryptographic key may be used by the client computer to encrypt or decrypt messages. Cryptographic device 300 may include a processor 302, a communication interface 304, and a computer-readable medium 306.

[0142] 1. Processing, transmitting, and storing

[0143] Processor 302 may include any suitable one or more data computing devices. Processor 302 is capable of interpreting code and executing instructions stored on computer-readable medium 306. Processor 302 may include a central processing unit (CPU) operating on a reduced instruction set, and may include a single-core or multi-core processor. Processor 302 may include an arithmetic logic unit (ALU) and cache memory. These components may be used by processor 302 to execute code or other functions.

[0144] The communication interface 304 may include any interface through which the cryptographic device 300 can communicate with other computers or devices. Examples of communication interfaces include wired interfaces such as USB, Ethernet, or FireWire. Examples also include interfaces for wireless communication, such as Bluetooth or Wi-Fi receivers. The cryptographic device 300 may have multiple communication interfaces 304, such as micro USB ports, Ethernet ports, cellular receivers, Bluetooth receivers, etc.

[0145] Cryptographic device 300 can communicate with other devices or computers via communication interface 304 through one or more secure and authenticated peer-to-peer channels. These channels can use standard public key infrastructure. For example, cryptographic device 300 and a client computer can exchange symmetric keys through their communication interfaces. This key exchange may include a Diffie-Hellman key exchange. After exchanging cryptographic keys, cryptographic device 300 and the client computer can communicate using standard authenticated encryption schemes over public channels (e.g., insecure networks) to encrypt any message with the cryptographic keys. Other authentication methods, such as digital signatures, may also be used. By performing this key exchange, communication between cryptographic device 300 and the client computer (e.g., commitment, partial computation, partial signature, signature verification, etc.) can be encrypted, thereby allowing cryptographic device 300 and the client computer to communicate securely over insecure networks.

[0146] Computer-readable medium 306 may include hardware that may possess or store code, data, or instructions interpretable by processor 302. Computer-readable medium 306 may store or otherwise include a number of software modules, including a distributed pseudo-random function module 308, a verification module 310, and a secure memory element 312. The secure memory element may store a secret share 314, a verification share 316, and a verification key 318.

[0147] 2. Distributed Pseudo-random Function Module

[0148] The distributed pseudo-random function module 308 may include code for evaluating pseudo-random functions (PRFs) or distributed pseudo-random functions (DPRFs). For example, this may include performing cryptographic operations associated with elliptic curve cryptography, block ciphers such as AES, or hash functions such as SHA-2.

[0149] For example, the distributed pseudo-random function module 308 may include code that can be used by the processor 302 to implement elliptic curve cryptography under the decisive Diffie-Hellman assumption. Elliptic curve cryptography can be used to generate partial computations based on commitments and secret shares 314. These partial computations can later be combined by a client computer to generate a cryptographic key, which can be used, for example, to encrypt messages or decrypt ciphertext, as described in Section I above.

[0150] Therefore, processor 302 can use distributed pseudo-random function module 308 to perform elliptic curve cryptography using the commitment H(m) of message m as input. The commitment can be transformed into points in an elliptic curve set, which are then multiplied by secret multipliers (e.g., secret share 314) to produce product points. These product points may include partial computations, which can then be sent by cryptographic device 300 to a client computer. Given the same commitment input and the same secret share 314, the resulting partial computations will be identical, thus enabling the partial computations to be used to generate consistent encryption and decryption keys.

[0151] 3. Verification Module

[0152] Verification module 310 may include code or instructions that can be executed by processor 302 to generate a partial signature and verify the verification signature. As described above, the verification signature can be used by cryptographic device 300 to determine whether the client computer is encrypting or decrypting data. The presence of a valid verification signature indicates that the client computer is decrypting data because cryptographic device 300 can verify the verification signature during distributed symmetric decryption.

[0153] Verification module 310 may use a verification share (e.g., stored in secure memory 312) to generate a partial signature based on a commitment received from a client computer. Cryptographic device 300 may send the partial signature to the client computer, which may also receive numerous other partial signatures from other cryptographic devices. The client computer may combine these partial signatures to generate a verification signature, which may then be sent to cryptographic device 300. Cryptographic device 300 may then use verification module 310 to verify the verification signature using a verification key. Verification module 310 may generate a partial signature by encrypting the commitment using its corresponding verification share and elliptic curve cryptography. Alternatively, verification module 310 may generate a partial signature by encrypting the commitment using its corresponding verification share and any suitable form of homomorphic cryptography. As another alternative, verification module 310 may use a commitment, a verification share, and a suitable message authentication code algorithm to generate a partial signature.

[0154] Verification module 310 can use verification key 318 to verify the verification signature. Verification key 318 may correspond to a verification value that can be derived from verification share 316 and other verification shares belonging to other cryptographic devices. In some embodiments, verification key 318 and verification value may include an asymmetric key pair. For example, verification key 318 may include a public cryptographic key, while verification value may include a private cryptographic key.

[0155] The signature verification may include a commitment H(m) encrypted using a verification value. The signature verification can be decrypted using verification key 318 to generate commitment H(m). The cryptographic device 300 may use verification module 310 to decrypt the signature verification using verification key 318 and compare the resulting commitment with a commitment received from the client computer. If the two commitments match, the signature verification is valid. However, the cryptographic device 300 may use verification module 310 to verify the signature verification using any other suitable method, such as based on paired friendly elliptic curves, message authentication codes (MAC), hashed message authentication codes (HMAC), etc. Example techniques for verifying signatures can be found in: [1] Boldyreva A. (2003) "Threshold Signatures, Multisignatures and BlindSignatures Based on the Gap-Diffie-Hellman-Group Signature Scheme." Source: Desmedt YG (eds) Public Key Cryptography-PKC 2003. PKC 2003. Lecture Notes in Computer Science, Vol. 2567. Springer, Berlin, Heidelberg; [2] Victor Shoup. 2000. "Practical threshold signatures." Proceedings of the 19th International Conference on Cryptography Theory and Applications (EUROCRYPT'00). Springer, Berlin, Heidelberg, pp. 207-220; and [3] Naor M., Pinkas B., Reingold O. (1999) Distributed Pseudo-random Functions and KDCs. Source: Stern J. (eds) Advances in Cryptology -- EUROCRYPT'99. EUROCRYPT 1999. Lectures in Computer Science, Vol. 1592. Springer, Berlin, Heidelberg.

[0156] 4. Secure storage

[0157] Secure memory 312 may include a memory area of ​​computer-readable medium 306 or a separate memory element. Secure memory 312 may store sensitive cryptographic material to make it difficult for unauthorized external personnel (e.g., hackers) to access it. For example, data stored in secure memory 312 may be stored in encrypted form. Secure memory 312 may store a secret share 314 derived from a shared secret. Additionally, secure memory 312 may store a verification share 316 derived from a verification value and a verification key 318 corresponding to the verification value. Cryptographic device 300 may use secret share 314 to generate partial computations for generating a cryptographic key. Similarly, cryptographic device 300 may use verification share 316 to derive a partial signature for generating a verification signature. Cryptographic device 300 may use verification key 318 to verify a verification signature generated from multiple partial signatures.

[0158] III. Generating and allocating secret shares and verification values

[0159] Before describing methods for improving distributed symmetric cryptography, it may be helpful to describe methods that can be used to allocate secret shares and verification shares to cryptographic devices in a network of cryptographic devices.

[0160] For illustrative purposes, the following text refers to... Figure 4 and 5 This describes a non-limiting example of the generation and allocation of secret shares and verification shares. However, it should be understood that any suitable method can be used to generate secret shares and verification shares and allocate them to cryptographic devices.

[0161] Figure 4 A share allocation system 400 is illustrated, comprising a trusted external server 402, a communication network 404, and a cryptographic device network 412. The cryptographic device network 412 may include optional proxy devices 406 and cryptographic devices 408 to 410. It is noteworthy that although only two cryptographic devices 408 and 410 are shown, the cryptographic device network 412 may include any number of cryptographic devices.

[0162] Trusted external server 402 may include a server computer capable of generating and distributing secret shares, verification shares, and verification keys. Trusted external server 402 is capable of communicating with cryptographic devices 408 to 410 or proxy device 406 via communication network 404. Trusted external server 402 may possess a processor and computer-readable medium and is capable of performing any operations necessary to generate a shared secret, secret share, verification value, or verification share according to any suitable secret sharing scheme (e.g., Shamir secret sharing as described above). For example, trusted external server 402 may generate a plurality of random numbers corresponding to the coefficients of a polynomial P(x). One of these random numbers may be deciphered as a shared secret or verification value. Trusted external server 402 may evaluate polynomial P(x) for different values ​​x. The evaluated polynomial and the corresponding secret share (and / or verification share) for the value x may be assigned to cryptographic devices 408 and 410.

[0163] The communication network 404 may include networks such as the Internet or cellular communication networks, through which devices, computers, and servers can communicate with each other. The communication network 404 may be secure or insecure. A trusted external server 402 may communicate with the cryptographic device network 412 through the communication network 404. For example, the trusted external server 402 may send a secret share, a verification share, and a verification key to the cryptographic device network through the communication network 404.

[0164] Cryptographic device network 412 may include cryptographic devices 408 and 410, and proxy device 406. Proxy device 406 may act as a gateway, mediating communication between cryptographic devices 408 and 410 and computers, devices, or servers outside cryptographic device network 412 (e.g., trusted external server 402). Secret shares or verification shares may be sent by trusted external server 402 to proxy device 406 via communication network 404. Proxy device 406 may distribute secret shares to their respective cryptographic devices.

[0165] Cryptographic devices 408 to 410 are essentially similar to those mentioned above. Figure 1 and 3 The described cryptographic device may include a processor, a communication interface, and a computer-readable medium. The computer-readable medium may have or include numerous software modules used by cryptographic devices 408 and 410 to perform distributed symmetric cryptography. Cryptographic devices 408 and 410 may additionally include secure memory elements. Cryptographic devices 408 and 410 may store secret shares, verification shares, and verification keys received from trusted external server 402 in their respective secure memory elements.

[0166] Figure 5The diagram illustrates a sequence diagram detailing an exemplary method for generating and distributing secret shares, verification values, and verification keys. It should be understood that the embodiments can be practiced using any suitable method for generating and distributing secret shares, verification shares, and verification keys, and therefore... Figure 5 The exemplary methods described are intended to be non-limiting. Although Figure 4 The communication network 404 is not explicitly shown, but communication between the cryptographic device network 502 and the trusted external server 504 can be transmitted through the communication network. Similarly, although Figure 4 The proxy device 404 is not shown, but communication with the cryptographic device network 502 can be received by the proxy device on behalf of the cryptographic device network.

[0167] Steps 506 and 508 are two steps in the handshake procedure between the cryptographic device network 502 and the trusted external server 504. Some communication protocols, such as Transmission Control Protocol (TCP), use handshake procedures to establish rules or characteristics for future communication between participating computers. For example, if the communication between the cryptographic device network 502 and the trusted external server 504 is encrypted, steps 506 and 508 may involve the exchange of encryption keys between the cryptographic device network 502 and the trusted external server 504.

[0168] For example, cryptographic device network 502 (or proxy device) may possess a symmetric cryptographic key that can be used to encrypt and decrypt messages sent between cryptographic device network 502 and trusted external server 504. Trusted external server 504 may possess the private key from a public-private key pair. Cryptographic device network 502 can use the public key from the public-private key pair to encrypt the symmetric cryptographic key, and then send the symmetric cryptographic key to trusted external server 504. Using the private key, trusted external server 504 can decrypt the symmetric cryptographic key. At this point, both cryptographic device network 502 and trusted external server 504 possess the symmetric cryptographic key. Cryptographic device network 502 and trusted external server 504 can use the symmetric cryptographic key to encrypt and decrypt any future communications between them.

[0169] In step 510, the cryptographic device network 502 may send information necessary to complete the generation and allocation process of secret shares and verification shares. This may include, for example, the number of devices in the cryptographic device network, the device threshold number of the cryptographic device network, address information, and any requested sample values. The address information may include a numeric address associated with each cryptographic device in the cryptographic device network 502, such as an IP address or a MAC address. The requested sample value may correspond to a specific value x, which is used to sample a polynomial P(x) to generate a secret share or verification value. For example, the sample value may be the number 5, and the secret share corresponding to that sample value may include (5, P(5)).

[0170] For example, in step 510, the cryptographic device network 502 may send a series of packets, each containing a requested sample value and the address of each cryptographic device corresponding to the requested sample value, such as an IP address or MAC address. Additionally, the packets may include, for example, information about a TCP or UDP port on which communication with the cryptographic devices in the cryptographic device network 502 takes place.

[0171] In step 512, the trusted external server 504 may generate a secret share, a verification value, and a verification key. The method by which the trusted external server 504 generates the shared verification value and verification key depends on the secret-sharing method used and the distributed pseudo-random function used during distributed symmetric cryptography. Similarly, the method by which the verification value and verification key are generated depends on the specific method used to verify the verification signature using the verification key. In some embodiments, the shared secret may include a random number, and the trusted external server 512 may use a cryptographically secure random number generator to generate the shared secret. In some embodiments, the verification value and verification key may include an asymmetric key pair, and the verification value and verification key may be generated using any appropriate method for generating asymmetric key pairs according to any suitable cryptosystem (e.g., RSA).

[0172] In step 514, the trusted external server 504 may generate a first polynomial corresponding to the shared secret and a second polynomial corresponding to the verification value. The trusted external server may encode the shared secret as a coefficient of the first polynomial and the verification value as a coefficient of the second polynomial. In some embodiments, the shared secret and the verification value may be encoded as zero-order coefficients of their respective polynomials. The trusted external server 504 may use any suitable technique to generate other coefficients for the first and second polynomials. For example, other coefficients may include random or pseudo-random numbers.

[0173] The properties of the polynomial (e.g., how the coefficients may be included) may be based entirely or partially on the information received by the trusted external server 504 in step 510 (e.g., the number of secret shares and verification shares). As described above, k+1 unique points are needed to uniquely define a polynomial of degree k (i.e., having k+1 coefficients, including zero-order coefficients). Therefore, the number of coefficients in the first polynomial may be equal to the threshold number of secret shares requested at step 510. Similarly, the number of coefficients in the second polynomial may be equal to the threshold number of verification shares requested at step 510.

[0174] In step 516, the trusted external server 504 can generate a secret share and a verification share based on the corresponding polynomials. The trusted external server 504 can sample the secret share polynomial and the verification share polynomial at a unique value x to generate a corresponding value P(x). These paired (x, P(x)) values ​​may include the secret share. The x value may include the preferred sampled value provided to the trusted external server 504 in step 510.

[0175] In step 518, the trusted external server 504 can use the routing or address information provided in step 510 to send the secret share, verification share, and verification key to the cryptographic devices in the cryptographic device network 502. In this way, each cryptographic device in the cryptographic device network 502 can receive its corresponding secret share and verification share, as well as the verification key common to all cryptographic devices.

[0176] Figure 5 The exemplary method is a non-limiting example of the secret share generation and allocation process. Many variations exist that may be obvious to those skilled in the art. As another example, a cryptographic device may receive its corresponding secret share via cryptographic methods such as inadvertent transmission. As yet another example, a network of cryptographic devices 502 may generate secret shares using, for example, secure multi-party computation methods without the assistance of a trusted external server 504.

[0177] IV. Distributed Symmetric Operations

[0178] A. Encryption

[0179] refer to Figure 6 This allows for a better understanding of distributed symmetric encryption. Figure 6 An improved distributed symmetric encryption process is illustrated according to some embodiments. In the improved distributed symmetric encryption (see below) Figure 8 (Description) In this method, the client computer uses multiple partial signatures generated by a cryptographic device to generate a verification signature. During improved distributed symmetric decryption, the client computer provides the verification signature to the cryptographic device. The verification signature indicates to the cryptographic device that the client computer is performing decryption. In contrast, in distributed symmetric decryption, the client computer does not generate a verification signature. Therefore, the cryptographic device cannot determine whether the client computer is performing distributed symmetric encryption or distributed symmetric decryption.

[0180] Figure 6 This diagram illustrates a mixed sequence of a client computer 602 performing a distributed symmetric encryption process and multiple cryptographic devices 604 to 610. The client computer 602 can perform the distributed symmetric encryption process using a threshold number of cryptographic devices, which may be fewer than the total number of cryptographic devices. Figure 6As indicated, client computer 602 is performing distributed symmetric encryption using cryptographic devices 604 to 608 instead of cryptographic device 610. Although Figure 6 Four cryptographic devices 604 to 610 are shown, but it should be understood that distributed symmetric encryption can be performed with any number of cryptographic devices.

[0181] In step 612, the client computer 602 may generate a commitment x. The commitment may be generated based on a message m and a random value r (or, alternatively, a "random temporary number"). The commitment x may include a hash value generated by using the message m and the random value r as input to a hash function (e.g., SHA-256).

[0182] In step 614, the client computer 602 may send commitment x to multiple participating cryptographic devices, namely cryptographic devices 604 to 608. The client computer 602 may send commitment x directly or through a proxy device to the participating cryptographic devices 604 to 608.

[0183] In step 616, cryptographic devices 604 to 608 can generate partial computations y1, y2, and y3 based on the commitment x and the corresponding secret shares sk1, sk2, and sk3 of the cryptographic devices. Cryptographic devices 604 to 608 can generate these partial computations y1, y2, and y3 using a distributed pseudo-random function, as described in Section I above. Cryptographic devices 604 to 608 can generate partial computations y1, y2, and y3 using the commitment x and the corresponding secret shares sk1, sk2, and sk3 by calling the distributed pseudo-random evaluation function DPRF.Eval (i.e., y1, y2, and y3). i =DPRF.Eval(sk i Distributed pseudo-random functions may include elliptic curve cryptography functions. For example, cryptographic devices 604 to 608 can be used with their respective secret shares sk. i Using elliptic curve cryptography to encrypt commitments x to generate their corresponding partial computations y i .

[0184] In step 618, the participating cryptographic devices 604 to 608 may send partial computations y1, y2, and y3 to the client computer 602. The participating cryptographic devices 604 to 608 may send partial computations y1, y2, and y3 directly or through a proxy device.

[0185] Optionally, in step 618, the participating cryptographic devices 604 to 608 may each send a non-interactive zero-knowledge proof (NIZK) to the client computer 602. The client computer 602 can use the NIZK to verify that the partial computations y1, y2, and y3 corresponding to those NIZKs have been correctly generated. If any NIZK fails to be verified, the client computer 602 may abort the distributed symmetric encryption process.

[0186] In step 620, the client computer 602 may combine the partial computations and generate a cryptographic key. The client computer 602 may combine partial computations y1, y2, and y3 to generate a key generation seed, which may be used in conjunction with a key generation algorithm to generate the cryptographic key. The client computer 602 may combine the partial computations in any suitable manner. For example, the client computer may use a distributed pseudo-random combination function DPRF.Combine (i.e., y = DPRF.Combine(y1, y2, y3)) that uses partial computations y1, y2, and y3 as independent variables. This function may involve the client computer 602 determining multiple Lagrange coefficients corresponding to the multiple partial computations. The client computer 602 may generate multiple intermediate computations by exponentiation of each partial computation with the Lagrange coefficients corresponding to the partial computations. The client computer 602 may generate a key generation seed by calculating the product of the multiple intermediate computations. The key generation seed may be input into a key generation algorithm to generate the cryptographic key. See Section I above for details.

[0187] In step 622, client computer 602 can encrypt message m using the cryptographic key to generate ciphertext e. Alternatively, client computer 602 can encrypt message m and a random number r used to blind the commitment (see step 612). Client computer 602 can encrypt the message using any suitable symmetric cryptosystem corresponding to the cryptographic key, such as AES (e.g., ciphertext e = AES, as shown at step 622). y (m|r)).

[0188] At step 624, client computer 602 may generate a payload including ciphertext e and commitment x. This payload includes the information needed to decrypt the ciphertext using distributed symmetric cryptography. Client computer 602 may send this payload to another client computer for secure message transmission.

[0189] B. Decryption

[0190] refer to Figure 7 This allows for a better understanding of distributed symmetric decryption. Figure 7 An improved distributed symmetric decryption process according to some embodiments of the present disclosure is illustrated. In the improved symmetric decryption (hereinafter referred to...) Figure 9 In the description, the client computer sends a verification signature to the participating cryptographic device. The verification signature instructs the cryptographic device that the client computer is performing decryption. In contrast, in... Figure 7 In this configuration, the client computer does not send a verification signature to the cryptographic device. Therefore, the cryptographic device cannot determine whether the client computer is performing distributed symmetric encryption or distributed symmetric decryption.

[0191] Figure 7 This diagram illustrates a mixed sequence of a client computer 702 and multiple cryptographic devices 704 to 710 performing a distributed symmetric decryption process. The client computer 702 can perform the distributed symmetric decryption process using a threshold number of cryptographic devices, which may be fewer than the total number of cryptographic devices. Figure 7 As indicated, client computer 702 is performing distributed symmetric decryption in conjunction with cryptographic devices 704, 706, and 710. It is noteworthy that client computer 702 can incorporate cryptographic devices other than those used during distributed symmetric encryption (e.g., ...). Figure 6 Cryptographic devices other than 604 to 608 in the client computer 702 perform distributed symmetric decryption. Cryptographic device 708 may not have been selected by the client computer 702 to participate in the distributed symmetric decryption process.

[0192] In some contexts, the term "cryptographic device" can refer to the cryptographic device involved in distributed symmetric encryption, while the term "additional cryptographic device" can refer to the cryptographic device involved in distributed symmetric decryption. The term "additional partial computation" can refer to partial computation generated by additional cryptographic devices—that is, those cryptographic devices involved in distributed symmetric decryption. Similarly, the term "additional secret share" can refer to the secret share corresponding to the additional cryptographic device.

[0193] In step 712, client computer 702 may send commitment x to cryptographic devices 704, 706, and 710. Client computer 702 may have already generated this commitment, or it may have received it from another computer, such as another client computer. For example, another client computer may have performed a distributed symmetric encryption process and generated a payload including ciphertext e and commitment x. This other client computer may have sent this payload to client computer 702, and client computer 702 may send the commitment received in said payload to cryptographic devices 704, 706, and 710. Client computer 702 may send the commitment directly or through a proxy device to cryptographic devices 704, 706, and 710.

[0194] In step 714, cryptographic devices 704, 706, and 710 can generate partial computations y1, y2, and y4 based on the commitment x and the corresponding secret shares sk1, sk2, and sk4 of the cryptographic devices. Cryptographic devices 704, 706, and 710 can use distributed pseudo-random functions to generate these partial computations, as described in Section I above. For example, as... Figure 7As shown, cryptographic devices 704, 706, and 710 can execute the DPRF.Eval function using their respective secret shares and commitments as arguments. The distributed pseudo-random function may include an elliptic curve cryptographic function. For example, cryptographic devices 704, 706, and 710 can each generate a partial computation by encrypting the commitment using their respective secret shares and elliptic curve cryptography.

[0195] In step 716, the participating cryptographic devices 704, 706, and 710 may send partial computations y1, y2, and y4 to the client computer 702. The participating cryptographic devices 704, 706, and 710 may send the partial computations directly or through a proxy device.

[0196] Optionally, in step 716, the participating cryptographic devices 704, 706, and 710 may each send a non-interactive zero-knowledge proof (NIZK) to the client computer 702. The client computer 702 can use the NIZK to verify that the partial computation corresponding to those NIZKs has been correctly generated. If any NIZK fails to verify, the client computer may abort the distributed symmetric decryption process.

[0197] In step 718, the client computer 702 may combine the partial computations to generate a cryptographic key. The client computer 702 may combine the partial computations to generate a key generation seed, and then use the key generation seed as input to a key generation algorithm to generate the cryptographic key. The client computer 702 may combine the partial computations using any suitable method, such as the DPRF.Combine function, which uses partial computations y1, y2, and y4 as independent variables. For example, the client computer 702 may first determine multiple Lagrange coefficients corresponding to multiple partial computations. The client computer 702 may generate multiple intermediate computations by exponentiation of each partial computation with the Lagrange coefficients corresponding to the partial computations. The client computer 702 may generate a key generation seed by calculating the product of the multiple intermediate computations. The key generation seed may be input into the key generation algorithm to generate the cryptographic key. See Section I above for details.

[0198] In step 720, the client computer 702 may decrypt the ciphertext to generate message m. Alternatively, the client computer 702 may decrypt the ciphertext to generate message m and a random value r for blinding the commitment (see...). Figure 6 Step 612). The client computer 702 can use any suitable symmetric cryptosystem, such as AES, corresponding to the cryptographic key to decrypt the ciphertext (e.g., ...). Figure 7 As shown, m|r=AES y -1 (e)).

[0199] In optional step 722, client computer 702 can verify whether the message matches the promise m. Client computer 702 can use the message and a random value as input to a hash function to generate an additional promise. Then, client computer 702 can compare the promise sent in step 712 with the promise generated in step 722. If the promises are the same, it indicates that the message has been correctly encrypted and decrypted.

[0200] V. Improved Distributed Symmetric Operations

[0201] As indicated above, in distributed symmetric operations, a cryptographic device may be unable to determine whether a client computer is encrypting a message or decrypting ciphertext. This is because, from the cryptographic device's perspective, distributed encryption and decryption are essentially the same: the client computer sends a commitment to the cryptographic device, the cryptographic device generates a partial computation, and the cryptographic device returns that partial computation to the client computer. The client computer then generates a cryptographic key based on the partial computation and uses that key to encrypt the message or decrypt the ciphertext. Therefore, in distributed symmetric operations, the cryptographic device may be unable to determine whether a client computer is encrypting or decrypting data. This, in turn, makes it difficult to record the behavior of the client computer or prevent the abuse of malicious client computers.

[0202] Improved distributed symmetric cryptography involves using a threshold signature scheme. During improved symmetric encryption, the cryptographic device generates a partial signature based on a commitment received from a client computer. The client computer can then combine these partial signatures to generate a verification signature. During decryption, the verification signature can be provided by the client computer to the cryptographic device. The cryptographic device can verify the verification signature using a verification key, and then, if the verification signature is successfully verified, chooses to participate in distributed symmetric decryption.

[0203] The presence or absence of a verification signature indicates to the cryptographic device which distributed cryptographic operation is being performed. If the verification signature is generated during a distributed cryptographic operation, the cryptographic device can determine that the client computer is performing encryption. If the verification signature is verified during a distributed cryptographic operation, the cryptographic device can determine that the client computer is performing decryption. In this way, the behavior of the client computer can be recorded or otherwise monitored. This is an improvement over the distributed symmetric operations described in Section IV above.

[0204] A. Encryption

[0205] Figure 8A hybrid sequence diagram is shown illustrating an exemplary method for improved distributed symmetric encryption according to some embodiments. Unlike traditional distributed symmetric encryption, improved distributed symmetric encryption may involve a client computer generating a verification signature. This verification signature may be provided to a cryptographic device during the improved distributed symmetric decryption process. The cryptographic device may verify the verification signature during the improved distributed symmetric decryption process to verify that the distributed symmetric encryption has been performed correctly. Furthermore, the cryptographic device may determine whether the client computer intends to encrypt or decrypt the message based on the content of the encryption or decryption request (e.g., the presence or absence of a verification signature).

[0206] Figure 8 A client computer 802 and a plurality of cryptographic devices 804 to 810 are shown performing an improved distributed symmetric encryption process. The client computer 802 can perform the improved distributed symmetric encryption process using a predetermined threshold number of cryptographic devices, which may be less than the total number of cryptographic devices. Figure 8 As indicated, client computer 802 is performing improved distributed symmetric encryption using cryptographic devices 804 to 808 instead of cryptographic device 810. It is worth noting that although four cryptographic devices 804 to 810 are shown, improved distributed symmetric encryption can be performed using any number of cryptographic devices.

[0207] In step 812, the client computer 802 may generate a commitment x. The commitment may be generated based on the message m to be encrypted and a random value r (or a "random number" or "random temporary number"). The commitment may include a hash value generated by using the message and the random value as input to a hash function (e.g., SHA-256, SHA3, BLAKE2, etc.).

[0208] In step 814, the client computer 802 may send a commitment x to multiple participating cryptographic devices, namely cryptographic devices 804 to 808. The client computer 802 may send the commitment directly or through a proxy device to the participating cryptographic devices 804 to 808. The client computer 802 may also send an indicator (e.g., as a bitwise or integer token) to the cryptographic devices 804 to 808. The indicator may indicate that the client computer wants to perform encryption. The cryptographic devices 804 to 808 may audit or otherwise analyze the indicator and enter or otherwise record the client computer 802's intent in a log file.

[0209] In step 816, cryptographic devices 804 to 808 may generate partial computations of y1, y2, and y3 based on the commitment and the corresponding secret shares sk1, sk2, and sk3 of the cryptographic device. Cryptographic devices 804 to 808 may generate these partial computations using a distributed pseudo-random function, as described in Section I above. The distributed pseudo-random function may include an elliptic curve cryptography function. For example, cryptographic devices 804 to 808 may generate the corresponding partial computations of the cryptographic device by encrypting the commitment using its corresponding secret share and elliptic curve cryptography. The distributed pseudo-random function may include a DPRF.Eval function that uses the commitment and the corresponding secret share as independent variables.

[0210] In step 818, cryptographic devices 804 to 808 may generate partial signatures z1, z2, and z3 based on the commitment and the corresponding verification shares of the cryptographic devices. Cryptographic device 810 may not have been selected by the client computer or the network of cryptographic devices to participate in the distributed symmetric encryption process. Alternatively, cryptographic device 810 may be offline, or may not have responded to a decryption request from client computer 802. Cryptographic devices 804 to 808 may generate these partial signatures using the commitment x, the corresponding verification shares sk'1, sk'2, and sk'3 of the cryptographic devices, and a distributed pseudo-random function, as described in Section I above.

[0211] Distributed pseudo-random functions may include elliptic curve cryptography functions. For example, cryptographic devices 804 to 808 can generate corresponding partial signatures of the cryptographic device by using their respective verification shares and elliptic curve cryptography to encrypt the commitment. However, it should be understood that cryptographic devices 804 to 808 can generate partial signatures in any other suitable manner. For example, using partial signature schemes based on pairwise friendly elliptic curves, message authentication codes, hash-based message authentication codes, etc. Cryptographic devices 804 to 808 can use the threshold-authenticated partial signature function TA.PartSign, which uses the commitment x and the corresponding verification shares sk'1, sk'2, and sk'3 of the cryptographic device as independent variables, to generate partial signatures.

[0212] Optionally, in step 818, the participating cryptographic devices 804 to 808 may each send a NIZK (non-interactive zero-knowledge proof) to the client computer 802. The client computer 802 can use the NIZK to verify that the partial computation corresponding to those NIZKs has been correctly generated. If any NIZK fails to be verified, the client computer may abort the improved distributed symmetric encryption process.

[0213] In step 820, the participating cryptographic devices 804 to 808 may send partial computations y1, y2, and y3, as well as partial signatures z1, z2, and z3, to the client computer 802. The participating cryptographic devices 804 to 808 may send the partial computations directly or through a proxy device.

[0214] In step 822, the client computer 802 may combine the partial computations and generate a cryptographic key y. The client computer 802 may combine the partial computations using the DPRF.Combine function, which uses partial computations y1, y2, and y3 as independent variables. In some embodiments, the client computer 802 may combine the partial computations to generate a key generation seed, and the key generation seed may be used in conjunction with a key generation algorithm to generate a cryptographic key. The client computer 802 may combine the partial computations in any suitable manner. For example, the client computer 802 may first determine multiple Lagrange coefficients corresponding to multiple partial computations. The client computer 802 may generate multiple intermediate computations by exponentiation of each partial computation with the Lagrange coefficients corresponding to the partial computations. The client computer 802 may generate a key generation seed by calculating the product of the multiple intermediate computations. The key generation seed may be input into a key generation algorithm to generate a cryptographic key. See Section I for details.

[0215] Similarly, in step 824, client computer 802 can combine partial signatures z1, z2, and z3 to generate a verification signature z. Client computer 802 can combine partial signatures z1, z2, and z3 using the TA.CombineSig function. Client computer 802 can combine the partial signatures in any suitable manner. For example, client computer 802 can first determine multiple Lagrange coefficients corresponding to multiple partial signatures. The client computer can generate multiple intermediate signatures by exponentiation of each partial signature with the Lagrange coefficients corresponding to the partial signatures. Client computer 802 can generate a verification signature by calculating the product of the multiple intermediate signatures. See Section I for details.

[0216] In step 826, client computer 802 can encrypt the message using the cryptographic key y to generate ciphertext e. Alternatively, client computer 802 can encrypt the message m and a random or temporary number r used to blind the commitment (see step 812). The client computer can encrypt the message using any suitable symmetric cryptosystem corresponding to the cryptographic key, such as AES (e.g., ...). Figure 8 As shown: e = AES y (m|r)).

[0217] In step 828, client computer 802 may generate a payload including ciphertext e, commitment x, and verification signature z. This payload includes the information needed to decrypt the ciphertext using an improved distributed symmetric cryptography. Client computer 802 may send the payload to another client computer for secure message transmission. This other client computer can then use the improved distributed symmetric cryptography, commitment, and verification signature to decrypt the ciphertext.

[0218] B. Decryption

[0219] refer to Figure 9 This allows for a better understanding of improved distributed symmetric decryption. In improved distributed symmetric decryption, the client computer sends a verification signature to the participating cryptographic device. The verification signature indicates to the cryptographic device that the client computer is performing decryption. This is an improvement over the distributed symmetric decryption described in Section IV because the cryptographic device is able to determine that the client computer is performing distributed symmetric decryption.

[0220] Figure 9 This diagram illustrates a mixed sequence of a client computer 902 and multiple cryptographic devices 904 to 910 performing an improved distributed symmetric decryption process. Figure 9 As indicated, client computer 902 is performing improved distributed symmetric decryption in conjunction with cryptographic devices 904, 906, and 910. It is noteworthy that client computer 902 may incorporate cryptographic devices other than those used during improved distributed symmetric encryption (e.g., ...). Figure 8 The cryptographic devices other than 804 to 808 in the system perform improved distributed symmetric decryption.

[0221] In some contexts, the term "cryptographic device" may refer to the cryptographic device involved in improved distributed symmetric encryption, while the term "additional cryptographic device" may refer to the cryptographic device involved in improved distributed symmetric decryption. The term "additional partial computation" may refer to partial computation generated by additional cryptographic devices—that is, those cryptographic devices involved in improved distributed symmetric decryption. Similarly, the term "additional secret share" may refer to the secret share corresponding to the additional cryptographic device.

[0222] In step 912, client computer 902 may send the commitment x and verification signature z to the participating cryptographic devices 904, 906, and 910. Client computer 902 may have already generated the commitment and verification signature themselves, or may have received the commitment and verification signature from another computer, such as another client computer. For example, another client computer (e.g., Figure 8Client computer 802 may have executed an improved distributed symmetric encryption process and generated a payload including ciphertext, a promise, and a verification signature. Another client computer may have sent this payload to client computer 902, and client computer 902 may send the promise and verification signature received in the payload to cryptographic devices 904, 906, and 910. Client computer 902 may send the promise and verification signature directly or through a proxy device to cryptographic devices 904, 906, and 910. Client computer 902 may additionally send an indicator to participating cryptographic devices 904, 906, and 910. The indicator may instruct the participating cryptographic devices that client computer 902 wants to perform decryption. Participating cryptographic devices 904, 906, and 910 may log this indicator in a log file.

[0223] In step 914, cryptographic devices 904, 906, and 910 can verify the verification signature z using the commitment x and the verification key vk. This may involve cryptographic devices 904, 906, and 910 performing the verification signature function VerSig using the verification key, commitment, and verification signature as arguments. If the verification signature is valid, cryptographic devices 904, 906, and 910 can continue the improved symmetric decryption process. Otherwise, cryptographic devices 904, 906, and 910 can terminate the process.

[0224] Cryptographic devices 904, 906, and 910 may verify the verification signature using any suitable technique or method. For example, the verification key may include the public key of a public-private key pair, and the verification value may include the private key of the public-private key pair. The verification signature may be equivalent to a commitment encrypted using the verification value. Cryptographic devices 904, 906, and 910 may verify the verification signature by decrypting it using the verification key to generate a commitment. The cryptographic devices 904, 906, and 910 may then compare the commitment with a commitment received from the client computer 902. If the commitments match, the verification signature is verified as valid.

[0225] It should be understood that cryptographic devices 904 and 906 may use any suitable method, such as the method based on the distributed signature function described above, to verify the verification signature. Cryptographic devices 904, 906, and 910 may also use a hash-based message authentication code function (HMAC function) to verify the verification signature.

[0226] In step 916, once the verification signature is determined to be valid, cryptographic devices 904, 906, and 910 can generate partial computations y1, y2, and y4 based on the commitment x and the corresponding secret shares sk1, sk2, and sk4 of the cryptographic devices. Cryptographic devices 904, 906, and 910 can use a distributed pseudo-random function to generate these partial computations, as described in Section I above. For example, cryptographic devices 904, 906, and 910 can generate partial computations by executing the DPRF.Eval function using their respective secret shares and commitments as arguments. The distributed pseudo-random function may include an elliptic curve cryptography function. For example, cryptographic devices 904, 906, and 910 can each generate partial computations by encrypting the commitment using their respective secret shares and elliptic curve cryptography.

[0227] In step 918, the participating cryptographic devices 904, 906, and 910 may send partial computations y1, y2, and y4 to the client computer 902. The participating cryptographic devices 904, 906, and 910 may send these partial computations directly or through a proxy device.

[0228] Optionally, in step 918, the participating cryptographic devices 904, 906, and 910 may each send a NIZK to the client computer 902. The client computer 902 can use the NIZK to verify that the partial computations corresponding to those NIZKs have been correctly generated. If any NIZK fails to be verified, the client computer may abort the improved distributed symmetric decryption process.

[0229] In step 920, client computer 902 may combine partial computations y1, y2, and y4 to generate a cryptographic key y. For example, client computer 902 may use the DPRF.Combine function to combine the partial computations. In some embodiments, client computer 902 may combine the partial computations to generate a key generation seed, and then use the key generation seed as input to a key generation algorithm to generate a cryptographic key. Client computer 902 may combine the partial computations in any suitable manner. For example, client computer 902 may first determine multiple Lagrange coefficients corresponding to multiple partial computations. Client computer 902 may generate multiple intermediate computations by exponentiation of each partial computation with the Lagrange coefficients corresponding to the partial computations. Client computer 902 may generate a key generation seed by calculating the product of the multiple intermediate computations. The key generation seed may be input into a key generation algorithm to generate a cryptographic key. See Section I for details.

[0230] In step 922, the client computer 902 may decrypt the ciphertext e to generate the message m. Alternatively, the client computer 902 may decrypt the ciphertext to generate the message m and a random value r for blinding the commitment (see...). Figure 6Step 812). The client computer 902 can use any suitable symmetric cryptosystem, such as AES, corresponding to the cryptographic key to decrypt the ciphertext (e.g., ...). Figure 9 As shown, m|r=AES y -1 (e)).

[0231] In optional step 924, client computer 904 can verify whether the message matches the commitment. Client computer 902 can use the message and a random value as input to a hash function to generate an additional commitment. Client computer 902 can then compare the commitment sent in step 912 with the commitment generated in step 922. If the commitments match, it indicates that the message has been correctly encrypted and decrypted.

[0232] VI. Computer System

[0233] Any computer system mentioned in this article can utilize any suitable number of subsystems. Figure 10 Examples of such subsystems are illustrated in computer device 1000. In some embodiments, the computer system includes a single computer device, and the subsystem may include components of the computer device. In other embodiments, the computer system may include multiple computer devices, each of which is a subsystem with internal components.

[0234] Figure 10 The subsystems shown are interconnected via system bus 1005. Additional subsystems are shown, such as printer 1004, keyboard 1008, storage device(s) 1009, monitor 1006 (coupled to display adapter 1011), etc. Peripheral devices and I / O devices coupled to input / output (I / O) controller 1001 can be connected to the computer system via any number of components known in the art, such as input / output (I / O) ports 1007 (e.g., USB, etc.). For example, I / O port 1007 or external interface 1010 (e.g., Ethernet, Wi-Fi, etc.) can be used to connect computer system 1000 to a wide area network such as the Internet, a mouse input device, or a scanner. Interconnection via system bus 1005 allows central processing unit 1003 to communicate with each subsystem and control the execution of instructions from system memory 1002 or storage device 1009 (e.g., a fixed disk, such as a hard disk drive or optical disk), as well as the exchange of information between subsystems. System memory 1002 and / or storage device 1009 may embody a computer-readable medium. Any data mentioned herein may be output from one component to another and may be output to a user.

[0235] A computer system may include multiple identical components or subsystems connected together, for example, via an external interface 1010 or an internal interface. In some embodiments, the computer system, subsystem, or device may communicate via a network. In such cases, one computer may be considered a client, and another computer may be considered a server, wherein each computer may be part of the same computer system. The client and server may each include multiple systems, subsystems, or components.

[0236] It should be understood that any embodiment of the present invention can be implemented using hardware (e.g., application-specific integrated circuits or field-programmable gate arrays) and / or computer software in the form of control logic, wherein the general-purpose programmable processor is modular or integrated. As used herein, the processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units on a single circuit board or networked thereon. Based on this disclosure and the teachings provided herein, those skilled in the art will know and understand other ways and / or methods of implementing embodiments of the present invention using hardware and combinations of hardware and software.

[0237] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing techniques such as conventional or object-oriented methods. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or DVDs (Digital Universal Discs), flash memory, etc. The computer-readable medium may be any combination of such storage or transmission means.

[0238] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, computer-readable media according to embodiments of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. The computer system may include a monitor, printer, or other suitable display for providing any results mentioned herein to a user.

[0239] Any method described herein can be performed wholly or partially by a computer system including one or more processors configured to perform the steps. Therefore, embodiments may relate to a computer system configured to perform the steps of any method described herein, possibly having different components that perform corresponding steps or groups of corresponding steps. Although presented as numbered steps, the method steps herein may also be performed simultaneously or in different orders. Furthermore, portions of these steps may be used in conjunction with portions of other steps from other methods. Similarly, all or part of a step may be optional. Additionally, any step of any method may be performed using modules, circuits, or other means for performing these steps.

[0240] Specific details of particular embodiments may be combined in any suitable manner without departing from the spirit and scope of the embodiments of the invention. However, other embodiments of the invention may relate to specific embodiments associated with each individual aspect or a particular combination of these individual aspects. The foregoing description of exemplary embodiments of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms described; many modifications and variations are possible in accordance with the teachings above. These embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling those skilled in the art to best utilize the invention in various embodiments and to make various modifications suitable for the particular intended use.

[0241] Unless explicitly indicated otherwise, the use of “a / kind” or “the / described” is intended to mean “one / kind or more / kinds”. Unless explicitly indicated otherwise, the use of “or” is intended to mean “inclusive or”, not “exclusive or”.

[0242] All patents, patent applications, publications, and descriptions mentioned herein are incorporated herein by reference in their entirety for all purposes. This does not imply an admission that they are prior art.

Claims

1. A method comprising, by a computer system: generating a commitment using a message and a random value; sending a request including the commitment to each of a plurality of cryptographic devices, the plurality of cryptographic devices storing a plurality of secret shares generated from a secret value and a plurality of verification shares generated from a verification value, the request indicating that each of the plurality of cryptographic devices is to perform a cryptographic function; sending an indicator to each of the plurality of cryptographic devices, the indicator indicating to the plurality of cryptographic devices that the computer system wants to perform an encryption, wherein the plurality of cryptographic devices are configured to record the indicator in a log file; receiving a plurality of partial computations from the plurality of cryptographic devices, wherein the plurality of partial computations are generated by the plurality of cryptographic devices using the plurality of secret shares and the commitment; receiving a plurality of partial signatures from the plurality of cryptographic devices, wherein the plurality of partial signatures are generated by the plurality of cryptographic devices using the plurality of verification shares and the commitment; generating a cryptographic key based on the plurality of partial computations; generating a verification signature based on the plurality of partial signatures; generating a ciphertext by encrypting the message and the random value using the cryptographic key; and generating a payload including the ciphertext, the verification signature, and the commitment.

2. The method of claim 1, wherein: sending the commitment to the plurality of cryptographic devices comprises sending the commitment to a proxy device, wherein the proxy device sends the commitment to the plurality of cryptographic devices; receiving the plurality of partial computations from the plurality of cryptographic devices comprises receiving the plurality of partial computations from the proxy device, wherein the proxy device receives the plurality of partial computations from the plurality of cryptographic devices; and receiving the plurality of partial signatures from the plurality of cryptographic devices comprises receiving the plurality of partial signatures from the proxy device, wherein the proxy device receives the plurality of partial signatures from the plurality of cryptographic devices.

3. The method of claim 1, wherein the plurality of cryptographic devices comprises at least a predetermined threshold number of cryptographic devices, and wherein the predetermined threshold number of cryptographic devices is less than a total number of cryptographic devices.

4. The method of claim 1, wherein generating the cryptographic key based on the plurality of partial computations comprises: generating a key generation seed based on the plurality of partial computations; and generating the cryptographic key by using the key generation seed as input to a key generation function.

5. The method of claim 1, wherein generating the commitment comprises generating a hash value of the message and the random value using a hash function.

6. The method of claim 1, further comprising selecting the plurality of cryptographic devices from a network of cryptographic devices.

7. The method of claim 1, further comprising: sending the verification signature and the commitment to a plurality of additional cryptographic devices, wherein the plurality of additional cryptographic devices verify the verification signature using a verification key and the commitment; receiving a plurality of additional partial computations, wherein the plurality of additional partial computations are generated by the plurality of additional cryptographic devices using a plurality of additional secret shares and the commitment; and verifying the plurality of additional partial computations using the cryptographic key. ​ ​ A second cryptographic key is generated based on the aforementioned additional components; as well as The ciphertext is decrypted using the second cryptographic key to generate the message and the random value.

8. The method of claim 7, wherein one or more of the plurality of cryptographic devices are identical to one or more of the plurality of additional cryptographic devices, and wherein one or more of the plurality of secret shares are identical to one or more of the plurality of additional secret shares.

9. A method comprising performing the following by a computer system: The verification signature and commitment are sent to multiple cryptographic devices, wherein the multiple cryptographic devices verify the verification signature using a verification key corresponding to the verification value and the commitment; Sending an indicator to the plurality of cryptographic devices, the indicator instructing the plurality of cryptographic devices that the computer system wants to perform decryption, wherein the plurality of cryptographic devices record the indicator in a log file; Receive multiple partial computations, wherein the multiple partial computations are generated by the multiple cryptographic devices using multiple secret shares and the commitment; A cryptographic key is generated based on the aforementioned multiple components; as well as The cryptographic key is used to decrypt the ciphertext to generate a message and a random value.

10. The method of claim 9, wherein the plurality of cryptographic devices verify the verification signature by: Decrypt the verification signature using the verification key to generate an additional commitment; and Determine whether the additional commitment is the same as the commitment.

11. The method according to claim 9, wherein: Sending the commitment to the plurality of cryptographic devices includes sending the commitment to a proxy device, wherein the proxy device sends the commitment to the plurality of cryptographic devices; Sending the verification signature to the plurality of cryptographic devices includes sending the verification signature to the proxy device, wherein the proxy device sends the verification signature to the plurality of cryptographic devices; as well as Receiving the plurality of partial calculations from the plurality of cryptographic devices includes receiving the plurality of partial calculations from the proxy device, wherein the proxy device receives the plurality of partial calculations from the plurality of cryptographic devices.

12. The method of claim 9, wherein the plurality of cryptographic devices comprises at least a predetermined threshold number of cryptographic devices, wherein the predetermined threshold number of cryptographic devices is less than the total number of cryptographic devices.

13. The method of claim 9, wherein generating the cryptographic key based on the plurality of parts comprises: Based on the aforementioned multiple components, a key is generated to generate a seed; as well as The cryptographic key is generated by using the key generation seed as input to the key generation function.

14. The method of claim 9, further comprising selecting the plurality of cryptographic devices from a network of cryptographic devices.

15. A method comprising performing: Receive a request from the client computer, the request including a commitment generated using a message and a random value; The client computer receives an indicator indicating that it wants to encrypt the message. Record the indicator in the log file; Calculated based on the secret share and the commitment generated portion; A partial signature is generated based on the verified share and the commitment; as well as The partial computation and the partial signature are sent to the client computer, thereby enabling the client computer to: (1) generate a cryptographic key using the partial computation, (2) encrypt the message using the cryptographic key to generate ciphertext, (3) generate a verification signature using the partial signature, and (4) generate a payload including the ciphertext, the verification signature, and the commitment.

16. The method of claim 15, further comprising receiving the secret share from a trusted external server before receiving the request from the client computer, wherein the trusted external server also sends one or more other secret shares to one or more other cryptographic devices.

17. The method of claim 15, further comprising: Receive the verification signature and the commitment from the client computer; Based on the verified signature and the commitment, it is determined that the client computer wants to decrypt the message; The verification signature is verified using the verification key and the commitment; The partial calculation is generated based on the commitment and the secret share; as well as The partial computation is sent to the client computer, which uses the partial computation to generate the cryptographic key and uses the cryptographic key to decrypt the ciphertext to generate the message and the random value.

18. The method of claim 17, wherein verifying the verification signature using the verification key and the commitment comprises: Use the verification key to decrypt the verification signature to generate an additional commitment; as well as Compare the commitment with the additional commitment.

19. The method of claim 17, further comprising: Receive another indicator from the client computer indicating that the client computer wants to perform decryption; as well as Record the other indicator in the log file.

20. A system comprising: One or more processors; as well as A computer-readable medium storing a plurality of instructions, which, when executed, cause the one or more processors to perform the method according to any one of claims 1 to 19.

Images