1.4 ¿Eres un Big Teacher?
Capítulo 3 Experiencias con datos en el aula
3.9 Analizar información, ganar tiempo de aula
Our scheme comprises four types of entity. Firstly, a key distribution centre is responsible for setting up the system and being authoritative on other entities within the system. The
KDC is trusted by the other entities to act honestly. Note that in the prior PVC scheme of Parno et al. [84], this role was played by a client device and would also be assumed to
act honestly on behalf of all other clients. In this work, we have expanded the duties of the KDC to allow revocation of malicious servers and have referred to it as a distinct entity,
rather than a client device, to make the separation of duties explicit, however we have not changed the underlying trust assumption regarding this entity. We assume that the KDC
can maintain state between the execution of each algorithm but, to ease readability, do not explicitly show this as an input and output of each algorithm run by the KDC.
Secondly, the system includes a set of clients (which are assumed to possess limited com- putational resources). These clients wish to outsource computations that they lack the
resources to compute locally. Each client is assumed to act honestly regarding a compu- tation that they themselves outsource (as they wish to gain from a correct computation)
but need not trust each other.
Thirdly, the system includes a set of computational servers that are willing to perform some set of computations on behalf of clients. These servers are not trusted by the clients to
perform the computation correctly and so the servers are required to produce an efficiently verifiable proof of the correctness of their computation. We will assume that servers have
unique identifiers in the form of natural numbers (note that arbitrary identifiers can also be efficiently mapped to unique natural numbers by a hash function or look up table).
The final type of entity within our system is verifiers. Verifiers can either be client devices
or other entities; they trust the client that outsourced a particular computation but do not trust the server that actually performed the computation.
Definition 3.4. A revocable publicly verifiable outsourced computation scheme (RPVC)
comprises the following algorithms:
• (PP, MK) ← Setup(1$ `, F ): run by the KDC to initialise the system and establish public parameters PP and a master secret key MK for a family of functions F ;
• P KF
$
← FnInit(F, MK, PP): run by the KDC to generate a public delegation key,
P KF, allowing clients to outsource computations of a function F ;
• SKS
$
← Register(S, MK, PP): run by the KDC to enrol a computation server S in
the system and generate a signing key SKS used to identify S;
• EKF,S
$
← Certify(S, F, MK, PP): run by the KDC to generate an evaluation key
EKF,S enabling the computation server S to perform computations of a function F ;
• (σF,x, V KF,x, RKF,x)
$
← ProbGen(x, P KF, PP): run by a client to delegate the com-
putation of F (x) to a server. The output values are: the encoded input, σF,x, of x
for the function F ; a verification key, V KF,x, that is used (only) to verify correctness of the result; and a retrieval key RKF,x which will enable the output value F (x) to
be read by authorised parties;
• θF (x) ← Compute(σ$ F,x, EKF,S, SKS, PP): run by a server S holding an encoded input σF,xof x for the function F , an evaluation key EKF,S for F and a signing key
SKS. The algorithm outputs an encoding, θF (x), of F (x);
• (y, τθF (x)) ← Verify(θF (x), V KF,x, RKF,x, PP): verification comprises two sub-algorithms
(which could be performed together in a single Verify operation as written here if the blind verification property is not required). The sub-algorithms are:
– (RTF (x), τθF (x)) ← BVerif(θF (x), V KF,x, PP): run by any verifying party (in the
standard model), or by the manager (in the manager model), in possession of an encoded output, θF (x) and a verification key V KF,x. The output is a retrieval
token, RTF (x), which encodes the actual output value (this can be thought of as a partial translation from θF (x) to F (x)). It also outputs a token τθF (x) which
is (accept, S) if the output is valid, or (reject, S) if S misbehaved;
– y ← Retrieve(τθF (x), RTF (x), V KF,x, RKF,x, PP): run by an authorised verifier
holding the retrieval key RKF,x to read the actual result y from the retrieval token RTF (x). The value of y is either F (x) or the distinguished symbol ⊥ (i.e.
• U M ← Revoke(τ$ θ
F (x), MK, PP): run by the KDC to generate update material U M
if a misbehaving server is reported i.e. that the Verify algorithms returned a token τθF (x) = (reject, S). If τθF (x) = (accept, S) then U M is set to be a distinguished
symbol ⊥ as no user is required to be revoked. Otherwise, this algorithm revokes all evaluation keys EK·,S of the server S, thereby preventing S from performing any
further evaluations. The update material U M is a set of updated evaluation keys EK·,S0 which are issued to all servers.2
Although not explicitly stated, the KDC may update the public parameters PP during
the execution of any algorithm. This reflects any changes that may be required to reflect changes in the user population (e.g. servers are added or removed from the system, or
granted the ability to compute additional functions).
Note that if a server is not given the retrieval key RKF,x then it too cannot learn the
output value F (x) and we gain output privacy. In the above, we assume that RKF,x is distributed to all authorised readers of the resulting value F (x) by the client that performs
ProbGen to outsource the computation. As an example, this could be performed using a broadcast encryption scheme to the set of authorised users [52].
Intuitively, we say that a RPVC scheme is correct if, when all algorithms are run honestly
in any arbitrary execution sequence and the result is computed by a non-revoked server, the verifying party always accepts the returned result and the result is correct. We can model
this as a cryptographic game between a challenger and a PPT adversary; the adversary aims to find an (honestly generated) encoded output (from a non-revoked server) which
either does not encode the correct result, or which does encode the correct result yet which will not be accepted by the verification algorithm.
The adversary is given access to a set of oracles; for each algorithm in Definition 3.4,
the adversary is given a corresponding oracle. Each oracle executes the corresponding algorithm on arguments provided by the adversary, and returns the output of the algorithm to the adversary, as well as maintaining some internal lists, which we shall detail below.
The adversary may call the Setup oracle only once (before making any other oracle queries), but can thereon call the remaining oracles any number of times and in any order.
2In some instantiations, it may not be necessary to issue entirely new evaluation keys to each entity. In
The challenger maintains two lists, LReg and LF; LReg is a list of tuples comprising server
identities, S, and the resulting signing keys, SKS, that have been queried to the Register oracle, whilst LF comprises tuples of the form (S, F, EKF,S) denoting that the server S
has been queried to the Certify oracle for the function F and that EKF,S was generated — that is, S has been certified to compute F . When the adversary makes a Revoke query with
a revocation token that identifies a server S to be revoked (that is, if τθF (x) = (reject, S) is
given as input to the Revoke oracle), the challenger removes all entries of the form (S, ·, ·)
(i.e. all entries for S for any function) from LF.
The challenger also creates and maintains a table T which records the parameters and
values relating to each computation performed through the oracle queries. T is updated in the following oracles:
• ProbGen: the challenger creates a new row in T comprising 8 components, all of
which are initialised to be empty; it then assigns x, F , the result F (x) (computed
by the challenger itself), σF,x, V KF,x and RKF,x to the first 6 components;
• Compute: the challenger first searches T for all rows that contain the queried σF,xin
the 4th component and where the 7th component is empty (i.e. those rows relating
to computations on this encoded input that have not yet been performed). For each such row, r, the challenger takes the second component (the function identifier, ˜F ),
and checks that there exists a server identity ˜S such that the tuple ( ˜S, SKS˜) ∈ LReg (where SKS˜ is that given as input to the Compute oracle) and such that the tuple
( ˜S, ˜F , EKF, ˜S) ∈ LF (where EKF, ˜Sis also that given as input to the Compute oracle). This check ensures that there is a currently un-revoked server (as the entries of LF
for ˜S have not been removed) that holds the signing key and evaluation key being used to perform the computation and which is certified for a function ˜F for which the encoded input σF,x for this computation was generated3.
The challenger then performs the Compute algorithm on the queried σF,x, EKF,S and SKS to produce an output θF (x). For each of the rows r of T found above,
the challenger writes θF (x) and ˜S to the 7th and 8th components of r respectively. Thus, a row of T will only have a (non-empty) value in the 7th component if there
3Note that there could be multiple such identities ˜S satisfying this check, if the parameters SK S and
EKF,S are both generated for multiple identities; in practice, good randomised algorithms should ensure
that there is a negligible chance that this actually occurs. We are only interested in ensuring that there exists at least one non-revoked server with these parameters to perform the computation, and so if multiple such server identifiers are found then the challenger may choose ˜S from this set at random.
exists a non-revoked, certified server to perform the computation for which σF,x was
generated.
Thus, when complete, the entries of T will be of the form
(x, F, F (x), σF,x, V KF,x, RKF,x, θF (x), S).
After a polynomial number of queries, the adversary will return a value θF (x)? which he
believes either encodes an incorrect computational result or which encodes a correct com- putational result yet which the Verify algorithm will reject (that is, an output for which
the protocol execution will not be correct). The challenger first performs a look up in T for all entries containing θF (x)? in the 7th position of the tuple, and stores any such entries
as another table ˜T . Note that this means that θ?F (x) must have been honestly generated by the Compute oracle (else it would not be in T ).
For each such row4, the challenger uses the 5th and 6thcomponents of the row (the verifi-
cation key and retrieval key) to run Verify on θ?F (x) to generate the outputs y and τθF (x).
The challenger first checks whether y matches the 3rd component of the row (that is,
whether y is the correct computational result F (x)). If so, it then checks whether τθF (x) =
(reject, S), and if so it ends the game by returning 1 to indicate that the adversary has
won the game (the adversary has found a valid encoding of a correct result, computed by a certified, non-revoked server, that the Verify algorithm is incorrectly rejecting).
On the other hand, if y did not match the correct value of F (x), the challenger also ends
the game by returning 1 to indicate that the adversary has won the game (the adversary in this case has found an incorrect result that was computed honestly by the algorithms).
If no row in ˜T allows the adversary to win, then the challenger outputs 0 to indicate
that the adversary has lost. An RPVC scheme is correct if, for all PPT adversaries, the probability that the adversary wins the game described above is 0.
4
Again, in practice it is unlikely that randomised algorithms will produce the same encoded output on different inputs but we allow it in the correctness definition.