We recall the computational assumptions on which our schemes are based.
Definition 2.36 (DL). Let G be a generator of cyclic groups of order p and let
G← G(1$ λ). We say the Discrete Logarithm assumption (DL) holds in G if there
exists no PPT adversary A that, given (g, ga) for a random generator g ∈ G
and random a ∈ Zp, can output a with more than negligible probability, i.e. if
Pr a ← A(g, ga) | g ← G, a$ ← Z$ p = negl(λ).
Definition 2.37 (Asymmetric bilinear groups). An asymmetric bilinear
group is a tuple bgp = (p, G1, G2, GT, g1, g2, e), such that:
• G1, G2, and GT are cyclic groups of prime order p,
• g1 ∈ G1 and g2 ∈ G2 are generators for their respective groups,
• the DL assumption holds in G1, G2, and GT,
• e : G1× G2 → GT is bilinear, i.e. e(g1a, g2b) = e(g1, g2)ab ∀ a, b ∈ Z,
• e is non-degenerate, i.e. e(g1, g2) 6= 1, and
• e is efficiently computable.
We will write gt= e(g1, g2).
In case of symmetric pairings where G1 ' G2 we write G for both G1 and G2
for the sake of convenience.
Definition 2.38 (DDH). Let G be a generator of asymmetric bilinear groups and
let bgp = (p, G1, G2, GT, g1, g2, e) $
← G(1λ). We say the Decisional Diffie–Hellman
assumption (DDH) holds in G1 if, for every PPT adversary A,
| Pr A(bgp, gx 1, g y 1, g xy 1 ) | x, y $ ← Zp − Pr A(bgp, gx 1, g y 1, g1z) | x, y, z $ ← Zp | = negl(λ).
Definition 2.39 (co − DHP∗ [44]). Let bgp = (p, G1, G2, GT, g1, g2, e) be a de-
scription of a bilinear group. We say the Computational Diffie-Hellman assumption holds in bgp, if there exists no ppt adversary A that given (bgp, ga
1, g1b, gb2) where
2.8 Cryptographic Assumptions
Definition 2.40 (Double Pairing Assumption in G1 (DBP1 [1])). Let bgp =
(p, G1, G2, GT, g2, e) $
← G(1λ) and R, Z ← G$
1. Any PPT adversary A can produce
(GR, GZ) ∈ G22\{(1, 1)} such that 1 = e (R, GR) · e (G, GZ) only with a probability
negligible in λ.
We have an analogous computational problem in G2.
Definition 2.41 (Double Pairing Assumption in G2 (DBP2 [1])). Let bgp =
(p, G1, G2, GT, g1, g2, e) $
← G(1λ) and R, Z $
← G2. Any PPT adversary A can
produce (GR, GZ) ∈ G21\{(1, 1)} such that 1 = e (GR, R) · e (GZ, Z) only with a
probability negligible in λ.
It is known that DBP1 implies the Decisional Diffie–Hellman assumption in G1
and DBP2 implies the Decisional Diffie–Hellman assumption in G2, and the security
reductions are tight [2].
We also use the Flexible Diffie–Hellman Inversion hardness assumption, intro- duced by Catalano, Fiore and Nizzardo [37]. In the extended version of their CRYPTO2015 paper, they formally investigate the hardness of this assumption and analyse it in the generic group model.
Definition 2.42 (FDHI [37]). Let G be a generator of asymmetric bilinear groups
and let bgp = (p, G1, G2, GT, g1, g2, e) $
← G(1λ). We say the Flexible Diffie–Hellman
Inversion (FDHI) assumption holds in bgp if, for every PPT adversary A,
Pr W ∈ G 1\{1G1} ∧ W 0 = W1 z | (W, W0) ← A(g1, g2, gz 2, gv2, g z v 1, g1r, g r v 1) | z, r, v ← Z$ p = negl(λ).
Definition 2.43 (Factorization Assumption). Let N = pq be a random RSA
modulus of length λ, where λ ∈ N. We say that the factorization assumption holds if for any PPT adversary A we have Pr[(p, q) ← A(N )] = negl(λ)
Definition 2.44 (DCRA [84]). Let N be the product of two (safe) primes, i.e.
N = pq. We say the Decisional composite residuosity assumption (DCRA) holds if there exists no ppt adversary A that can distinguish between an element drawn uniformly random from the set Z∗N2 and an element from the set {zN|z ∈ Z∗N2},
that is the set of the N -th residues modulo N2.
Definition 2.45 (Strong RSA [14]). Let N = pq be a random RSA modulus
of length λ, where λ ∈ N, and z ∈ ZN a random element in ZN. We say
that the Strong RSA assumption holds if for any PPT adversary A we have
3
Classifying Verifiable Computing
Schemes by Their Privacy Prop-
erties
Today, it is common practice to outsource large-scale computations to the cloud. In such a situation, it is desirable to be able to verify the outsourced computation. The background for the field of verifiable computing was discussed in Section 2.6. In addition to the basic properties discussed there, further properties are required when dealing with sensitive data. Particularly sensitive data, e.g. medical data, must remain private even in the long term. Thus, privacy that depends on the computational hardness of certain problems is insufficient. Here everlasting, i.e. information-theoretic privacy is required.
To account for the different types of privacy threats arising in such scenarios we distinguish between four different privacy notions. We first distinguish by
which information is private - input or the outcome of the computation. We then
distinguish by the attacker we want to prevent from learning sensitive information. In the case of verifiable computing, this can either be the server performing the computation or the third-party verifier verifying the correctness.
Organization. In this chapter we first provide definitions for multiple privacy notions related to verifiable computing in Section 3.1. We then give an overview of existing verifiable computing schemes and their properties - in particular their privacy properties in Section 3.2.
Publications. This section is based on publication [S1].
3.1 Privacy
Verifiable computing can guarantee the integrity of a computation. Beyond that, a desirable property is to protect the secrecy of the client’s inputs towards the server(s)
3 Classifying Verifiable Computing Schemes by Their Privacy Properties
Experiment EXPIn−PrivacyServer
A [VC, f, λ, t] (sk, ek, vk) ← VKeyGen(f, 1λ) (x0, x1) ← AO ProbGen(vk,·) (ek), s.t. f (x0) = f (x1) (σ0, ρ0) ← ProbGen(sk, x0) (σ1, ρ1) ← ProbGen(sk, x1) b← {0, 1}$ σyb ← Compute(ek, σxb) B ← A with B ⊂ {1, . . . , n} and |B| = t − 1 b∗ ← AOProbGen(sk,·) (ek, x0, x1, {σyb,j}j∈B) if b∗ = b then return 1 else return 0 end if
and when using a publicly verifiable scheme also towards the verifiers. To formally define input privacy w.r.t the servers we define experiment EXPIn−PrivacyServer
A , during
which the adversary controls t servers. We use the oracle OProbGen(sk,x) which calls
ProbGen(sk, x) to obtain (σx, ρx) and only returns the public part σx.
In this experiment, the adversary first receives the public verification key for the scheme. Then, it selects two inputs x0, x1 and is given the encoding of one of the
two inputs chosen at random. The adversary then must determine which input has been encoded. During this process, the adversary may request the encoding of any input of its choice. We define an adversaries A’s advantage as
AdvIn−PrivacyServer
A (VC, f, λ, t) =
Pr
h
EXPIn−PrivacyServer
A [VC, f, λ, t] = 1 i − 1 2 .
Definition 3.1 (Input privacy w.r.t. the server [62]). A verifiable computing
scheme VC provides unconditional input privacy with respect to the server if any computationally unbounded adversary A has AdvIn−PrivacyServer
A (VC, f, λ, t) = 0.
If the advantage is negligible, we say the scheme provides computational input
privacy with respect to the server.
We give an analogous definition for output privacy. To formally define output pri-
vacy w.r.t the server, we define experiment EXPOut−PrivacyServer
A , during which the ad-
versary controls t servers. We use the oracle OProbGen(sk,x) which calls ProbGen(sk, x)
to obtain (σx, ρx) and only returns the public part σx.
In this experiment, the adversary first receives the public evaluation key for the scheme. Then, it selects two inputs x0, x1. It is given the results of the computation
y0 = f (x0), y1 = f (x1) and is given the encoding of one of the two inputs chosen at
3.1 Privacy
Experiment EXPOut−PrivacyServer
A [VC, f, λ, t] (sk, ek, vk) ← VKeyGen(f, 1λ) (x0, x1) ← AO ProbGen(sk,·) (ek) (σx0, ρx0) ← ProbGen(sk, x0) (σx1, ρx1) ← ProbGen(sk, x1) b← {0, 1}$ σyb ← Compute(ek, σxb) B ← A with B ⊂ {1, . . . , n} and |B| = t − 1 b∗ ← AOProbGen(sk,·) (ek, y0, y1, {σyb,j}j∈B) if b∗ = b then return 1 else return 0 end if
and then must determine which encoded output has been computed. During this process, the adversary may request the encoding of any input of its choice.
We define an adversaries A’s advantage as AdvOut−PrivacyServer
A (VC, f, λ, t) = Pr h
EXPOut−PrivacyServer
A [VC, f, λ, t] = 1 i − 1 2
Definition 3.2 (Output privacy w.r.t. the server). A verifiable computing scheme
VC provides unconditional output privacy with respect to the server if any compu-
tationally unbounded adversary A has AdvOut−PrivacyServer
A (VC, f, λ, t) = 0.
If the advantage is merely negligible, we say the scheme provides computational
output privacy with respect to the server.
If we have a publicly verifiable computing scheme a third-party verifier might try to learn about the input data from the publicly available verification data. To formally define input privacy w.r.t a third-party verifier we define the following experiment.
In this experiment, the adversary first receives the public verification key for the scheme. Then, it selects two inputs x0, x1 and is given the encoding of one of the
two inputs chosen at random. The adversary then must determine which input has been encoded. Note that during this process the adversary is allowed to request the encoding of any input of its choice.
We define an adversaries A’s advantage as AdvIn−PrivacyVerifier
A (VC, f, λ) = Pr h
EXPIn−PrivacyVerifier
A [VC, f, λ] = 1 i − 1 2 .
3 Classifying Verifiable Computing Schemes by Their Privacy Properties
Experiment EXPIn−PrivacyVerifier
A [VC, f, λ] (sk, vk, ek) ← VKeyGen(f, 1λ) (x0, x1) ← AO ProbGen(sk,·) (vk) (σx0, ρx0) ← ProbGen(sk, x0) (σx1, ρx1) ← ProbGen(sk, x1) b← {0, 1}$ σyb ← Compute(ek, σxb) b∗ ← AOProbGen(sk,·) (vk, x0, x1, σyb, ρyb) if b∗ = b then return 1 else return 0 end if
Definition 3.3 (Input Privacy w.r.t. the Verifier). A verifiable computing scheme
VC provides input privacy if
AdvIn−PrivacyVerifier
A (VC, f, λ) ≤ negl(λ).
If the advantage is negligible, we say the scheme provides computational input
privacy with respect to the verifier.
Note that for authenticator-based verifiable computing schemes [12] this captures all the variations of the context hiding property (see Definitions 5.1 to 2.18) discussed in Section 2.2.
For a publicly verifiable computing scheme, it is interesting to show correctness of a computation without revealing its outcome. A third-party verifier might try to learn about the output data from the publicly available verification data. To formally define output privacy w.r.t a third-party verifier, we define the following:
Definition 3.4 (Output privacy w.r.t. the verifier). A verifiable computing scheme
VC provides unconditional output privacy with respect to the verifier if there exist
additional algorithms (HideCompute, HideVerify, Decode):
HideCompute(ek, σx) : The computation algorithm takes the evaluation key ek
and the encoded input σx. It outputs an encoded version ˜σy of the function’s
output y = f (x).
HideVerify(vk, ˜σy) : The verification algorithm obtains a verification key vk and
an encoding ˜σy. It outputs either ⊥, or ˆσy.
Decode(vk, ρx, ˆσy, σy) : It takes as input the verification key vk, a decoding value
ρx, and encoded values ˆσy, σy. It outputs either ⊥ indicating that σy does not
3.1 Privacy
Experiment EXPout−PrivacyVerifier
A [VC, f, λ] (sk, ek, vk) ← VKeyGen(f, 1λ) (x0, x1) ← AO ProbGen(vk,·) (ek) (σx0, ρx0) ← ProbGen(sk, x0) (σx1, ρx1) ← ProbGen(sk, x1) ˜ σy0 ← HideCompute(ek, σx0) ˜ σy1 ← HideCompute(ek, σx1) b← {0, 1}$ b∗ ← AOProbGen(vk,·) (ek, y0, y1, ˜σyb, ρxb) if b∗ = b then return 1 else return 0 end if
and the following two properties hold:
Correctness For any security parameter λ, and any admissible function f ,
let (sk, ek, vk) ← VKeyGen(1λ, f), and any input x, we have for (σ
x, ρx) ←
ProbGen(sk, x), σy ← Compute(ek, σx),
and
˜
σy ← HideCompute(ek, σx), ˆσy ← HideVerify(vk, ˜σy)
Pr[Decode(vk, ρx, ˆσy, σy) 6= Verify(vk, ρx, σy)] = negl(λ).
Privacy We describe the experiment EXPout−PrivacyVerifier
A .
In this experiment, the adversary first receives the public verification key for the scheme. Then, it selects two inputs x0, x1. It is given the results
y0 = f (x0), y1 = f (x1) and is given the encoding of one of the two outputs
chosen at random. The adversary then must determine which input has been encoded. During this process, the adversary may request the encoding of any input of its choice. We define an adversaries A’s advantage as
AdvOut−PrivacyVerifier
A (VC, f, λ) = Pr h
EXPOut−PrivacyVerifier
A [VC, f, λ] = 1 i − 1 2 .
for any computationally unbounded adversary A, AdvOut−PrivacyVerifier
A (VC, f, λ) =
0.
If the advantage is negligible, we say the scheme provides computational output
3 Classifying Verifiable Computing Schemes by Their Privacy Properties