22000
Vinod Vaikuntanathan: Okay. So we're very, very happy to have Bryan here to talk
about noninteractive verifiable computation. Bryan was a graduate student at CMU, but
his advisor was Adrian Perrig. And he now is one of our own. He works in the security
and privacy group of [inaudible], all thew ay across the big chasm from our building.
But welcome.
>> Bryan Parno: Thanks, Vinod. So like Vinod said today, I'm going to be talking about
noninteractive verifiable computing. The first part of the talk is based on work that went
into my thesis and also into a crypto paper.
And it may be familiar to some of you. And then later in the talk I'm going to get into
work that I've been doing here with Seny and Vinod and David Molnar to try and extend
the work a little bit further. You'll probably notice the transition where we go from lots of
pictures to little bit rougher material, stuff that's still being worked on. I'm very interested
in ideas or suggestions you may have.
So to dive in, the general problem that we're trying to address is that there's some
person out there, say Alice, who is a scientist. She has a lot of work she needs to do but
she doesn't have a lot of funding. So what does she do? She outsources her
computation to the cloud. So she has some problems she wants to solve and data that
goes along with it, and she hopes to get an answer back. And based on that data she's
going to choose some new data and submit a new query. And she's going to get an
answer back.
And unfortunately from Alice's perspective, it's very hard to tell is the cloud doing what
she's asked it to do, or is it doing something a little bit cheaper and simpler from their
perspective.
So obviously this is a hot topic right now. There's all kinds of people that want to
outsource computation. There's sort of the distributed systems that have been around
for a long time, study at home, boink, there's our own personal offerings here at
Microsoft, Azure and also Amazon's, and even the other element which you might not
immediately think of is mobile computing. So you have this sort of weak client device,
you'd like to outsource your computation to something stronger.
But the question is can the results you get back be trusted. There's no point in doing this
outsourcing if you can't rely on the results you're getting back. We'd like to provide some
higher level of assurance about them.
And so to be a little bit more precise about the goal, we'd like Alice to be able to specify
some function to a third party who is in this case untrusted and supply an input for that
function and get back the result of applying the function.
And then she should be able to adaptively choose new inputs based on that output and
get back additional inputs, hopefully polynomial many. And the key requirement here is
we would want to have integrity. We want to know the results coming back are correct.
An additional requirement that you might have is secrecy either for the inputs, the
outputs or both. Some applications like study at home don't care about secrecy.
They're doing scientific computing, it's an open process. Secrecy is not important.
If you're doing medical data or outsourcing rendering of your latest film, then secrecy is
very important. Of course, the key constraint that makes this interesting is that you have
to do less work to prepare and verify the information than computing the function
yourself, otherwise why bother.
So there's been some previous work in this area, and it falls into two main categories.
The first is verifying specific functions.
So, for example, early I guess 2000s, there was some work on verifying the inversion of
a one-way function. And so for that specific class it's a little bit easier because you put in
some answers you know and ask for the inversions on the one you don't know and do
some comparisons when it comes back.
Obviously that doesn't work for all functions. Similarly, anything in NP presumably is
easier to check than to do yourself.
But there's lots of other interesting functions that don't naturally lend themselves to this
kind of approach. Then there's work on general functions. They have largely come from
the PCP family. So the prover generates a large PCP proof, commits to it in some
fashion through random Oracle, for example, and selectively reveals bits about it so the
guy outsourcing the computation can verify the proof actually exists and is correct.
There's been some work on reducing how much you rely on the PCP. Anytime you get
PCP involved, everything gets more complicated and much larger and harder to deploy
in practice. It would be nice to avoid this machinery if we could.
The other interesting point is none of these consider data privacy. All this previous work
was just about the integrity property, not about secrecy. For some of them it's somewhat
complicated to think about how you might go about adding secrecy on top.
So in contrast, the protocol that we developed within this framework is generic, works for
any function. It avoids all this complexity of PCP, CS proofs, and it's asymptotically
optimal in terms of the amount of CPU and bandwidth utilization.
It's noninteractive. So I hand off the problem and eventually the answer comes back. I
don't have to help you along the way. And it has this nice property of preserving input
and output secrecy. So looks pretty good. We'll get into later in the talk why there's
some drawbacks to this approach though.
In general, I'll go into the general protocol we developed and explain how the
construction works, what the advantages and disadvantages are. And then in the
second half of the talk I will talk about some of our more recent efforts about making it
even more practical and trying to get it somewhere where you might actually envision
running it on a computer.
So high level, one of the changes that we made in this problem area is to change the
model a little bit. And we did that by introducing an off-line phase in which you perform
some amount of key generation. And so the idea is that you're going to do this one time
for, say, for a function, and then amortize that over many inputs, which you want to
evaluate that function.
And so when you're in the online phase, you're going to choose some new input X.
You're going to generate a problem instance from that using your secret key.
You're going to give a portion of that to the worker and keep some secret information
potentially to yourself. And the worker is going to execute a compute function on that
input using the public key that you supplied and eventually produce some alleged output.
You have a verification function that's going to tell what the actual answer is or that the
worker has tried to cheat you somehow. By doing a whole lot of these instances for a
given function, we hope to amortize the initial work we have to do for the setup phase.
>>: You don't even decode the answer?
>> Bryan Parno: So the decoding is part of the verification. So verification spits out the
decoded output or some bottom.
>>: [inaudible].
>> Bryan Parno: Yeah. So one of the key insights here was that if you look at Yao's
garbled circuit computation, make a few tweaks, we can turn it into what we call a
one-time verifiable computation. So you can verify a single input computation. At a high
level what we do here, we choose the function we want to compute. We convert it into a
circuit. We apply Yao's garbled circling technique, which I'll go into in a few more slides.
And we send the circuit to the worker. We then choose input, garble the input, following
Yao's techniques, send that to the worker. The worker then uses Yao's techniques to
apply the circuit. But it's important here we're not doing any oblivious transfer. In
traditional Yao we have two parties, they both have secret inputs. Here we only have
Alice supplying inputs.
Second -- and so of course the worker is not supplying any inputs, just using the ones
that Alice gives him. When he gets the response, traditionally in Yao you hand off a
decoding table so the worker can tell what the answer was. But here we don't care
about the worker except as far as he does work for us. So we're going to send the
encoded output back to Alice and then she's going to use the decoding table to check
the answer and make sure it's a legitimate answer for this function. So that's the high
level view.
Let's go into a little bit more detail and to refresh your memory about how Yao's
construction works. The first step you have to take is to convert the function you want to
compute into a circuit.
>>: Is it a one-time computation you didn't really say the computation, you could have
computed --
>> Bryan Parno: Yes, exactly. One-time computation is not very useful. But we have
sort of a generic technique for transforming a one-time computation into multiple.
>>: Following [inaudible] somebody chest, somebody need Yao, it was a million to one,
are you in the same ballpark?
>> Bryan Parno: For using Yao.
>>: For using Yao. Standard Yao, not modification.
>> Bryan Parno: Yes, quite possible. We're using Yao fairly generically. There's
certainly been some work on how you can do Yao more efficiently. Benny Pincus's
group and whatnot. But, yeah, we still have all the slow down you would get from
converting to Boolean circuit and computing that way on computers that are not
optimized for that.
So you do have to convert to this Boolean circuit. You crank it through your favorite
compiler, produce that. And the next step is to do this garbling. So this is what Yao was
using for two-party computation back in the '80s. And the idea is that for each gate and
for each wire in the circuit you're going to choose two wire labels.
So for wire A, we choose A0A1, B0B1, and Z0Z1. For each of these values chose some
large space dictated by security parameter.
Then we're going to write down the truth table for the gate. So this is an N gate. You
can check, make sure I did that right.
And then we're going to replace all the bit values with the corresponding labels that we
chose in the first step. So then to actually compute the garbled version of the gate,
we're going to encrypt each value of Z with the corresponding values of A and B as keys.
And so for the first row in the table we're going to encrypt Z0 using A0 and B0s keys and
so on throughout the table. We'll say that the garbled representation of this gate is these
four cipher texts.
>>: So [inaudible].
>> Bryan Parno: What's that.
>>: Also randomly permuted.
>> Bryan Parno: Yes, for Yao it's important you randomly permute this. For our
purposes it's not as important. Because we're just doing the integrity part.
So then to garble the input it's very simple. You pick the bits. You convert them to their
corresponding labels. So A1 and B0 in this case, and you can do that for all of your
label values. And so Alice is doing this whole process for the entire circuit, the entire
input, sends this whole big collection of cipher text over to the adversary along with the
input and then he has to do the work.
How does he do the work? For each of the four cipher texts, he takes the first garbled
input he's been given and tries to decrypt all four. So for this example it will work on the
last two. Then he takes the second one, tries to decrypt all four and, it only works on the
third one. As long as you use a decryption function that makes it evident whether
decryption has succeeded or failed it's very easy for the worker to say this is the output
of this particular gate. And clearly you can propogate this through because the Z0
becomes the input value for the next one and you use that to decrypt the next set of
cipher text.
The worker can do it all the way through the circuit and wind up with some
representation corresponding to a series of wire labels for the output. In this case just
Z0. So then Alice has to check to make sure he did the work she asked him to do. The
way she does that, she compares the values she got back. If it's Z0 she concludes the
answer was Z0. If it was Z1 it's a 1, if it's none of the above, then she concludes the
worker was trying to cheat her.
Simple security analysis. This is to say, if you don't want to get rejected as a worker,
you have to produce either Z1 or Z0, there are large random numbers, so chances of
guessing are small. The only recommendation you have about ZI value was the cipher
text to which you don't have proper keys. As long as you choose a good encryption
system then your information about this is computationally negligible. Good?
So but we do have this problem. Somebody mentioned that it's insecure to reuse these
circuits. And it's easy to see if Alice chooses a new input, say 1-1. Computes the
garbling, whatever it happens to be and sends it over to the worker. The worker can
simply ignore whatever he was given and send back the same thing he returned last
time.
And so in this case it was Z0. Alice will look at it. It's a legitimate value for the output
wire label. It's one of the two Z values but in this case it's the wrong Z value. So Alice is
tricked into accepting A0 when it should have been a 1.
And so the interesting observation here is that the only reason he's able to cheat is
because he's recycling this old knowledge. It's because we gave him some bit of
information he didn't have in the first round that he's able to cheat in the later round.
So what we said was, all right, well, let's add another level of encryption to get rid of this
information we gave up in the first round.
Oh. And sorry, the first point is that you can't just simply throw away the circuit and
compute a new one because obviously that's as expensive as doing the computation
yourself. So what we really need is some manner of recycling this circuit so we can use
it over and over again.
And, in particular, the way we're going to do that is using fully homomorphic encryption.
So fully homomorphic encryption means if we have two cipher texts, we can take an
arbitrary function, evaluate it over those cipher texts, and get an encryption of the
function on the underlying plain text. In particular, an interesting function you might want
to apply is the decrypt function for the Yao encryptions. So what this gives us is an
encryption with a homomorphic encryption system with the decryption of B with A as a
key.
And, of course, it's important to note that fully homomorphic encryption on its own
doesn't give you integrity, because if I give you a bunch of homomorphically inputs, you
can compute whatever function you want over them, I will get a legitimate set of cipher
text on the return.
>>: Do you have any estimate how slow that would be?
>> Bryan Parno: Yes. Fully homomorphic encryption is very slow. So ->>: You built it on top of Yao.
>> Bryan Parno: Yes, so current -- think Craig and Shy have an implementation of
Craig's fully homomorphic encryption scheme, and it runs anywhere from I think a
minute -- minutes to lots of minutes to do a bit of this function F. And then so for each
gate -- for each F gate that you want to do, it takes on the order of minutes. And so for
our purposes if we want to do, say, decrypt, which AES has maybe 10,000 gates without
a whole lot of optimization, then you're looking at days to weeks per verifiable gate.
>>: But the costly work is only the evaluation, right, the encryption and decryption are
fairly simple and the evaluation is only done by the server anyway.
>> Bryan Parno: Yes so ->>: It's still not practical because even for a server it's a lot of work. But ->> Bryan Parno: Especially for the person doing the outsourcing, the trade-offs are
good. So Alice doesn't have to do a lot of work compared to the amount of work the
worker does. On the other hand, Alice may be paying Amazon for each compute cycle
so expanding the work factor by weeks is probably not optimal.
But, yeah, it's a good point. So how do we apply this? Well, we do the same thing we
did before. We compute the garbled circuit, give it to the worker. Compute the same
garbled input. This time rather than giving the input in the clear we choose the public
key for the home more for if I can system and send the input to the worker. The worker
uses the key to homzly input the circuit and apply it to the input that we've given and that
will result in an encrypted version of the garbled output.
And it's important to note if you sort of naively apply Yao in this case you get something
that's very inefficient. In a few slides I can show you how you can do this a little bit more
intelligently. On the order of magnitude we're talking about, it probably doesn't matter
that much. But it's a nice optimization.
But the worker can't make anything out of this. All he has is a cipher text. So he has to
return it to Alice who has the key and hence can decrypt this result she got and do the
checks that she did before.
So now, of course, when she wants to outsource a new input, say W, all she has to do is
garble it and choose a new public key for the homormorphic encryption system, provide
the public key, the worker has to convert the circuit into an encrypted form again and
apply it to this new input. Once he's applied it, he's going to get a new encrypted output,
return it to Alice.
Now the nice thing about this system is we can repeat it polynomial number of times by
choosing a new public key each time and. If the worker ever tries to recycle something
he saw before it's very obvious he's cheated because it's going to decrypt badly with our
newly chosen key.
So before I go into sort of the Yao optimization, this last step -- question?
>>: Question, so what property -- why do you need to public key [inaudible].
>> Bryan Parno: You need a new public key every time because if we recycled the blue
key, for example, then we could give him the blue version of W, and then he's just going
to give us back the blue version of Y again. So we run -- you'd run into the same
recycling property.
By changing this key, we guarantee that if he ever tries to give us back an old output, we
know, because it's going to be encrypted with a different key than it was before.
>>: So what property do you need for the encryption scheme to do this?
>> Bryan Parno: From the verifiable from the verifiable homomorphic scheme?
>>: [inaudible] it's semantic secure. It's nonmalleable. It's different keys, right? If I give
you encryption of a message under one key, you can't construct encryption [inaudible] a
different key. That's semantic properties guarantees, right? That's the thing you need to
do. Semantic security does ->> Bryan Parno: NCPA gets us through, which is important because fully homomorphic
encryption is never going to be CCA secure, at least not in the traditional sense.
>>: I see.
>> Bryan Parno: So this transformation that we've applied here actually is a generic
transform. So we can take any scheme that's one-time verifiable, apply this
transformation, and wind up with a generally verifiable computation scheme.
>>: [inaudible].
>> Bryan Parno: Sure.
>>: So another thing if you encrypt under the same public key then whatever time you
can carry on if I give you the [inaudible] without encrypting, you can also apply the same
attack inside the encryption.
>>: Yeah, that's true.
>>: Okay. Now the [inaudible] cannot be taken care of, can it be taken care of even if
you change?
>> Bryan Parno: What do you mean by an attack?
>>: It's the same public key you can get a setting. If you change the public key between
multiple executions, I assume there's ->>: [inaudible].
>>: So it's like what we all said before. Just think of a case if you could do anything like
this then you would just -- even if you had just one public key you could generate
another public key for your homomorphic, if you could do anything else between the two
keys you can also do it with a second key that you generate by yourself. So semantic
security itself guarantees that ->>: No, no. So here the goal would be to force incorrect output. The goal would be to
force correct output. I never go the same public key, I could force the incorrect output.
>>: Yes. But the attack is to correlate what you learned in the first execution. Either in
the clear or in the [inaudible] text to do something about it in the second. What I'm
saying is what we're trying to say is you use two different public keys, then you get
nonmalability. What you learn in the first case, inside or inside the cipher text doesn't
help you, in the second case.
>>: I guess you cannot get it under the new public key.
>>: Under the new public key you can't, but that's what -- if you know it, then ->> Bryan Parno: It might help -- so there's actually -- we can look at a second example
where we go from a one-time verifiable scheme to a fully verifiable scheme. So this was
from a scheme from crypto that was -- if you're familiar with the recapture system where
you enter two words on the Internet they know the answer to one and the other is used
to help with OCR, it's very similar to that.
So the idea is so we're going to build it up from a very simple scheme. So Alice wants to
verify the computation on a single input so she chooses some random input herself, and
precomputes the function on that input.
And then when she's given a random input X, she sends both X and R to the worker and
the worker's expected to compute F on both of those and they're randomly permuted,
when it comes back Alice just compares the results she computed and makes sure that
that one's correct and then checks, and accepts that the other one's correct.
So soundness one-half so you could repeat this a whole lot of times. All right. But we
don't want to compute on arbitrary, on random Xs, we want to compute on specific Xs.
So the way you get rid of that is you again pick R at random. You precompute F of R.
But this time we homomorphically encrypt, this is not the transform, this is layer one of
homomorphic encryption. The input R and homomorphically apply the function F. So
this time we can pick an arbitrary X and we're going to send an encrypted version of X
and encrypted version of R to the worker.
Essentially we went back to the system we had what appears to the workers two
randomly chosen inputs. Except that now we can pick X arbitrarily. Even X worker
might be what the worker might anticipate. So now the worker has to return encrypted
versions of these two and we compare this homomorphically encrypted version with the
one that came back.
There's an interesting catch that you might think you could precompute just F of R and
sort of decrypt these two that come back and do the comparison but that actually leaves
you open to an attack. That's a bad idea. So it's important to do the check this way.
>>: I think you mean compared as far as what you get, like ->> Bryan Parno: Compute the homomorphically encrypted F of R.
>>: Doing as much work as a worker and paying for all the homomorphic stuff, too.
>> Bryan Parno: She's not winning yet. This is building up a one-time variable system.
This gives us soundness one-half. How do we get up to better soundness? You do it by
sticking I here. You have some KR values, KX values, you intersperse them, and based
on how many you choose, you basically get 1 over 2 to the K on that order. Now we've
got soundness. This is one time verifiable, because these Rs look the same. And so if I
send the same Rs each time, the worker will know which ones he has to do the real
computations for and can cheat on the other ones.
So this is where the -- Melissa?
>>: [inaudible].
>> Bryan Parno: No. So this is so you can do multiple -- oh, yes, sorry. I'm sorry. Yes.
Same X value. So you check that not only are all the R values correct but you also
check that all the X values match.
>>: [inaudible].
>> Bryan Parno: Yeah. The trouble with this fuzzy notation here.
So how do we convert this to a reusable scheme? Well, we apply a layer of fully
homomorphic encryption on top of it. Basically we generate a new public key. Encrypt
all of this stuff fully homomorphically and he does all the stuff that he was going to do
before fully homomorphically. And this way each time we choose a new random public
key we can recycle these R values and the F of R values that we calculated here.
So if you thought that ours was slow, you can try adding yet another layer of fully
homomorphic encryption on it and this part is going to be age of the universe
computation.
On the plus side, this scheme lets you get away from the very large public key that we
had before. So with the protocol I described, we have to transmit the entire garbled
circuit into the worker and he has to do the encryption. Here, I just have to transmit the
inputs. Of course, they're doubly fully homomorphic encryption so they're large.
Theoretically it's a nice property.
>>: Two approaches are really, can you think of them as really the same, except that
you replace Yao by fully homomorphic encryption compared to [inaudible] so you both
have fully homomorphic encryption on the top layer. Instead of Yao you use ->> Bryan Parno: Yeah, so I guess theirs is a combination of this pick-and-choose, plus
fully homomorphic encryption, whereas Yao is a slightly different property, I think.
But it's two different ways of arriving at a one-time verifiable computation and the same
mechanism for doing the recycling. If you're doing the Yao approach sort of a naive way
would be to say take whatever gigantic circuit you would use to ordinarily evaluate Yao.
So whatever that big program is and evaluate fuelly homomorphically that's expensive
because the eval step is the size of that circuit.
So you might want to do it simpler and do it in pieces. So, for example, you might
encrypt each one of these cipher texts with a fully homomorphic encryption key, and
then restrict yourself to only evaluating the decrypt function.
So that's naturally going to be much smaller than the larger function that calls decrypt,
looks at the outputs, does some work and so on.
And so that seems nice, because we're just mimicking what Yao would have done
before and it's just happening inside of the fully homomorphic encryption. So we're
decrypting with the second value. And we wind up like this.
What's the potential problem here?
>>: Can't check ->> Bryan Parno: Exactly. In the old Yao we could look at the old value and say aha this
looks different from the other ones. But now we can't check directly. So we are forced
to homomorphically uncheck.
But the advantage is that both -- we can do that via simple addition, and the encryption
scheme or the decrypt function can be very small, and so overall this gets you a more
practically efficient than doing the entire Yao process inside of the garbling.
Of course at the cost of fully homomorphic encryption schemes, it may not matter a
whole lot. But we'll take what optimizations we can get here.
So in terms of proof sketch, what we --
>>: That sigma is coordination? On this slide.
>> Bryan Parno: Actual sum. So we just assume that the decrypt function either returns
the plain text, if it's the correct key, or zero.
>>: Or zero. All right.
>> Bryan Parno: So the proof basically goes in two stages. First we show that Yao is in
fact one-time verifiable, and you can basically reduce that to the security of Yao as a
multi-party computation.
And that's because you can take all of these encryption values that we had before
representing a gate, and slowly replace all of the inner illegitimate values with the
legitimate values.
So at the end you wind up with a circuit where only legitimate output values are
available, so the adversary can't possibly produce the cheating output. As long as the
encryption scheme is NPCA secure, you can't tell the difference between the two worlds.
Once you know that Yao is one-time verifiable you have to take the second step and
that's based upon the semantic security of the fully homomorphic encryption system. So
there we can slowly replace these input values with randomly chosen values. So the
worker is going to proceed through the circuit just as he did before with these random
values. All the decryptions are going to fall. He'll wind up with some encryption of zero
but because of the NCPA property of the encryption scheme, he can't distinguish that.
So isn't going to learn anything helpful.
So just to summarize, we have these nice properties that we have a generic
construction, because any F that you can turn into a circuit will work. It's not interactive.
Preserves the input output seizuringsy just as survey side effect of using the fully
homomorphic encryption. And has nice asymptotic performance.
So from Alice's perspective she does this one-time computation of garbling the circuit,
which is linear in the number of gates. Then for each work instance that she wants to
outsource she needs to garble and encrypt the input which is linear in the number of bits
of the input.
The worker then homomorphically applies the circuit, which technically ignoring security
parameters is linear in the number of gates in the circuit. And finally we do the
decryption, which again is just a single operation per output bit. And so at the end we
wind up with something that's linear in the size of the input plus output from Alice's
perspective and it's linear in the size of the circuit from the worker's perspective which is
nice when you're paying for these computations. Theoretically it's a pretty nice system
but there are some drawbacks. One we're only achieving efficiency via amortization. If
you're only going to evaluate the function a number of times, then this is not the way to
do it.
>>: That's true also for the other solution, the [inaudible].
>> Bryan Parno: Yes, because they also do the precomputation to determine what the
correct output should be.
>>: Is there any solution that doesn't require modernization?
>> Bryan Parno: I believe the PCP ones.
>>: The proofs.
>> Bryan Parno: Somebody just shows up to your door and says hey I've got this proof
and they give you this short little hash. Then there's this big elephant that we're using,
fully homomorphic encryption, which we've already talked about how slow that can be.
And so interesting -- then there's this additional interesting question of how do you
respond when you catch a worker cheating? So, say, the worker does send something
back that doesn't match what you were expecting, you might think, okay, you're going to
send them a nasty letter, you're going to deduct some money from his account, what
have you.
The trouble is with our current construction, we can't make the proof go through when
we provide this extra feedback to the worker.
And the way you can think about it is that the worker can speculate as to what the
correct output label is. And using the fully homomorphic encryption properties he can
basically toggle one of the bits in the output label. And he can submit that to us. And
we're either going to say yes it's correct, in which case he knows what that bit was, or
we're going to say, no, you're cheating in which case he learns a bit.
And so you could say anytime you catch somebody cheating you regarble the circuit and
maybe it's worth paying that extra cost for having caught somebody. But it's not, seems
undesirable.
The other thing you could do is, say, in the morning somebody at home could send out
all their all units for work, then collect all results and late in the evening run the check
over a million people and catch all the cheaters that way.
And so ->>: Naively, if I catch somebody cheating I don't do any more business with him but
you're using the same encryption for a bunch of workers, is that the problem?
>> Bryan Parno: Ideally you'd like to be able to use the same encryption over the same
number of workers so you can't tell which ones are colluding. But you're right if you're
using it per worker then you wouldn't have this problem.
And then you could always throw lawyers at the problems then.
>>: Of course the lawyers. Just throw the switch.
>> Bryan Parno: Sure. And so some of the work we've been doing here at MSR is
looking at how can we make the system more practical. So sort of taking some of the
ideas but something that is not going to take on the orders of weeks to compute.
And so the high level idea is to say that there seems to be an interesting connection
between verifiable computing and various proxy schemes. So proxy signature schemes,
proxy reencryption schemes.
And so just as a reminder, proxy resignatures were a primitive introduced via Blaze,
Bloomer and Strauss [phonetic], and then later sort of more rigorously formalized by
Antnessy [phonetic] and Homberger [phonetic]. The idea is you take the standard
definition for a signature and you add two additional functions.
So one is a rekey operation, which takes in a public key and a secret key from two
different users and produces what's called a proxy key or a rekey.
And the idea is that you can take this rekey and feed it into the second signature called
resign. And what this lets you do if you have a proxy key from A to B and you have a
signature from A on some message, you can convert it into a message from B.
And so essentially by giving up your secret key here, you're basically saying, anytime
Alice signs something, it's okay to say that it came from Bob.
And so there's a number of properties you might want from this. So this is from antenna
antenna and horn horn defined a lot of properties external which means if you're not a
participant you should have the same forgery preventions as any other signature
scheme.
If you are participating, you want what they call internal security or limited proxy.
So the idea is that if I give a proxy my key, then or a proxy key, he should be able to
produce signatures that were legitimately signed by the person who is the target of the
proxy and that I -- that if the proxy holds the key he shouldn't be able to forge my
signature on messages that weren't signed by the person that I delegated to. And
similarly the person that I delegated to shouldn't be in danger just because I created one
of these keys.
In terms of functionality, there's a whole lot of different nice properties you might have.
So you might want to say unidirectional. So that means that I can proxy -- I can give out
a key that proxies from me to Vinod and it doesn't automatically imply you can proxy to
Vinod back to me. It maps nicely to real world relationships.
>>: That's security property, right? If I give you the proxy key from you to me, you can't
forge I guess your signatures.
>> Bryan Parno: You can think -- it depends. If you say you need this functionality, then
it changes what your definition of limited proxy is.
Then there's multi use. It might be the case that a proxy key can only transform a
signature once and nobody else can transform that signature again. Or you might be
able to say that signatures can be proxied in arbitrary number of times.
You might want a private proxy. You might not want it to be the case that you can
distinguish signatures that are the result of proxying from signatures that were sort of
generated straight from the source.
Transparent is very similar. Nontransitive means if you have a proxy key from A to B
and B to C you shouldn't be able to combine them into a proxy key from A to C.
And some other properties that probably aren't too important for our discussion. So
there's been a handful of existing implementations. The first one from BBS is largely
program -- it just doesn't stand up to hardly any of these properties that you might
actually desire for the scheme.
The more recent papers proposed one scheme that's multi-use, which is nice. You can
proxy arbitrary number of times, but it's bidirectional. If I give out a key for me and
Vinod, it's going to go back and forth. They also have one that's single use but it's
unidirectional or it's unidirectional but only single use.
More recently, in this paper, Lee Barren [phonetic] and Vinod came up with one that's
multi-use and unidirectional. That's nice, but it has a problem that your signature grows
every time it gets proxied and grows linearly. And you can think of this scheme in some
fashion as essentially giving out almost a certificate chain.
So I sign something that says it's okay to take from me to Vinod. Vinod signs something
that says it's okay to go from him to Sini, so to proxy twice you sort of staple these
certificates together.
That's why you get this linear growth. There's a little bit more subtlety to it so they can
have the transparency property so they can hide where the signatures came from but
that's basically it.
>>: The assumptions there in these works?
>> Bryan Parno: Let's see. I think these are both based on pairings. So various elliptic
curve ->>: Paired things or ->> Bryan Parno: Fairly standard things. This one is based on a slightly non-standard
pairing assumption. It's like triple DDDH or something like that. Looked plausible.
So one of our ideas in this direction has been to say what if we take this notion of proxy
resignatures and generalize it a little bit into something called threshold proxy
signatures.
So we're going to have two algorithms that are very similar to these but instead we're
going to have something called threshold proxy key. And that's going to take in two
public keys and a secret key. And generate a threshold key.
And the property of this threshold key is you can have this other algorithm that says if
you're given the threshold key and a signature from A and a signature from B on the
same message, you can convert that into a signature from C.
So very similar from before, but we had this property that you need two signatures to
advance to the third one. And so if you look at this -- you can actually see that once you
have these you don't really need these, you can build this from something like this.
And in fact for our purposes, we can take this set of properties and we don't actually care
about all this for circuit construction.
So all we care about is unidirectional. If you're going through the circuit it's important
that you can't get part way and sort of reverse your way back up to learn things that you
weren't supposed to know. We need multi-use because of course circuits can have
many hops and key optimal deals with how big your proxy keys grew.
And so the way you would construct this is you would say we're going to choose proxy
keys or choose signature keys for each one of these wire values, just like we did with
Yao, using this key gen function. And then for each one of the logic evaluations in that
gate we're going to generate a threshold key. So A0 and B0 lead to some value of C0,
Z, so we're going to set up a threshold key for that. And so then you're going to wind up
with four threshold keys that represent this gate functionality. So to use it, when you get
some input X, choose a new random message for each bit and encrypt the message
using the corresponding signature key and you give this to the worker who then applies
these threshold proxy keys to calculate a way through the circuit.
>>: Keep the message on the signature key, what's that mean?
>> Bryan Parno: So each one of these is a signing, is a signing key. So say the input's
01. She's going to use A0 to encrypt the message and she's going to use B 1 -- sorry.
Sign the message. Sorry.
>>: And your message is going to be what?
>> Bryan Parno: Randomly chosen message from some reasonably large space.
The intuition is you can use the threshold key proxy to a signature from C 0 or C1 but not
both because you don't have corresponding inputs. At the end of the day I can use the
verification key to check that you have a legitimate signature from either Z0 or Z 1 on the
message I gave you.
So this is a nice property that the proof of security basically reduces exactly to the
threshold proxy signature scheme, because the threshold proxy, you basically have to
say that security depends on that I never gave you a signature with some combination of
keys that you already have threshold keys that get you the output.
>>: Even though it seems like you're doing -- you can do an end but not an end or is that
something that can easily be solved?
>> Bryan Parno: No. So the threshold that you get "and.."
>>: In this ->>: You just switched.
>>: Oh, you just have a cross -- okay. Good. Good.
>> Bryan Parno: And then we also have this nice property because we're using
signatures, we get around the adaptivity property, because a signature scheme is
defined if I give you a signature on one message, it shouldn't help you generate a
signature with another message.
So this seems like a promising approach. The problem is if we look back at these
existing constructions of proxy resignature schemes, well, then one's broken, we're not
going to use that.
This one's bidirectional, no good. This one is unidirectional, but doesn't have this
threshold property. It's not obvious how to combine the two. And this one definitely
doesn't. So they're out.
And this one definitely doesn't have the thresholding property because you basically
have these two long certificate chains and you can't easily just merge the certificate
chains that are coming along. Okay. So can't use prior works. So we need to come up
with something on our own.
And so one way in which we've attempted to go about this is to define a slightly weaker
notion, which is additively key homomorphic key proxy schemes. So we still have sort of
the standard proxy definition, but we also have this additional property we want. That is
if you take messages that are signed by two different people or take the same message
signed by two different people and perform some operation on them, you can get a
signature on the message with the sum of the two keys. So a little bit of a strange
property, but not unimaginable.
And certainly weaker than the full threshold property. So one way you can think about
instantiating this is with RSA or something like RSA. So standard key gen and signing
procedure for naive RSA up here, then to rekey you just give out the division of the two
keys. For resigning, you take the signature you're given and raise it to the rekey, and so
sort of check the math, you'll wind up with the message raised to the new exponent, and
of course this has this nice key homomorphic property here.
Everybody good? Okay. And so RSA construction, you would pick all of your wire
labels to be RSA exponents or you choose the A, B and Z 0s to be RSA exponents and
you choose the other Z value to be the sum of the two.
And so the way you could do this is for each gate you're going to give out three or two
proxy keys. One that takes you from A0 to Z0 and one that takes you from B0 to Z0. So
that sort of gets you the or property and the sum will get you the and property. So I think
that speaks a little bit to your question from earlier.
So in this fashion we're sort of taking advantage of the fact that or shortcuts, if you have
A0 it doesn't matter what you have for B, you automatically get Z0. And, similarly, for if
you're given B0 you should automatically get Z0, regardless of A. Unfortunately, there's
some problems.
So there's some good properties and bad properties. Good properties are this is clearly
very efficient. It's just exponentiation per gate evaluation. It's easy to compute to do the
preparatory work and do the verification.
>>: You mentioned efficient. Now after hearing about Gentry, it's efficient, but as the
security minimum level, how much slower is it than ->> Bryan Parno: It's still much more efficient compared to previously, probably not in the
realm of you'd want to start a business selling this as a service.
>>: Okay.
>> Bryan Parno: But I would say it's significantly forward in terms of efficiency.
And you might even be able to get this adaptive security property because we're using
something that looks like an RSA signature so maybe you get that property as well.
The problem is we don't yet have a proof that this is secure. And in fact most of our
attempts at proving it run into this problem that you're giving out this rekey value, which
is derived from the keys, in the clear.
And so one way in which you might go about embedding an RSA challenge is to set one
of the Z0 values to be the challenge value on which you're trying to produce a signature.
So let's say we know he's going to cheat by producing A0. So we're going to embed the
challenge exponent here. So then we need to work our way backwards and make sure
we can produce signatures on the inputs that we're given.
And we can do that based on our knowledge that Z 0's not a legitimate value. So if Z0 is
not legitimate that means we're never going to give out A0 and B0 because they're not
legitimate either. So we can take advantage of that in our construction of the circuit that
we're going to give to the simulator. The problem is that the way in which you compute
those reveals information about the path that you took through that construction.
And so an adversary can look at the distribution of those K values and determine they're
not uniform. There's something going on with them. And therefore he can refuse to play
the game with you.
And that comes largely from the fact that we're giving out those division values sort of in
the clear, and from the fact that it's hard to randomize them. So one way in which you
traditionally randomize RSA exponents is to multiply them by some random number mod
in the whole group. The point of using RSA here we don't know the order of the group,
because if we did it would no longer be unidirectional.
So we don't actually have an attack on the system, but proving security seems to be
tricky in this case.
>>: Is it crucial to use RSA. Can you use other -- because of the simulation?
>> Bryan Parno: The reason why we picked RSA in the first place it gives you a nice
unidirectional property that you can go forward but not backwards, because RSA even
given the exponent you can exponentiate by it but you can't divide. Something like
standard Diffie-Hellman or some other group-based thing, if I give you Z0 over A0 you
can invert that and work your way backwards.
However, one area which that's not the case is pairings. So return to pairings because it
has this nice unidirectional approach. And again you can define sort of standard basic
signature scheme, you define the rekey, to look very similar, except now we can hide it
up in the exponent. And then the resign operation just does a pairing.
And we still have this nice additive homomorphic property.
>>: That's exactly what I was going to say because for the security proof, typically make
this interactive assumptions, right? And inferring sort of is usually easier to make the
assumptions, for example, if I was to ask you [inaudible] plus AI could ask you for any
random A and then for any different A you cannot give me [inaudible] specific proof for X
and it's okay to make such assumptions but it's hard to make assumptions for RSA. So
it might still be [inaudible] if you're there then there.
>> Bryan Parno: Well, the pairings get us our -- we're still efficient in the sense we
discussed earlier. We get the unidirectionality from the pairing. Secure and quite
possibly adaptively secure based on signatures. But it has this big problem that we're
using pairings. Right? So we don't get the multi-use one. Once you do the pairing,
you're stuck in the target group, and we can't get the unidirectional property again.
And so that sort of implies we can evaluate circuits that are Boolean formulas, because
Boolean formulas only require sort of one level of wire splits at the top. And once you've
done that, everything is sort of, you have no wire splits in the rest of the circuit, and so
we can use the pairing once at the beginning and then let everything run from there.
>>: Is there a [inaudible] homomorphic signatures? How does it permit this?
>> Bryan Parno: The recent paper from Dan Boneh and I forget the student.
>>: [inaudible].
>> Bryan Parno: Yeah.
>>: [inaudible].
>> Bryan Parno: So with their paper, they don't get the amortization property. So they,
for each computation you want to do you need this tag value that they came up with. So
the worker has to come up with this tag value that for each new computation and coming
up with that tag value is essentially takes as much work as doing the computation
themselves.
So he can provide these tag values that anybody can use to do computations but he sort
of has to do amount of precomputation equal to the amount of work that somebody else
does later.
So it has the advantage you can do a whole bunch of precomputation and later when the
results come in you can do very fast verified computing. But the total amount of work
you do to prepare is exactly equal to the amount of work the worker does, essentially.
Does that make sense?
>>: So what's the idea, I'm going to assign my input give it to you, you can compute a
function, you can compute a signature on the result and give it back to verify? But then
the second time I'm going to give you signature sort of different input, and you should be
able to like mix and match these signatures, yes? So we have after sort of assigning the
first one using the first tag and the second one using a different tag. To do that, I need
to -- that kills the amortization, turns out. There's no need -- no reason why that should
be the case, but...
>>: In a sense it's a limitation that you have to provide as many signatures as there are
computations you want [inaudible] so if I wanted to do K definitions I have to give you
signatures for at least K text [inaudible].
>>: Yes.
>>: So you don't get to amortize it the way these other schemes have been doing.
>>: More problems than that. That's why they can only do limited number of -- they can
do linear functions, they can do constant degree polynomials, and even for that -- I
mean, the property ->> Bryan Parno: So it has some nice properties but it's unfortunately not sufficient for
this.
>>: Low arbitrary number of times.
>> Bryan Parno: We can do arbitrary number of times but you're stuck with Boolean
formulas and Boolean formulas are sort of unappealing because the amount of work you
would save with this is a constant fraction of the work to do the preparation.
So but there is this interesting connection I think Vinod and his intern were investigating
this summer looking at this looks a lot like sort of the boiled down part of an ABE
scheme. And so you could think about an ABE schemes are also essentially largely
limited to Boolean formulas unless you do things like blow up the leaves to handle other
functions.
And so there may be some interesting connections as to why they're stuck with Boolean
formulas and why Boolean formulas seem to work well here.
And so one other approach you might take is instead of doing additively key
homomorphic and key proxying, you might have additively message homomorphic and
message proxying. This is a little weirder primitive, but if you imagine there's some
master key generation, standard key signature algorithm, and instead of doing rekeying
and resigning of keys, we say that we use this master key to say that you get a proxy
key from two different messages. And so for any signature on MA, with any key, you
can convert it to a signature with that same key on message B.
So, again, kind of a little bit strange. But you would also want this additive property
which is less strange if you have the encryption under the same key of two messages
you can add them together and get the sum.
And so if you wanted to build this, then looks very similar to before but this time we're
going to associate random message value with each wire, and we're going to give out all
these rekeys, and then to do the computation, Alice is going to generate one new
signature key for the entire input and she's going to sign all the input messages using
that key.
The worker can then proxy through the circuit, going from two input messages, proxy it
to a single output message, and at the end we're going to wind up with a signature on
one of the output wire value messages using that original key that Alice chose.
So this time we're going to be view the messages instead of the keys. And so we've
been working on ininstantiation of this based on lattices, in particular based on a
signature scheme from Vinod, some folks at IBM, and has the advantage that it does
have this proxy property. So you can proxy for messages, and it has this additively
homomorphicic property. Unfortunately there's a couple of limitations. So you can't do
full-sized circuits.
You can't reuse it a polynomial number of times. You have to reuse it, what did we
decide, logarithmic, polylogarithmic. So don't get as much reuse, but you get some
reuse. Then there's this much bigger problem that this particular signature scheme has
the property that if you give out a signature on two linearly related messages using the
same key, then there's the adversary has a good chance he can recover the secret key
corresponding function to your signing key.
It's important you only sign non-related messages. And of course when we're
constructing these circuits we're going to wind up with lots of linearly related messages
because we're taking advantage of this additive property. And so until you get rid of this
property, this construction is not going to work.
>>: So what [inaudible] the construction. The bonsai [phonetic] construction of
[inaudible], et al. ->>: We don't even know if it's additively homomorphic. So our construction is additively
homomorphic.
>>: I thought that was the problem, I guess.
>>: If you don't even have [inaudible] then what's the point?
>>: If the messages are shorter than 128 bits and you generate each at most at random,
you need two to the 64 messages before you get linear relation.
>> Bryan Parno: That would be if you generate all messages at random, but for this
construction, we're taking advantage of this additive thing so that, for example, the inputs
might be A and B and we're going to define the output message to be that. That's what
eventually gets you into trouble.
So if you could pick them, if you had sort of the full thresholding that we talked about
before, then you wouldn't need to pick them in this fashion. And then you'd be okay.
So this is lattice ininstantiation. So just to wrap up here, since we're running out of time,
this verifiable computation system of sort of doing a little bit of precomputation work and
amortizing it over lots of inputs seems to fit nicely with what everybody wants to do these
days, pushing stuff out to the cloud. We found that combining Yao with fully
homomorphic encryption yields this theoretically very nice protocol for doing this, and
that this method of applying fully homomorphic encryption does seem to be generic
given any sort of one-time verifiable computation.
We can get a lot more practical if we turn to these proxy-based schemes, but
unfortunately we sort of have high level approaches based on these proxy schemes but
we don't have very good concrete instantiations. So that's what we've been spending
most of our time on lately is to come up with concrete instantiations that match these
definitions better.
So if you have ideas or other possible approaches in this direction, we'd be very
interested in talking more about that. And that's the end. Thank you. [applause].
>>: Have you looked at the relapse problem that people may have crafted which is the
running of double agents in wartime, double-cross system.
>> Bryan Parno: So trying to check answers against ->>: Yeah, you think your spooks are working for you but maybe they are not.
>> Bryan Parno: So I guess the other one-time verifiable computation scheme that I
showed does take some flavor of that. It gives you some unknowns and some knowns
and then checks based on the knowns.
And that works well for one time -- in general, the problem with applying that notion that
you could get rid of all this crypto stuff and just give out the same computational problem
many times, in fact that approach that study at home it largely takes. But you're never
safe from collusion in that case. It's always the possibility you're giving it out to a
thousand people you think are different and and it's one guy sitting in his basement. But
that's certainly a popular alternative.
>>: Does this work with [inaudible] on clouding clouds, assuming we're doing clouds.
[inaudible].
>> Bryan Parno: Yeah, so if you make assumptions about the workers not colluding, I
think you can certainly make more ->>: Crosscheck.
>> Bryan Parno: The other interesting thing to look at is all of this stuff has been
building on the Yao construction, basically garbled circuits and just basic circuits. But
Yao is just sort of a very early secure multi-party computation protocol and a ton of work
done and other ways of doing secure multi-party computations. Might be interesting to
look and say can we take some of those techniques as well and adapt them to this
setting.
>>: Even if you just care about [inaudible] and not care about verifiability, then you still -then there's no hope of getting rid of the fully homomorphic encryption, right because
again even if you give up verifiability completely you still get fully homomorphic
encryption. So it seems like there's a limit to -- like there's a limit to how efficient this
thing can get without also informing the efficiency of fully homomorphic encryption.
>>: What if you give up privacy and you just want verifiability?
>>: No, I'm saying if you want privacy, if you want privacy.
>>: If you want privacy -- if you want privacy for general functionality, then that's exactly
what fully homomorphic is giving you.
>>: It assumes a lot of [inaudible].
>>: Sorry.
>>: Like compactness, right?
>>: You do need compactness, because if you ->>: Exactly, otherwise your communication complexity cannot relate to the size of the
computation, otherwise it's exactly like what you're trying to avoid, because then really
the answer is going to be ->>: So maybe like if you want efficiency then you need to like explicitly focus on
schemes that do not have, that do not give privacy.
>> Bryan Parno: In fact, these proxy schemes, at least some of the ones we've been
looking at don't give you privacy, because you're going to use a different key depending
on which inputs are coming in. It does seem intuitive if you give up privacy, that seems
like a big give, you should be getting some ->>: The point is you have to give it up, it seems, if you don't want to --
>>: Right.
>>: Again, an old problem, between the war, there was a lot o f communication bureaus,
battalions of people with hand-cranked adding machines, they must have made
mistakes and they must have had procedures to handle mistakes. And of course the
people you remember are dying off. And it may be useful to pick some brains on this
before they all die.
>> Bryan Parno: Sure. And though I think one of the differences in that situation is at
least assuming your computers have not been suborned, you're largely looking for
random mistakes.
>>: And laziness, of course.
>> Bryan Parno: And laziness. But I think if you're looking for sort of the ->>: That's harder.
>> Bryan Parno: Yeah. Any other questions?
Vinod Vaikuntanathan: Let's thank Bryan.
[applause]