DISTRIBUTED DECREASING

Description

Technical Field

[0001] This disclosure describes mechanisms for distributed decryption between two or more parties.Background

[0002] Distributed signing is a cryptographic process by which a cryptographic signature can only be applied to a document with the involvement of multiple parties. Distributed decryption is similarly a cryptographic process by which a document can only be decrypted with the involvement of multiple parties. As the reader will understand, distributed signing and decryption offer enhanced security. The secret key is shared by two or more parties, such that a single party can't sign or decrypt a document without the involvement of one or more additional parties.

[0003] In distributed signing, a document is formatted before the signing is performed. In distributed decryption, on the other hand, the formatting of the resulting plaintext is checked after the decryption has been performed. Distributed decryption may therefore have some attack scenarios that distributed signing does not have.

[0004] For satisfying stronger security requirements, such as security against chosen-ciphertext attacks (CCA), the decryption step of a distributed decryption process fails if the formatting is wrong, and the decryption can returns nothing besides a notification of failure. Where an adversary does not have a required share of the secret decryption key, it cannot distinguish between encryptions of different documents even if it has available a decryption functionality that it can apply to other ciphertexts.

[0005] Threshold Cryptosystems Secure against Chosen-Ciphertext Attacks by Pierre-Alain Fouque and David Pointcheval describes a first threshold cryptosystem secure against CCA that relies on the factorization problem and a second threshold cryptosystem secure against CCA based on the Rivest-Shamir-Adleman (RSA) model. Chosen-Ciphertext Security of Multiple Encryption by Yevgeniy Dodis and Jonathan Katz describes generic constructions of multiple-encryption schemes secure against CCA.

[0006] A problem, however, is that known distributed decryption approaches do not account for attacks arising from a parties to distributed decryption systems who are acting maliciously and in a less detectable manner. There exists a demand for a distributed decryption approach which improves security against such malicious parties to distributed decryption systems.

[0007] US2021 / 391987 A1 and WO 2022 / 069035 A1 are disclosures which belong to the prior art.Summary

[0008] The objects of the present invention are achieved by means of the appended set of claims.

[0009] The present disclosure describes methods and devices which improve security of decryption in distributed decryption systems, and in particular which provide security against malicious parties to distributed decryption systems which are undetectable by known threshold decryption security schemes. In particular, the present disclosure improves security against malicious parties who have used offline guessing attacks to obtain a share of a secret decryption key, for example against chosen ciphertext attacks by malicious parties who have learned some shares of the secret decryption key.

[0010] For example, a malicious party may have learned partial information about some shares of the key, from the parties that are unable to offer proper protection to their key-shares. Using this partial information, and having a ciphertext that it wants to decrypt, the malicious party may make an educated guess, what these key-shares may be. Invoking the decryption protocol with honest parties, the malicious party may find out whether its guess was correct. Even if the guess was wrong, and the malicious party is unable to decrypt the ciphertext, the outcome adds to the malicious party's information about these shares of the key, and repeated invocation of the decryption protocol may allow the malicious party to narrow down to the single correct value of these shares.

[0011] One way of improving security is to avoid the offline attacks that an adversary may be able to do after they have obtained the encrypted secret key share from a device, where the encryption key has low entropy. The success of an offline attack does not necessarily mean that the adversary has recovered the secret key share, but it may also simply mean that the adversary can recognize that decryption is being performed correctly.

[0012] In a first aspect there is provided a computer-implemented method for distributed asymmetric decryption between a first party and a second party, each of the first and second parties holding a different respective share of a secret key, the method comprising: receiving, at the second party: (i) a zero-knowledge proof of knowledge; and (ii) a plurality of inputs associated with a ciphertext to be decrypted, wherein the ciphertext is encrypted with a public key associated with the secret key; checking, by the second party, that the zero-knowledge proof of knowledge was generated based on the first party's share of the secret key; and in response to determining that the zero-knowledge proof of knowledge was generated based on the first party's share of the secret key, sending, by the second party, information derived from the second party's share of the secret key.

[0013] The association between the public key and the secret key may be an asymmetric association. That is, the public key may be for encrypting the document, and the secret key may be used for decrypting the document. The keys may work in opposite cryptographic directions from one another. The public and secret keys may be part of an asymmetric cryptographic system.

[0014] Because the secret key is split between the first party's share and the second party's share, the first aspect relates to distributed decryption (for example threshold decryption). Herein, the secret key may be the product of the first party's share of the secret key and the second party's share of the secret key. Therefore, the first party's share of the secret key may be defined as the secret key divided by the second party's share of the secret key. Similarly, the second party's share of the secret key may be defined as the secret key divided by the first party's share of the secret key.

[0015] Because the zero-knowledge proof of knowledge was generated based on the first party's share of the secret key, the proofs allows the verifier to check that the party that generated the proofs knows the value of the first party's share of the secret key sk 1 . In this example, the second party P2 verifies the proof received from the first party P1 in order to ascertain that the first party P1 knows its own share of the secret key sk 1 . This mechanism allows the first party and the second party to generate and send verifiable statements of knowledge of a particular value to each other without revealing the value itself. Whenever a zero-knowledge proof of knowledge cannot be verified by a party, the party halts its operations and does not further interact with the proof generator. As the proof generator does not receive a reply from the verifying party, any malicious attempt to extract information from the party is prevented. This means that, along with protection from Chosen-Ciphertext Attacks (CCA), the system is also provided with a novel security mechanism to counter offline-guessing attacks.

[0016] The first aspect may be performed at a network computer device, for example a server or a client device. That is to say, the second party may be a network computer device, such as a server or a client device. The first party may be a client device in communication with the second party.

[0017] In a second aspect there is provided a network device configured for performing distributed asymmetric decryption with a client device holding a first share of a secret key, the network device comprising a memory storing a second share of the secret key, and being configured to: receive, from a client device: (i) a zero-knowledge proof of knowledge; and (ii) a plurality of inputs associated with a ciphertext to be decrypted, wherein the ciphertext is encrypted with a public key associated with the secret key; check that the zero-knowledge proof of knowledge was generated based on the first share of the secret key; and in response to determining that the zero-knowledge proof of knowledge was generated based on the first share of the secret key, send information derived from the second share of the secret key to the client device.

[0018] In the present disclosure, "network device" and "second party" are used interchangeably. Therefore, where a feature is described in connection to the network device, it is to be understood that the feature in question applies equally to the second party. Similarly, "client device" and "first party" are used interchangeably in the present disclosure.

[0019] The network device may comprise a storage device and at least one processor. The storage device may have instructions stored thereon which, when executed by the at least one processor, cause the at least one processor to perform the required steps.

[0020] In a third aspect there is provided a computer-readable medium (for example a non-transitory computer readable medium) having instructions stored thereon which cause at least one processor to execute a method according to the first aspect.

[0021] Optional features of the first, second and third aspects are described below.

[0022] The ciphertext may comprise at least three elements: a first element, comprising a generator of a cyclic group raised to the power of a randomly generated number within the size of the cyclic group; a second element, comprising an encryption of a plaintext based on the public key, a hashing function, and the randomly generated number; a third element, comprising a further zero-knowledge proof of knowledge which is based on the randomly generated number.

[0023] In one embodiment, the plurality of inputs associated with the ciphertext received at the second party may comprise the first, second and third elements of the ciphertext. This embodiment may correspond to Figure 4 and the accompanying description below.

[0024] In an alternative embodiment with enhanced security, the plurality of inputs associated with the ciphertext received at the second party may comprise: a blinded version of the first element of the ciphertext, obtained by secretly picking and applying an exponent to mask the first element of the ciphertext; and a blinded proof obtained by malleating the non-interactive zero-knowledge proof of knowledge in the third element of the ciphertext. Malleating the proof in the third element of the ciphertext may include secretly picking and applying one or more exponents to mask one or more components of the proof. The blinded proof may be a designated-verifier, non-interactive zero-knowledge proof of knowledge. In particular, the proof may be also provided with an additional layer of encryption by applying a proof creation key during the malleation of the proof, so that the resulting blinded proof can only be verified using a proof verification key paired with the proof creation key. The second party may possess the proof verification key paired with the proof creation key and, therefore, may be the designated verifier of the blinded proof. Using the proof verification key, the second party may verify the blinded proof received from the first party. This embodiment may correspond to Figure 5 and the accompanying description below.

[0025] One or more of the zero-knowledge proofs of knowledge disclosed herein may be a non-interactive zero-knowledge proof of knowledge. For example, every zero-knowledge proof of knowledge disclosed herein may be a non-interactive zero-knowledge proof of knowledge. This type of zero-knowledge proof requires no interaction between the prover and verifier. Therefore, using the non-interactive zero-knowledge proof over the interactive zero knowledge proof saves communication and data transfer overhead, as it does not require any interaction. Further, it allows one proof to be used for any number of verifiers without interacting with each verifier, thereby reducing the amount of proofs that need to be generated by a prover.

[0026] The network device may check that the further zero-knowledge proof of knowledge in the third element of the ciphertext pertains to the same randomly generated number as the first element and the second element of the ciphertext. This check ensures that the received ciphertext was not maliciously generated as part of a CCA. It involves verifying that the second element c, representing the encryption of the plaintext, was obtained using the same randomly generated number r also used for obtaining the first element u, rather than being handpicked as required in CCA.

[0027] The network device may, for example, compute a third value (β) by inputting: (i) the generator of the cyclic group, (ii) the first element of the ciphertext, (iii) the first value (α), and (iv) the second element of the ciphertext, into a random hashing function; and then check whether the generator of the cyclic group raised to the power of the second value (γ) equals a value obtained by multiplying the first value (α) by the first element of the ciphertext raised to the power of the computed third value (β).

[0028] The further zero-knowledge proof of knowledge may comprise: a first value (α) based on the generator of the cyclic group and the randomly generated number; and a second value (γ) based at least on the randomly generated number, a random hashing function, the generator of the cyclic group, the first value (α), and the first element of the ciphertext.

[0029] The information derived from the second party's share of the secret key may be calculated by applying the second party's share of the secret key sk 2 to the first element u of the ciphertext. This operation ensures that the value of the second party's share of the secret key sk 2 is never transmitted over the network, thereby introducing an additional safeguard in case the communication is intercepted or listened to by a malicious actor. For example, the information may be derived from the second party's share of the secret key by raising the first element u of the ciphertext to the power of the second party's share of the secret key sk 2 .

[0030] The first party's share of the public key may be obtained by raising a generator of a cyclic group raised to the power of a value of the first party's share of the secret key. Determining that the zero-knowledge proof of knowledge was generated based on the first party's share of the secret key may serve to verify that the first party's share of the secret key is compatible with the first party's share of the public key.

[0031] Herein, the public key may be the product of the first party's share of the public key and the second party's share of the public key. Therefore, the first party's share of the public key may be defined as the public key divided by the second party's share of the public key. Similarly, the second party's share of the public key may be defined as the public key divided by the first party's share of the public key.

[0032] The first party's share of the public key may not itself be publicly known. However, the first party's share of the public key may be derivable from the public key and the second party's share of the public key.

[0033] Similarly, the second party's share of the public key may not itself be publicly known. The second party's share of the public key may be derivable from the public key and the first party's share of the public key.

[0034] Checking that the zero-knowledge proof of knowledge was generated based on the first party's share of the secret key may comprise: computing, at the second party, a fourth value (β') by inputting: (i) the generator of the cyclic group, (ii) the first party's share of the public key, (iii) a fifth value (α') included in the received proof of knowledge, into a random hashing function; checking whether the generator raised to the power of a received sixth value (γ') included in the received proof of knowledge, equals: the product of the fifth value (α') included in the received proof of knowledge, multiplied by the first party's share of the public key raised to the power of the computed fourth value (β'). Additionally, the computing of the fourth value (β') may comprise further inputting: (iv) the first element of the ciphertext, (v) the second element of the ciphertext, and (vi) the third element of the ciphertext.

[0035] A party from which a zero-knowledge proof of knowledge was received may be blacklisted when it is determined that the zero knowledge proof of knowledge received from the party was not generated based on the first party's share of the secret key. For example, the first party may be blacklisted by the second party once a predetermined number of invalid zero-knowledge proofs of knowledge have been received by the second party from the first party.

[0036] The network device may generate a further zero-knowledge proof of knowledge based on the second party's share of the secret key; and send to the client computing device the further zero-knowledge proof of knowledge with the information derived from the second party's share of the secret key. The second party's share of the public key may be obtained, for example, by raising a generator of a cyclic group raised to the power of a value of the second party's share of the secret key. In one example, the further zero-knowledge proof of knowledge based on the second party's share of the secret key may be generated by: generating, at the second party, a random number within the size of the cyclic group; computing a seventh value (α-u) by raising the first element of the ciphertext to the power of the generated random number; computing a eighth value (α-g) by raising the generator of the cyclic group to the power of the generated random number; computing a ninth value (β") by inputting: (i) the first element of the ciphertext; (ii) the generator; (iii) the first element of the ciphertext raised to the power of the second party's share of the public key; (iv) the second party's share of the public key; (v) the seventh value (α-u); and (vi) the eighth value of (α-g), into a random hashing function; computing a tenth value (γ") by multiplying the ninth value (β") by the value of the second party's share of the secret key and subsequently adding the generated random value to it; wherein the seventh, eighth, ninth and tenth values comprise the further zero-knowledge proof of knowledge.

[0037] In a fourth aspect there is provided a computer-implemented method for distributed asymmetric decryption between a first party and a second party, each of the first and second parties holding a different respective share of a secret key, the method comprising: generating, by the first party, a zero-knowledge proof of knowledge based on the first party's share of the secret key; sending, by the first party: (i) the zero-knowledge proof of knowledge; and (ii) a plurality of inputs associated with a ciphertext to be decrypted, wherein the ciphertext is encrypted with a public key associated with the secret key; receiving, at the first party, information derived from the second party's share of the secret key; and generating, by the first party, a decryption of the ciphertext using the first party's share of the secret key and the received information.

[0038] The fourth aspect may be performed at a client device, such as a mobile device. That is to say, the first party may be a client device. The second party may be a network device in communication with the first party. As the reader will understand, the first party of the third aspect may be configured to operate in communication with the second party of the first aspect, so as to perform distributed decryption.

[0039] In a fifth aspect there is provided a client computing device, such as a mobile device, which is configured for performing distributed asymmetric decryption with a network device holding a second share of a secret key, the client computing device comprising a memory storing a first share of the secret key, and being configured to: generate a zero-knowledge proof of knowledge based on the first share of the secret key; send: (i) the zero-knowledge proof of knowledge; and (ii) a plurality of inputs associated with a ciphertext to be decrypted, wherein the ciphertext is encrypted with a public key associated with the secret key, to the network device; receive information derived from the second share of the secret key from the network device; and generate a decryption of the ciphertext using the first share of the secret key and the received information.

[0040] In the present disclosure, "client device" and "first party" are used interchangeably. Therefore, where a feature is described in connection to the client device, it is to be understood that the feature in question applies equally to the first party.

[0041] As the reader will understand, the client device of the fifth aspect may be configured to operate in communication with the network device of the second aspect, so as to perform distributed decryption.

[0042] The client device may comprise a storage device and at least one processor. The storage device may have instructions stored thereon which, when executed by the at least one processor, cause the at least one processor to perform the required steps.

[0043] In a sixth aspect there is provided a computer-readable medium (for example a non-transitory computer readable medium) having instructions stored thereon which cause at least one processor to execute a method according to the fourth aspect.

[0044] Optional features of the fourth, fifth and sixth aspects will now be described.

[0045] The information derived from the second party's share of the secret key may comprises the result of an operation in which the second party's share of the secret key is applied to an element of the ciphertext. For example, the information may be derived from the second party's share of the secret key by raising the first element of the ciphertext to the power of the second party's share of the secret key.

[0046] The ciphertext may comprise at least three elements: a first element, comprising a generator of a cyclic group raised to the power of a randomly generated number within the size of the cyclic group; a second element, comprising an encryption of a plaintext based on the public key, a hashing function, and the randomly generated number; a third element, comprising a further zero-knowledge proof of knowledge which is based on the randomly generated number. In one example, the further zero-knowledge proof of knowledge may comprise: a first value (α) based on the generator and the randomly generated number, and a second value (γ) based at least on the randomly generated number, a random hashing function, the generator, the first value (α), and the first element of the ciphertext.

[0047] In one embodiment, the plurality of inputs associated with the ciphertext sent by the first party may comprise the first, second and third elements of the ciphertext. This embodiment may correspond to Figure 4 and the accompanying description below.

[0048] In an alternative embodiment with enhanced security, the plurality of inputs associated with the ciphertext sent by the first party may comprise: a blinded version of the first element of the ciphertext, obtained by secretly picking and applying an exponent to mask the first element of the ciphertext; and a blinded proof obtained by malleating the non-interactive zero-knowledge proof of knowledge in the third element of the ciphertext. Malleating the proof in the third element of the ciphertext may include secretly picking and applying one or more exponents to mask one or more components of the proof. The blinded proof may be a designated-verifier, non-interactive zero-knowledge proof of knowledge. In particular, the proof may be also provided with an additional layer of encryption by applying a proof creation key during the malleation of the proof, so that the resulting blinded proof can only be verified using a proof verification key paired with the proof creation key. The second party may possess the proof verification key paired with the proof creation key and, therefore, may be the designated verifier of the blinded proof. Using the proof verification key, the second party may verify the blinded proof received from the first party. This embodiment may correspond to Figure 5 and the accompanying description below.

[0049] One or more of the zero-knowledge proofs of knowledge may be a non-interactive zero-knowledge proof of knowledge. For example, every zero-knowledge proof of knowledge may be a non-interactive zero-knowledge proof of knowledge.

[0050] The client computing device may check that the further zero-knowledge proof of knowledge in the third element of the ciphertext pertains to the same randomly generated number as the first element and the second element of the ciphertext. The client computing device may, for example, compute a third value (β) by inputting: (i) the generator of the cyclic group, (ii) the first element of the ciphertext, (iii) the first value (α), and (iv) the second element of the ciphertext, into a random hashing function; and then check whether the generator of the cyclic group raised to the power of the second value (γ) equals a value obtained by multiplying the first value (α) by the first element of the ciphertext raised to the power of the computed third value (β).

[0051] A first party share of the public key may be generated based on the first party's share of the secret key. The first party share of the public key may be used to generate the zero-knowledge proof of knowledge. The first party's share of the public key may be destroyed after use. For example, the first party's share of the public key may be generated responsive to receiving a request to decrypt the ciphertext and may be destroyed immediately after use.

[0052] Generating the zero-knowledge proof of knowledge based on the first party's share of the secret key may comprise generating two or more randomized values based on a generator of a cyclic group, the first party's share of the secret key, and the first party's share of the public key, using a randomly generated number and a random hashing function. The zero-knowledge proof of knowledge based on the first party's share of the secret key may be generated by: generating, at the first party, a random number within the size of a cyclic group; computing a fifth value (α') by raising a generator of the cyclic group to the power of the generated random number; computing a fourth value (β') by inputting: (i) the generator, (ii) the first party's share of the public key, (iii) the fifth value (α'), into a random hashing function; computing a sixth value (γ') by multiplying the fourth value (β') by the value of the first party's share of the secret key and subsequently adding the generated random value to it; wherein the fifth and sixth values comprise zero-knowledge proof of knowledge. Additionally, the computing of the fourth value (β') may comprise further inputting: (iv) the first element of the ciphertext, (v) the second element of the ciphertext, and (vi) the third element of the ciphertext.

[0053] A decryption of the ciphertext may be generated using the first party's share of the secret key and the received information. The decryption may be obtained, for example, by generating a decryption of the second element of the ciphertext using a hashing function, the first party's share of the secret key, and the received information.

[0054] Before generating a decryption of the ciphertext using the first party's share of the secret key and the received information, the first party may receive a further zero-knowledge proof of knowledge and verifies that the received further proof of knowledge pertains to the second party's share of the secret key. The received zero-knowledge proof of knowledge may comprise, for example: (i) a seventh value (α-u), (ii) a eighth value (α-g), and (iii) a tenth value (γ"). The first party may check that the received proof of knowledge pertains to the second party's share of the secret key, for example, by: computing, at the first party, a ninth value (β") by inputting: (i) the first element of the ciphertext; (ii) the generator; (iii) the first element of the ciphertext raised to the power of the second party's share of the public key; (iv) the second party's share of the public key; (v) the received seventh value (α-u); and (vi) the received eighth value (α-g), into a random hashing function; checking, at the first party: whether the first element of the ciphertext raised to the power of the received value of Gamma equals: the product of the received seventh value (α-u) multiplied by the second party's share of the public key raised to the power of the computed ninth value (β"); and whether the generator raised to the power of the received tenth value (γ"), equals: the product of the received seventh value (α-g) multiplied by the second party's share of the public key raised to the power of the computed ninth value (β"). The second party's share of the public key may be derived from the public key and the first party's share of the public key. In another embodiment, the first party generates a decryption of the ciphertext without verifying the further proof of knowledge. In yet another embodiment, the first party generates a decryption of the ciphertext without receiving any further proof of knowledge from the second party.

[0055] According to an embodiment, the further zero-knowledge proof of knowledge in the third element of the ciphertext may comprise a designated-verifier zero-knowledge proof of knowledge for the second party. The first party may hold an encryption key that encrypts information that can only be decrypted with a corresponding verification key. The second party may hold a verification key that decrypts information encrypted with a corresponding encryption key. Additionally, when generating or verifying the zero-knowledge proof of knowledge based on the first party's share of the secret key, both the first party and the second party may compute the fourth value (β') by further inputting into the random hashing function: (iv) the first element of the ciphertext, and (v) the third element of the ciphertext.Brief Description of the Drawings

[0056] The present disclosure will now be described in detail, with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram showing an example overall system architecture, including a server and a client device, for performing distributed decryption according to the present disclosure; Figure 2 is a schematic diagram showing the client device from Figure 1; Figure 3 is a schematic diagram showing the server device from Figure 1; Figure 4 is a flow chart showing a distributed decryption process according to the present disclosure; and Figure 5 is a flow chart showing a distributed decryption process with additional privacy-preserving features according to the present disclosure; Figure 6 shows a schematic representation of a computer apparatus which can be used to perform methods described herein.

[0057] Like reference numerals are used for like components throughout the description and drawings.Detailed Description

[0058] The present disclosure relates generally to improving security of decryption in distributed decryption systems, and in particular providing security against malicious parties to distributed decryption systems.

[0059] In distributed decryption systems, a secret key for performing decryption operations on ciphertext documents is distributed between two or more respective devices. Each device stores a respective share of the secret key. In order to decrypt a ciphertext document and thereby obtain the corresponding plaintext document, both shares of the secret key are needed. Therefore, a single device is not on its own able to decrypt the ciphertext document. In the present disclosure, we describe the principles of the present disclosure using two devices, each of which has a respective share of the secret key. However, as the reader will understand, the present disclosure could be implemented on any number of devices - for example three devices, four devices, or more, provided that each device has stored thereon a respective share of the secret key.

[0060] Figure 1 shows an example of a system architecture for implementing the distributed decryption according to present disclosure. It includes a network device 120 and a client device 110, connected to one another over a network 130. The network device 120 has one or more processors 122 and a memory 124 storing data and instructions. The client device 110 has one or more processors 112 and a memory 114 storing data and instructions.

[0061] The network device 120 may typically be a server device. However, in some examples, the network device may be a client device similar to device 110. The client device 110 may be a mobile phone, a tablet device, a laptop, or a PC. Hereafter, the network device 120 will be referred to a server device 120 for simplicity, in order to clearly distinguish from the client device 110. However, the reader will understand that the scope of the present disclosure is not limited thereto.

[0062] The network connection 130 may be a wired connection, or a wireless connection. For example, the network connection may be a WWAN connection (e.g. a 2G, 3G, 4G, 4G LTE, or 5G cellular connection), or a WLAN connection (e.g. WiFi). Where devices 110 and 120 are both client devices, the connection may even be a near field connection, such as Bluetooth. As the reader will understand, this is a non-exhaustive list of possible connections between the devices 110, 120.

[0063] Figure 2 shows the example client device 110 (sometimes referred to herein as party 1, or "P1") in more detail. Figure 3 shows the example server device 120 (sometimes referred to herein as party 2, or "P2") in more detail. Data stored in the memory 124 of the server device 120 includes the full public key pk, the first party's share of the public key pk 1 , the second party's share of the public key pk 2 , and the second party's share of secret key sk 2 . Data stored in the memory 114 of the client device 110 includes the full public key pk, the first party's share of secret key sk 1 , and the ciphertext.

[0064] Figure 4 is a flowchart showing an embodiment of the present disclosure. A series of operations are depicted in the flowchart involving client device 110 and server device 120. Client device 110 acts as the first party P1 to the method and server device 120 acts as the second party P2 to the method. A number of the operations include data transfers between client device 110 and server device 120 performed over the network 130.

[0065] The flowchart in Figure 4 is an example method for decrypting a ciphertext according to the present disclosure. A ciphertext, also known as encrypted or encoded information, contains a form of a given original message that is unreadable by a human or a computer without the proper cipher to decrypt it. A cipher is an algorithm for performing encryption or decryption. Decryption, the inverse of encryption, is the process of turning a ciphertext into a readable message, known as plaintext.

[0066] The method makes use of non-interactive zero-knowledge proofs of knowledge of certain statements, in particular related to knowing certain discrete logarithms. Given a relation ⊆ X × W, the equation π = NIZKPoK[wx | x w] denotes the proof that someone knows a value w ∈ W, such that the value x, known to the verifier of the proof, is related to w. The checking of this proof is denoted by check(π|x), which returns either true or false. In the example method of Figure 4, NIZKPoK-s are used for the knowledge of discrete logarithms. These NIZKPoK-s come with associated data D, meaning that they are intended to be considered valid only within the scope of D. In turn, this means, that if someone tries to tamper with D, then this is noticed and the proof is considered invalid.

[0067] NIZKPoK-s are implemented with the use of random oracles. A random oracle H: X → can be thought of as a random function. It is modelled as a box that takes queries x ∈ X from anyone, and responds with elements of . Internally, that box maintains the current partial mapping from X to , extending it whenever it is queried with an x that it has not seen before. Implementations of random oracles are based on hash functions.

[0068] Let H 1 be a random oracle that takes any kinds of arguments (converted into bit-strings) into elements of ℤ p . The proof NIZKPoK D< x g 1 , … , g k , h 1 , … , h k ∧ i = 1 k g i x = h i is implemented as follows: 1. Randomly generate r ∈ ℤ p 2. For each i, compute α i ← g i r 3. Compute β = H 1 (g 1 ,...,g k , h 1 ,..., h k , α i , , α k , D 4. Compute γ = r + βx 5. Output α i , α k , γ

[0069] The verification of this NIZKPoK proceeds as follows: 1. Compute β = H 1 (g 1 ,..., g k , h 1 ,..., h k , α i , ... ,α k , D 2. For each i, check that g i γ = α i ⋅ h i β .

[0070] Equation i shows an algorithm corresponding to Figure 4. The algorithm is the decryption protocol for a given ciphertext (u, c, π), wherein: u represents the value obtained from raising the generator g to the power of a randomly generated number r; c represents the encryption of the plaintext; π represents the zero-knowledge proof of knowledge based on the first element u. The algorithm uses hashing function H as random oracle for its proofs and returns the plaintext m.

[0071] Figure 4 illustrates an example method between only two parties. The method may be performed by, for example, a client computing device 110 as the first party P1 and a server device 120 as the second party P2. The method may nevertheless involve two or more parties. For example, the method may involve a server device acting as the second party and one or more client computing devices behaving like the first party.

[0072] At operation 310, the client computing device 110 checks that the non-interactive zero-knowledge proof of knowledge in the third element of the ciphertext (i.e. element π of the ciphertext (u, c, π) from Equation i) is a zero-knowledge proof of knowledge based on the first element of the ciphertext (i.e. element u of the ciphertext (u, c, π) from Equation i). Operation 310 is implemented by line 3 of Equation i. The verification of this NIZKPoK proceeds as follows: 1. Compute β = H(g, u, α, c) 2. Check that g γ< = α u β<

[0073] At operation 312, the client computing device 110 computes the first party's share of the public key pk 1 based on the first party's share of the secret key sk 1 . Operation 312 is implemented by line 4 of Equation i. The first party's share of the public key pk 1 is computed by raising the generator g to the power of the first party's share of the secret key sk 1 .

[0074] At operation 314, the client computing device 110 generates a zero-knowledge proof of knowledge π 2 based on the first party's share of the secret key sk 1 . Operation 314 is implemented by line 5 of Equation i. The generation of non-interactive zero-knowledge proof of knowledge π 2 is implemented as follows: 1. Randomly generate r 1 ∈ ℤ p 2. Compute α 1 ← g r1< 3. Compute β 1 = H(g, pk 1 , α 1 , u, c, π) 4. Compute γ 1 = r 1 + β 1 sk 1 5. Output α 1 , γ 1

[0075] At operation 316, the client computing device 110 sends the ciphertext (u, c, π) and the generated zero-knowledge proof of knowledge π 2 to the server device 120 over the network 130. The server device 120 receives the ciphertext (u, c, π) and the generated zero-knowledge proof of knowledge π 2 from the client computing device 110. Operation 316 is implemented by line 6 of Equation i.

[0076] At operation 318, the server device 120 checks that the non-interactive zero-knowledge proof of knowledge in the third element of the ciphertext (i.e. element π of the ciphertext (u, c, π) from Equation i) is a zero-knowledge proof of knowledge based on the first element of the ciphertext (i.e. element u of the ciphertext (u, c, π) from Equation i). Operation 318 is implemented by the first check in line 9 of Equation i. The verification of this NIZKPoK proceeds as follows: 1. Compute β = H(g, u, α, c) 2. Check that g γ< = α u β<

[0077] At operation 320, the server device 120 checks that the received zero-knowledge proof of knowledge π 2 is a zero-knowledge proof of knowledge based on the first party's share of the secret key sk 1 . Operation 320 is implemented by the second check in line 9 of Equation i. The verification of this NIZKPoK proceeds as follows: 1. Compute β 1 = H(g, pk 1 , α 1 , u, c, π) 2. Check that g γ 1 = α 1 ⋅ pk 1 β 1

[0078] At operation 322, the server device 120 computes a value w based on the second party's share of the secret key sk 2 . Operation 322 is implemented by line 10 of Equation i. The value assigned to the variable named w is obtained by raising the first element of the ciphertext (i.e. element u of the ciphertext (u, c, π) from Equation i) to the power of the second party's share of the secret key sk 2 .

[0079] At operation 324, the server device 120 generates a zero-knowledge proof of knowledge τ based on the second party's share of the secret key sk 2 . Operation 324 is implemented by line 11 of Equation i. The generation of non-interactive zero-knowledge proof of knowledge τ is implemented as follows: 1. Randomly generate r 2 ∈ ℤ p 2. Compute α u ← u r2< 3. Compute α g ← g r2< 4. Compute β 2 = H(u, g, u pk2< , pk 2 , α u , α g ) 5. Compute γ 2 = r 2 + β 2 sk 2 6. Output α u , α g , γ 2

[0080] At operation 326, the server device 120 sends the value w and the generated zero-knowledge proof of knowledge τ to the client computing device 110 over the network 130.

[0081] The client computing device 110 receives the value w and the generated zero-knowledge proof of knowledge τ from the server device 120. Operation 326 is implemented by line 12 of Equation i.

[0082] At operation 328, the client computing device 110 checks that the received zero-knowledge proof of knowledge τ is a zero-knowledge proof of knowledge based on the second party's share of the secret key sk 2 . Operation 328 is implemented by line 15 of Equation i. The verification of this NIZKPoK proceeds as follows: 1. Compute β 2 = H(u, g, u pk2< , pk 2 , α u , α g ) 2. Check that u γ 2 = α u ⋅ pk 2 β 2 3. Check that g γ 2 = α g ⋅ pk 2 β 2

[0083] The client computing device 110 derives the second party's share of the public key pk 2 from the public key pk and the first party's share of the public key pk 1 . In particular, the second party's share of the public key pk 2 is obtained by dividing the public key pk by the first party's share of the public key pk 1 .

[0084] At operation 330, the client computing device 110 generates a decryption of the second element of the ciphertext (i.e. element c of the ciphertext (u, c, π) from Equation i) based on the first party's share of the secret key sk 1 and the received value w. Operation 330 is implemented by line 16 of Equation i. The first element u of the ciphertext (u, c, π) is raised to the power of the first party's share of the secret key sk 1 . The value resulting from this operation is then multiplied by the received value w, wherein w corresponds to the first element u of the ciphertext (u, c, π) raised to the power of the second party's share of the secret key sk 2 . The product of the multiplication is then inputted into the hashing function H. Finally, the ciphertext c is decrypted by applying the ⊕ operation between c and the output of the hashing function H.

[0085] At operation 332, the client computing device 110 obtains the plaintext corresponding to the second element of the ciphertext (i.e. the plaintext corresponding to element c of the ciphertext (u, c, π) from Equation i). The plaintext m corresponds to the decryption of ciphertext c obtained in operation 330. The plaintext m contains the original message that was encrypted by the issuer of the ciphertext (u, c, π).

[0086] The setup for the cryptographic scheme used in the example of Figure 4 and the algorithm in Equation i will now be described.

[0087] When using ElGamal encryption, a cyclic group with a hard Decisional Diffie-Hellman (DDH) problem is used, e.g. some subgroup of the group of points of an elliptic curve. For example, let g be a generator of the group and p the number of elements in the group. Both g and p are known to all parties. Then, in this EIGamal encryption scheme, the secret key is a random value sk ∈ ℤ p , where ℤ p denotes the set of integers modulo p. The corresponding public key is h = g sk< . . To encrypt a message m ∈ G, the sender generates a random r ∈ ℤ p and computes the ciphertext (c 1 , c 2 ) = (g r< , m h r< ). To decrypt the ciphertext (c 1 , c 2 ), the receiver must compute c 1 sk and then find m = c 2 / c 1 sk .

[0088] In the example of Figure 4 and the algorithm in Equation i, we use an alternate setting called hash-ElGamal encryption. Possible plaintexts are bit-strings of a given length n. In this case, a hash function H : G → 0 1 n is used. The hash function is modelled after a random oracle, i.e. its outputs are perfectly random. To encrypt a message m ∈ {0, 1} n< , the sender generates a random r ∈ ℤ p and computes the ciphertext (c 1 , c 2 ) = (g r< , m Hh r< )). To decrypt the ciphertext (c 1 , c 2 ), the receiver must compute c 1 sk and then find m = c 2 ⊕ H c 1 sk .

[0089] As decryption is distributed, the public key may also be generated in a distributed manner. In an embodiment that includes k parties, each one of them selects a random sk i ∈ ℤ p as their respective share sk i of the secret key sk. Each party then computes its public-key share pk i = g ai< and sends it to the other parties (or, alternatively, to a certification authority trusted by all parties to publish the public key pk). The product pk = g ai< ··· g ak< is the public key. The corresponding secret key is sk = sk 1 + ··· + sk k . sk materialise at any point during the decryption process, thereby providing the distributed system with an additional safeguard in case of interceptions from malicious actors or other types of data breaches.

[0090] The decryption protocol between P1 and P2 given in Equation i relies on the assumption that the previous phases of Setup, Key Generation and Encryption have already been completed ahead of its execution. The Setup phase includes: the generation of cyclic group using generator g with hard DDH problem; and the selection of hash function H : G → 0 1 n modelled after a random oracle. In the Key Generation phase, P1 randomly selects sk 1 ∈ ℤ p and P2 randomly selects sk 2 ∈ ℤ p . The phone P1 stores only pk and sk 1 . The phone does not store pk 1 to prevent malicious actors from verifying a guess of sk 1 by matching it against sk 1 , in case of an interception or a data breach. The server P2 stores pk, sk 2 and may also store pk 1 and pk 2 for the purpose of speeding up its computations. During the Encryption phase, the random number r ∈ ℤ p is generated and then used in both the first element u and second element c of the ciphertext (u, c, π). The third element π of the ciphertext is used to prove to both P1 and P2 that the same randomly generated r was used in the first and second elements of the ciphertext. The verification of π by either P1 or P2 provides protection from CCA, which rely on c being handpicked by the attacker. Once P1 has been provided with the ciphertext, the decryption protocol of Equation i may be initiated.

[0091] Figure 5 is a flowchart showing a further embodiment according to the present disclosure. A series of operations are depicted in the flowchart involving client device 110 and server device 120. Client device 110 acts as the first party P1 to the method and server device 120 acts as the second party P2 to the method. A number of the operations include data transfers between client device 110 and server device 120 performed over the network 130.

[0092] The flowchart in Figure 5 is a more elaborate example method for decrypting a ciphertext, and includes additional privacy-preserving features relative to the method of Figure 4. In particular, in the example method of Figure 5 the first party P1 only sends a blinded version of the ciphertext to the second party P2. The blinded ciphertext comprises a masked version of the first element u of the original ciphertext and a malleated version of the proof in the third element π of the original ciphertext, while the second element c of the original ciphertext is omitted altogether. This means that, not only does P2 never see the encrypted message itself (i.e. the second element of the original ciphertext), but potential listeners are also denied the opportunity to acquire it as it is not transmitted over network 130 for the duration of the protocol. Further, the remaining elements of the original ciphertext are only sent to P2 via network 130 in an altered form and the malleated proof is a designated-verifier proof that can only be verified by P2. Therefore, the combination of privacy-preserving techniques used in the example method of Figure 5 results in every part of the original ciphertext being highly inaccessible to an attacker.

[0093] Equation j shows an algorithm corresponding to Figure 5. The algorithm is the decryption protocol for a given ciphertext (u, c, π), wherein: u represents the value obtained from raising the generator g to the power of a randomly generated number r; c represents the encryption of the plaintext; π represents the zero-knowledge proof of knowledge based on the first element u. The algorithm uses hashing function H as random oracle for its proofs and returns the plaintext m. Unlike the algorithm of Equation i, in the algorithm shown in Equation j the third element π of the ciphertext appears as a string (α 1 , Γ 1 , Γ 2 ). Additionally, a proof creation key (ek, B 1 , B 2 ) is used by P1 for generating a designated-verifier proof and a verification key (β, vk) is used by P2 for checking the proof.

[0094] Figure 5 illustrates an example method between only two parties. The method may be performed by, for example, a client computing device 110 as the first party P1 and a server device 120 as the second party P2. The method may nevertheless involve two or more parties. For example, the method may involve a server device acting as the second party and one or more client computing devices behaving like the first party.

[0095] Before execution of the algorithm, the client computing device 110 may check that the non-interactive zero-knowledge proof of knowledge in the third element of the ciphertext (i.e. string (α 1 , Γ 1 , Γ 2 ) from Equation j) is a zero-knowledge proof of knowledge based on the first element of the ciphertext (i.e. element u of the ciphertext from Equation j).

[0096] At operation 510, the client computing device 110 computes the first party's share of the public key pk 1 based on the first party's share of the secret key sk 1 . Operation 510 is implemented by line 2 of Equation j. The first party's share of the public key pk 1 is computed by raising the generator g to the power of the first party's share of the secret key sk 1 .

[0097] At operation 512, the client computing device 110 randomly picks an exponent z, which is kept secret by P1 for the duration of the protocol, and applies z to the first element u of the ciphertext. Operation 512 is implemented by lines 3 and 4 of Equation j. The resulting u', obtained by raising u to the power of z, is treated as a masked version of the first element u of the ciphertext.

[0098] At operation 514, the client computing device 110 malleates the proof in the third element (α 1 , Γ 1 , Γ 2 ) of the ciphertext. As part of this process, the proof is malleated using proof creation key ek, which is part of a keypair that includes proof creation key ek and proof verification key vk. The resulting malleated proof is therefore also a designated-verifier proof, i.e. it is only verifiable using the proof verification key vk. The proof verification key vk is a secret key held by P2. Operation 514 is implemented by line 5 of Equation j, where string ( α 1 ′ , Γ 1 ′ , Γ 2 ′ ) is the resulting designated-verifier malleated proof. The string ( α 1 ′ , Γ 1 ′ , Γ 2 ′ ) is obtained by malleating the proof in the third element ( α 1 , Γ 1 , Γ 2 ) of the ciphertext as follows: 1. Compute α 1 ′ ← α 1 z ⋅ g z ′ mod p , wherein z ′ ← $ I ρ + 2 d + 2 κ ) 2. Compute Γ 1 ′ → Γ 1 z ⋅ ε ek z ′ 3. Compute Γ 2 ′ ← Γ 2 z ⋅ ε ek z ′ 4. Output ( α 1 ′ , Γ 1 ′ , Γ 2 ′ )

[0099] Here, I (p + 2d + 2κ) indicates the set of integers with a number of bits equal to ρ + 2d + 2κ. The value d corresponds to the number of bits for the size p of cyclic group G. Additionally, ρ and κ are fixed security parameters for soundness and privacy of the scheme. Typical values for these parameters are between 80 and 128 (or 256). It can normally be assumed that ρ ≤ κ ≤ d.

[0100] At operation 516, the client computing device 110 composes a blinded version of the ciphertext using the masked first element u' and the designated-verifier malleated proof. Notably, the second element c of the original ciphertext does not feature in the blinded version. Operation 516 is a conceptual step that is useful for understanding the following steps in the algorithm of Equation j and therefore the operation itself does not appear in the pseudocode. The resulting blinded ciphertext appears in line 7 of Equation j as string ( u ′ , α 1 ′ , Γ 1 ′ , Γ 2 ′ ).

[0101] At operation 518, the client computing device 110 generates a non-interactive zero-knowledge proof of knowledge π 2 based on the first party's share of the secret key sk 1 . Operation 518 is implemented by line 6 of Equation j, where proof π 2 is generated in the form of proof string (g", α 4 , α 4 " , γ 4 ) as follows: 1. Randomly generate r 4 ← $ ℤ p 2. Compute α 4 ← g r4< 3. Compute h" ← H 3 (g, pk 1 , α 4 , u', α 1 ′ , Γ 1 ′ , Γ 2 ′ ), where h " ∈ G 4. Compute g" ← (h") 1lsk1< 5. Compute α 4 " ← g " r 4 6. Compute β 4 ← H 4 (g, g", pk 1 , h", α 4 , α 4 " , u', α 1 ′ , Γ 1 ′ , Γ 2 ′ ), where β 4 ∈ ℤ p β 4 7. Compute γ 4 ← r 4 + β 4 · sk 1 8. Output (g", α 4 , α 4 " , γ 4 )

[0102] At operation 520, the client computing device 110 sends the blinded ciphertext (u', α 1 ′ , Γ 1 ′ , Γ 2 ′ ) and the generated proof string (g", α 4 , α 4 " , γ 4 ) to the server device 120 over the network 130. The server device 120 receives the ciphertext (u', α 1 ′ , Γ 1 ′ , Γ 2 ′ ) and the generated proof string (g", α 4 , α 4 " , γ 4 ) from the client computing device 110. Operation 520 is implemented by line 7 of Equation j.

[0103] At operation 522, the server device 120 checks that the received designated-verifier malleated proof (α 1 ', Γ 1 ', Γ 2 ') is a zero-knowledge proof of knowledge based on the first element of the ciphertext (i.e. element u of the ciphertext from Equation j). In order to verify the designated-verifier malleated proof, P2 must use its verification key (β, vk). Operation 522 is implemented by line 9 of Equation j. The verification of this proof proceeds as follows: 1. Check that (Γ 1' ) = (Γ 2 ' 2. If check fails, the proof is rejected; if check passes, check that α 1 ′ ⋅ u ′ β = g D vk Γ 1 ′ 3. If check fails, the proof is rejected; if check passes, the proof is accepted

[0104] At operation 524, the server device 120 checks that the received proof string (g", α 4 , α 4 " , γ 4 ), also known as proof π 2 , is a non-interactive zero-knowledge proof of knowledge based on the first party's share of the secret key sk 1 . Operation 524 is implemented by lines 10 and 11 of Equation j. The verification of this NIZKPoK proceeds as follows: 1. Compute h" ← H 3 (g,pk 1 ,α 4 ,u', α 1 ′ , Γ 1 ′ , Γ 2 ′ ) 2. Compute β 4 ← H 4 (g, g", pk 1 , h", α 4 , α 4 " , u', α 1 ′ , Γ 1 ′ , Γ 2 ′ ) 3. Check that g γ 4 = α 4 ⋅ pk 1 β 4 4. If check fails, the proof is rejected; if check passes, check that g " γ 4 = α 4 " ⋅ h " β 4 5. If check passes, the proof is accepted

[0105] At operation 526, the server device 120 computes a value w based on the second party's share of the secret key sk 2 . Operation 526 is implemented by line 12 of Equation j, where the value assigned to the variable named w is obtained by raising the first element of the blinded ciphertext (i.e. the masked first element u' of the ciphertext from Equation j) to the power of the second party's share of the secret key sk 2 .

[0106] At operation 528, the server device 120 generates a non-interactive zero-knowledge proof of knowledge τ based on the second party's share of the secret key sk 2 . Operation 528 is implemented by line 13 of Equation j, where proof τ is generated in the form of proof string (α 51 , α 52 , γ 5 ) as follows: 1. Randomly generate r 5 ← $ ℤ p 2. Compute α 51 ← (u') r5< 3. Compute α 52 ← pk 1 r 5 4. Compute β 5 ← H 5 (u', pk 1 , w, pk, α 51 , α 52 ), where β 5 ∈ ℤ p 5. Compute γ 5 ← r 5 + β 5 · sk 2 6. Output (α 51 , α 52 , γ 5 )

[0107] At operation 530, the server device 120 sends the value w and the generated proof string (α 51 , α 52 , γ 5 ) to the client computing device 110 over the network 130. The client computing device 110 receives the value w and proof string (α 51 , α 52 , γ 5 ) from the server device 120. Operation 530 is implemented by line 14 of Equation j.

[0108] At operation 532, the client computing device 110 checks that the received proof string (α 51 , α 52 , γ 5 ), also known as proof τ, is a non-interactive zero-knowledge proof of knowledge based on the second party's share of the secret key sk 2 . Operation 532 is implemented by line 16 of Equation j. The verification of this NIZKPoK proceeds as follows: 1. Compute β 5 ← H 5 (u', pk 1 , w, pk, α 51 , α 52 ) 2. Check that (u') γ5< = α 51 · w β5< 3. If check fails, the proof is rejected; if check passes, check that pk 1 γ 5 = α 52 ⋅ pk β 5 4. If check passes, the proof is accepted

[0109] At operation 534, the client computing device 110 generates a decryption of the second element of the original ciphertext (i.e. element c of the ciphertext from Equation j) based on the first party's share of the secret key sk 1 and the received value w. Operation 534 is implemented by line 17 of Equation j. The received value w is raised to the power of the first party's share of the secret key sk 1 divided by exponent z. The value resulting from this operation is then inputted into the hashing function H. Finally, the ciphertext c is decrypted by applying the ⊕ operation between c and the output of the hashing function H.

[0110] At operation 536, the client computing device 110 obtains the plaintext corresponding to the second element of the original ciphertext (i.e. the plaintext corresponding to element c of the ciphertext from Equation j). The plaintext m contains the message that was encrypted by the issuer of the original ciphertext.

[0111] The resulting protocol is given in Equation k, which unfolds all the operations shown in Equation j. The protocol featured in Equation k is the same scheme given in Equation j, but it is simply shown in full by listing every step explicitly thereby removing calls to subroutines.

[0112] The setup for the cryptographic scheme used in the example of Figure 5 and the algorithm in Equation j will now be described. The ElGamal scheme is used for encryption and decryption. When using ElGamal encryption, a cyclic group with a hard Decisional Diffie-Hellman (DDH) problem is used, e.g. some subgroup of the group of points of an elliptic curve. For example, let g be a generator of the group and p the number of elements in the group. Both g and p are known to all parties. Then, in this EIGamal encryption scheme, the secret key is a random value sk ∈ ℤ p , where ℤ p denotes the set of integers modulo p. The corresponding public key is h = g sk< . . To encrypt a message m ∈ G, the sender generates a random r ∈ ℤ p and computes the ciphertext (c 1 , c 2 ) = (g r< , m · h r< ). To decrypt the ciphertext (c 1 , c 2 ), the receiver must compute c 1 sk and then find m = c 2 / c 1 sk .

[0113] In the example of Figure 5 and the algorithm in Equation j, we use an alternate setting called hash-ElGamal encryption. Possible plaintexts are bit-strings of a given length n. In this case, a hash function H : G → 0 1 n is used. The hash function is modelled after a random oracle, i.e. its outputs are perfectly random. To encrypt a message m ∈ {0, 1} n< , the sender generates a random r ∈ ℤ p and computes the ciphertext (c 1 , c 2 ) = (g r< , m Hh r< )). To decrypt the ciphertext (c 1 , c 2 ), the receiver must compute c 1 sk and then find m = c 2 ⊕ H c 1 sk .

[0114] As decryption is distributed, the public key may also be generated in a distributed manner. In an embodiment that includes 2 parties, each one of them selects a random sk i ∈ ℤ p as their respective share sk i of the secret key sk. Each party then computes its public-key share pk i = g ai< and sends it to the other parties (or, alternatively, to a certification authority trusted by all parties to publish the public key pk). In this privacy-preserving variant of the scheme, the public key is defined as pk = (g sk1< ) sk2< . The corresponding secret key is sk = sk 1 · sk 2 . Hence, the secret key is multiplicatively shared, not additively. However, the full secret key sk does again not materialise at any point during the decryption process, thereby still providing the distributed system with an additional safeguard in case of interceptions from malicious actors or other types of data breaches.

[0115] The decryption protocol between P1 and P2 given in Equation j relies on the assumption that the previous phases of Setup, Key Generation and Encryption have already been completed ahead of its execution.

[0116] The Setup phase includes: the generation of cyclic group of size p (a prime number) using generator g with hard DDH problem; and the selection of hash function H : G → 0 1 n modelled after a random oracle.

[0117] The size p of cyclic group is d bits long. Further, two fixed security parameters ρ and κ are chosen for soundness and privacy of the scheme. Typical values for these parameters range between 80 and 128 (or 256), and it normally is assumed that ρ ≤ κ ≤ d.

[0118] Throughout the protocol, there are six different types of invocations to hash function H. These are denoted as H, H 1 , H 2 , H 3 , H 4 , H 5 . Different invocations have different output types: H returns a bit-string of the same length as the plaintext m H 1 and H 3 return an element of H 2 returns an integer of length ρ H 4 and H 5 return an element of ℤ p

[0119] In the Key Generation phase, Phone P1 randomly chooses sk 1 ∈ ℤ p and server P2 randomly chooses sk 2 ∈ ℤ p . Then, they send pk 1 = g sk1< and pk 2 = g sk2< to each other. Let pk = pk 1 sk 2 = pk 2 sk 1 . The phone P1 stores only pk and sk 1 , the latter encrypted with a low-entropy symmetric key. The server P2 stores pk, sk 2 , and, for speeding up its computations, also pk 1 and pk 2 . The phone P1 may not store neither pk 1 nor pk 2 , because a guess of sk 1 can be matched against either of them.

[0120] The private key of the system is shared multiplicatively, not additively. This is as confidentiality-preserving as additive sharing, because p - the size of the group - is a prime number.

[0121] The server P2 also generates the DVNIZK key ((ek, B 1 ), (vk, β)), where β ≤ 2 ρ< , homomorphic cryptosystem, and sends the public part to the phone P1. The server P2 computes a different encryption B 2 = ε ek (β), and sends this one to the phone P1 as well. The server P2 then proves to the phone P1 that (ek, B 1 ) is correctly formed, and B 1 and B 2 encrypt the same plaintext. The proof of equality of plaintexts must make use of the random oracle H somehow. The phone P1 may sign (ek, B 1 , B 2 ); let σ be the signature.

[0122] Without wishing to be bound by theory, a Paillier cryptosystem, or a Damgård-Jurik cryptosystem, may for example be used. Both Paillier cryptosystems, and Damgård-Jurik cryptosystems, are homomorphic. See, for example, Damgård [Ivan Damgård, Nelly Fazio, Antonio Nicolosi: "Non-interactive Zero-Knowledge from Homomorphic Encryption". Proceedings of the Theory of Cryptography Conference (TCC) 2006: 41-59, Sec. 6].

[0123] As a result, the entire public key is (svk, pk, ek, B 1 , B 2 , σ). The phone P1 holds the private value sk 1 . The server P2 holds the private values sk 2 , vk, β.

[0124] During the Encryption phase, the random number r ∈ ℤ p is generated and then used in both the first element u and second element c of the ciphertext (u, c, π). The third element π of the ciphertext is used to prove to both P1 and P2 that the same randomly generated r was used in the first and second elements of the ciphertext. The verification of π by either P1 or P2 provides protection from CCA, which rely on c being handpicked by the attacker. Once P1 has conducted initial checks on the original ciphertext, the decryption protocol of Equation j may be initiated.

[0125] The roles of our two parties are not identical: it is the phone P1 that initially obtains the ciphertext, and decides, when to decrypt it. For decryption, it requests the help of the assisting server P2. But when the phone P1 initially receives the ciphertext, it can already perform some checks on it, and forget some of the components of the ciphertext that are later not used in the decryption protocol.

[0126] Given a public key (svk, pk, ek, B 1 , B 2 , σ), and a message m ∈ {0, 1} ℓ< , perform the steps in the pseudocode shown in Equation e. In this algorithm, all values randomly generated from the sets I(k) for various bit-lengths k are thought of as integers, and the computations with them do not wrap around (wrap-arounds are explicit, using the mod operation). In Equation e, the outputs u and c are the ciphertext from the EIGamal encryption scheme. The outputs α 1 , Γ 1 and Γ 2 are the DVNIZK proof for the assisting server P2, that someone knows the discrete logarithm of u. The value h' makes this DVNIZK have simulatable exponents. The rest of the ciphertext is a NIZK proof (i.e. verifiable by anyone) that α 1 , Γ 1 , Γ 2 constitute this DVNIZK proof, and α 1 ′ , h ′ make it have simulatable exponents. Presenting this proof amounts to showing that the encryptor knows the values r 0 and r 1 , such that u = g r0< , h' = (g') r0< , g r 1 = α 1 , g ′ r 1 = α 1 ′ , and ε ek r 1 ⋅ B i r 0 = Γ i , where i ∈ {1,2}.

[0127] The NIZK proof is generated by picking random r 2 and r 3 for hiding the values r 0 and r 1 , committing to them by giving the values α 3 , α 3 ′ and A 2 , and showing that their random linear combinations work as expected.

[0128] When the phone P1 receives the ciphertext, it can immediately check the NIZK proof that the DVNIZK proof is a good proof. The pseudocode in Equation f shows how the check is done. The algorithm returns only these components of the ciphertext that are needed for decryption according to Equation j.

[0129] The use of the DVNIZK proofs (α 1 , Γ 1 , Γ 2 ) is not the only manner in which proofs of knowledge of the exponent r can be malleated and privacy for P1 can be obtained. By introducing more complex cryptographic primitives, such as bilinear pairings, NIZK proofs can be malleated even without the need to designate a particular verifier.

[0130] In the bilinear pairings setting, three cyclic groups G 1 , G 2 , G T of the same size p are used at the same time, where the decisional Diffie-Hellman problem is difficult in each group. In addition to the usual group operations in the three groups, there must exist an operation e that takes two arguments - one from G 1 and one from G 2 - and returns an element of G T . This operation e must be bilinear, i.e. for all elements g 1 and g 2 of G 1 , elements h 1 and h 2 of G 2 , and numbers x (in ℤ p ), it must satisfy e g 1 ⋅ g 2 x , h 1 = e g 1 h 1 ⋅ e g 2 h 1 x , and e g 1 , h 1 ⋅ h 2 x , = e g 1 h 1 ⋅ e g 1 h 2 x . Also, the operation e must be non-degenerate, meaning that there should exist inputs, where the output of e is not the unit element of G T . For example, the elements of the groups G 1 , G 2 may be points on related elliptic curves, while G T is a subgroup of the multiplicative group of a finite field. Without wishing to be bound by theory, Weil pairings, or Tate pairings, both of which involve elliptical curves usually over finite fields, may for example be used.

[0131] Groth-Sahai proofs [see Jens Groth and Amit Sahai: "Efficient non-interactive proof systems for bilinear groups". EUROCRYPT 2008 proceedings, pages 415-432] are an example framework for constructing NIZK proofs about knowing the multiplicative relationships between elements of groups G 1 , G 2 , G T . Groth-Sahai proofs are malleable with respect to certain operations [see Melissa Chase, Markulf Kohlweiss, Anna Lysyanskaya, and Sarah Meiklejohn: "Malleable proof systems and applications". EUROCRYPT 2012 proceedings, pages 281-300]. For example, given a set of elements of G 1 , G 2 , G T and a Groth-Sahai proof that these elements are in a certain relationship and / or the prover knows certain exponents that relate these elements, it is possible to introduce additional elements with certain relationships to existing ones, and perhaps remove some of the existing elements, and then modify the Groth-Sahai proof so that it also proves the relationships that hold for the newly introduced elements.

[0132] Taking the scheme whose decryption process is described in Fig. 4, we could use group G 1 as the underlying group of that scheme. In this case, we could use in place of the NIZK proof π (Equation i) a Groth-Sahai proof that someone knows the discrete logarithm of u. It is now possible for the party P1 to replace u with some u' = u z< for a random z (as in Equation j), and also change π into π', such that the latter proves that someone knows the discrete logarithm of u'. Party P1 will then ask party P2 to apply the secret key share sk 2 onto u', including π' in its request (instead of α 1 ′ , Γ 1 ′ , Γ 2 ′ ). Party P2 verifies π' against u'.

[0133] The details of Groth-Sahai proofs and their malleability will now be described and applied to the use case of blinding a ciphertext. Let g be the generator of G 1 , and h be the generator of G 2 . Groth-Sahai proofs make use of a Common Reference String (CRS), which must have been generated beforehand by a trusted party, and may be shared by all instances of Groth-Sahai proofs. In this case, the CRS consists of elements of G 2 , such that (h, ) is a Diffie-Hellman tuple, i.e. log h = . When the party performing the encryption has computed u = g r< , 1. Generate random element s of ℤ p 2. Let d 1 = · h s< 3. Let d 2 = 4. Let T = g s< 5. The proof π is (d 1 , d 2 , T). We see that d 1 , d 2 are elements of G 2 , while T is an element of G 1

[0134] In order to verify π (with respect to u), the verifier performs the following checks: 1. Check that e(g, d 1 ) = e(u, ) · e(T, h) 2. Check that e(g, d 2 ) = e(u, ) . e(T,)

[0135] When party P1 wants to blind the value u and the proof π = (d 1 , d 2 , T), it will generate random elements z,y of ℤ p , and perform the following computations: 1. Let u' = u z< 2. Let d 1 ′ = d 1 z ⋅ h y 3. Let d 2 ′ = d 2 z ⋅ Q y 4. Let T' = T z< · g y<

[0136] Now u' is the blinded value, and d 1 ′ , d 2 ′ , T ′ the blinded proof. The blinded proof is verified by performing exactly the same checks as for the original proof.

[0137] Turning finally to Figure 6, Figure 6 shows a schematic and simplified representation of a computer apparatus 600 which can be used to perform methods described herein, either alone, in combination with other computer apparatuses or as part of a network or a "cloud" computing arrangement.

[0138] The computer apparatus 600 comprises various data processing resources such as a processor 602 (in particular, a hardware processor) coupled to a central bus structure. Also connected to the bus structure are further data processing resources such as memory 604. A display adapter 606 connects a display device 608 to the bus structure. One or more user-input device adapters 610 connect a user-input device 612, such as a keyboard and / or a mouse to the bus structure. One or more communications adapters 614 are also connected to the bus structure to provide connections to other computer systems 600 and other networks.

[0139] In operation, the processor 602 of computer system 600 executes a computer program comprising computer-executable instructions that may be stored in memory 604. When executed, the computer-executable instructions may cause the computer system 600 to perform one or more of the methods described herein. The results of the processing performed may be displayed to a user via the display adapter 606 and display device 608. User inputs for controlling the operation of the computer system 600 may be received via the user-input device adapters 610 from the user-input devices 612.

[0140] It will be apparent that some features of computer system 600 shown in Figure 6 may be absent in certain cases. For example, one or more of the plurality of computer apparatuses 600 may have no need for display adapter 606 or display device 608. This may be the case, for example, for particular server-side computer apparatuses 600 which are used only for their processing capabilities and do not need to display information to users. Similarly, user input device adapter 610 and user input device 612 may not be required. In its simplest form, computer apparatus 600 comprises processor 602 and memory 604.

[0141] The above detailed description describes a variety of example arrangements for and methods of performing distributed decryption. However, the described arrangements and methods are merely exemplary, and it will be appreciated by a person skilled in the art that various modifications can be made without departing from the scope of the appended claims.

[0142] More generally, it should be appreciated that the number of steps shown in the figures is not intended to be limiting. Steps may be repeated as often as necessary and certain steps may be omitted.

[0143] The computer apparatus discussed above may be a local computer or a server.

[0144] While various specific combinations of components and method steps have been described, these are merely examples. Components and method steps may be combined in any suitable arrangement or combination. Components and method steps may also be omitted to leave any suitable combination of components or method steps.

[0145] The described methods may be implemented using computer executable instructions. A computer program product or computer readable medium may comprise or store the computer executable instructions. The computer program product or computer readable medium may comprise a hard disk drive, a flash memory, a read-only memory (ROM), a CD, a DVD, a cache, a random-access memory (RAM) and / or any other storage media in which information

[0146] is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and / or for caching of the information). A computer program may comprise the computer executable instructions. The computer readable medium may be a tangible or non-transitory computer readable medium. The term "computer readable" encompasses "machine readable".

[0147] In an implementation, the modules, components and other features described herein can be implemented as discrete components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices.

[0148] The singular terms "a" and "an" should not be taken to mean "one and only one". Rather, they should be taken to mean "at least one" or "one or more" unless stated otherwise. The word "comprising" and its derivatives including "comprises" and "comprise" include each of the stated features, but does not exclude the inclusion of one or more further features.

[0149] The above implementations have been described by way of example only, and the described implementations are to be considered in all respects only as illustrative and not restrictive. It will be appreciated that variations of the described implementations may be made without departing from the scope of the disclosure. It will also be apparent that there are many variations that have not been described, but that fall within the scope of the appended claims.

Claims

1. A computer-implemented method for distributed asymmetric decryption between a first party (110) and a second party (120), each of the first and second parties holding a different respective share of a secret key, the method comprising: receiving, at the second party: (i) a zero-knowledge proof of knowledge; and (ii) a plurality of inputs associated with a ciphertext to be decrypted, wherein the ciphertext is encrypted with a public key associated with the secret key; checking, by the second party, that the zero-knowledge proof of knowledge was generated based on the first party's share of the secret key; and in response to determining that the zero-knowledge proof of knowledge was generated based on the first party's share of the secret key, sending, by the second party, information derived from the second party's share of the secret key; wherein the ciphertext comprises at least three elements: a first element, comprising a generator of a cyclic group raised to the power of a randomly generated number within the size of the cyclic group; a second element, comprising an encryption of a plaintext based on the public key, a hashing function, and the randomly generated number; a third element, comprising a non-interactive zero-knowledge proof of knowledge which is based on the randomly generated number; and wherein the plurality of inputs associated with the ciphertext received at the second party comprise: a blinded version of the first element of the ciphertext, the blinded version obtained by secretly picking and applying an exponent to mask the first element of the ciphertext; and a blinded proof obtained by malleating the non-interactive zero-knowledge proof of knowledge in the third element of the ciphertext.

2. The method of claim 1, wherein the information derived from the second party's share of the secret key is calculated by applying the second party's share of the secret key to an element of the ciphertext.

3. The method of claim 1, further comprising: checking, at the second party, that the non-interactive zero-knowledge proof of knowledge pertains to the same randomly generated number as the first element and the second element of the ciphertext.

4. The method of claim 3, wherein the non-interactive zero-knowledge proof of knowledge comprises: a first value (α) based on the generator of the cyclic group and the randomly generated number; and a second value (γ) based at least on the randomly generated number, a random hashing function, the generator of the cyclic group, the first value (α), and the first element of the ciphertext; and wherein checking that the non-interactive zero-knowledge proof of knowledge pertains to the same randomly generated number as the first element and the second element of the ciphertext optionally comprises: computing, at the second party, a third value (β) by inputting: (i) the generator of the cyclic group, (ii) the first element of the ciphertext, (iii) the first value (α), and (iv) the second element of the ciphertext, into a random hashing function; checking whether the generator of the cyclic group raised to the power of the second value (γ) equals a value obtained by multiplying the first value (α) by the first element of the ciphertext raised to the power of the computed third value (β).

5. The method of claim 1, wherein malleating the proof in the third element of the ciphertext comprises secretly picking and applying one or more exponents to mask components of the proof; and / or wherein the blinded proof is a designated-verifier non-interactive zero-knowledge proof of knowledge, which is malleated using a proof creation key and can only be verified using a proof verification key paired with the proof creation key; and the second party holds the proof verification key paired with the proof creation key; the method optionally further comprising verifying, at the second party, the blinded proof.

6. A network device (second party) configured for performing distributed asymmetric decryption with a client device (first party) holding a first share of a secret key, the network device comprising a memory storing a second share of the secret key, and being configured to perform a method according to any of claim 1 to 5.

7. A computer-implemented method for distributed asymmetric decryption between a first party (110) and a second party (120), each of the first and second parties holding a different respective share of a secret key, the method comprising: generating, by the first party, a zero-knowledge proof of knowledge based on the first party's share of the secret key; sending, by the first party: (i) the zero-knowledge proof of knowledge; and (ii) a plurality of inputs associated with a ciphertext to be decrypted, wherein the ciphertext is encrypted with a public key associated with the secret key; receiving, at the first party, information derived from the second party's share of the secret key; and generating, by the first party, a decryption of the ciphertext using the first party's share of the secret key and the received information; wherein the ciphertext comprises at least three elements: a first element, comprising a generator of the cyclic group raised to the power of a randomly generated number within the size of the cyclic group; a second element, comprising an encryption of a plaintext based on the public key, a hashing function, and the randomly generated number; a third element, comprising a non-interactive zero-knowledge proof of knowledge which is based on the randomly generated number; and wherein the plurality of inputs associated with the ciphertext sent by the first party comprise: a blinded version of the first element of the ciphertext, the blinded version obtained by secretly picking and applying an exponent to mask the first element of the ciphertext; and a blinded proof obtained by malleating the non-interactive zero-knowledge proof of knowledge in the third element of the ciphertext.

8. The method of claim 7, further comprising: generating a first party share of the public key based on the first party's share of the secret key; using the first party share of the public key to generate the zero-knowledge proof of knowledge; and destroying the first party's share of the public key after use.

9. The method of claim 7 or claim 8, wherein the first party's share of the public key is generated responsive to receiving a request to decrypt the ciphertext and is destroyed after use.

10. The method according to any of claims 7 to 9, wherein generating the zero-knowledge proof of knowledge based on the first party's share of the secret key comprises generating two or more randomized values based on a generator of a cyclic group, the first party's share of the secret key, and the first party's share of the public key, using a randomly generated number and a random hashing function.

11. The method of claim 7, wherein malleating the proof in the third element of the ciphertext comprises secretly picking and applying one or more exponents to mask components of the proof; and / or wherein the blinded proof is a designated-verifier non-interactive zero-knowledge proof of knowledge, which is malleated using a proof creation key and can only be verified using a proof verification key paired with the proof creation key; and the second party holds the proof verification key paired with the proof creation key; wherein the method further comprises verifying, at the second party, the blinded proof.

12. A client device "first party" (110) configured for performing distributed asymmetric decryption with a network device "second party" (120) holding a second share of a secret key, the client device comprising a memory storing a first share of the secret key, and being configured to perform a method according to any of claims 7 to 11.

13. A computer readable medium (114 / 124) having instructions stored thereon which when executed by a processor (112 / 122) cause the processor to perform a method according to any of claims 1 to 5 or a method according to any of claims 7 to 11.