System and method for untrusted distributed symmetric encryption

Abstract

Provided are systems and methods for symmetric encryption without a trusted third party. A system for symmetric encryption includes a plurality of participant devices that operate without a trusted third party to eliminate potential security risks associated with the third party, and allowing the holder of the piece of information to encrypt the information with the aid of a subset of k participants among the n participants in such a way that the information can only be recovered with the aid of another subset of k participants among those identical n participants. A method for symmetric encryption comprises a setting phase, an encryption phase and a decryption phase. K participants in the n participants will be involved in the encryption and decryption stages. All participants are involved in the setting stage.

Description

Technical Field

[0001] The embodiments disclosed herein relate to cryptography and encryption protocols, and more specifically, to systems and methods for cryptographic symmetric encryption in the absence of a trusted third party. Background Technology

[0002] The foundation for the secret sharing scheme was laid in Adi Shamir's 1979 paper. How to Share a Secret (Shamir, A., Communications of the ACM, 1979, Vol. 22, No. 11, pp. 612-613) describes this. This article introduces embedded in k-1 The concept of secrets in polynomials of degree n, where k This refers to the number of participants required to restore the secret. In the described scheme, k-1 polynomial of degree n Each point is evaluated, and each evaluation is given to a different participant. A subset of the participants can then use Lagrange interpolation to jointly recover the secret.

[0003] This article opened doors to many new areas of research. Today, the sum of this research is collectively referred to as [the article on...]. Threshold password The work, or involving a group of n The study of cryptographic systems with multiple participants, from the aforementioned group n A subset of participants k Each participant is asked to perform an operation (usually encryption and decryption).

[0004] Of particular interest is the study of distributed pseudo-random functions (DPRFs), in which a group of participants collaborate to compute the seemingly random output of a function. DPRFs themselves refer to a scheme involving all participants, where no subgroup of the participants can obtain the correct output.

[0005] Naor, Pinkas, and Reingold introduced this concept in their 1999 paper, *Distributed Pseudo-Random Functions and KDC* (Naor, M., et al., *Eurocrypt'99 International Conference: Lecture Notes in Computer Science*, 1999, Vol. 1592, pp. 327-346). Threshold DPRF The concept, where the output of DPRF can be determined by a total n Among the participants k Subgroups of each participant were correctly evaluated, while those above... k-1A subset of participants cannot do so. In this scheme, only a fixed size subset of participants is required to correctly evaluate the function. This work is integral to the invention described herein.

[0006] While the study of threshold cryptography is a fairly old concept, dating back to 1994 (De Santis, A, et al., “How to share a function securely”, TOC 94: Proceedings of the twenty-sixth annual ACM symposium on Theory of Computing, May 1994, pp. 522-533), it only gained momentum in the 2010s in the cryptography community. The National Institute of Standards and Technology (NIST) held a workshop on threshold cryptography in 2019 and published “Roadmap Toward Criteria for Threshold Schemes for Cryptographic Primitives” (Brandao, L., et al., NISTIR 8214A, 2020) in 2020.

[0007] Until 2018, researchers mostly focused on public-key threshold cryptography. When it comes to symmetric threshold cryptography, the core definitions and concepts were introduced in 2018 (Agarwal, S., et al., “DiSE: Distributed Symmetric-key Encryption”, CCS '18: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 1993-2010). The article also details the general structure of threshold authenticated encryption based on any DPRF. The researchers describe the scheme as an alternative to the use of expensive hardware security modules or the simple use of single point of failure solutions. It presents the participants as a set of servers, possibly owned by the same corporate entity.

[0008] In existing symmetric threshold cryptography schemes, a fundamental limitation and security risk is the need for a trusted third party to facilitate or mediate interactions between participants. If the trusted third party is compromised, hacked, or otherwise unavailable, the entire cryptographic process, including the secret, can be compromised.

[0009] Accordingly, there is a need for an improved cryptographic system and method for threshold symmetric encryption without a trusted third party, while preserving all security guarantees, which overcomes at least some of the limitations of existing systems and methods. SUMMARY

[0010] Systems and methods for untrusted distributed symmetric encryption are described. According to an embodiment, there is a system for symmetric encryption. The system includes a plurality of participant devices that operate without a trusted third party to eliminate potential security risks associated with the third party and to allow holders of pieces of information to encrypt the information with the help of a subset of k participants out of n participants in such a way that the information can only be recovered with the help of another subset of k participants out of the same n participants, which can be the same or different from the subset of participants involved in the encryption.

[0011] According to another embodiment, there is a method for symmetric encryption without a trusted third party. The method includes a setup phase involving all participants and further includes an encryption and decryption phase involving n k participants out of n participants. k k participants.

[0012] The setup phase includes initiating a setup request by direct communication between the participants or facilitated by a communication facilitation subsystem such as a web portal or a dedicated server; creating and sending setup information to the plurality of participant devices, directly or through the communication facilitation subsystem; verifying the setup information by each participant device and creating a whitelist of identifiers of encryption requesters and decryption requesters; creating a partial secret by each participant device; passing the partial secret shares among the participant devices; adding the partial secret shares to obtain a secret share for each participant device, which is stored in a cryptographic storage device; computing and publishing a commitment by each participant device to a public storage device; collecting the commitments for attesting future encryption and decryption operations; and attesting data generated by a test encryption using the identifiers in the whitelist and the commitments stored in the public storage device.

[0013] The encryption phase includes: sending, by the information holder device, directly or through the communication facilitation subsystem, an encryption request to the participant devices including its own identifier and commitment; passing, directly or through the communication facilitation subsystem, the identifier and commitment to the participant devices; verifying, by each participant device, that the identifier is whitelisted; calculating, by each participant device, an evaluation and evidence to be sent to the information holder device; verifying, by the information holder device, the evaluation and evidence received from each participant device using the commitment stored in the public storage device; combining, by the information handler device, the received evaluations to form a mask to be used to hide the information or, in the case of a large amount of information, a symmetric key that can be used to recover the information; and publishing the masked data, identifier and commitment to the public storage device.

[0014] The decryption phase includes: retrieving, by the information request device, the identifier, the participant's secret shared commitment and the commitment to the original message through direct communication or with the help of a communication facilitation subsystem such as a web portal or a dedicated server; sending, directly or with the help of the aforementioned communication facilitation subsystem, the identifier and the commitment to the message to each participant device; verifying, by each participant device, that the information request device is whitelisted for decryption requests and that the information holder device is whitelisted for encryption requests; calculating, by each participant device, an evaluation as a function of the received commitment and its individual secret share, together with the evidence sent to the information requester device; sending, by each participant device, the aforementioned evaluation and evidence; validating, by the information requester device, the received evidence; combining, by the information requester device, the evaluations to reform the mask; using the aforementioned mask to decrypt the ciphertext retrieved from the public storage device; and using the message commitment to verify the integrity of the retrieved message.

[0015] Other aspects and features will become apparent to those of ordinary skill in the art upon review of the following description of some exemplary embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0016] The drawings accompanying herewith are used to illustrate various examples of the articles, methods and apparatuses of the present specification. In the drawings: Figure 1 is a diagram of a system for threshold symmetric encryption shown during the setup phase according to an embodiment; Figure 2 is a diagram of a system for threshold symmetric encryption shown during the encryption phase according to an embodiment; Figure 3 is a diagram of a system for threshold symmetric encryption shown during the decryption phase according to an embodiment; Figure 4A is a flowchart of the setup phase of a threshold symmetric encryption method according to an embodiment; Figure 4B is a flowchart of the encryption phase of the threshold symmetric encryption method according to an embodiment; Figure 4C is a flowchart of the decryption phase of the threshold symmetric encryption method according to an embodiment; Figure 5 is Figure 1 and Figure 4A is a simplified diagram of an exemplary implementation of the setup phase shown in Figure 6 is Figure 2 and Figure 4B is a simplified diagram of an exemplary implementation of the encryption phase shown in Figure 7 is Figure 3 and Figure 4C is a simplified diagram of an exemplary implementation of the decryption phase shown in DETAILED DESCRIPTION

[0017] Various apparatus or processes will be described below to provide an example of each claimed embodiment. The embodiments described below do not limit any claimed embodiment and are not required for any claimed embodiment. Any claimed embodiment can encompass processes or apparatus differing from those described below. The claimed embodiments are not limited to apparatus having all of the features of any one described below or to features common to multiple or all of the described apparatus.

[0018] One or more systems described herein can be implemented in a computer program executing on programmable computers, each computer including at least one processor, a data storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. For example, and without limitation, the programmable computers can be programmable logic units, mainframe computers, servers and personal computers, cloud-based programs or systems, laptops, personal data assistants, cellular phones, smart phones, or tablet devices.

[0019] Each program is preferably implemented in a high level procedural or object oriented programming and / or scripting language to communicate with a computer system. However, programs can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language. Each such computer program is preferably stored on a storage media or a device readable by a general or special purpose programmable computer for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein.

[0020] The description of embodiments having several components in communication with each other does not imply that all of these components are required. On the contrary, a variety of optional components are described to illustrate various potential embodiments of the present application.

[0021] Moreover, while process steps, method steps, algorithms, or the like can be described in a sequential order (in the present disclosure and / or in claims), such processes, methods, and algorithms can be configured to work in alternate orders. In other words, any sequence or order of steps that are described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein can be performed in any order practicable. Moreover, some steps can be performed simultaneously.

[0022] When a single device or article is described herein, it will be readily apparent that more than one device / article (whether or not they cooperate) can be used in place of a single device / article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device / article can be used in place of the more than one device or article. This includes cases where the

[0023] Reference herein to "(one or more) participant" refers to an individual / device / system that holds cryptographic information and can mathematically contribute to encryption or decryption operations. An "entity" can request operations of encryption or decryption. A participant can or can not be an entity. It should be noted that certain values herein include the prefix "0x", indicating hexadecimal notation.

[0024] The cryptographic system to be described is one that operates without a trusted third party, to eliminate potential security risks associated with the third party, and allows the holder of a piece of information to encrypt that information with the help of a subset of k participants out of n participants, in such a way that the information can only be recovered with the help of another subset of k participants out of those same n participants. In particular, the system is set up without a trusted third party, while preserving all security guarantees, as compared to traditional encryption protocols. Moreover, a different setup is described, which moves away from a set of servers and towards collaboration between corporate entities and individual customers.

[0025] In this document, Security Strong correctness, message privacy, and strong authenticity are defined to exist, as defined by Agarwal, S, et al. The present invention includes an algorithm, called Setup phase , Encryption phase Decryption phase and n of k In this document, the following terms are used: Figure 1 Threshold scheme (where 0 < k <= n ), which is used to pass on the number of participants out of n k ​the fact that one participant is involved. All participants are involved in the setup phase.

[0026] Setup phase Reference gen1 shown is a simplified diagram of a system 100 for threshold symmetric encryption during the setup phase 100 according to an embodiment. The system 100 provides a way to jointly encrypt any information or document in such a way that ensures its security, despite malicious action by a subset of the participants. In general, there can be any number n of participants (i.e. p1 , p2 , p4 … p n ).

[0027] In the setup phase, the initiator 10 will identify the participants 12a, 12b, 12c, 12d involved and provide them with setup information 11 to contact each other. The setup information 11 will also identify the location of a shared public repository 13 to be used by all participants 12a, 12b, 12c, 12d, and will provide the participants with a list of authorized entities (called a whitelist) that are allowed to initiate the encryption and decryption phases, as well as public information required for starting the encryption process. It should be noted that no secure channel is required to pass the setup information 11 to the participants 12a, 12b, 12c, 12d.

[0028] The setup information 11 includes: the total number of participants n ; the required number of participants involved in the encryption or decryption operation k ; the public storage 13; a list of entities allowed to make encryption requests and a list of entities allowed to make decryption requests. The list of entities allowed to make decryption requests can be different from the list of entities allowed to make encryption requests.

[0029] The setup information 11 also includes: a cyclic group G with order q, where the discrete logarithm problem (DLP) is difficult; two generators chosen independently of each other, which will be provided with evidence that the initiator 10 does not know any mathematical relationship between the two generators; an ordering of the participants; and a unique identifier of the group of participants.

[0030] After receiving the setup information 11, each participant 12a, 12b, 12c, 12d will individually perform the following operations: (1) create two whitelists matching the provided list of entities allowed to make encryption and decryption requests, respectively; (2) create a secret value between 0 and q-1 (inclusive) of the order of the group G, called a partial secret; (3) split the partial secret into n partial secret shares, requiring kThe partial secret is re-formed through partial secret sharing; and (4) this is transmitted via an end-to-end secure channel. n Each part is secretly shared and distributed to all. n One participant.

[0031] Once all are received n Each participant 12a, 12b, 12c, and 12d will combine these partial secret shares 22 to form a secret share. The secret share is represented as Cartesian coordinates (x, y), where the x-coordinates can be common and correspond to their order in group G, and the y-coordinates are the participants' partial secrets. s .

[0032] Participants 12a, 12b, 12c, and 12d subsequently publish their individual secret sharing of Peterson commitments 33a, 33b, 33c, and 33d in the shared public storage device 13 by calculating the following: for the two generators provided by initiator 10 gen2 , Secret sharing , s yes gen1 The y-coordinate, and r It is a value randomly selected between 1 and q-1 (inclusive), and the calculation is performed. *gen2 s = γ r Figure 2 Each participant holds 12a, 12b, 12c, and 12d privately. s and r As a private key.

[0033] Once all commitments 33a, 33b, 33c, and 33d have been published, each participant 12a, 12b, 12c, and 12d will verify that no malicious activity occurred during the setup phase (not shown). Each participant 12a, 12b, 12c, and 12d will ensure the correctness of the generated Share 22 by contacting all other participants and requesting their help in encrypting random values. A whitelist is set up for the participants solely for this verification purpose. Participants 12a, 12b, 12c, and 12d will verify that no malicious activity occurred during the setup phase (not shown). k Encryption of random values ​​with the help of several participants and in n The encryption of random values ​​is the same with the help of multiple participants, but different from that in k-1 The encryption of random values, aided by multiple participants, verifies the consistency of all shared 22 values. Details of the encryption process are described below.

[0034] Encryption phase refer to Figure 3wherein shown is a simplified diagram of the encryption phase 110 according to an embodiment. The encryption phase 110 can be initiated by any entity that is allowed to do so according to the whitelist identified in the setup phase. The encryption phase allows one such entity to encrypt any piece of information in such a way that n k participants 12a, 12b, 12c, 12d are needed to decrypt the information. Note that participant 12d represents a subset of participants that are not involved in the encryption and in fact do not have to be online at all, as only k out of n participants are needed. Note that the participants 12a, 12b, 12c that help with the encryption are not necessarily the same as the participants that help with the decryption ( k ). n ). k ). ρ ).

[0035] The encryption phase 100 is initiated by an info holder 14, which can or can not be a participant as identified in the setup phase. The info holder 14 will contact k k participants 12a, 12b, 12c (or n if it is itself a participant), and will provide them with a packet 44 that includes a commitment a and their own identifier, the commitment a being a function of the information / message m k-1 that they want to encrypt. m

[0036] The info holder 14 first computes a commitment a of m m under newly generated randomness p as follows: a = XOF(m || id ), where XOF is an extendable output function, e.g. SHAKE256, and || is the concatenation symbol. The info holder 14 sends its identifier ω = H(id || and a to the k k participants 12a, 12b, 12c in a packet 44.

[0037] Each contacted participant 12a, 12b, 12c will first confirm that the info holder 14 is part of the provided whitelist, and is allowed to request encryption before providing a response 55 to the info holder 14. The response 55 consists of two elements: (A) a value that will be a function of the data included in the packet 44 and the participant’s secret share, and (B) a proof that will be used to establish security.

[0038] Each contacted participant 12a, 12b, 12c will compute the value (A) as: · h = ω a )， where H() is a cryptographically secure hash function​； · mask1, mask2 s (Using r as defined in the setup phase s ); · Each contacted participant 12a, 12b, 12c sets the evidence (B) to be: · A random sample in the range [1, q-1] ω ; · Set t = challenge = H'(h, ω, γ, gen1, gen2, t, t') mask1 , t' = gen1 mask1 * gen2 mask2 ; · Set challenge, sig1, sig2 , for H'(), which is a cryptographically secure hash function different from H(); · Set sig1 = (mask1-challenge*s), sig2 = (mask2-challenge*r) (using r as defined in the setup phase); and · Call challenge, ) the evidence, as it proves that the participant used their secret share in its computation.

[0039] Each participant 12a, 12b, 12c then returns to the information holder 14, through an end-to-end secure channel, the evaluation h, the evidence sig1, sig2 ω ), and optionally ω = H(id || as a response 55.

[0040] Upon receiving the responses 55 from all contacted participants, the information holder 14 will then validate the received evidence and combine the received values to form the mask: · Compute t = ω α ) ; · For each received response: o Compute t' = gen1 sig1 * h challenge ; o Compute * gen2 sig1 * γ sig2 challenge = H'(h, ω, γ, gen1, gen2, t, t') challenge ; and o Verify comb .

[0041] If all verifications are not successful, the encryption phase terminates. If all verifications are successful, the information holder 14 computes a Lagrange interpolation of all received responses 55 h e = PRG(comb) using the identifiers of the participants as listed in the ordered list of participants and the values provided in the participants' responses 55 xor (m || ρ) comb where PRG is a pseudo-random number generator seeded by id

[0042] Preferably, although not mandatorily, the information holder 14 will encrypt its information using any symmetric cipher matching its targeted level of security and will hide the symmetric cipher key with a mask. According to other embodiments, the information is encrypted using a mask (without a symmetric cipher), although this usually requires more storage space. The information holder 14 will subsequently publish 66 in the designated public storage 13 the commitment a, the identifier of the information holder 14 Figure 3 and the value e (which masks the encrypted information / message m and the randomness used to compute a).

[0043] The decryption phase Reference is made to id' wherein a simplified diagram of the decryption phase 120 according to an embodiment is shown. The decryption phase 120 can be initiated by any entity allowed to do so according to the list identified in the setup phase. In the decryption phase 120, an information requestor 15, which can or can not be a participant as identified in the setup phase, will contact k participants 12b, 12c, 12d (or k-1 if it is itself a participant), and will provide them with a packet 77 matching the information they wish to retrieve along with their identifier Figure 2 , which can be found in the designated public storage 13. Note that the participants 12a represent a subset of participants not involved in the decryption and in fact do not necessarily have to be online at all, as only k out of n participants are needed. Note that the participants 12b, 12c, 12d that help with the decryption are not necessarily the same as the participants that helped with the encryption (see id ).

[0044] The information requestor 15 will first retrieve the encrypted information 67, i.e. id' , a and e from the public storage 13. The information requestor 15 will then send its own packet 77, which includes its own identifier k to the id || participants 12a, 12b, 12c.​and id α. Note the identifier of the entity requesting encryption id' and the identifier of the entity requesting decryption Evidence .

[0045] The contacted participants 12b, 12c, 12d will first confirm that the information requester 15 is part of the provided whitelist and is allowed to request decryption, and then will provide the response 88 to the information requester 15 over an end-to-end secure channel. The response 88 consists of two elements: (A) an evaluation, which will be a function of the commitment α to the information / message m and the secret share of that participant, and (B) a value that will be used to establish security ω = H(id || . Each contacted participant 12b, 12c, 12d confirms that both id and id’ are the allowed information requester and the allowed information holder, respectively, and then computes (A) and (B) in the same way as the encryption phase described above.

[0046] The information requester 15 will then verify the received evidence and will combine the received values to form a mask: • Compute t = ω α ) ; • For each received response 88: o Compute t' = gen1 sig1 * h challenge ; o Compute * gen2 sig1 * γ sig2 challenge = H'(h, ω, γ, gen1, gen2, t, t') challenge ; and o Verify comb .

[0047] If all verifications are successful, the Lagrange interpolation of all received responses 88 is computed h using the identifiers of the participants as listed in the ordered list of participants and the values provided in the participants’ answers ρ .

[0048] Next, the information requester 15 computes m || ρ = PRG(comb) xor e, and verifies α = XOF(m || Figures 4A-4C ).

[0049] If this last check is successful, the information requester 15 has successfully recovered the original information / message m . As mentioned above, mThe symmetric cipher key can or can not be itself a symmetric cipher key, since the use of a symmetric cipher in the encryption phase is optional. In embodiments where a symmetric cipher is used, the information requestor 15 will use the mask to reveal the symmetric cipher key used in the encryption phase and will use that symmetric cipher key to decrypt the desired information, thus completing the decryption phase. In embodiments where a symmetric cipher is not used, m The symmetric cipher key can or can not be itself a symmetric cipher key, since the use of a symmetric cipher in the encryption phase is optional. In embodiments where a symmetric cipher is used, the information requestor 15 will use the mask to reveal the symmetric cipher key used in the encryption phase and will use that symmetric cipher key to decrypt the desired information, thus completing the decryption phase. In embodiments where a symmetric cipher is not used,

[0050] Further Considerations Direct manipulation of large amounts of data is often inconvenient. To speed up computation and limit the amount of storage space required, it is recommended to first encrypt the large information / message using a cryptographically secure symmetric encryption scheme such as AES m and then use the present scheme to encrypt only the symmetric encryption key itself, not the entire data (including the information / message and / or encryption key).

[0051] Reference Figure 4A is shown is a flowchart of a threshold symmetric encryption method, including a setup phase 300 Figure 4B , an encryption phase 330 Figure 4C , and a decryption phase 350 Figure 4A . The phases 300, 330, 350 can be executed in order as part of the encryption method. Note that the setup phase 300 Figure 4B must be completed only once, and based on the same setup phase 300, the encryption phase 330 Figure 4C and the decryption phase 350 Figure 4A can be completed multiple times.

[0052] Reference Figure 1 is shown is a flowchart of the setup phase 300 of a threshold symmetric encryption method. The setup phase 300 can be executed by the system 100 shown in Figure 4B .

[0053] At 302, a setup request is initiated from an end user device. The setup request can be sent directly to each participant device, or via a communication facilitation subsystem. Preferably, the communication facilitation subsystem is a web portal, but it can be a different communication facilitation subsystem, such as a dedicated server.

[0054] At 304, setup information for each participant device, as specified in the setup request, is sent to each participant device. Typically, the setup information specifies the encryption requestor, the decryption requestor, and details of the number and identity of the participant devices.

[0055] At 306, each participant device validates the setup information and generates its own white list for encryption and decryption. According to some embodiments, each participant device validates the setup information locally. According to other embodiments, the setup information can be validated in a distributed manner across more than one participant device.

[0056] At 308, each participant device creates a partial secret and a partial secret share according to Shamir's secret sharing scheme.

[0057] At 310, each participant device shares its partial secret share with each other participant device over an end-to-end secure channel.

[0058] At 312, each participant device adds its received partial secret shares to obtain its secret share. The secret share is stored in a cryptographic storage device.

[0059] At 314, each participant device computes a secret share commitment and publishes it to a public storage device. Typically, the commitment will be used later for encryption and / or decryption.

[0060] At 316, the participant devices collect the published commitments from the public storage device for use in authenticating future encryption and decryption operations.

[0061] At 318, preferably, the data generated during the setup phase is validated by a single test encryption (i.e., a test run of the generated data including participant device identifications, white lists, secret shares, commitments, etc.) to ensure that no malicious activity occurred during the setup phase. According to some embodiments, this step 318 can be omitted.

[0062] Reference is made to Figure 2 shown is a flow diagram of an encryption phase 330 of the threshold symmetric encryption method. The encryption phase 330 can be performed by the system 110 shown in Figure 4C

[0063] At 332, the information holder device initiates an encryption request including an identifier of the information holder device and a commitment. The encryption request can be sent directly to each participant device, or preferably, via a communication facilitation subsystem (e.g., a web portal or a dedicated server).

[0064] At 334, the identifier and commitment of the information holder device are passed to the participant devices.

[0065] At 336, each participant device validates that the identifier of the information holder device is listed on the white list for the encryption request.

[0066] ​At 338, each participant device computes the evaluation and the evidence to send to the information holder device over an end-to-end secure channel.

[0067] At 340, the information holder device verifies the evaluation and the evidence received from each participant device using the secret share commitment stored in the public storage device.

[0068] At 342, the information holder device combines the evidence and the evaluation received from each participant device to form a mask.

[0069] At 344, the information holder device encrypts the information using the mask.

[0070] Reference is made to Figure 3 Shown therein is a flow diagram of a decryption phase 350 of the threshold symmetric encryption method. The encryption phase 350 can be performed by the system 120 shown in Figure 5

[0071] At 352, the information request device sends a decryption request including its identifier and an indication of the information to be retrieved from the public storage device. The decryption request can be sent directly to each participant device, or preferably through a communication facilitating subsystem (e.g., a web portal or a dedicated server).

[0072] At 354, the identifier and the commitment of the information holder device are retrieved from the public storage device together with the encrypted information. This retrieval can be performed directly by the information request device, or by the communication facilitating subsystem.

[0073] At 356, the identifier and the commitment of the information request device are sent to the participant devices, directly or via the communication facilitating subsystem, together with the identifier of the information holding device.

[0074] At 358, each participant device verifies that the identifier of the information request device is whitelisted for decryption requests, and that the identifier of the information holding device is whitelisted for encryption requests. According to some embodiments, each participant device verifies locally that the information holding device and the information request device are whitelisted for encryption and decryption, respectively. According to other embodiments, the verification can be performed in a distributed manner across more than one device.

[0075] At 360, each participant device sends to the information request device, over an end-to-end secure channel, a verification including a second evaluation and a second evidence.

[0076] At 362, the information request device verifies the second hash, the second evaluation and the second evidence received from each participant device using the secret share commitment stored in the public storage device.

[0077] ​At point 364, the second assessment and second evidence received from each participant's device are combined to generate a mask.

[0078] At position 366, the information request device uses a mask to decrypt the encrypted information / message.

[0079] Example Setup phase ( Figure 6 ), encryption stage ( Figure 7 ) and decryption phase ( Figures 5-7 )of Figure 6 The exemplary implementations shown are provided as possible embodiments of the invention. All examples relate to a system with four participants / devices / systems: end user 202, service provider 204, system provider 206, and backup 208.

[0080] End user 202, service provider 204, system provider 206, and backup 208 can be a server computer, desktop computer, laptop computer, tablet computer, PDA, smartphone, or other computing device. One or more of devices 202, 204, 206, and 208 can be virtual devices / machines. Devices 202, 204, 206, and 208 can include a connection to a network, such as a wired or wireless connection to the Internet. In some cases, the network can include other types of computer or telecommunications networks.

[0081] Devices 202, 204, 206, and 208 may include one or more of the following: memory, auxiliary storage device, processor(s), input device, display device, and output device. The memory may include random access memory (RAM) or a similar type of memory. Furthermore, the memory may store one or more applications for execution by the processor. Applications, computer-readable instructions, or programs may be stored in the memory or auxiliary storage device, or may be received from the Internet or other networks.

[0082] An application may correspond to a software module including computer-executable instructions to perform processing for the functions described below. Auxiliary storage devices may include hard disk drives, floppy disk drives, CD drives, DVD drives, Blu-ray drives, or other types of non-volatile data storage devices. A processor may execute applications, computer-readable instructions, or programs.

[0083] The devices 202, 204, 206, 208 can include input devices for entering information into the devices 202, 204, 206, 208. For example, the input devices can be a keyboard, a keypad, a cursor control device, a touch screen, a camera, or a microphone. The devices 202, 204, 206, 208 can include display devices for presenting visual information. For example, the display devices can be a computer monitor, a flat-panel display, a projector, or a display panel.

[0084] Although the devices 202, 204, 206, 208 are described with various components, one skilled in the art will appreciate that the devices 202, 204, 206, 208 can contain fewer, additional, or different components in some cases. In addition, although aspects of the implementations of the devices 202, 204, 206, 208 can be described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on or read from other types of computer program product or computer-readable medium, such as secondary storage devices, including hard disks, floppy disks, CD-ROMs, or DVD s; carrier waves from the Internet or other propria ty networks; or other forms of RAM or ROM. The computer-readable medium can include instructions for controlling the devices 202, 204, 206, 208 and / or the processors to perform a particular method.

[0085] Each device 202, 204, 206, 208 can be associated with a user / company account. Any suitable mechanism for associating a device with an account is expressly contemplated, including by using the password storage devices 203, 205, 207, 209 as described below.

[0086] In the description of the subsequent example implementations, the devices / participants 202, 204, 206, 208 are described as performing certain actions. It will be appreciated that any one or more of these devices can perform the actions automatically or in response to an interaction by a user of the device. That is, a user of the devices 202, 204, 206, 208 can manipulate one or more input devices (e.g., a touch screen, a mouse, or a button) to cause the device to perform the described actions. In many cases, this aspect can not be described below, but it should be understood.

[0087] Each participant 202, 204, 206, 208 is associated with a password storage device, such as a portable password module 203 (e.g., Multi-Pass™, Yubikey™, etc.) or a hardware security module 205, 207, 209. The password storage devices 203, 205, 207, 209 can only be accessed by the participant 202, 204, 206, 208 to which they are linked.

[0088] The communication facilitating subsystem (communication system) 212, created in collaboration between the various service providers and system providers 206, is used to connect the participants 202, 204, 206, 208 when they are online. The communication system 212 is preferably a web portal, but can also be a different communication facilitating subsystem, such as a dedicated server. Using the communication system 212, the end user 202 can request encryption of various documents that have been created in conjunction with the service providers. According to other embodiments, the participants 202, 204, 206, 208 can communicate directly without the mediation of the communication system 212.

[0089] It is assumed that the service providers 204, the system providers 206 and the backup provider 208 are always online, and that the end user 202 is only online when it initiates an operation. The cloud-based public storage 214 (e.g. AWS®) is always online.

[0090] Reference is made to gen1 an individual who wishes to protect a digital copy of a notarized house purchase agreement, and a company specialized in digital security, which is able and willing to provide data protection using the above invention. The individual, the notary and the company are the end user 202, the service provider 204 and the system provider 206, respectively. An independent entity, referred to as the backup 208, is also provided as a participant, which is managed by the system provider 206 independently of its core system. The end user 202, the service provider 204, the system provider 206 and the backup 208 form a set of four participants.

[0091] The end user 202, acting as the initiator, creates a request 220 through the communication system 212. The request 220 includes the total number of participants n=4 and the required number of participants involved in the encryption or decryption operation k=3 In this example, the list of entities allowed to make an encryption request will contain only the end user 202; the list of entities allowed to make a decryption request will contain the end user 202, the service provider 204 and the system provider 206. Note that in this example, the list of allowed entities contains only entities that are also participants. In other embodiments of the invention, this is not necessarily the case.

[0092] The communication system 212 generates information 222 based on the request 220. The information 222 includes a cyclic group defined by the following values, for example a set of points on the elliptic curve secp256k1: • the prime number p = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f defining the field; • the curve equation is y 2 = x3 + 7; • the base point G = (0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798, 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8); • the order q of the group = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141; and • the cofactor h of the group = 1.

[0093] The first generator gen2 is set to the base point G. The second generator init can be computed as follows: • generate 32 random bytes, called init rand ; • hash gen2 rand to the above curve using an elliptic hash method, for example as described by Faz-Hernandez et al., using the domain separation tag ‘PEDERSEN_SECP256K1_COMMIT_PRNG-v1.13.0-hash_to_curve’ and SHA256 as the hash algorithm (“Hashing to Elliptical Curves,” Internet Engineering Task Force: Crypto Forum Research Group accessible at <https: / / www.ietf.org / archive / id / draft-irtf-cfrg-hash-to-curve-10.html>); and • if the result gen1 is the same as init with very low probability, try again with new randomness.

[0094] gen2 rand and gen2 will be published, so that each participant can verify that init was generated from Figure 5 rand , which constitutes satisfactory evidence that the relationship between the two generators is unknown.

[0095] In this example, the following values are set: • Seed: 0xe5699fe804e189bc320b93ababcab2d39175d9f688ca53b66c9d07bfa32a772d; and • Generator: (0x262ee3413bbb3beb89139998678f5d22e571e1548b4c445b313cd870987f3f83, 0x39bae3a78b57176e15d244f77144cbfda8e047f2bad04bf3b0ec6f162b081f70).

[0096] In this example, the ordering of the participants is set as follows: • 1. End user 202; • 2. Service provider 204; • 3. System provider 206; and • 4. Backup 208.

[0097] The identifier of each participant is a random universally unique identifier, as follows: • End user 202: e44838bd-a5c1-4f1a-8746-1c9e87b504c4; • Service provider 204: 106d8052-e68b-4763-b4fc-f233d224cedc; • System provider 206: c538806e-4073-4b12-bc4a-bde52adb6c40; and • Backup 208: 3ffca6d1-8a14-4b6a-a723-47e76fa07fd9.

[0098] The communication system 212 creates the information 222 detailed above, and passes them to all the participants 204, 206, 208 involved. The communication system 212 also provides the participants with the means to communicate with each other and with the public storage 214, which can be done through intermediation by the communication system 212 itself.

[0099] Locally, each participant 204, 206, 208 verifies the information 222 and creates a copy of the received white list.

[0100] Participants 204, 206, 208 then use Shamir's secret sharing scheme to create a partial secret, and split the partial secret share 224 among them as follows: End user 202: • Quadratic polynomial: 0x17b2f0c7fdd1bf1f77a7f2a3af1b4ac55a73eb436a82350a0f114e73c3239954 + 0x9ad8dc4fbff7873500a6c477ce0dc749620dee3cda5d6b257d6091c0dec7b2a3 * x + 0x45883af57eabdbcdd4c4c3b3f9f02d881ba7b258885fffe490fa07d1f9cb7d06 * x^ 2 ; • Partial secret: 0x17b2f0c7fdd1bf1f77a7f2a3af1b4ac55a73eb436a82350a0f114e73c3239954; • Partial secret share 224: o For self (end user 202): (1, 0xf814080d3c7522224d137acf77193f96d8298bd8cd3fa0141d6be8069bb6c8fd); o For service provider 204: (2, 0x6385953d78703cc0cc088a6332f78f7b17d0d751e22bca6fce15d423c7747030); o For system provider 206: (3, 0x5a079858b1c30efaf487215ee2b63a6f8ec7877c07d7f494a0b3cfe4e6c9116f); and o For backup 208: (4, 0xdb9a115ee86d98d0c68f3fc2865540743d0d9c573e441e829545db49f9b4acba).

[0101] Service provider 204: • Quadratic polynomial: 0xfd4b14b951844a6062e8e04b8be59bab669f4a20a0f7830e89cdb66cff9850a7 + 0x6382f59a1bb82d40ae8cd8f4ab973b1d854ce27828ee7f50b45bae69ef66eee2 * x + 0xf082184567d7d88c015fc3ab73f5467945a863b8039a7e072d9c17ce2e07482c * x 2 ; • Partial secret: 0xfd4b14b951844a6062e8e04b8be59bab669f4a20a0f7830e89cdb66cff9850a7; • Partial secret share224: o For end user 202: (1, 0x51502298d514502d12d57cebab721d44bc36d6836eef3feeec20bf8b7c9a0533); o For self (service provider 204): (2, 0x8659610328540711c581a0e2b2e92bd1e2704d6f94d358a1e9d999b9857408d6); o For system provider 206: (3, 0x9c66cff84b436f0e7aed4c30a24ac7541e9cd1fe635b2cebc325e66a49f01a4f); and o For backup 208: (4, 0x93786f783de2882333187ed57996efcb70bc642fda86bccc7805a59dca0e399e).

[0102] System provider 206: • Quadratic polynomial: 0x9fb7db5b29b356970eb4059fd9f36a4aaacb30b16585a22d0d1ccf5feb67c748 + 0xab146c8adadaeb0f4165b9a72a204a6b278d320f932a80b2d0a49173b07e23e9 * x + 0x6e43678cc44b4555bd7ad9d97511d6e33e9825ce136645f013b1eb8238864de5 * x 2 ; • Partial secret: 0x9fb7db5b29b356970eb4059fd9f36a4aaacb30b16585a22d0d1ccf5feb67c748; • Partial secret share224: o For end user 202: (1, 0x9fb7db5b29b356970eb4059fd9f36a4aaacb30b16585a22d0d1ccf5feb67c748); o For service provider 204: (2, 0xaeee52a3f096420c876ae054027b5ab1c4399554cb99da9fbdb684a9bdda82eb); o For self (system provider 206): (3, 0x8153c4eea0e987c87c36db3a75f4d790f4b2edb6b1e9d84fb15d94021855688a); and o For backup 208: (4, 0x30400652d9d3582febf889d3d3920237e7adb4ce0fbdc1a40c961bd213a6a8b2).

[0103] Backup 208: • Quadratic polynomial: 0xd51c9fffba7c8089f574934d3302b786ce9edc3f27e91d3d614efc78ef0902ba + 0xf7f205b0455e23601ae73a4b1cf469065f262b957be07cb40d207375f3e6b820 * x + 0x911ce83fe862ecb5b222c40a484e5fccb52e8f687684aa832418d1c780044287 * x 2 ; • Partial secret: 0xd51c9fffba7c8089f574934d3302b786ce9edc3f27e91d3d614efc78ef0902ba; • Partial secret share 224: o For end user 202: (1, 0xd51c9fffba7c8089f574934d3302b786ce9edc3f27e91d3d614efc78ef0902ba); o For service provider 204: (2, 0x9744c5fe6c47a20f3ce180c8e2508ccbc3b208a8d519f874cd751c2c5d836d1); o For system provider 206: (3, 0xd6f6db4fb6113d0d8963268b14a150d6753d82764bef9017cefcc277c93177d1); and o For self (backup 208): (4, 0xc6b33abf5623d965833dbd1e2bba587c233f49659905953719af19a22c26bb5d).

[0104] It should be noted that the partial secret shares 224 listed above are not points on an elliptic curve, but rather points in two-dimensional Cartesian space. All participants 202, 204, 206, 208 will discard the quadratic polynomial and the partial secret, and distribute the partial secret shares 224 to each other. Note that while γ = gen1*s + gen2*rDirect communication between the participants 204, 206, 208 is shown, but this can be done mediated through the communication system 212 (as is done between the end user 202 and the other participants 204, 206, 208). It should also be noted that the communication between the participants 204, 206, 208 is end-to-end protected, such that the communication system 212 can direct traffic, but cannot see the content of the communication.

[0105] The participants 202, 204, 206, 208 add their partial secret shares 224 (specifically, their shared y-coordinates, which are the second values of the pairs listed below) to obtain a secret share 226 using modulo addition: • The end user 202 secret share: (1, 0xbe38a600f5b94970641190a82f817eaf986cb57f6b0c5ef5f853b651525515b0); • The service provider 204 secret share: (2, 0xa2419544781f00000cc323a676811eccc006fdba20a1fcfd02aae5bd0064f181); • The system provider 206 secret share: (3, 0x4eb9088f540142df750e6f550f972a2da1f70fda0a7b4970648f4faf71d38997); • The backup 208 secret share: (4, 0x6605c1e95647528968de0589ff388af6435944ed62fcf1b2b3ebf9426323c7e5); and • The shared secret that remains unknown to all participants is: (0, 0x89d280dc3385e0a0deb96bdc47f70844c51f88873a57370b87a6139ffcc0317b).

[0106] From the two generators provided by the communication system 212, the participants 202, 204, 206, 208 can compute the following commitments 228 (using new randomness r and the equation 0x79f407f06c570b29005aff824d46b5a39bfe8220aa90be4466ddbb159c8705c0 ): • The end user 202: ○r： o γ: (0x57f34d6d89556b51c797b6af94b1d5795e708742d73e63c4cde0429a06f3546c, 0x530b772755bcee3583c01bf82cb3674af0d1f5a2e303687cbb375df77f5c9f6e) • Service provider 204: 0xd619de2b4bb87cc36ae36153863a21d5c46890b1e45691e5de974476f114e279 ○r： o γ: (0xcb9f96da6e04c629d1a951815bfd43631c6ce97e77473b4da7aa0b63521cbb0d, 0xe03c738ad0c609f1eb96eebdea24db93c844e1cc23fc0d648f5d7737ae58261d) • System provider 206: ​ ○r： 0xa437ae2c673f24ac7d3d9459acafa6290a5892c031730651ddc9ea17197b4453 o gamma: (0x868edba0cc40b1e5e1d583dc81cb6f61ac5535436d7b464b708877191e1fbc3a, 0xebac13434a2d5c110d56d0f652dcaed5c15005f3113bd8c6321104d3acac2d9c) • backup 208: ○r： 0x87c745559349f1c301295412fce8742fda9d62debee347890f8fca06fe025637 o gamma: (0xe3920fda26117206c98e20b5f09fd4c7ad1ebe662e41229eb931011d11e32935, 0xcda4530999a3cc1bc8ea36a0627bcab82100070d9deee96f93dbfedb61131a4f) 。

[0107] The secret shares 226 are stored in the respective cryptographic stores 203, 205, 207, 209.

[0108] The participants 202, 204, 206, 208 compute, and then publish their commitments 228. Each participant 202, 204, 206, 208 then computes a random number r and secret share s the secret share 226, and publishes γ. Note that while the figure shows direct communication with the public store 214, this can be done through intermediation of the communication system 212.

[0109] The participants 202, 204, 206, 208 collect the commitments 230 that will be used to verify future encryption and decryption operations.

[0110] Participants 202, 204, 206, 208 also undergo a single encryption phase (not shown) that uses a random value to certify the data generated during the setup phase. After having obtained the encrypted responses of the other participants to the random value, each participant will certify that: • the value obtained by combining the responses of any 3 participants (possibly including itself) is the same as the value obtained by combining the responses of all 4 participants; • the value obtained by combining the responses of any 2 participants (possibly including itself) is different from the value obtained by combining the responses of any 3 participants; and • the value obtained by combining the responses of any 3 participants (possibly including itself) is not at infinity.

[0111] If any of the certifications fail, the participant will claim that the setup phase failed, and it will be necessary to start over with new values. Otherwise, the setup phase ends successfully, and any number of encryption and decryption phase .

[0112] Reference figure 6 is shown is an exemplary implementation of the encryption phase. Here, end user 202 is the information holder. End user 202 connects to communication system 212 to provide an encryption request 240 that includes their own identifier. Encryption request 240 can be linked with the identifier of end user's portable cryptographic device 203, or can be linked with an identifier assigned to end user 202 by communication system 212, but in either case, matches an identifier listed in the whitelist created during the setup phase.

[0113] To reduce computation time and storage space, the information to be encrypted by the user will first be locally encrypted using AES-256. The resulting ciphertext will be uploaded to a designated public storage 214, and the encryption phase will use only a 32-byte AES key as the message m . For example, the AES key is as follows: 0xece39589748cb37d62c68fe58ed5e39e8c5cca51093729adbff138804351c298.

[0114] End user will then compute the commitment a to the message m , as follows: • new randomness p = 0x6cf931d678a0c886462b288814e36099ccdb5ca5681704a821f9da150719e664 • a = 0x6cf931d678a0c886462b288814e36099ccdb5ca5681704a821f9da150719e664 • a = 0x6cf931d678a0c886462b288814e36099ccdb5ca5681704a821f9da150719e664 SHAKE256(0xece39589748cb37d62c68fe58ed5e39e8c5cca51093729adbff138804351c2986cf931d678a0c886462b288814e36099ccdb5ca5681704a821f9da150719e664) = 0x53058f73c1d4607c5c53064f1e7bc5c88fff1c62e0fa462aed86f0fa3470a6cabdc5bb7a1efef5989164d242cf6004c60d70d30235a8f2d51a93a0ab5449cf795b16364b3ec9cd9ba2a20a38bee2760550a8c76b228e64076772413c96a23d6e.

[0115] Note that a is three times the length of the message, taking into account the security parameters.

[0116] In this example, the communication system 212 then sends this information 242 along with its identifier to three of the four participants: the service provider 204, the system provider 206 and the end user 202 (the backup 208 is not involved here). Note that the end user 202, although the initiator of the encryption request 240, is treated like any other participant.

[0117] The participants 202, 204, 206 verify that the identifier is on the whitelist, and then compute the evaluation h and the proof 244: The service provider 204: • hashes the concatenation of id and a (bottom right) to the above curve using the method described by Faz-Hernandez et al. using the domain separation tag 'DISE_SECP256K1_DST-v1-hash_to_curve' and SHA256 as the hash algorithm; • omega H (0xe44838bda5c14f1a87461c9e87b504c453058f73c1d4607c5c53064f1e7bc5c88fff1c62e0fa462aed86f0fa3470a6cabdc5bb7a1efef5989164d242cf6004c60d70d30235a8f2d51a93a0ab5449cf795b16364b3ec9cd9ba2a20a38bee2760550a8c76b228e64076772413c96a23d6e) = (0xbe6da964023e176f14730782e86a45bc1236fc28a440ef6fdfbbe919bc2398e8,0x981713afc6894875a136f844b372e357b34fd1cf1394d30b0861b7645bd81d6a) ; • Compute h = omega * s = (0xed4f1ae19e7d0791ed78dd2b8721aab379509bc1e2ef7533939507d0740f2eb6,0x51f2454480894506e1d3bdf349cdc78aa3a7522e6b4deb8acf0498c75d7c0b53) ; • Randomly sample in the range (1, q-1) mask1 , mask2 : o mask 1 = 0xf06ac15c2438270044c0d920ca4838b12abb9b80b7a18d15ffdd6efae80b861b ； o mask 2 = 0xf82106d5fb3c801a2ac3c64864dd7e9ac27b6bcc16edb18725b6d8b754d6fa47 ； • Set t = omega * mask 1 = (0xf7a44bebefc5e4e203d965ae66dc735202552a09e48d19259419ad3a005d7a73, 0x61d317c4b48015f85786441c192ad32b80dbd510d1d2337236201c61a77b808); • Set t' = gen1 * mask1 + gen2 * mask2 = (0x8e69f5ed58273f82ad7ee38df698d46b9e1b5c0b3b4b178875aacb609b3b7580, 0xe25e7eaf2adfd6b249942d519e10ef60399bf5fcfd9e3efdb8cbe4d9d5e2fc82); • Use the method described by Faz-Hernandez et al. using the domain separation tag 'PUBLICLY_VERIFIABLE_NIZK-v2-hash_to_field' and SHA256 as the hash algorithm to challenge = H'(challenge, sig1, sig2) h, omega, gamma, gen1, gen2, t, t' Set to the above curve; o challenge = 0xba66345e352db119f7734ec4eb8811760d6b10133dd85fbd0912c908df385c81 ； • Set sig1 = ( mask1 - challenge * s) % q = 0xb9a327f10eecbb4e0c531cc8f30d478c70e26d94b6a9a532af3c5b0d7263f2f5; • Set sig2 = (mask2 - challenge * r) % q 0x3293241eb1bebbf3339520024eb17b270ddd5b0377b547f4cb96d306aa7db60b; and • Call (challenge, sig1, sig2) the proof.

[0118] System provider 206: • Hash the concatenation of id and a (bottom right) to the above curve using the method described by Faz-Hernandez, A. et al. using the domain separation tag 'DISE SECP256K1_DST-vl-hash_to_curve' and SHA256 as the hash algorithm; · omega H(0xe44838bda5c14f1a87461c9e87b504c453058f73c1d4607c5c53064f1e7bc5c88fff1c62e0fa462aed86f0fa3470a6cabdc5bb7a1efef5989164d242cf6004c60d70d30235a8f2d51a93a0ab5449cf795b16364b3ec9cd9ba2a20a38bee2760550a8c76b228e64076772413c96a23d6e) = (0xbe6da964023e176f14730782e86a45bc1236fc28a440ef6fdfbbe919bc2398e8,0x981713afc6894875a136f844b372e357b34fd1cf1394d30b0861b7645bd81d6a) ; • Compute h = omega * s = (0xffab47e3a59f3d83e0071e43faa97b70ffe12ef2152208f3bb533b0a5cfc49fc,0x2d74d2848f0698cf629f95921586596825d1c3f853c6411d77a2052eb527b215) ; • Randomly sample mask1 , mask2 : o mask 1 = 0xbbb716500b726b84e00cc624cfad876628754b6f931dd3e0278333e0defc4d0f ； o mask 2 = 0x5275e357521b4587b1a102e9563bd398f4027663f34a781d75bfc6dff0dd2bf8 ； • Set t = omega * mask 1 = (0xbb3ee393435b695b314fd8adc2fc0b27d744622149cfa9e1763c9cf5c49d2f81, 0x722c6f46ee563e6b7126a6ea4346d1d4e88be6b63c74f108a860daaf1f723b25); • Set t' = gen1 * mask1 + gen2 * mask2 = (0xa65cea98a731ae016227388b747cc97dde95c7f1644cdf3790edf6aae02b3f51, 0x40b3f9ad7b1292148e60552ab6dbe0aab5d19dc9448417386a967d07df73999d); • Use the method described by Faz-Hernandez et al. using the domain separation tag 'PUBLICLY_VERIFIABLE_NIZK-v2-hash_to_field' and SHA256 as the hash algorithm to compute challenge = H'(challenge, sig1, sig2) h, omega, gamma, gen1, gen2, t, t' Set to the above curve; o challenge = 0xa5b0e8448b0488b6fab6512ec098fc9dc8814cdeb94402d22e758e5051127463 ； • Set sig1 = (sig1, sig2) mask1 - challenge * s) % q = (sig1, sig2) 0xe852faac7504992e83aade90c2a306d8d5c815f6f628df778462ca257734343a; • Set sig2 = (mask2 - challenge * r) % q 0xc20e6ced665013d09c99a6003c327b454047ac49b5d518fc10cd5a37da9510e6; and • Call (challenge, sig1, sig2) a proof.

[0119] Because end user 202 needs its own share as well, it verifies that it is listed in the white list and locally does the following: • Hashes the concatenation of id and a (bottom right) to the above curve using the method described by Faz-Hernandez et al. using the domain separation tag 'DISE_SECP256K1_DST-vl-hash_to_curve' and SHA256 as the hash algorithm; • omega H(0xe44838bda5c14f1a87461c9e87b504c453058f73c1d4607c5c53064f1e7bc5c88fff1c62e0fa462aed86f0fa3470a6cabdc5bb7a1efef5989164d242cf6004c60d70d30235a8f2d51a93a0ab5449cf795b16364b3ec9cd9ba2a20a38bee2760550a8c76b228e64076772413c96a23d6e)= (0xbe6da964023e176f14730782e86a45bc1236fc28a440ef6fdfbbe919bc2398e8,0x981713afc6894875a136f844b372e357b34fd1cf1394d30b0861b7645bd81d6a) ; • Compute h = omega * s = (0xac992d539e7c8708b4503a44f56a4f51e6bff0734f2261513c1cc64eab96f818,0xf419b3412f799ff5e03c098492248777edffe0b3ab62539605a0b98774297e02) ; • Randomly sample mask1 , mask2 : o mask 1 = 0xc5ae57854208a16e69628496da1dc5d53cdc1a64509f3d73bfce1655eeb1ca0d ； o mask 2 = 0xbc7f7590ee430cb0cc578321817609cdb649d4ff3beb7f612f7574c127a5838c ； • Set t = omega * mask 1 = (0xa3ff332261d0bb5540c0b7d5020fb8570dfbe82d9e285fe312c5541aca3cf700, 0x851bd9c57639631637781b44c10b4300f14b83403bb2b7675b20b183719358fd); • Set t' = gen1 * mask1 + gen2 * mask2 = (0xa09f62292090b490f2796ea5739203541991334f012cf67d2fa783c12d43be71, 0x9e6c855ff4fe0ac7b205ee4d7a600e3a2a907e6d4394b37004885c9c9a804c83); • Use the method described by Faz-Hernandez et al. using the domain separation tag 'PUBLICLY_VERIFIABLE_NIZK-v2-hash_to_field' and SHA256 as the hash algorithm to challenge = H'(x, y, z) = H'(x, y, z, 0); h, omega, gamma, gen1, gen2, t, t' Set to the above curve; o challenge = 0xe1d9edcd245147a39aefefaec987fa59d1a8c90e7580fde934573bdff7cefc72 ； • Set sig1 = ( mask1 - challenge * s) % q = 0x73adc9e688291c744a47145600ee2676c8affedbc3d4dde279f7fa5d02fe14a8; • Set sig2 = (mask2 - challenge * r) % q 0x81c3428e7dd79a216ff1062bba4431efd5b96ca9587f20ad1b826a7890a5ea9; and • call (challenge, sig1, sig2) as evidence.

[0120] Participants 202, 204, 206 send their respective h and proof resulting data 246 to the information holder / end user 202 over an end-to-end secure channel. Note that while figure 6 direct communication is shown, this can be done through intermediation by the communication system 212.

[0121] Once the end user 202 has all three shares (including its own), it does the following for each response: • locally compute omega (as a base); • compute t = h * challenge * sig1 + gen1 * sig2 omega * sig1 + h * challenge; • compute t' = gen1 * sig1 + gen2 * sig2 + h * challenge gamma * challenge; and • verify challenge = H'(h, omega , gamma , gen1, gen2, t, t').

[0122] If all verifications are successful, the end user will use Lagrange interpolation on the following values obtained by taking the order of the participants and the values they provided: h End user 202: • (1, (0xac992d539e7c8708b4503a44f56a4f51e6bff0734f2261513c1cc64eab96f818,0xf419b3412f799ff5e03c098492248777edffe0b3ab62539605a0b98774297e02)) Service provider 204: • (2, (0xed4f1ae19e7d0791ed78dd2b8721aab379509bc1e2ef7533939507d0740f2eb6,0x51f2454480894506e1d3bdf349cdc78aa3a7522e6b4deb8acf0498c75d7c0b53)) System provider 206: ​• (3, (0xffab47e3a59f3d83e0071e43faa97b70ffe12ef2152208f3bb533b0a5cfc49fc, 0x2d74d2848f0698cf629f95921586596825d1c3f853c6411d77a2052eb527b215))).

[0123] The Lagrange interpolation of those values gives the value comb = (0xe4c8737c190f22b5a5a4771ee486bb4676146aa6f65f19f516311d9c6f7d8caa, 0x872a5bbddf2420e8d1badc9f056ebf1ad8bc8d726490ae5aaebcd7c80ef3b79e). The end user 202 then uses comb as a seed for the pseudo-random number generator: • serialized comb = comb.x || comb.y = 0x04e4c8737c190f22b5a5a4771ee486bb4676146aa6f65f19f516311d9c6f7d8caa872a5bbddf2420e8d1badc9f056ebf1ad8bc8d726490ae5aaebcd7c80ef3b79e ； • Compute csprng seed = SHA256(serialized comb ) 0x886041f507cd49e99429c7d888ed2ac1d0983abeebcf2bff012fd1eaca60c906; and • Return AES(0x00 * 64) using CTR mode and a random nonce, where csprng seed as a key: o one-time random number 0xc22912f781a7b1d1 o = PRG(comb) =0x421a6408e86f9418d0faaa668a11a8e64e0ec27dd6ad75cb9df7a552800528d43e85e2ac5369bf155357f310396850a5cce84c1ac13f0e8c371e2f135bdbb202.

[0124] Finally, the end user 200 computes e = PRG(comb) xor (m || p) = 0xaef9f1819ce32765b23c258304c44b78c252082cdf9a5c6622069dd2c354ea4c527cd37a2bc97793157cdb982d8b303c003310bfa9280a2416e7f5065cc25466.

[0125] the end user's ID, a, e , the nonce and the original ciphertext 248 will be published in the designated public storage 214.

[0126] Referring to figure 7 shown is an exemplary implementation of the decryption phase. Here, the end user 202 is the information requester. The end user 202 connects to the communication system 212 to send a decryption request 260 that includes their own identifier and indicates the information they wish to retrieve.

[0127] The communication system 212 retrieves the relevant information, i.e., the end user's ID, a, e , the nonce and the original ciphertext 262 from the public storage 214. Here, it might seem redundant for the end user 202 to retrieve its own ID, but in other examples, the ID is not necessarily readily available.

[0128] The communication system 212 passes this information 264 to three of the four participants: the service provider 204, the system provider 206 and the end user 202 (the backup 208 is not involved here). Note that the end user 202, although the initiator of the decryption request 260, is treated like any other participant.

[0129] The following information 264 is sent to the other participants involved in the decryption: • id'= e44838bd-a5c1-4f1a-8746-1c9e87b504c4, the identifier of the entity requesting decryption; • id = e44838bd-a5c1-4f1a-8746-1c9e87b504c4, the identifier of the entity completing encryption; and • a = 0x53058f73c1d4607c5c53064f1e7bc5c88fff1c62e0fa462aed86f0fa3470a6cabdc5bb7a1efef5989164d242cf6004c60d70d30235a8f2d51a93a0ab5449cf795b16364b3ec9cd9ba2a20a38bee2760550a8c76b228e64076772413c96a23d6e, retrieved from public storage.

[0130] As in the encryption phase ( figure 6 ), the end user 202 will select itself as the third party involved in the decryption and will therefore perform some computations locally.

[0131] The participants 202, 204, 206 verify that the identifier of the information requester ( id' ) is whitelisted for decryption and that the identifier of the information holder ( id ) is whitelisted for encryption; then, using the newly generated random values for mask1 , mask2 , the hash and the witness 266 are computed as described above for encryption phase .

[0132] The participants 202, 204, 206 send the resulting data including omega , h and proof 268 to the information requester / end user 202 over an end-to-end secure channel. Note that while figure 7 shows direct communication, this can be done through intermediation by the communication system 212.

[0133] The end user 202 verifies the data it receives using the commitments stored in the public storage during the setup phase and then uses the received data to recover the initial information. The end user 202 performs the same verifications as it did during the encryption phase, i.e. by computing t , t’ and verifying that challenge matches the hash of h , omega , gamma , gen1 , gen2 , t and t’ .

[0134] If all verifications are successful, the end user 202 will compute the Lagrange interpolation of all received responses as it did in the encryption phase to obtain comb . The end user 202 will then compute m || p = PRG(comb) xor e , using the same XOF as in the encryption phase to verify a = XOF(m || p) , and if this last verification is successful, the end user 202 can recover the message, which is the AES key needed to recover the plaintext.

Claims

1. A computer-implemented method for performing symmetric encryption without a trusted third party, the method comprising: The setup request is initiated by the end-user device; Based on the setting request, setting information is created and sent to multiple participant devices, wherein the setting information includes identifiers of the encryption requester and the decryption requester; Each participant device verifies the setup information and creates a whitelist of the identifiers of the encryption requesters and the decryption requesters; Each participant's device creates a partial secret; A portion of the secret is shared within the participant's device; Each participant device adds the partial secret share to obtain a secret share, which is then used to store the secret share in a cryptographic storage device; Each participant's device calculates a secret sharing commitment and publishes it to a public storage device; as well as Each participant's device collects the secret-sharing commitment from the public storage device to verify future encryption and decryption operations.

2. The computer-implemented method according to claim 1, further comprising: Each participant device uses the identifier from the whitelist and the secret-sharing commitment to verify the data generated in the test encryption.

3. The computer-implemented method according to claim 1, further comprising: Each participant's device divides a portion of the secret into n The parts are secretly shared, among which n It equals the total number of participants' devices.

4. The method according to claim 1, wherein, Transmitting the partial secret sharing within the participant's device includes: Each participant device retains a partial secret share and sends the partial secret share to each other participant device via an end-to-end secure channel.

5. The computer-implemented method according to claim 1, further comprising: An encrypted request, including an identifier and a commitment, is initiated by the information holder device. The identifier and the commitment shall be passed to at least a first subset of the participant devices; The identifier is verified by each participant device in the first subset to be whitelisted for encryption; Evaluations and evidence are calculated by each participant device in the first subset and transmitted to the information holder device via an end-to-end secure channel; The information holder device uses the secret sharing commitment stored in the public storage device to verify the assessment and the evidence received from each participant device in the first subset; The information holder device combines the assessment and the evidence to form a mask; The information holder device uses the mask to encrypt the information; as well as The information holder device publishes the identifier, the commitment, and the encrypted information to the public storage device.

6. The computer-implemented method according to claim 4, wherein, Encrypting the information using the mask by the information holder device includes: The information is encrypted directly using the mask.

7. The computer-implemented method according to claim 4, wherein, Encrypting the information using the mask by the information holder device includes: The information is encrypted using a symmetric cryptographic key; and The mask is used to encrypt the symmetric cryptographic key.

8. The computer-implemented method according to claim 4, further comprising: A decryption request is initiated by an information request device, the decryption request including the identifier of the information request device and an indication of the encrypted information; The information requesting device retrieves the encrypted information, the identifier, and the commitment from the information holder device from the public storage device; The information requesting device sends its identifier and commitment, as well as the identifier of the information holder device, to at least a second subset of the participant devices; Each participant device in the second subset verifies that the identifier of the information requesting device is whitelisted for decrypting the request, and the identifier of the information holder device is whitelisted for encrypting the request; The second assessment and the second evidence are calculated by each participant device in the second subset and sent to the information requesting device via an end-to-end secure channel; The information requesting device uses the secret sharing commitment stored in the public storage device to verify the second evidence and the second assessment received from each participant device in the second subset; The information request device combines the second evaluation and the second evidence to generate the mask; as well as The information request device uses the mask to decrypt the encrypted information.

9. The computer-implemented method according to claim 7, wherein, Using the mask to decrypt the encrypted information includes: The information can be decrypted directly using the mask.

10. The computer-implemented method according to claim 7, wherein, Using the mask to decrypt the encrypted information includes: Use the mask to decrypt the symmetric cryptographic key; and The encrypted information is decrypted using the symmetric cryptographic key.

11. A system for performing symmetric encryption without a trusted third party, the system comprising: Multiple participant devices, each configured as follows: Verify the settings information to create a whitelist of identifiers for encryption requesters and decryption requesters; Create a partially secret sharing device and pass it on to all other participants; The aforementioned partial secret sharing is combined to obtain a secret sharing for the participant's device; The commitment to secret sharing will be published on public storage devices; Verify that the identifier in the encryption request is whitelisted for use in the encryption request; Send assessments and evidence to the information holder's device; The identifier in the verification decryption request is whitelisted for use in the decryption request, and the information holder device is whitelisted for use in the encryption request; as well as Send verification to the information request device; The information holder device is configured to: Send the encryption request; as well as The commitment stored in the public storage device is used to verify the assessment and evidence received from each participant's device to encrypt the information; The information request device is configured to: Send the decryption request; as well as The information is decrypted using the commitment stored in the public storage device.

12. The system of claim 11, further comprising: The communication facilitation subsystem is configured as follows: The secret sharing is transmitted between the participant devices; The commitment is transmitted between the participant device, the public storage device, and the information holder device; The setting request and setting information are transmitted from the user device to the participant device; The encryption request is transmitted from the information holder device to the participant device; as well as The decryption request is transmitted from the information request device to the participant device.

13. The system according to claim 12, wherein, The communication facilitation subsystem is a web portal or a dedicated server.

14. The system of claim 11, further comprising: The user device is configured to: A setup request is initiated to send setup information for encrypting and decrypting the original message to the plurality of participant devices, the setup information including the identifiers of the encryption requester and the decryption requester.

15. The system according to claim 14, wherein, The user device is the information holder device.

16. The system according to claim 14, wherein, The user device is the information request device.

17. The system according to claim 11, wherein, The settings information includes: The total number of participants' devices, n; The required number k of participant devices used for encryption or decryption operations; A list of entities authorized to initiate encryption; and A list of entities authorized to initiate decryption.

18. The system according to claim 11, wherein, Each secret share is represented as a Cartesian coordinate.

19. The system according to claim 18, wherein, The Cartesian coordinates include: The x-coordinate is a common value corresponding to the order of a given participant's device in a cyclic group G with order q; and The y-coordinate is a portion of the secret shared by the given participant's device.

Images