Robust Encryption, Extended

Robustness is a notion often tacitly assumed while working with encrypted data. Roughly speaking, it states that a ciphertext cannot be decrypted under diﬀerent keys. Initially formalized in a public-key context, it has been further extended to key-encapsulation mechanisms, and more recently to pseudorandom functions, message authentication codes and authenticated encryption. In this work, we motivate the importance of establishing similar guarantees for functional encryption schemes, even under adversarially generated keys. Our main security notion is intended to capture the scenario where a ciphertext obtained under a master key (corresponding to Authority 1) is decrypted by functional keys issued under a diﬀerent master key (Authority 2). Furthermore, we show there exist simple functional encryption schemes where robustness under adversarial key-generation is not achieved. As a secondary and independent result, we formalize robustness for digital signatures – a signature should not verify under multiple keys – and point out that certain signature schemes are not robust when the keys are adversarially generated. We present simple, generic transforms that turn a scheme into a robust one, while maintaining the original scheme’s security. For the case of public-key functional encryption, we look into ciphertext anonymity and provide a transform achieving it.


Introduction
Cryptographic primitives, such as encryption and signature schemes, provide security guarantees under the condition, often left implicit, that they are "used correctly".Fatal examples of cryptographic misuse abound, from weak key generation to nonce-reuse.This reliance on operational security has attracted attackers, who can for instance impose faulty or backdoored random number generators to erode cryptographic protections.At the same time, the social usage of technology leans towards a more open environment than the one in which historic primitives were designed: keys are generated by one party, shared with another, certified by third...These two observations raise new interesting questions, which have only recently been addressed in the cryptographic literature.For instance, if Alice generates keys that she is using, but doesn't share, can an adversary (observing Alice or influencing her in some way) nevertheless generate a different set of keys, which would allow decryption (maybe only partial)?Intuitively this should not be the case, but it was not until the seminal work of Abdalla, Bellare and Neven [ABN10], that this situation was formally analysed.They introduced the notion of robustness, which ensures that a ciphertext cannot be decrypted under multiple keys.
Is robustness desirable?Imagine a scenario where users within a network exchange messages by broadcasting them, and further encrypt them with the public key of the recipient to ensure confidentiality.If this is the case, we usually assume that there is only one receiver, by arguing that no other members apart from the intended recipient can decrypt the ciphertext and obtain a valid (non-⊥) plaintext.But if the adversary can somehow tamper with the key generation process, she may "craft" keys that behave unexpectedly for some messages, or design alternative keys that give at least some information on some of the messages.
Farshim et al. [FLPQ13] refined the original definition of robustness, by covering the cases where the keys are adversarially generated, under a master notion called "complete robustness".Mohassel addressed the question in the context of key-encapsulation mechanisms [Moh10].More recently, Farshim et al. also defined robustness for symmetric primitives [FOR17], motivated by the security of oblivious transfer protocols [CO15] or message authentication codes.Further extensions of their security notions found applications in novel passwordauthenticated key-exchange protocols described by Jarecki et al. [JKX18] or (fast) message-franking schemes [GLR17].Surprisingly, achieving robustness in the symmetric setting seems to be more challenging than the public-key case: the technique applied in [ABN10] of committing to the public-key and encrypting the decommitment is no longer applicable, since there is no reference information such as a pk to commit to.
The above line of work, however, leaves open several questions.Indeed, to the best of our knowledge there has been no notion of robustness defined for digital signatures [GMR84,BGI14] (counterparts of MACs in the public-key world) or functional encryption [BSW11,O'N10].Yet, some existing schemes seem to be vulnerable to attacks that a proper notion of robustness would prevent.Consider digital signature schemes (DS), that are used to authenticate electronic documents.The textbook notion, capturing the existential unforgeability of a DS ensures that an adversary, interacting with one signing oracle, cannot forge a signature (for a message he did not previously query).On the other hand, a real-world scenario is placed in a multi-user context, where it is often assumed (but not necessarily proven) that a signature can only be verified under the issuer's key.
Example 1: Consider a practical situation where a clerk has acquired a digital signature for daily use, with a third party generating the pairs of keys.Even if the scheme remains unforgeable according to the classical definition, we do not have formal guarantees that two pairs of keys -(sk, pk) and (sk , pk ) -generated by the third party (potentially malicious), cannot be used to produce a signature σ for some chosen message M , verifiable under both pk and pk -something completely undesirable in practice.To be fully explicit with our example, let us suppose one pair of keys (pk, sk) is given to the clerk and the second pair (pk , sk ), is issued by the third party and is covertly used by a local/global security agency.When needed (and if needed), an operator can issue a signature (using sk ) for the message: "I attest [...] is true." which can later be verified under pk, thus having baleful consequences for the clerk.
To give a flavour of a signature scheme where such an attack is feasible, consider the one obtained from a toy version of the Boneh-Boyen scheme [BB04].The construction is pairing-based and can be summarized as follows: (1) keygeneration samples two group generators g 1 ∈ G 1 and g 2 ∈ G 2 , both of prime order p, and publishes as a public key (g 1 , g 2 , g x 2 , e(g 1 , g 2 )) -for a uniformly sampled x over Z p -keeping x as a secret key.To sign the message M , one computes σ ← g 1/(x+M ) 1 . A robustness attack against this simple signature scheme exploits the randomness in choosing the secret keys, observing that for a different pair (pk , sk ), one can choose g 1 ≡ g t 1 (mod p) and then can set The above example provides the intuition that robustness has practical consequences.As expected, under correct key generation, standard unforgeability does imply robustness.But it fails in a malicious setting.Fortunately, we can provide a trivial construction that generically transforms any unforgeable signature scheme into a completely robust one (allowing for adversarial, yet well-formed keys).As we prove in Section 4.1, the natural idea of including the public key (or a collision-resistant hash of it) in the signature is indeed sufficient.
Speaking roughly about robustness as the property of a ciphertext of not being decryptable under multiple keys, then, when it comes to decryption, a functional encryption (FE) scheme trivially does not exhibit this property.The reason resides in the broken symmetry to the way decryption works in symmetric/public-key schemes.Through its purpose, a functional ciphertext can be decrypted under multiple keys [BSW11,O'N10].In this respect, an adversary holding multiple functional keys (which is not a restriction by itself) will be able to decrypt under multiple keys.Therefore, defining robustness in terms of decryption itself is fallacious.Instead, an appropriate definition should ensure the FE ciphertext can be decrypted only by the intended set of receivers.
Example 2: Consider a simple use case of a functional encryption scheme for the "inner product" function (IP FE) [ABDP15,ALS16].From a technical perspective, suppose the ciphertext is generated by encrypting a plaintext M as C ← FE.Enc(mpk, M ; R).If msk is somehow corrupted3 to msk , then is it possible that performing decryption under sk y reveals a different plaintext M = M ?Intuitively, if the functional encryption scheme meets robustness, we expect that no ciphertext can be decrypted under functional keys issued by different master secret keys.
As a concrete scenario, consider a Computer Science (CS) department's registry, which holds the marks obtained by each student in the Crypto course, the final grade being computed as a weighted average of the stored marks (i.e.homework counts 30%, midterm 20% and final 50%).A priori established confidentiality rules ask that a clerk should not have access to the marks, but still, it must be possible to compute the final grade.Therefore, considering the set of marks as the vector x and the weights as y, one can use an IP FE scheme, to obtain the final grade, its formula mapping to x • y.In order to achieve this, for each course: (1) the course leader encrypts the marks; (2) later, the clerk obtains a new key sk y (depending on the established course weights), and uses it to obtain the final average.A failure to guarantee robustness could result in a successful decryption, but the final average being incorrect (and possibly under the control of an adversary).To illustrate this, consider the (bounded-norm) IP FE scheme instantiated from ElGamal and introduced in [ABDP15]: encrypting a plaintext under mpk = (g s1 , . . ., g sn ) -where msk = s = (s 1 , . . ., s n ) -is done as follows: C ←$ (g r , g r•s1+x1 , . . ., g r•sn+xn ), for r sampled uniformly at random over Z p .If an attacker wishes to obtain the same C , then r remains the same, but it can use different s and x , implicitly changing the value of msk.As expected, even if FE.KDer is correct, and the queried key is indeed issued for the vector y, the final decrypted result corresponds to x • y rather than to x • y.
Our contributions.We begin by motivating and defining the notion of robust signature schemes under honest and adversarial keys, denoted as strong (SROB) and complete (CROB) robustness (Section 3.1).A natural question is whether existing schemes already possess a form of robustness: we show that while SROB is indeed typically guaranteed, it is not the case of CROB, thus providing a separation between the two security concepts.Fortunately, there exists a simple generic transform, in the standard model, that turns a SROB signature scheme into a CROB one (Section 4.1).
In Section 3.2, we define robustness for functional encryption in a multiauthority context.The strongest security notion we propose (FEROB) is intended to capture adversaries able to generate the keys and the randomness used during encryption and key-derivation, while remaining as simple as possible.As regards the generic transforms, we provide them in the public and private-key paradigms (Section 4.2).The case for private-key FE schemes [BKS16,KS17] relies on rightinjective PRGs and collision-resistant PRFs, concepts that we review in Section 2. Finally, in the original spirit of the security notion we consider, we discuss anonymity in the context of functional encryption schemes.

Preliminaries
Notations.We denote the security parameter by λ ∈ N * and we assume it is implicitly given to all algorithms in the unary representation 1 λ .An algorithm is equivalent to a Turing machine.Algorithms are assumed to be randomized unless stated otherwise; PPT stands for "probabilistic polynomialtime," in the security parameter (rather than the total length of its inputs).Given a randomized algorithm A we denote the action of running A on input(s) (1 λ , x 1 , . . . ) with uniform random coins r and assigning the output(s) to (y 1 , . . . ) by (y 1 , . . . ) ←$ A(1 λ , x 1 , . . .; r).When A is given oracle access to some procedure O, we write A O .For a finite set S, we denote its cardinality by |S| and the action of sampling a uniformly at random element x from X by x ←$ X.We define [k] := {1, . . ., k}.A real-valued function Negl(λ) is negligible if Negl(λ) ∈ O(λ −ω(1) ).We denote the set of all negligible functions by Negl.Throughout the paper ⊥ stands for a special error symbol, while || denotes concatenation.For completeness, we recall definitions of cryptographic primitives to be used in Appendix A, and detail below on the most important concepts.
2.1 (Right-Injective) Pseudorandom Generators Definition 1.A pseudorandom generator PRG : {0, 1} n → {0, 1} n+ takes as input a random seed s of length n and outputs a pseudorandom binary string of length n + .We require a negligible advantage for any PPT adversary A against the PRG security experiment defined in Figure 1: Right-Injective PRGs.We will make use of length-doubling, right-injective PRGs, where the right-injectivity condition is defined as . Such constructions can be achieved assuming the existence of one-way permutations, as shown by Yao [Yao82].

(Collision-Resistant) Pseudorandom Functions
The notion of a pseudorandom function (PRF), introduced in the seminal work of Goldreich, Goldwasser, and Micali [GGM86], is a foundational building block in theoretical cryptography.A PRF is a keyed functionality guaranteeing the randomness of its output under various assumptions.PRFs found applications in the construction of both symmetric and public-key primitives.
Definition 2. A PRF is a pair of PPT algorithms (PRF.Gen, PRF.Eval) such that: sk ←$ PRF.Gen(1 λ ): is the randomized procedure that samples a secret key sk, given as input the unary version of the security parameter.y ← PRF.Eval(sk, M ): is the deterministic procedure that outputs y, corresponding to the evaluation of M under sk.
We require the advantage of any PPT adversary A in the PRF security experiment defined in Figure 1 to be negligible: Collision-Resistant PRFs.We make use of collision-resistant PRFs [FOR17].The collision-resistance property is defined over both the secret-keys and the inputs: Such constructions can be achieved by combining (1) length-doubling rightinjective PRGs and (2) key-injective PRFs.The latter primitive can be obtained via the GGM construction (see for instance [CHN + 16, Appendix C]).

Functional Encryption
Functional encryption [BSW11,O'N10] is one of the most general encryption paradigms, allowing for surgical access over encrypted data: ciphertexts correspond to messages M , keys are derived for functions f , while adversaries are able to learn f (M ) and (ideally) nothing more.FE can be also defined in a private-key setting: the master secret key msk is used to encrypt the plaintext M , as there is no mpk.We defer the formalization of private-key FE to Appendix A.
Definition 3 (Functional Encryption Scheme -Public-Key Setting).A functional encryption scheme FE in the public-key setting consists of a tuple of PPT algorithms (Setup, Gen, KDer, Enc, Dec) such that: pars ←$ FE.Setup(1 λ ): we assume the existence of a Setup algorithm producing a set of public parameters which are implicitly given to all algorithms.When omitted, the output of FE.Setup is ∅.-(msk, mpk) ←$ FE.Gen(1 λ ) : takes as input the unary representation of the security parameter λ and outputs a pair of master secret/public keys.-sk f ←$ FE.KDer(msk, f ): given the master secret key and a function f , the (possibly randomized) key-derivation procedure outputs a corresponding sk f .
-C ←$ FE.Enc(mpk, M ): the randomized encryption procedure encrypts the plaintext M with respect to mpk.-FE.Dec(sk f , C ): decrypts the ciphertext C using the functional key sk f in order to learn a valid message f (M ) or a special symbol ⊥, in case the decryption procedure fails.
A functional encryption scheme is s-IND-FE-CPA-secure if the advantage of any PPT adversary A against the IND-FE-CPA-game defined in Figure 2 is negligible: Similarly we say that it is adaptive Anonymity.We define the classical notion of anonymity to the context of functional encryption and its security experiment in Figure 1 (right).We point out that usually, in a FE scheme, a central authority answers key-derivation queries from a potential set of users U, therefore it is unnatural to assume that a user does not know from whom it received the functional key.What we want to ensure is that an adversary A ∈ U cannot tell which authority issued a ciphertext, without interacting with the key-derivation procedures, otherwise the game becomes trivial.In consequence, we define anonymity only in the context of public-key FE, as for a private scheme, the adversary uses encryption oracles to obtain a ciphertext.Thus, anonymity requires that a PPT bounded adversary can tell which mpk was used to encrypt a ciphertext only with negligible probability: 3 Robustness: Definitions, Implications and Separations Robustness guarantees hardness in finding ciphertexts (resp.signatures) generated under adversarial, but well-formed keys, decryptable (resp.verifiable) under multiple secret (resp.verification) keys.As stated in the introductory part, this property is often tacitly presumed, but almost as often left without a proof.In this work, we capture two levels of strengths of an adversary: strong robustness models the case where the keys are honestly generated and the adversary is agnostic of their actual values, the interaction being interfaced through decryption/signing oracles.A related, stronger notion, dubbed complete robustness gives an adversary the ability to generate keys (not necessarily honestly).In this work, we restrict to the cases where the keys are malicious, but well-formed. 4e commence by presenting the security definition for digital signatures in Section 3.1, and then for functional encryption in Section 3.2.

Warm-Up: Robustness for Digital Signatures
The case for digital signatures is treated with respect to two security notions, which we denote strong and complete robustness.The winning condition remains the same in both experiments: that of obtaining a signature/message pair in such a way that it verifies under both public keys.In the SROB experiment, two signing oracles under sk 1 , sk 2 are given to the adversary, while a CROB adversary generates its intrinsic keys for accomplishing essentially the same break.
Definition 4 (SROB and CROB Security).Let DS be a digital signature scheme.We say DS achieves complete robustness if the advantage of any PPT adversary A against the CROB game depicted in Figure 3 (right side) is negligible: . SROB-security is defined similarly, the SROB A DS (λ) game being defined in Figure 3 (left side).Notice the difference to the classical unforgeability game where the adversary obtains signatures issued under the same secret key.We prove any EUF-scheme is implicitly strong-robust, and show there exist signature schemes that fail to achieve complete robustness (thus providing a separation between the two).
Remark 1 (Comparison with Unambiguity).Bellare and Duan [BD09] had described, earlier but in a different context, a notion of digital signature unambiguity.
Ver(pk 2 , σ, M ) = 1: return 1 return 0 Figure 3. Games defining strong robustness SROB (left) and complete robustness CROB (right) for a digital signature scheme DS.We assume a negligible probability of sampling pk 1 = pk 2 in the SROB game.As stated in [BD09], "Unambiguity can be viewed as a signature analogue of the robustness property of anonymous encryption defined in [ABN10].[...] Unambiguity [...] can be viewed as preventing forgery under an adversarially-modified verification key, something not part of the normal definition of a signature."The original motivation for unambiguity stems from the design of partial signatures.
It is natural to wonder whether unambiguity (UNAMB) coincides with either notion of signature robustness discussed above.Since unforgeability does not imply unambiguity, and since any partial signature scheme is a signature scheme, we have SROB = UNAMB.However, it turns out that the definition UNAMB (for partial signatures) is naturally extended to signatures and matches CROB.
Proposition 1.Let DS be a CROB-secure digital signature scheme.Then DS is also SROB-secure, the advantage of breaking the strong robustness game being bounded as follows: Adv SROB A,DS (λ) ≤ Adv CROB A ,DS (λ) .
Of interest, is a minimal level of robustness achieved by any digital signature scheme, and as it turns out, SROB is accomplished.
Lemma 1.Any EUF-secure digital signature scheme DS is SROB-secure.The advantage of breaking the SROB game is bounded by the advantage of breaking the EUF game: Proof (Lemma 1).Let A be a PPT adversary against the strong robustness game.Let A stand for an adversary against the unforgeability of the digital signature.We assume without loss of generality that A: (1) never queries a "winning" message M to the second signing oracle after it has been signed by the first oracle (since it can check it right away) and (2) it never queries a "winning" message M to the first oracle after it has been signed by the second oracle (for the same reason).We present the reduction in Figure 4 and describe it below: 1.The EUF game proceeds by sampling (sk 1 , pk 1 ) and builds a signing oracle Sign sk1 (•). 2. The reduction A is given pk 1 and oracle access to the Sign sk1 (•).A samples uniformly at random (sk 2 , pk 2 ) via DS.Gen and constructs a second signing oracle Sign sk2 (•). 3. A runs A w.r.t. the two (pk 1 , pk 2 ) and the corresponding signing oracles Sign sk1 (•), Sign sk2 (•).A keeps track of the queried messages to each oracle.4. A returns a pair (σ, M ) which verifies under both public keys with probability SROB , s.t.M has been queried to either Sign sk1 or Sign sk2 but not to both. 5.A returns (σ, M ).If M ∈ Sign sk1 (•).SignedMessages(), A aborts and runs A again.With probability 1 2 , M was not queried before to Sign sk1 (•).The tuple (σ, M ) wins the EUF game w.r.t.(pk 1 , sk 1 ) with probability ≥ 1 2 • SROB .
Thus, the reduction (Figure 4) shows the advantage of winning SROB is bounded by the advantage of breaking EUF, which completes the proof.
We also show a separation between the SROB and CROB, by pointing to a signature scheme that is not CROB secure (but already SROB).
Proposition 2. There exist DS schemes that are not CROB-secure.
Proof (Proposition 2).We provide a simple counterexample as follows.Consider the digital signature scheme in [BB08]: , where e : -Sign: given a message M , sample r ←$ Z p and compute σ ← g 1/(x+M +yr) 1 .Note that with overwhelming probability, x + M + yr = 0 mod p, where p is the order of G 1 .The signature is the pair (σ, r).
To win the CROB game, an adversary A proceeds as follows: 5 See for instance [BB08] for the definition and usage of a cryptographic pairing.

Robustness for Functional Encryption
As discussed in the motivational part of Section 1, robustness should be considered as a security notion achieved by a functional encryption scheme.In what follows, we define it for the public/private key settings.We stress about the existence of essentially two major paths one can explore.A first stream of work would study the meaning of robustness in a single-authority context.In rough terms, the problem one would like to solve can be stated as: if a ciphertext is correctly generated, and the adversary issues two keys, is there a chance that one of the keys fails in decrypting the ciphertext?An astute reader may immediately notice that in such a setting, an adversary may always win such a game by issuing a pair of correct/random functional keys, as it owns the master secret key (assuming msk is adversarially generated).In a "dual" mode, if the functional keys are correctly generated under the same msk, is there a ciphertext decryptable under one key and not under the other?The intuition behind: if C is generated with respect to some mpk, we want the decryption to pass for any functional key correctly generated with respect to the (mpk, msk).However, if C is obtained under some other mpk = mpk or is sampled according to some distribution, we expect decryption not to pass under any functional keys generated with respect to msk.Therefore, a definition should capture this problematic case: decryption "works" under one correctly generated key out of two.
Multi-Authority Setting.A second path is placed in a multi-authority context -that is, assuming there exist multiple pairs (msk, mpk).Aiming for a correct definition, one property that should be guaranteed is that a ciphertext should not be decryptable under two (or more) functional keys issued via different master secret keys.Stated differently, if msk 1 produces sk f1 and msk 2 = msk 1 produces sk f2 for two functionalities f 1 , f 2 , we do not want that C (say encrypted under mpk 1 ) to be decrypted under sk f2 (it already decrypts under sk f1 with high probability due to the correctness of the scheme).We follow the lines of Definition 4, and propose two new flavours of robustness, corresponding to the cases where the adversary has oracle access to the (encryption, if in a private key setting case), key-derivation and decryption oracles.The security experiments are depicted in Figure 5.The difference between the two paradigms may seem minor (for our purpose), but in fact having a public master key confers a significant advantage when it comes to deriving a generic transform for achieving complete robustness, as detailed in Section 4. In what follows, we will explore the multi-authority path, since it naturally maps to our motivational examples.
Definition 5 (SROB and FEROB Security for FE).Let FE be a functional encryption scheme.We say FE achieves functional robustness if the advantage of any PPT adversary A against the FEROB game defined in Figure 5  As stated in the algorithmic description of the security experiment, an adversary against the strongest notion of FEROB attempts to find colliding ciphertexts, which decrypt under two msk-separated keys sk f 1 , sk f 2 .
Lemma 2 (Implications).Let FE denote a functional encryption scheme.If FE is FEROB-secure, then it is also SROB-secure.
Proof (Lemma 2).We prove the implication holds in both the public and private key settings: Public-Key FE.We take the contrapositive.For a scheme FE, we assume the existence of an adversary A winning the SROB-game with non-negligible advantage SROB .A reduction A that wins the FEROB game is built as follows: (1) A samples uniformly at random (msk 1 , mpk 1 , msk 2 , mpk 2 ); (2) the corresponding oracles for key-derivation are built; (3) A runs with access to the aforementioned oracles, returning (C , sk f1 , sk f2 ).If A outputs a winning tuple, then A wins the FEROB game by releasing the messages and the randomness terms used to construct (C , sk f1 , sk f2 ).Hence, Adv SROB A,FE (λ) ≤ Adv FEROB A ,FE (λ).Private-Key FE.We take the contrapositive.For a scheme FE, we assume the existence of an adversary A winning the SROB-game with non-negligible advantage SROB .A reduction A that wins the FEROB game is built as follows: (1) A samples uniformly at random (msk 1 , msk 2 ); (2) A constructs the encryption and key-derivation oracles under the two keys; (3) A runs A with access to these oracles, records the random coins used and obtains (C , sk f1 , sk f2 ).Finally A wins the FEROB game by issuing the FEROB tuple, using the random coins used to derive the functional keys and the ciphertext and therefore we have: Proposition 3 (Separations).There exist functional encryption schemes in the public/private-key setting that are not FEROB-secure.
We introduce FEROB and SROB in the context of FE schemes defined both in the public and private key setting.For the SROB games, we give the oracles implementing Enc and KDer procedures, mentioning that each query to the latter oracle adds an entry of the form (f, sk f ) in the corresponding list Li -where i ∈ {1, 2} stands for the index of the used master keys.
Proof (Proposition 3).As sketched in Section 1, a DDH instantiation for the FE scheme of [ABDP15] is not FEROB-secure.The adversary is built upon the idea presented in the introduction and is shown in Figure 6.Given that any public-key functional encryption scheme can be trivially converted into one in the private-key setting simply by making mpk private, we obtain an FE scheme for the inner product functionality in the private-key setting that is not FEROB-secure.

Robust Digital Signatures
We put forward a generic transform similar in spirit to the original work of Abdalla, Bellare, and Neven [ABN10] in the context of digital signatures.For a digital signature scheme, we benefit from the fact that pk acts as an "immutable" value to which one can easily commit to, while signing a message.Thus, checking if a message verifies under another public key implicitly breaks the binding property of the commitment scheme.For simplicity, we use a hash instead of a commitment scheme.Lemma 3. Let DS be an EUF-secure digital signature scheme.Let H denote a collision-resistant hash function.The digital signature DS obtained through the transform depicted in Figure 7 is CROB-secure.
Proof (Lemma 3).We prove both the unforgeability and the complete robustness of the newly obtained construction: Unforgeability.Assume the existence of a PPT adversary A against DS.We build an adversary A against the EUF of the underlying DS.The unforgeability experiment EUF for DS samples (pk, sk) and constructs a signing oracle under sk, which is given to A .A is given a collision resistant hash function H and Figure 7.A generic transform that turns any digital signature scheme DS into one that is, in addition, CROB-secure.The (publicly available) collision-resistant hash function H can be based on claw-free permutations in the standard model, as shown in the seminal work of Damgård [Dam88].It is used as a commitment to the public-key.
builds its own signing oracle Sign; when queried, Sign returns the output of Sign concatenated to the value of H(pk).When A replies with (σ, M ), it must be the case that Ver(pk, σ, M ) passes, which breaks EUF for DS.Thus we conclude that: . CROB.To show robustness, we rely on the collision-resistance of H.The CROB game in Figure 3 specifies that the adversary A against the CROB game finds pk 1 = pk 2 such that Ver passes.The latter implies H(pk 1 ) = H(pk 2 ), trivially breaking the collision-resistance of H, giving us: .

Achieving Robustness for Functional Encryption
The ABN Transform [ABN10] adapted to Public-Key FE.As for the case of digital signatures, one can reuse the elegant idea rooted in the binding property of a commitment scheme.Concretely, one can start from a FE scheme, encrypt the plaintext, and post-process the resulting ciphertext through the use of a public-key encryption scheme.The transform consists in committing to the two public keys (corresponding to FE and PK) and encrypting the resulting decommitment together with the output of FE.Enc under pk.For decryption, in addition to the functional key, the secret key sk6 is needed to recover the decommitment from the "middle" part of the ciphertext.A key difference to the ABN transform would be rooted in the innate nature of FE: one cannot encrypt the plaintext under pk, as this would break indistinguishability.
Simple Robustness Transforms in the Public-Key Setting.A simpler idea makes use of a collision-resistant hash function and simply appends the hash of mpk||C to the already existing ciphertext.
Lemma 4. Let FE be an IND-FE-CPA-secure functional encryption scheme in the public setting and let H denote a collision-resistant hash function.The Figure 8. Generic transform that turns an FE scheme into a FEROB scheme FE.
functional encryption scheme FE obtained through the transform depicted in Figure 8 is FEROB-secure, while preserving the IND-FE-CPA-security.
Indistinguishability. The proof follows easily down to the indistinguishability of the underlying scheme FE: during the challenge phase, the reduction will be given the C * corresponding to M b (chosen by A); after appending H(C * ||mpk), the adversary will be given C * .Observe that the reduction can answer all the functional key-derivation queries the adversary makes.Hence the advantage in winning the IND-FE-CPA game against FE is bounded by the advantage of winning the IND-FE-CPA game against FE.
FEROB Transform in the Private-Key FE Setting.In this part, we provide a similar generic transform for turning any FE scheme into one that is FEROB-secure, in the private-key framework.
Lemma 5. Let FE be an IND-FE-CPA functional encryption scheme in the private-key setting.Let PRG denote a right-injective length doubling pseudorandom generator from {0, 1} λ to {0, 1} 2•λ and PRF a collision-resistant PRF.The functional encryption scheme FE obtained through the transform depicted in Figure 9 is FEROB-secure, while preserving IND-FE-CPA-security.
return ⊥ return FE.Dec(sk f , C1) Figure 9.A generic transform that turns a FE scheme in the private-key setting into a FEROB-secure scheme FE.

Robustness. Assuming the FEROB adversary
we argue that: -C 2 = PRF.Eval(sk 1 , C 1 ) = PRF.Eval(sk 2 , C 1 ).Down to the collision-resistance (over both keys and inputs) property of the PRF, it results that sk 1 = sk 2 .the Gen function makes use of a right injective pseudorandom generator.
Since the right half is exactly sk 1 (= sk 2 ), through the injectivity property, it must be the case that the seed R used to feed the PRG is the same.since the randomness R is the same for both cases, it results that the random coins used by FE.Gen are the same, implying that msk 1 = msk 2 .finally, we obtain that msk 1 = msk 2 , which is not allowed in the robustness game.
Therefore, the advantage of breaking the FEROB game is bounded by the union bound applied on the collision-resistance of the PRF and right-injectivity of the PRG: IND-FE-CPA-security.The reduction proceeds via one game hop: -Game 0 : is the game, where the adversary runs against the scheme depicted in Figure 9 -the output of the PRG is the expected one.-Game 1 : based on the pseudorandomness property of the PRG, we change the output to a truly random string, ensuring independence between msk and sk.The distance to Game 0 is bounded by the pseudorandomness advantage against PRG.We now show that the advantage of an adversary winning the IND-FE-CPA experiment against FE in this setting is negligible.
Assume the existence of a PPT adversary A against the IND-FE-CPA of FE.We build an adversary A against the IND-FE-CPA of the underlying FE scheme.The IND-FE-CPA experiment samples a bit b , the key msk and constructs a key-derivation oracle KDer under msk, such that it can be accessed A .The reduction then proceeds as follows: 1.A chooses uniformly at random sk to key the PRF utility.Analysis of the reduction.The correctness of the reduction follows trivially.Thus we conclude that in Game 1 , the probability of winning is: .
For the analysis, we also include the fact that the transition between Game 0 and Game 1 is bounded by the pseudorandomness of PRG: Finally, it follows that: + Adv PRG A ,PRG (λ) .

Anonymity and Robustness
Interestingly, FEROB does not imply anonymity as defined in Figure 1 (right) for the public-key case.And based on FEROB ⇒ SROB, it follows that SROB does not imply anonymity in a generic fashion.Therefore, we have the following separation: Proposition 4.There exist FEROB transforms for public-key functional encryption that do not ensure anonymity (as defined in Figure 1).
Proof (Proposition 4).We consider the scheme in Figure 8 and observe that the anonymity game can be easily won as follows: an adversary, given two master public keys and the ciphertext C ← (C 1 , C 2 ), decides the issuer by checking whether H(C 1 ||mpk 1 ) We also show that specific FE schemes enjoy anonymity.
Proposition 5.The ElGamal instantiation of the inner-product functional encryption scheme presented in [ABDP15] reaches anonymity (Figure 1).
The proof is given in Appendix B. A similar result can be trivially shown for the FE scheme for general circuits supporting a single functional key by Sahai and Seyalioglu [SS10] when instantiated with an anonymous PKE.
Finally, we give a generic construction of an anonymous FEROB scheme.Reaching both anonymity and robustness for FE is non-trivial: on one hand, we expect the ciphertext to be "robust" w.r.t. a sole authority (mpk), but the "link" should not be detectable when included in the ciphertext (anonymity).Therefore, we attempt to embed such a link in the functional key.Our solution ensures FEROB through the means of a collision-resistant PRF with keys K generated on the fly.An independent functional key to compute the PRF value is issued via a second FE supporting general circuits, while the PRF key K is encrypted under the additional mpk .Theorem 1.Let PRF denote a collision-resistant PRF computable by circuits in a class C. Let FE be an ANON-secure functional encryption scheme supporting circuits in C. Given an ANON, IND-FE-CPA-secure scheme FE, the functional encryption scheme F E obtained via the transform in Figure 10 is FEROB-secure while preserving the original scheme's security guarantees.

Proof (Theorem 1).
Robustness.FEROB follows from the collision resistance of the PRF: if an adversary A is able to find (K , C 1 ), (K , C 1 ) such that PRF(K , C 1 ) = PRF(K , C 1 ), then A wins the collision resistance game against the PRF.
Indistinguishability. Follows from the IND-FE-CPA-security of the underlying scheme FE.For any adversary A against the IND-FE-CPA-security of the scheme FE in Figure 10, we build the reduction A that wins the IND-FE-CPA game against FE as follows: First, the IND-FE-CPA experiment samples its own master keys and initializes the key-derivation oracle.The reduction A instantiates FE by sampling the master keys (msk , mpk ).
Regarding the challenge ciphertext, whenever the adversary A sends the challenge tuple (M 0 , M 1 ), the reduction A proceeds as follows: (1) obtains challenge ciphertext C 1 from the IND-FE-CPA experiment; (2) samples (on the fly) its own key K ; (3) computes C 2 , C 3 , which are forwarded to A. Note that all these steps are perfectly computable, as A knows mpk .
Regarding key-derivation queries, whenever A requests a functional key for some f , A forwards the request to the key-generation oracle.Independently, the reduction obtains a functional key for C PRF(•,mpk) , a circuit that is designed to compute C 2 (the PRF value) over the encrypted K .
It is clear the reduction A can simulate the IND-FE-CPA game for F E in the view of its adversary A .Thus, whenever A returns b, A returns the same bit and wins under the same advantage.
Anonymity.Follows from the anonymity of the underlying FE scheme.We use a hybrid argument.We start from a setting corresponding to b = 0 in the ANON A FE game (Game 0 ).
-Game 1 : in Game 1 , we change C 3 from FE .Enc(mpk 0 , K ) to FE .Enc(mpk 1 , K ), based on the ANON property of FE , the hop between the two games being bounded by Adv ANON A,FE (λ).-Game 2 : we change C 1 from FE.Enc(mpk 0 , M ) to FE.Enc(mpk 1 , M ), based on the anonymity of the underlying FE scheme, the distance to the previous game being bounded by Adv ANON A,FE (λ).Implicitly, in Game 2 , the reduction updates the value of the PRF from PRF(K , FE.Enc(mpk 0 , C 1 )) to PRF(K , FE.Enc(mpk 1 , C 1 )).
Finally observe that Game 2 maps to the setting where b = 1 in the anonymity game for the FE scheme.Therefore, Adv ANON A,FE ≤ Adv ANON A1,FE (λ)+Adv ANON A2,FE (λ) .

Figure 1 .
Figure 1.Experiments defining pseudorandomness for PRGs (left) and PRFs (middle).Anonymity for public-key functional encryption is defined on the right.

Figure 2 .
Figure2.The selective and adaptive indistinguishability experiments defined for a functional encryption scheme.The difference between the private-key and the public settings are marked in boxed lines of codes, corresponding to the latter notion.

Figure 4 .
Figure 4.The reduction A in Lemma 1.

Figure 6 .
Figure 6.A FEROB adversary against the DDH instantiation of the bounded-norm inner product scheme in [ABDP15].
2. A builds the FE.Enc oracle and the FE.KDer oracle by querying the given FE.Enc, FE.KDer.The PRF is evaluated under sk.3. A runs A, obtains a tuple (M 0 , M 1 ) and gets back the encryption of M b (say C * ) by querying FE.Enc(msk, M b ).A computes the corresponding C * , which is passed to A. 4. finally, A returns a bit b, which constitutes the output of A .
Figure10.A generic transform that converts an FE scheme into a FEROB scheme FE, without ensuring anonymity.Here C PRF denotes the circuit that computes the PRF value, where mpk is hard-coded in the circuit.