23671
>> Seny Kamara: Okay. It's a pleasure to have Samuel Ranellucci speaking
today. Samuel is a student at the University of Montreal. And he has done some
work on multi-product computation. Today he'll be talking about obligatory
transfer.
>> Samuel Ranellucci: So my name is Samuel Ranellucci. And today I will be
talking to you about a primitive called generalized oblivious transfer.
And then I'll show a couple of applications of generalized oblivious transfer. So
first of all, I'm going to talk about a couple of primitives. First of all, there are
going to be building blocks for understanding and creating our protocols. The
first one is oblivious transfer. So we have a sender who has two messages. And
the receiver gets to learn one of the two messages. But he should have know
information about the other message and the sender should not know any -should not know any information about the choice of receiver of which message
the receiver received.
Another important building block is bit commitment. It's a functionality where the
sender commits to a value where he chooses a message and then the receiver
receives some confirmation that in fact the sender is committed to a value. And
then later the sender reveals the value and the receiver is assured that it's the
value that the sender originally chose. And an easy way to think of this is with an
actual physical protocol, where you take a message and put it in a lockbox, and
then give the lockbox to the other person. And you can't change the message,
because he has the lockbox, and if he wants to, the only way he can open the
message or give the message is if you give him the combination. An important
primitive that we're going to be using is going to be called verifiable oblivious
transfer and it's kind of a combination of oblivious transfer and commitment. So
it's very much like an oblivious transfer, but also the sender is committed to his
input and at a later time you're able to reveal the values that you sent, that the
sender can reveal later, what values he sent and then you'll be assured that
those are the values that he sent.
So VOT is not a very commonly used primitive. So two ways you can implement
this are in the information theoretic setting, you can erase channels to more or
less implement it as it is, and we're going to be using, we'll use it to implement
generalizable oblivious transfers later. In the computational setting, what we can
do if we look at how OT is implemented, usually it's very much to implement OT
first the senders commits to two messages and then the receiver creates a
ciphertext which allows himself, if decrypted, to learn one of the two messages.
And then the sender decrypts that ciphered text allowing the receiver to learn one
of those two messages. If we look at that OT paradigm in the computational
setting, well, it would seem very evident to make it verifiable oblivious transfer by
simply revealing the value of the original ciphertext.
Of course, proving its security is another thing. So another important thing that
we're going to need to know about is what an access structure -- so an access
structure is -- well, first we have a set of indices and access structure is where
you take a certain set from the power set and you called those sets authorized
sets. And it's important that if you take an authorized set and you add elements
to it, then it's also an authorized set.
And a very important notion, the complement of an access structure is -- well, for
each element of the access structure, you can take its complement and the
complement of the access structure is just the set of all those sets. So maybe
that takes a further -- requires further explanation. So first we have a set I, which
is one, two, three, and then we have an access structure which is the set
containing only the element one, and the set containing the element two, three as
well as all that is implied by these two sets for the access structure.
And the complement of the set one is the set two, three, so that's in the
complement access structure. And the complement of two, three is one. So that
is in the access structure. Is everybody following up to now? Okay. So also we
look at secret sharing more as -- here we define secret sharing not as a protocol
between dealers and the player and dealer, but we look at it as an information
theoretic primitive where first we have an access structure, a domain and there's
two algorithms. The share and reconstruct. So the share algorithm takes a
secret and divides it into share. Such that if you have an authorized set of
shares, then you're able to reconstruct the secret. If you're not, you're unable to
do so, and you're not able to gain any information of the secret. And also will
define as shares are consistent if -- if you take any set of shares they're going to
reconstruct to the same secret.
So here we define what are generalized oblivious transfer primitive is. So we
have some sets of messages that you're allowed to extract and others that you're
not allowed to. For example, for one out of two OT you're allowed to extract sets
of one -- you can either extract the first message or the second message, but
you're not allowed to extract the first and the second message. And this is as
general as you can go with generalized oblivious transfer. So the input is just the
sender has to choose messages and the receiver chooses which message he
wants to learn. And if he wants to learn an authorized set, he's able to extract all
the messages. Otherwise, the protocol will -- the functionality outputs an abort.
So how are we going to implement generalized oblivious transfer? Well, first
we're going to -- the sender is going to choose a secret. And he's going to share
that secret using an appropriate access structure. And then for each message
you'll execute an OT. Sender and receiver will execute an OT. Where either the
receiver learns a share or he learns a message. And if the receiver is honest
and he chooses a valid set of messages, well, he's going to be able to recover
the secret, and he can then send the secret back to the sender and the sender is
going to be like, yes, you acted honestly because you gave me the secret. And
then he's going to kind of reveal -- he's going to reveal the information that's
needed to learn the messages.
So I missed this part, but in the -- you're not going to actually send the
messages. You're going to send an encrypted version of the message in the OT
and the share. And that way you're going to be able to extract the messages you
want plus the secret. If you don't extract the secret, then you're not -- then the
sender is not going to give you the one-time pads.
Is everybody clear on this at that point?
>>: If it's competitive, it's two OT.
>> Samuel Ranellucci: Yeah, along with a share.
>>: Along with a share to secret. And then if you're able to -- then so the receiver
chooses what -- so in the limited two OT you put two messages. Each one with
its share.
>> Samuel Ranellucci: No, no, you put either a message -- the receiver either
extracts the message or a share. So if he extracts a share, he's closer to
extracting the secret. If he extracts a message, well, he gets the message.
If he tries to get an unauthorized message, well -- if he gets a set of message
that are not authorized, he's not able to reconstruct the secret. And the guy won't
allow him to extract the messages. So formally this is the protocol. It's not -- it's
still incorrect, but it gets closer.
So it's simple. We choose random pads. We encrypt -- the sender encrypts the
messages using the one-time pads. He selects a random secret and then shares
it. And the receiver just chooses which messages he wants to learn. And then
they execute on OT with the encrypted messages, the shares, and BI is which -does he want to learn the message or the share. And tries to reconstruct the
secret.
He then sends the secret along. If the secret is not the right one, well, he aborts.
And the important thing here is that if he chooses an unauthorized message,
well, he's not going to be able to reconstruct the secret. And then he just sends
the one-time pads and using the encrypted messages that he received he can
get those messages. All good up to now? Is that clear?
>>: Takes a little while to adjust.
>> Samuel Ranellucci: Okay. Should I move forward?
Okay. The protocol, though, has a fatal flaw. Well, let's look at what the security
proof is. So the security proof for this is that the sender privacy is protected
because he has to extract the secret. And to extract the secret, he has to be -he has to act honestly. And the receiver privacy, well, DOTs don't reveal
anything about the receiver's input. Unfortunately, this is not complete, because
there's a small flaw. And the flaw -- well, there's a big flaw. Sorry. A very big
flaw -- is that you can corrupt the shares here. And when you execute -- when
he chooses to reconstruct the secret, the receiver -- so the sender is cheating,
and he wants to learn what the set of messages that the receiver learned. And
what he's going to do he's going to corrupt the shares, and he's going to
reconstruct the secret, but what he's going to reconstruct is that it now becomes
a function of which messages he chooses, and this allows the sender to learn
what messages the receiver learned. So this allows him to break the protocol.
So now how do we fix it? Well, the main problem here is that the shares can be
inconsistent. So what we want to ensure is that the shares are consistent. So
the basic idea is to replace the OT with verifiable OT. Instead of sending the
secrets directly, he commits to it. And then he -- the sender can reveal his
shares. The shares that he used because of the properties of the verifiable
oblivious transfer, and then he can check that the shares are consistent. If
they're inconsistent, the abort. And since he's committed to it, only committed to
it the sender can't learn any information about it. But then to make sure that the
sender actually chose valid shares, we open the commitment, and the sender
can now make sure that the receiver acted honestly.
>>: The verifiability, the point is that the end gets all the messages, the receiver
gets all the messages.
>> Samuel Ranellucci: No, no. So the receiver -- so for the verifiable OT, it's like
an ordinary OT, except that the sender is committed to his -- in addition he's
committed to the inputs. So then you can reveal your inputs that you gave the
oblivious transfer.
>>: And revealing, couldn't reveal all of them, just opening the commitment?
>> Samuel Ranellucci: Yes, you can open the commitment. But it's the sender
who chooses to if he wants to.
>>: Here you're saying you're assembling all the shares?
>> Samuel Ranellucci: Yes, you're going to reveal all the shares. The reason
why is you want to make sure that you're always going to reconstruct the same
secret. And so this allows you to do GOT. So the only thing now is you have to
come up with access structure. So before we had a protocol that wasn't secure
but they argued security.
So we want to go a little bit stronger. So we used the universal composability
framework to show its security. And what that essentially entails, I think, I should
go less into detail about it. But what it entails is you have a real world and a deal
world where the simulator is kind of controlling it. And who only uses the actual
functionality. And you want to pretend that -- he wants to pretend that it's the real
world. And you make it so that it's indistinguishable. It's a bit complicated. But
essentially what we're doing is just a simulation of the protocol and using only the
ideal functionality.
So here, when we're saying -- when we're doing the sender simulation, we're
doing that there's the environment, there's the simulator, and then there's the
actual protocol. And we want to pretend -- we want to make it so that they're
indistinguishable.
Are you guys familiar with simulation-based security? Okay. So this is basically
in short it's basically a simulation so that you -- the real protocol and the ideal
protocol look exactly the same.
>>: The recipient is ->> Samuel Ranellucci: No, the sender is corrupt. The sender is corrupt. So the
environment is trying to cheat. And so the simulator just looks, and if he sees
anything inconsistent, he just aborts. That's basically what he has to do. And
then he can extract the messages and just interact with the ideal functionality.
And that's going to be the solution. Here it's the receiver that's corrupted, and
we're trying to simulate that. And so it's just simulating what the protocol would
look like. And the only flaw in this is that if he guesses S, if he tries to cheat and
guesses S correctly, well then that's the only case where the simulation really
fails. But that happens only with exponentially small probability.
Okay. So we showed how GOT -- we can do GOT. So what are the applications
of generalized oblivious transfer? So, first of all, K out of NOT then becomes
easy -- very easy to do. Because the complement of the access structure
associated through N minus K out of N secret sharing is exactly the set of
messages authorized by XK out of NOT.
So you execute N verifiable OTs and you can do any K out of NOT. So another
application of generalized oblivious transfer is something called batch
Single-Choice Cut-And-Choose OT. This is a very strong type of -- so you have
an N by S matrix of pairs of values. So just to make it -- I'll write an example
here. You have A, B, C, D, E, F and G, H.
And so there's -- and receiver, he can learn for each row either the first one or
the second one of each in the row. And then he can also learn both values in
half the columns. So, for example, if I have this, if I choose to learn -- if the
receiver chooses this column and for this row he chooses 0 and for this row he
chooses 1, well, the values he's going to get is A, C, D, and for this one he's
going to get F and G, H. And the first element of the pair and then he's going to
get both of these values, and he's also going to get both of these values because
he chose to learn this column, both values. And for this one he's going to get F
because it's the first one, the second one. And then he's going to choose -- he's
going to learn both because he chose this column to learn.
>>: Unusual variant. Are there applications to this that can't be achieved easily
with normal OT.
>> Samuel Ranellucci: Huh?
>>: Are there applications to this particular variant that aren't in normal OT.
>> Samuel Ranellucci: Yes. So -- well, in short, there's a way to define secret
sharing that uses the right access structure for this one that actually only uses
twice the size of the -- so you have two secret sharing schemes that I'm going to
use and like combine them together to give you an access structure. And then
there's an application -- so we're going to have ->>: [inaudible].
>> Samuel Ranellucci: Okay. Yeah, so there's going to be two basic secret
sharings that you're going to combine together. The first one is going to ensure
that you learn only the first or the second value for each row. And this is
basically you have an L out of L secret sharing. And then you divide it again
each share into shares. So that you can make sure that you learn only one value
per each row. And then you're going to use -- you're going to ensure that you're
only going to learn both inputs for half the columns. And that's the secret
sharing. And you're going to combine them, their shares together by con
indicatenating them and this is going to allow you to do batch single cutting
chose T.
What are the applications of this particular version of OT or the generalized?
Well, you have to do with yaw's garbled circuit. It's in the cut and choose
paradigm. Usually in the cut and choose paradigm what you're going to do,
there's going to be half the circuits that are going to be checked for consistency.
So you know that they're right. And then you're going to evaluate half of them.
And the big problem is that you have to do three things. You have to check the
circuits. You have to make sure that the first player uses consistent input and the
second one uses consistent input.
But what that single choice cut and choose OT allows you to do two of the three
things. It forces P1 to send consistent circuits because these are basically you
can think of these as the first -- the second players' inputs. You can either learn
the first -- the 0 value or the 1 value. And this is kind of forcing him to use
consistent inputs.
And the column is to check the consistency of circuits where he gets both keys
for the circuit. So this allows you to make sure that the circuits are consistent,
and that the second player always uses the same input.
And what's missing is that you want to make sure that the first player's input are
consistent. But you can use a combination of bit commitments, bit commitment
with exhort to do that.
Is that clear up to now?
>>: [inaudible].
>> Samuel Ranellucci: Yes, exactly. They're batch single choice kind of choose.
OT protocol. But they're D dependent on a very specific computational
assumption, while we have a very black box primitive for doing it.
Was anyone at crypto here? Okay. So do you remember -- so do you remember
the multi- -- did they actually use it? Okay. So the multi-sender K out of NOT is
another primitive. So every sender inputs a vector of N strings and then the
receiver inputs a set of indices of size exactly K. And so here each -- so the
receiver basically chooses the same -- so if we think of every player's input as a
row in a matrix, well, the receiver is going to choose certain columns and extract
those columns.
>>: The keys, just some other parameters.
>> Samuel Ranellucci: Yeah, it's one of the parameters. It's just multi-send K
out of NOT. So it's a parameter.
So ->>: As they said it's one -- the first message or second message.
>> Samuel Ranellucci: Or the second message for everybody. Can I have -where is the eraser? So here, for example, if the input from the sender is 0-1
and the second one is 1-0, well, he can either choose this one, and he'll learn
0-1, or he can choose this one, and he'll learn 1-0.
But there's many senders. So it's a bit different than generalizability is
transferred. Well, so how do we implement this functionality. Well, first of all, we
first think of it as a GOT. So it's a very simple GOT where you basically have a
GOT where you have a matrix and you just say that you're going to extract the
columns. And you kind of look at the shares like they are.
But that's the single sender and a single receiver. So now you want to extend
that to many senders and just one receiver. So is this clear the secret sharing,
that it's just linear -- you divide the shares, each share has a row and you take
the share and divide it and take each share and reshare it for each column.
Okay. So you can see that the GOT version is correct. So now we have to take
this protocol which only has one player and you make it so that there's many
senders instead of just one. So the way we do it is each sender generates the
share as in the GOT version of it. Instead of using any secret sharing we're
going to use linear secret sharing, so each player is going to have a row
associated to them.
So everybody is going to give them their row. And then they're going to add up
those rows and if they reconstruct all the rows, the sender should be, the receiver
should be able to extract the sum of the secrets. So if each player selects a
secret, then by combining these shares the resulting secret will be the sum of the
secret. So this is like the share combination.
And so to get the actual multi-sender K out of NOT protocol, what we do is we
combine the shares together and then each person uses those shares to do like
a K out of NOT for GOT using those shares, and then they're also going to
commit to their secrets and at the end what the sender should -- what the
receiver should reveal is the sum of the secrets and then they're going to
decommit to their secrets and we're going to verify that's correct.
Also, there's the things that you still have to check the consistency of shares and
all of that. But it all comes together.
>>: [inaudible].
>> Samuel Ranellucci: So it's the same access structure as the GOT version,
but instead you've got many secrets that have been combined into one. And the
senders have to commit to their secret and then reveal it so that certain senders
can't just change their secret so that it appears that like you recovered the right
secret when he didn't.
But the nice thing is that then each sender only has to use NVOTs with the
receiver and the receiver -- he has to do N squared verifiable Ts, but he only -each sender only has to do N verifiabilities, but the sharing cost is quadratic,
though, in the number of players.
So the applications of the multi-sender K out of NOT are relating to the IPS
compiler. And the IPS compiler is that you have an inner protocol and an outer
protocol where you have like in the inner protocol you have real players. And in
the outer protocol you have honest protocol for honest majority. Protocol that
sees if you have honest majority.
And if you try to cheat, what you have to do is corrupt at least the majority of the
outer protocol. But in IPS compiler you have a watch list where you're kind of
spying on certain players. And if you want to corrupt -- if you detect any
cheating, you abort. So in this compiler, there's a watch list where you're spying
on people. And then if you want to cheat you have to corrupt at least the
majority. But if you're corrupting at least the majority, well, if somebody is spying
on many -- spying on some of the virtual parties, then you'll be able to detect that
they're cheating.
So the multi-sender K out of NOT protocol was an important primitive to actually
optimize it. It's in the article. So it's a cheap way to spy on the virtual parties. So
something that's probably easier than what I've shown you is priced oblivious
transfer. So priced oblivious transfer is imagine you want -- you want to buy a
movie but you don't want to tell them which movie you want them to buy or you
want to buy many movies. And then each movie has a certain cost, and you pay
a certain amount like $30 and you say okay I'm going to buy movies for $30
worth. And then you say, okay, we're going to interact so that you buy those
movies but I don't know which movies you bought. And I'm assured that you're
not going to buy more than $30 worth of movies.
So the solution is that we're going to use weighted secret sharing where each
share has a weight W, WI and a set is authorized if and only if the weight of
those is greater than or equal than a certain number. So the trick here is just
say, okay, if you -- so the share is going to be the -- to extract the secret you're
just going to say that each share, each movie is going to have a share
associated to it that has the right price, that has its price as its weight.
And if you want to get more than the price, well, you're not going to be able to
extract the secret.
>>: Secret sharing is more efficient than just given WI shares of it?
>> Samuel Ranellucci: I don't know, honestly, which is actually one of my
questions. So here we've shown a couple of applications of generalized
oblivious transfer. And that can be instantiated through verifiability so we have K
out of NOT, which is a simple generalization. We have batch single choice cut
and choose OT which is very secure function evaluation and we have the
multi-sender K out of NOT protocol which was useful for the IPS compiler, its
optimization. And we also have price oblivious transfer. And think there are
many more, but haven't been clever enough to see more for now. I'm still
looking.
And future questions are what are more GOT applications? Is there more
efficient things -- can we do protocols more efficiently with it which is the
optimization. Also a missing part is we'd like to show that a lot of different
primitives, a lot of computational primitives can be used to implement verifiable
OT and we'd like it to be secure in the universal composability framework.
And also the last one is how efficiently can we implement different generalized
oblivious transfers, which has something to do with an access structure, access
structure.
Thank you. That concludes my presentation.
[applause]
>>: When you talk about efficiency, I have to admit I bristle a little bit when I see
people talking about, in and out of them [inaudible] secret share, because you
don't -- secret sharing is too colorful a tool for that. You can share it but just
creating a bunch of values whose XOR is the secret and you don't have to go
through all the secret sharing mechanism.
>> Samuel Ranellucci: Well, for the batch single choice cut and choose OT, it
was a bit complicated because you had to have learned half the columns you
learn both values and yet you have to also learn only -- you only should be able
to learn for those -- for those that are not in the columns you should only learn
ones that are not valued. So sometimes it's more complicated.
>>: Yeah, it's used as a component. Some don't have to bother the polynomials,
just do it?
>>: [inaudible].
>> Samuel Ranellucci: Yeah.
>>: Construction here is like black box?
>> Samuel Ranellucci: Yes.
>>: If you wanted to instantiate the instructions [inaudible] the most efficient
instantiation would be based on the assumption?
>> Samuel Ranellucci: I think it would just depend on -- I think all you need to do
is look how cheap is verifiable oblivious transfer. And I was saying that ->>: Intuitions of that?
>> Samuel Ranellucci: Some are -- it's getting to be like, I don't know,
something -- I think there's a lot of protocols per universal composable OT, string
OT and they require like 20 exponentiations, something like that. I think if you
take most OT protocols and try and transform into verifiable OT I think there's a
lot of room you can do that very simply because a lot of them as they said
followed the paradigm where you commit to your messages and then the
receiver sends a ciphertext and then the sender -- maybe I should go back to the
example, because I actually used something more general. But an easy way to
do homomorphic encryption is using an easy way to implement -- a lot of people
use homomorphic encryption to implement OT and so why -- I think I'll use the
board. So why homomorphic encryption is useful is because if you encrypt X 0
and if you encrypt X1, and you send it to the receiver -- receiver, well the
receiver, what he can do, is what he can do is he can calculate a C and then he
can -- he can then encrypt C and encrypt whichever message he wants to learn
with it. And this will give him the encryption of C plus XV. Right? And so there's
still a proof of knowledge to show that he actually did that. But then all he has to
do is then send -- we'll call this C prime. He sends C prime and then he'll send a
decryption of C prime, and this will allow him to just -- he just -- he learns we'll
call this M prime and he just does M prime minus C, and he gets XV.
This is pretty much blinding. If you want to transform this to a Bot, well, all you
have to do is take this and decrypt this and that reveals X 0. So it's -- it's another
thing to show that it's security but it's a very simple way of getting verifiable OT
conceptually. And that's why I think verifiable OT is a very sound primitive.
>>: [inaudible] is there a possibility of getting an extension type of version of OT?
[inaudible].
>> Samuel Ranellucci: Well, there's -- okay. So do you know by linear -- so
there's certain homomorphic encryption -- homomorphic commitments and I think
if you combine generalized oblivious transfer and they somehow rely on
homomorphic encryptions, homomorphic -- actually, perhaps you can also use
the homomorphic properties, for example, because of the plain text to do other
things like that.
So there's possibly extensions but I'm not sure how.
>>: [inaudible].
>>: Used a bunch.
>>: Speed up some.
>>: [inaudible].
>> Samuel Ranellucci: Okay. I was thinking of another thing so in batch single
choice OT, for example, they've actually got optimizations where they use,
instead of just doing one at a time, the OTs, they kind of do them in parallel, and
they use exponentially -- instead of one exponentiation they can do many very
cheaply rather than doing just one of them at the same time. So in that sense
there's optimizations that can be done.
>>: Batch.
>> Samuel Ranellucci: No, but maybe in general, general transfer, you have
verifiabilities and combine them and do them more efficiently than just doing
them independently.
[applause]
>> Samuel Ranellucci: Thank you for having me at Microsoft Research. It's
been a pleasure.