GROUP ENCRYPTION METHODS AND DEVICES

Abstract

The present invention improves on prior art group encryption schemes by encrypting an alias of a recipient's public key instead of the public key itself. A Group Manager publishes the encryption of the alias,the corresponding public key and a corresponding certificate on a public database DB. The alias is a resulting value of a suitably chosen function ƒ on the public key, and can be viewed as a hash of the public key. This can allow a significant decrease in the size and cost of the resulting construction as the alias can be made smaller than the public key. In particular, there is no need to apply the second encryption scheme as many times as there are group dements in the recipient's public key.

Description

TECHNICAL FIELD

The present invention relates generally to cryptography, and in particular to group encryption.

BACKGROUND

This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.

In this section, the group encryption primitive is defined, the necessary building blocks public key encryption, tag-based encryption, and one-time signatures are presented, and the state-of-the-art in group encryption is described.

Group encryption was introduced by Kiayias-Tsiounis-Yung as an encryption analogue of group signature; see Aggelos Kiayias, Yiannis Tsiounis, and Moti Yung: “Group Encryption”, ASIACRYPT 2007: pp. 181-199. Group encryption is useful in situations where it is desired to conceal a recipient (decryptor) within a group of legitimate users.

An illustrative example is a network service provider (NSP) that wants to send certain ads to a subscribed customer whose profile matches the ads to be sent. At the same time, the NSP wants to prove to its client, i.e. the company that pays the NSP for sending the ads, that it did indeed send the ads in question within his group of subscribers, while keeping the exact identity of the recipient a secret. The privacy of the ad's recipient should also be preserved within the group of the NSP's subscribers.

Group encryption constitutes a plausible solution to this problem as it allows a sender (the NSP in the example) to encrypt a message (the ad) for a targeted user, and additionally makes it possible for a verifier to check that the formed ciphertext is valid (e.g. that the corresponding plaintext satisfies some relation) and that some anonymous member from the subscribers's group is able to decrypt it. Group encryption also supports the functionality of opening the ciphertext and recovering down the recipient's identity in case of disputes by a designated authority.

More formally, a group encryption (GE) scheme involves a group manager (GM) who registers group members, and an opening authority (OA) that is capable of recovering the identity of the recipient from the corresponding ciphertext.

The main procedures that underlay a GE scheme are:

• • Join. An interactive protocol between the GM and a potential group member. The GM issues a certificate cert_i on the group member's public key pk. The GM further stores the pair (pk,cert) in a public database DB.
  • Encrypt. Produces a ciphertext c on an input message m under a targeted group member's public key pk with regard to an input tag t, which is a binary string that specifies the context of the encryption. In order to prevent sending bogus messages, it is required that the message m to be encrypted satisfies some a priori relation: m is a “witness” of an “instance” x (public value) with respect to a relation R; i.e. (m,x)∈ R. In this sense, Encrypt also outputs the instance x corresponding to the encrypted witness.
  • Decrypt. Recovers the message m encrypted in an input ciphertext c with regard to the input tag t using a private key sk corresponding to the public key pk under which the ciphertext was created. The procedure further checks whether the recovered message is a witness of the input instance x, i.e (m,x)∈ R. If this is the case, then the algorithm outputs m, otherwise it outputs Fail.
  • Open. Inputs a ciphertext c, a tag t, and the private key of the OA, and recovers the public key pk under which the ciphertext was created with regard to the input tag t.
  • Prove. Provides proof, interactive or non-interactive, from the entity that creates a ciphertext to any verifier. The verifier should be convinced that the ciphertext in question is valid (for instance, that the underlying message satisfies the relation R) and that it can be decrypted by some anonymous registered group member.

A public key encryption (PKE) scheme comprises a key generation algorithm that generates pairs of the form (public key, private key), an encryption algorithm which produces an encryption of an input message using the public key of the recipient, and a decryption algorithm which recovers the message encrypted in an input ciphertext using the proper private key.

A tag-based encryption scheme (TBE) further requires an additional argument, a tag, for both the encryption and decryption. Informally, a tag is a binary string of appropriate length which specifies information about the encryption (date, context, etc . . . ).

One-time digital signature schemes can be used to sign, at most, one message; otherwise, signatures can be forged. A new public key is required for each message that is signed. They are, like ‘normal’ digital signatures, defined by the key generation algorithm, the signing algorithm, and the verification algorithm. The security of one-time signature schemes relies on the difficulty, given a public key, to come up with a new valid pair of message and corresponding signature.

The paper by Kiayias-Tsiounis-Yung mentioned hereinbefore provides a generic construction for a secure Group Encryption scheme that uses a digital signature scheme S for certification of the users public keys, a tag-based encryption scheme E₁ for encrypting the message, another tag-based encrypting scheme E₂ for encrypting the recipient public key, and a commitment scheme for committing to the used key and to its certificate. In more detail, the scheme works as follows:

• • Join. The GM produces a signature s (in other words a certificate) on the user's public key pk using its private signing key S.sk. The GM further stores (pk,s) in the public database DB.
  • Encrypt_{pk}(m,t). To encrypt a message m (such that (m,x)∈ R, where x is a public value) for a recipient with public key pk with regard to a tag t, Alice:
    • creates commitments c₃ on pk and c₄ on the certificate,
    • encrypts pk with regard to a tag (t,c₃,c₄) under public key pk_OA of the opening authority using E₂.Encrypt, giving a result c₂,
    • encrypts m with regard to a tag (t,c₂,c₃,c₄) under the public key pk using E₁.Encrypt, giving a result c₁,
    • returns the tuple (c₁,c₂,c₃,c₄) as a group encryption of m under pk with regard to t.
  • Decrypt_{sk}(c,t,x). First parses c as (c₁,c₂,c₃,c₄), then calls E₁.Decrypt on c₁ and (t, c₂,c₃,c₄) using the private key sk and returns the result, say m, if (m,x)∈ R and “fail” otherwise.
  • Open_{skOA}(c,t). First parses c as (c₁,c₂,c₃,c₄), then calls E₂.Decrypt on c₂ and (t,c₃,c₄) using the private key of the OA sk_OA and returns the result.
  • Prove(c,t,x). Alice, the entity that created the ciphertext c=(c₁,c₂,c₃,c₄), with regard to the tag t provides a proof that the ciphertext is valid and can be decrypted by the private key corresponding to the public key, encrypted in c₂, and committed to in c₃ whose certificate is committed to in c₄. Alice further proves that the message underlying the ciphertext is a witness for x with regard to the public relation R. Alice uses the private coins (i.e. random values used to generate the commitments c₃ and c₄, and the encryptions c₁ and c₂) used to generate c in order to provide the proof hereinbefore.

Cathalo-Libert-Yung has provided a concrete realization of a Group Encryption scheme, see Julien Cathalo, Benoît Libert, Moti Yung: “Group Encryption: Non-interactive Realization in the Standard Model”, ASIACRYPT 2009: pp. 179-196. The scheme uses Shacham's encryption scheme [see Hovav Shacham: “A Cramer-Shoup Encryption Scheme from the Linear Assumption and from Progressively Weaker Linear Variants”, Cryptology ePrint Archive, Report 2007/074] for encrypting the message, and Kiltz' encryption [see Eike Kiltz: “Chosen-Ciphertext Security from Tag-Based Encryption”, TCC 2006: pp. 581-600] for encrypting the public key of the recipient. The solution departs from the construction provided by Kiayias-Tsiounis-Yung by waiving the commitments c₃ and c₄ to the proof underlying the Prove procedure.

More precisely, if S refers to a digital signature scheme given in the paper, OTS refers to any secure one-signature scheme, [Kiltz] refers to Kiltz's encryption scheme and [Shacham] refers to Shacham's encryption scheme, the scheme is defined by:

• • Join On an input public key pk, the GM produces a signature (or a certificate) using its private signing key S.sk and stores (pk,cert) in a public database DB.
  • Encrypt_{pk}(m,t) To encrypt a message m (where m is the Diffie-Hellman solution of some (x,y): e(m,g)=e(x,y), where e is the pairing underling the message space, say G, and g is a generator of this group) for a recipient with public key pk with regard to a tag t, Alice:
    • calls OTS.keygen to generate a pair of signing and verifying keys (OTS.sk,OTS.vk).
    • creates c₁=[Schacham].Encrypt_{pk}(m,(OTS.vk,t)) and c₂=[Kiltz].Encrypt_{pkOA}(pk,OTS.vk). The tag used for c₁ is (OTS.vk,t) and the tag used for c₂ is the verification key OTS.sk.
    • produces a one-time signature s on (c₁,c₂,t) using OTS.sk; s=OTS.Sign_{OTS,sk}(c₁,c₂,t).
    • returns c=(c₁,c₂,OTS.vk,s) as a group encryption of m under pk with regard to t.
  • Decrypt_{sk}(c,t,x,y)
    • parse c as (c₁,c₂,OTS.vk,s).
    • check the signature s on (c₁,c₂,t) with regard to OTS.vk; if OTS.Verify_{OTS.vk}(s,(c₁,c₂,t))=0 return Fail, else compute [Shacham].Decrypt_{sk}(c₁,(OTS.vk,t): return the computed value if it is the Diffie-Hellman solution for (x,y), otherwise return Fail.
  • Open_{skOA}(c,t)
    • parse c as (c₁,c₂, OTS.vk, s).
    • check the signature s on (c₁,c₂,t) with regard to OTS.vk; if OTS.Verify_{OTS.vk}(s,(c₁,c₂,t)=0 return Fail, else call [Kiltz].Decrypt_{skOA}(c₂,OTS.vk) and return its result.
  • Prove(c,t,x,y). Alice, the entity that created the ciphertext c with regard to the tag t provides a non-interactive proof that c is well formed, and that it can be decrypted by some anonymous member that has a certified public key.

The schemes provided by Kiayias-Tsiounis-Yung and Cathalo-Libert-Yung achieve secure Group Encryption by instantiating the construction with encryption schemes that satisfy the strong security notions (i.e. encryption schemes that are secure against powerful adversaries). According to the used building blocks, the resulting realizations compare as follows:

• • 1. Kiayias-Tsiounis-Yung: their instantiation of the generic construction achieves a ciphertext of size 2.5 kB using 1024-bit moduli, and a proof of size 70 kB. Moreover, the proof entails interaction with the verifier, and thus requires the prover to remember all the randomness used to generate the ciphertext if she wants to run several times the same proof.
  • 2. Cathalo-Libert-Yung improves upon the above scheme; it achieves a smaller ciphertext, 1.25 kB using 256-bit moduli, and a smaller proof, 16.125 kB. Moreover, the proof has the merit of being non-interactive and thus does not require a stateful prover. However, the proof makes use of the expensive Groth-Sahai proof system which requires hundreds or thousands of pairing equations verifications that render it fairly impractical.

The skilled person will thus realise that both Kiayias-Tsiounis-Yung and Cathalo-Libert-Yung remain rather expensive due to the size or cost of the ciphertext and the proof.

For instance, both Kiayias-Tsiounis-Yung and Cathalo-Libert-Yung resort to encrypting each component of the public key—the public key always consists of a vector of group elements—and as a consequence apply the same expensive (in terms of resource use) encryption (“E₂” or [Kiltz]) n times, where n denotes the number of elements in the public key of the recipient.

The skilled person will appreciate that there is a need for a solution that provides an improved GE scheme. This invention provides such a solution.

SUMMARY OF INVENTION

In a first aspect, the invention is directed to a method of group encrypting a plaintext m with regard to a tag t for a recipient with a public key pk to obtain a ciphertext c. A device obtains a signing key OTS.sk and a verifying key OTS.vk; creates a first encrypted value c₁ and a second encrypted value c₂, by calculating c₁=E₁.Encrypt_{pk}(m,OTS.vk) and c₂=E₂.Encrypt_{pkOA}(f(Pk),OTS.vk), wherein E₁ is a first encryption algorithm, E₂ is a second encryption algorithm and ƒ is a mapping function; produces a signature s on the first encrypted value the second encrypted value c₂ and the tag t using the signing key OTS.sk by calculating s=OTS.Sign_{OTS.sk}(c₁,c₂,t), wherein OTS.Sign is a signature algorithm; and outputs the ciphertext c, wherein the ciphertext c comprises the first encrypted value c₁, the second encrypted value c₂, the verifying key OTS.vk and the signature s.

In a first preferred embodiment, the message m satisfies a publicly verifiable relation R.

In a second aspect, the invention is directed to a method of decrypting a group encryption c comprising a first encrypted value c₁, a second encrypted value c₂, a verifying key OTS.vk and a signature s, wherein the signature s is on the first encrypted value c₁, the second encrypted value c₂ and a tag t. A device receives the group encryption c; verifies the signature s with regard to a verifying key OTS.vk; and if the signature s is successfully verified, decrypts the first encrypted value c₁ using an decryption algorithm E₁ and the verifying key OTS.vk.

In a first preferred embodiment, verifying the signature further comprises verifying that a decryption of the first encrypted value c₁ satisfies a public relation R.

In a third aspect, the invention is directed to a device for group encrypting of a plaintext m with regard to a tag t for a recipient with a public key pk to obtain a ciphertext c. The device comprises a processor configured to: obtain a signing key OTS.sk and a verifying key OTS.vk; create a first encrypted value c₁ and a second encrypted value c₂, by calculating c₁=E₁.Encrypt_{pk}(m,OTS.vk) and c₂=E₂.EncryPt_{pkOA} (f(pk),OTS.vk), wherein E₁ is a first encryption algorithm, E₂ is a second encryption algorithm and ƒ is a mapping function; produce a signature s on the first commitment c₁, the second commitment c₂ and the tag t using the signing key OTS.sk by calculating s=OTS.Sign_{OTS.sk}(c₁,c₂,t), wherein OTS.Sign is a signature algorithm; and output the ciphertext c, wherein the ciphertext c comprises the first encrypted value c₁, the second encrypted value c₂, the verifying key OTS.vk and the signature s.

In a first preferred embodiment, the message m satisfies a publicly verifiable relation R.

In a fourth aspect, the invention is directed to a device for decrypting a group encryption c comprising a first encrypted value c₁, a second encrypted value c₂, a verifying key OTS.vk and a signature s, wherein the signature s is on the first encrypted value the second encrypted value c₂ and a tag t. The device comprises a processor configured to: receive the group encryption c; verify the signature s with regard to a verifying key OTS.vk; and if the signature s is successfully verified, decrypt the first encrypted value c₁ using an decryption algorithm E₁ and the verifying key OTS.vk.

In a first preferred embodiment, the processor further verifies that a decryption of the first encrypted value c₁ satisfies a public relation R.

In a fifth aspect, the invention is directed to a computer program product having stored thereon instructions that, when executed by a processor, perform the method of the first aspect.

In a sixth aspect, the invention is directed to a computer program product having stored thereon instructions that, when executed by a processor, perform the method of the second aspect.

BRIEF DESCRIPTION OF DRAWINGS

Preferred features of the present invention will now be described, by way of non-limiting example, with reference to the accompanying drawings, in which:

FIG. 1 illustrates a Group Encryption system according to a preferred embodiment of the invention.

DESCRIPTION OF EMBODIMENTS

A main inventive idea of the present invention is to encrypt an alias of the recipient's public key instead of the public key itself. The Group Manager (GM) publishes the public key, the corresponding encryption of the alias and certificate in the public database DB. The alias is a resulting value of a suitably chosen mapping function ƒ applied on the public key.

Calculations using the function ƒ are preferably easy to perform, the function preferably reduces the size of the input, and two different input values should not result in identical entries in the database DB. The mapping function ƒ may be said to be a sort of hash function that is collision resistant by having the group manager ensures this property by, for example, randomizing a new message until its entry in the database is unique.

This can allow a significant decrease in the size and cost of the resulting construction as the alias can be made smaller than the public key. In particular, there is no need to apply the second encryption scheme as many times as there are group elements in the recipient's public key.

However a drawback is that, in the Open procedure, the opening authority OA is required to look in the database DB for the preimage (public key) of the alias. Fortunately, the recourse to the Open procedure occurs very rarely; i.e. only in case of disputes.

The Group Encryption scheme of the present invention uses a number of building blocks (examples will be given later in the description):

• • Encryption schemes: two encryption schemes E₁ and E₂ are used. It has to be noted that for the purpose of the invention, it is sufficient that E₁ and E₂ are weakly secured, as defined below:
    • A weakly secure encryption scheme is one that does not reach the “highest” security notion. The correct security notion for E₁ is indistinguishable and anonymous under selective tag weak chosen ciphertext attacks (IND-st-wCCA and ANO-st-wCCA). For E₂ only IND-st-wCCA security is required.
    • Both security notions combine a security goal (IND or ANO) and an attack model (st-wCCA).
    • The indistinguishability (IND) goal informally denotes the difficulty to get information about the message from the ciphertext. Anonymity (ANO) refers to the difficulty to infer information about the public key from the ciphertext.
    • Concerning the attack model st-wCCA, it refers to the scenario where the attacker commits beforehand (before receiving the challenge public key) to the tag she wishes to be challenged on, and she is not allowed to issue decryption queries which involve this challenge tag.
  • Signature or certification schemes: a signature scheme that signs group elements is used. A suitable candidate is a structure-preserving signature scheme S, i.e. a scheme where the verification key, messages, and signatures are group elements, and where the verification algorithm consist of a predicate of pairing equation verifications.
  • One-time signature schemes: a secure one-time signature OTS is used.
  • Relation R: a relation that is publicly verifiable is used.
    • Function ƒ: a function ƒ which is efficiently computable (can be evaluated in polynomial time in the size of the input) is used.
    • Using these building blocks, the scheme is constructed as follows:
  • Join. On an input public key pk, GM computes f(pk) in addition to a signature (or a certificate) cert on pk using S.sk (S is the used certification scheme). GM further stores (pk,f(pk),cert) in a public database DB. Note that GM may proceed to simple measures in order to avoid collisions, i.e. avoid that two different public keys pk and pk′ map to the same value using f. One possible measure in case a particular function ƒ is used will be detailed hereinafter.
  • Encrypt_{pk}(m,t). To encrypt a message m (which is a witness of some x with regard to a known relation R) for a recipient with public key pk with regard to a tag t, an entity:
    • Calls OTS.keygen to generate a pair of signing and verifying keys (OTS.sk, OTS.vk).
    • Creates (c₁,c₂)=(E₁.Encrypt_{pk}(m,OTS.vk), E₂.Encrypt_{pkOA} (f(pk),OTS.vk)). It will be noted that OTS.vk is considered as a tag.
    • Produces a signature s on (c₁,c₂,t) using OTS.sk; s=OTS.Sign_{OTS.sk}(c₁,c₂,t).
    • Return c=(c₁,c₂,OTS.vk,s) as a group encryption of m under pk with regard to t.
  • Decrypt_{sk}(c,t,x).
    • Parse c as (c₁,c₂,OTS.vk,s).
    • Verify the signature s on (c₁,c₂,t) with regard to OTS.vk. If OTS.Verify_{OTS.vk}(s,(c₁,c₂,t))=0 return Fail, else compute E₁.DecryPt_{sk}(c₁, OTS.vk): return the computed value if it is a witness for x with regard to R, otherwise return Fail.
  • Open_{skOA}(c,t).
    • Parse c as (c₁,c₂,OTS.vk,s).
    • Verify the signature s on (c₁,c₂,t) with regard to OTS.vk. If OTS.Verify_{OTS.vk}(s,(c₁,c₂,t)=0 return Fail, else call E₂.Decrypt_{skOA}(c₂, OTS.vk) which returns a value F.
    • Look up DB for the preimage of the value F with regard to the function ƒ, and return the result of this search.
  • Prove(c,t,x). The entity that created the ciphertext c with regard to the tag t provides the following proofs using the random coins used to generate c=(c₁,c₂,OTS.vk,s):
    • Proof of knowledge of the message underlying c₁ with regard to tag OTS.vk under some public key pk and that this message is a witness for x with regard to the relation R.
    • Proof of knowledge of the decryption of c₂ with regard to tag OTS.vk under the key pk_OA and that this decryption is the value of the function ƒ on pk.
    • Proof of knowledge of a certificate cert on pk.

Certain classes of signature and encryption schemes allow an efficient performance of these proofs.

For non-interactive proofs, it is preferred to use components that accept efficient non-interactive proofs of knowledge of the witness in question (e.g. message or key in case of signature/encryption schemes, preimage in case of the function ƒ or witness in case of the relation R) such as Groth-Sahai [Jens Groth, Amit Sahai: Efficient Non-interactive Proof Systems for Bilinear Groups. EUROCRYPT 2008: 415-432] compatible cryptosystems. In this sense, one can use the so-called automorphic signatures (i.e. signature schemes where the verification key message and resulting signature are group elements and where the verification algorithm consists of a conjunction of pairing product equations) and encryption schemes where the encryption algorithm performs group or pairing operations on the input (this entails that the message, public key and ciphertext are group elements). The function ƒ also performs group (or pairing in case of bilinear groups) operations on the input. The same thing applies for the relation R.

Similarly, it is preferred to use components that accept efficient interactive proofs of the witness. In this sense, it is preferred to use signature schemes that make it possible to define a homomorphic function cp, given a signature σ on a message M, such that φ(S,M) evaluates to g(R,vk) where vk is the verification key, g is a public function, and (S,R) is a pair converted from a where R reveals no information about σ or M, and S is a “vital” part of the signature; the underlying conversion algorithm is referred to as the CONVERT algorithm. It is also preferred to use encryption schemes that accept efficient proofs of correctness of a decryption with regard to a given key and a given tag. Moreover, the scheme used to encrypt the public key (E₂) should be homomorphic with regard to the message and the scheme E₁ should be homomorphic with regard to both the public key and the message. Further, encryption scheme E₁ comes with an algorithm, referred to as the COMPUTE algorithm, which on input an encryption c₁ of a message m under a public key pk with respect to a given tag t produces another encryption c′₁ of another message m′ under another public key pk′ with respect to the same tag t such that the composition of c₁ and c′₁ is equal to the encryption of the composition of m and m′ under the composition of pk and pk′ with respect to tag t; wherein composition has to be understood as applying the algebraic group operation equipping the set the involved elements belong to. Moreover, the function ƒ is preferably a homomorphic function (f applied to the composition of two inputs is the composition of the values of ƒ at these two inputs). And similarly, the relation R should allow, given an instance x, to define a homorphic function F_R and an image I such that F_R(w)=I, where w is the witness corresponding to the instance x.

A preferred signature scheme for use with the present invention is the scheme proposed by Masayuki Abe, Georg Fuchsbauer, Jens Groth, Kristiyan Haralambiev and Miyako Ohkubo in “Structure-Preserving Signatures and Commitments to Group Elements”; CRYPTO 2010: 209-236.

A preferred encryption scheme for use with the present invention is the weakly secure tag-based variant provided by David Cash, Eike Kiltz and Victor Shoup in “The Twin Diffie-Hellman Problem and Applications”; Journal of Cryptology 22(4): 470-504 (2009).

A preferred function ƒ, if the public keys are n-vectors of group elements, is the following:

f: Gⁿ→G

• • (X₁, . . . , X_n)→X₁^a1 . . . X_n^Bn
  • where (G,•) is a group with order some d, n is some integer, and a₁, . . . , a_n are public elements from Z_d, i.e. the set of integers modulo d. The function ƒ maps then a tuple of n elements in group G to an element in group G.
  • With this choice of f, GM can avoid collisions by systematically randomizing the key pk. More precisely, GM considers a random r=(r₁, . . . , r_n) in the exponent group Z_d to randomize pk in order to avoid collisions for the function ƒ; pk=(X₁, . . . , X_n)←pk^r=(X₁^r1, . . . , X_n^rn). GM further publishes r to allow the recipient to update its private key accordingly—this is only possible when X_i=g_i^xi, where g_i are known generators of G, and x_i is the private key corresponding to X_i. The certificate is computed on the newly computed public key and stored along with the key and its alias in DB.

Finally a preferred relation R is (m,x,y)∈ R⇄e(m,P)=e(x,y) where e is an efficient pairing with domain G×H (G and H are cryptographic bilinear groups), and P is a fixed element from H.

The interactive Prove protocol between the prover who generated the ciphertext c for receiver with public key pk and any verifier proceeds in three passes: commitment, challenge, and response. In the commitment pass, the prover runs the CONVERT algorithm on input the group manager's public key S.pk, public pk and corresponding certificate to obtain the pair (S, R). The prover also runs the COMPUTE algorithm on input c₁ and obtains the tuple (pk′, m′, c′₁). Next, the prover computes F′=f(pk′), I′_R=F_R(m′), and I′=pk′). Finally, the prover computes c′₂ which is the encryption of F′ under public key pk_OA. The prover sends the tuple (R, I′, I′_R, c′₂) to the verifier. Upon receiving this tuple, in the challenge pass, the verifier selects at random an integer b and computes I=g(R, S.pk) and I_R such that F_R(m)=I_R. The verifier sends the challenge b to the prover. Upon receiving this challenge, the prover computes and sends the values z_s, z_pk, z_m and z_F where z_pk is the composition of pk′ and pk^b, z_S is the composition of S′ and S^b, z_m is the composition of m′ and m^b, and z_F is the composition of F′ and F^b. Finally, the prover proves the knowledge that (PoK1) the composition of c′₁ and c₁^b is the encryption of z_m under public key z_pk with respect to tag t, and (PoK2) the composition of c′₂and c₂″ is the encryption of z_F under public key pk_OA with respect to tag t. At the end of protocol, the verifier accepts if (1) φ(z_S, z_pk) is equal to the composition of I′ and I^b, (2) F_R(z_m) is the composition of I′_R and I^b_R, (3) f(z_pk) is equal to z_F, and (4) PoK1 and PoK2 are valid. The skilled person will observe that, when instantiated with the preferred encryption schemes, the proofs of knowledge PoK1 and PoK2 boil down to showing the equality of discrete logarithms; efficient methods thereof can be derived from the seminal work of Claus P. Schnorr, “Efficient signature generation by smart cards”, Journal of Cryptology, 4(3):161-179, 1991. See also Jan Camenisch, “Group signature schemes and payment systems based on the discrete logarithm problem”, PhD thesis, vol. 2 of ETH Series in Information Security and Cryptography, Hartung-Gorre Verlag, 1998 (ISBN 3-89649-286-1).

FIG. 1 illustrates a system 100 for group encryption according to a preferred embodiment of the present invention. For ease of illustration and comprehension, the connections between the devices in the system have been omitted.

The system 100 comprises a sender 110 and a receiver 120, each comprising at least one interface unit 111, 121 configured for communication with the other device, at least one processor (“processor”) 112, 122 and at least one memory 113, 123 configured for storing data, such as accumulators and intermediary calculation results. The system 100 further comprises a Group Manager 130, a database 140, a third party 150 and an Opening Authority 160; although not illustrated for the sake of clarity, each of these devices comprises the necessary hardware such as processors and memory.

The processor 112 of the sender 110 is configured to perform the Encrypt and Prove parts of the present group encryption scheme, and the processor 122 of the receiver 120 is adapted to decrypt a received group encryption, i.e. perform Decrypt. The Group manager 130 is configured to perform the Join part and thereby store data in the database 140. The third party 150 is configured to verify proofs provided by the sender and the Opening Authority 160 is configured to perform the Open part of the group encryption scheme. A first computer program product 114 such as a CD-ROM or a DVD comprises stored instructions that, when executed by the processor 112 of the sender 110, performs Encryption and Prove according to the invention. A second computer program product 124 comprises stored instructions that, when executed by the processor 122 of the receiver 120, performs Decrypt according to the invention.

The skilled person will appreciate that the Group Encryption scheme of the present invention can allow a significant reduction of the size and cost when compared to prior art schemes. For instance, the GE scheme of the present invention results in a 0.4 kB ciphertext (instead of 1.25 kB or 2.5 kB in the prior art) if it is instantiate with:

• • The signature scheme proposed by Masayuki Abe, Georg Fuchsbauer, Jens Groth, Kristiyan Haralambiev and Miyako Ohkubo in “Structure-Preserving Signatures and Commitments to Group Elements”; CRYPTO 2010: 209-236.
  • The one-time signature provided by Jens Groth, Rafail Ostrovsky and Amit Sahai in “Non-interactive Zaps and New Techniques for NIZK”; CRYPTO 2006: 97-111.
  • The weakly secure tag-based variant provided by David Cash, Eike Kiltz and Victor Shoup in “The Twin Diffie-Hellman Problem and Applications”; Journal of Cryptology 22(4): 470-504 (2009) to instantiate E₁ and E₂.

In addition, the proofs are shorter and can be carried out with or without interaction with the verifier (1 kB for the interactive proof, and 2 kB for the non-interactive one), leaving to the latter the choice of performing cheap, interactive proofs, or expensive, non-interactive proofs. Moreover, verification of the proof requires 325 pairing computations (to be compared to 3895 pairing computations in the prior art).

As mentioned previously, the GE scheme of the present invention has the drawback of accessing the database DB in each Open procedure in order to find the preimage of the alias of the public key's. Fortunately, the recourse to Open happens only in case conflicts, and thus very rarely.

While the present invention has been described in the context of GE, its scope is not limited to this kind of cryptographic schemes. Any cryptographic scheme involving the encryption of (long) messages present in (online) public DB may equally benefit from the invention. Applying the present invention, (short) aliases will be associated with each message of the DB and added to the DB. The encryption of the message will then be replaced with the encryption of the alias, shortening therefore the size of the ciphertext. Upon decryption, the alias will be recovered and, using a request to the online DB, the associated message will also be recovered.

Each feature disclosed in the description and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination. Features described as being implemented in hardware may also be implemented in software, and vice versa. Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

1. A method of group encrypting a plaintext m with regard to a tag t for a recipient with a public key pk to obtain a ciphertext the method comprising at a device: creating a first encrypted value c1 and a second encrypted value c2, by calculating c1=E1.Encrypt{pk}(m,OTS.vk) and c2=E2.Encrypt{pkOA} (f(pk),OTS.vk), wherein E1 is a first encryption algorithm, E2 is a second encryption algorithm, pkOA is a further public key, OTS.sk is a signing key, OTS.vk is a verifying key and ƒ is a mapping function;producing a signature s on the first encrypted value c1, the second encrypted value c2 and the tag t using the signing key OTS.sk by calculating s=OTS.Sign{OTS.sk}(c1,c2,t), wherein OTS.Sign is a signature algorithm; andoutputting the ciphertext c, wherein the ciphertext c comprises the first encrypted value c1, the second encrypted value c2, the verifying key OTS.vk and the signature s.

2. The method of claim 1, wherein message m satisfies a publicly verifiable relation R

3. A method of decrypting a group encryption c comprising a first encrypted value c1, a second encrypted value c2, a verifying key OTS.vk and a signature s, wherein the signature s is on the first encrypted value c1, the second encrypted value c2 and a tag 4 the method comprising at a device: receiving the group encryption c,verifying the signature s with regard to a verifying key OTS.vk;if the signature s is successfully verified, decrypting the first encrypted value c1 using a decryption algorithm E1 and the verifying key OTS.vk.

4. The method of claim 3, wherein the signature verification step further comprises verifying that a decryption of the first encrypted value c1 satisfies a public relation R.

5. A device for group encrypting of a plaintext in with regard to a tag t for a recipient with a public key pk to obtain a ciphertext c, the device comprising a hardware processor configured to: create a first encrypted value c1 and a second encrypted value c2, by calculating c1=E1.Encrypt{pk}(m,OTS.vk) and c2=E2.Encrypt{pkOA} (f(pk),OTS.vk), wherein E1 is a first encryption algorithm, E2 is a second encryption algorithm, pkOA is a further public key, OTS.sk is a signing key, OTS.vk is a verifying key and ƒ is a mapping function;produce a signature s on the first encrypted value a, the second encrypted value c2 and the tag t using the signing key OTS.sk by calculating s=OTS.Sign{OTS.sk}(c1,c2,t), wherein OTS.Sign is a signature algorithm; andoutput the ciphertext c, wherein the ciphertext c comprises the first encrypted value c1, the second encrypted value c2, the verifying key OTS.vk and the signature s.

6. The device of claim 5, wherein message m satisfies a publicly verifiable relation R

7. A device for decrypting a group encryption c comprising a first encrypted value c1, a second encrypted value c2, a verifying key OTS.vk and a signature s, wherein the signature s is on the first encrypted value c1, the second encrypted value c2 and a tag t, the device comprising a hardware processor configured to: receive the group encryption c,verify the signature s with regard to a verifying key OTS.vk; andif the signature s is successfully verified, decrypt the first encrypted value c1 using a decryption algorithm E1 and the verifying key OTS.vk.

8. The device of claim 7, wherein the processor is further configured to verify that a decryption of the first encrypted value c1 satisfies a public relation R.

9. A computer program product having stored thereon instructions that, when executed by a processor, perform the method of claim 1.

10. A computer program product having stored thereon instructions that, when executed by a processor, perform the method of claim 3.