>> Seny Kamara: All right so it’s our pleasure to have Alptekin Kupcu
speaking today. Alptekin Kupcu is here as a visiting researcher. He is a
visiting professor at Koc University and he works mostly on cloud computing,
, security and cryptography. Today he will be speaking about
some of his recent work.
>> Alptekin Kupcu:
everyone for coming. So this
talk has two main parts. In the first part I will talk about one specific
protocol in a litt
le bit of detail and the second part will be kind of an
overview of our other work let’s say. As long as no one is in a hurry I am
not in a hurry so please ask me any questions that you want.
Okay. So I will talk about fair exchange first. So what is
fair exchange? I
will define it, what has been done on it previously and then what we did,
which is this efficient and scalable barter protocol and then our
implementation results on it. Then we will apply this fair exchange to a
case study in a peer
eer file sharing system. And then as I said in the
second part of my talk I will talk about other case studies regarding
cryptographic protocols for different cloud systems.
Okay. So let’s start with fair exchange; what’s fair exchange? In a fair
ange we have Alice and
they each have an item they would like to
exchange. So what does it mean that the exchange is fair? At the end of the
exchange either Alice get’s Bob’s item and Bob get’s Alice’s item or none of
them get anything. So that’s f
airness. Now fairness is trivial if we have a
trusted third party that we will call the Arbiter. Okay, why, because Alice
and Bob can just send their files to the Arbiter and then the Arbiter will
send the items. If he receives both of them he sends the
items otherwise he
Okay. So the interesting scenario here is what’s called an optimistic fair
exchange. That was introduced by [indiscernible]. Now what’s
>> In this a natural industry this Arbiter is called an escrow agent. If
have ever done a mortgage
>> Alptekin Kupcu: True, we will be actually using escrows; very good point,
we will get to that point.
So what’s optimistic fair exchange? We have this Arbiter, but it’s contacted
only if something goes wrong. Let’s
only in that case we
will contact the Arbiter. Okay. So we are optimistic in the sense that we
first start by assuming that everything will go okay. If everything goes
okay Arbiter is not involved, the protocol is very efficient and if
goes wrong the Arbiter will be involved.
Okay. What we want if something goes wrong is a guarantee that the Arbiter
will resolve the issue in some finite amount of time. Okay, time resolution
is necessary. So let’s see what has been done on
this and what we are doing.
optimistic fair exchange as I said as introduced by [indiscernible]
mainly as a contract signing protocol. So the items Alice and Bob were
exchanging are signatures on some message, some contract. They also provided
a file exchange mechanism. So Alice and Bob are exchanging files.
This file exchange mechanism requires another third party that we will call
the tracker. This tracker provides hashes of the file so that we can verify
that the file we received is inde
ed the correct file. Okay. And
unfortunately in their case the tracker must be involved in every exchange.
This is one of the
issues that we will solve. I
ndeed as part of our group at
Brown including Melissa here. So as part of our previous work we co
a buy protocol. So what does it mean for a protocol to be a buy protocol?
One of the parties item is money. The other
item is let’s say some
file. So I am buying a file by giving money. Okay. Of course what does it
mean? We also hav
e a third, third party called the bank. The bank needs to
handle money issues.
And the next one, this one I will be talking about in detail, this is what we
achieve, bartering, which is much more efficient than the other ones. And
here we will also us
e money, but only as a warranty. So in the worst case
our barter protocol turns into a buy protocol. So before we talk about buy
or barter let’s talk about electronic cash because we said we are using money
So in this scenario I will talk specif
ic to this endorsed e
construction, but you can think of it as a general [indiscernible] schema as
well. So we have Alice, Bob and the bank. So Alice can go to the bank,
withdraw some number of bank notes and then what she does is the following:
she takes one of these bank notes and she rips a piece of this bank note.
Now there is this ripped piece and there is the remaining bank note. Think
of this ripping process as unique.
nly Alice has the matching ripped piece
to combine it back to a full
So what we will say is that
we will call it the un
endorsed coin. She sends this to Bob and then the ripped piece we will call
the endorsement. Now Alice will perform a fair exchange of the endorsement
h Bob’s file to buy it. Once Bob obtains both the un
coin and the endorsement he can combine them back, get a full bank note and
then go deposit it to the bank.
Any questions here?
>> Why do you need the first tear? Why don’t you do the fai
r exchange on the
full bank note?
>> Alptekin Kupcu: Because this way it will be much more efficient. So just
very simplistically think this way exchanging a much larger item verses
exchanging a much smaller piece.
>> Alptekin Kupcu
: True, but I will get to that. I will also give efficiency
numbers and so on.
Okay. So now we are ready to see the buy protocol, the previous existing
work. So this is Alice, this is Bob and this is our Arbiter. The Arbiter
has an orange key, the c
olor coding is important, so he has an orange key.
What does it mean? The Arbiter knows the orange secret key; Alice and Bob
know the orange public key.
So the protocol goes as follows: Bob picks a black key of his choice,
encrypts his file and send i
t to Alice. Then Alice she wants to buy this
file. She prepares this un
endorsed coin and the endorsement, encrypts the
endorsement using the Arbiter’s orange key and attaches a contract to this.
The contract basically specifies that Alice is buying thi
s file from Bob and
giving him this coin. Now once Bob receives these he sends his black key so
Alice can decrypt and obtain the original file and Alice sends the
endorsement so Bob can combine this with the un
endorsed coin and
coin, okay, th
e bank note.
The problem in this scheme is this step with the orange encryption is a very
costly step. So if Alice and Bob would like to buy multiple files for each
file they need to perform this costly step. So the problem here is
definitely there is
a scalable efficiency problem. Of course it’s also not
good in terms of the bank because we are always buying stuff so all these
will be deposited, there will be withdraws and so on. So the bank is a
central entity, this is not good.
The solution is b
artering, so no money changes hands if everything goes well.
So we will see how to do it fairly, efficiently and scalab
y. This will
save the bank from more work and this will actually be much better then done
over multiple files. So let’s see our ba
rter protocol. We again have Alice,
Bob and the Arbiter. The Arbiter as before has his orange key. Now he also
has a blue key. There are two separate keys of the Arbiter at this point.
So Alice will again prepare this un
endorsed coin and the endorse
encrypt the endorsement with the Arbiter’s orange key as before. And she
attaches a signature to this encryption. Then Bob picks a black key of his
choice, encrypts his file,
it. Now this is a barter remember, two
files are being exch
anged, so Alice will also encrypt her file with her
choice of green key. Then she will encrypt the green key with the Arbiter’s
blue key, not orange, blue this time. She attaches the contract specifying
these files are being exchanged and the matching si
gnature to make sure this
endorsement can be linked to this exchange.
By the way,
when ever I say signature that’s not really true. I will show
the underlying system, but for now you can think of it as the only purpose
being able to match this message
with this message. Okay, that’s the purpose
it serves. Any expectations of how the protocol will proceed; any guesses?
>> Do the two signatures cancel out?
>> Alptekin Kupcu: Forget about the
remember our goal is to
exchange two files s
o what should we do to exchange two files? What does
Alice need to obtain Bob’s file?
>> The black key.
>> Alptekin Kupcu: The black key, thank you. So Bob sends the black key and
now the response of Alice?
>> Green key.
>> Alptekin Kupcu: Gree
n key, that’s the whole protocol. If something goes
wrong, for example Alice chooses not to send her green key. She has already
obtained the black key, so Bob’s file, she already has it. In this case Bob
will take the messages from Alice to the Arbiter
and the Arbiter
will see the details, be able to give him either the green key of Alice or
the endorsement of Alice’s coin.
>> [inaudible] if it’s the green key that was under the blue key in that
>> Alptekin Kupcu: Yes, we will se
e, exactly. So it will be either the
correct green key or the correct endorsement, but either, that’s important
because if Bob manages to get both he has an advantage. So if Bob didn’t
send his black key
>> So [inaudible] is garbage?
lptekin Kupcu: Where?
>> In the green, is that what you are saying?
>> Alptekin Kupcu: This green key is garbage or
>> Alptekin Kupcu: Then what will happen actually is Bob will obtain Alice’s
>> But how?
Kupcu: Let me get to the details in a few slides. I will get to
the details. If Bob let’s say doesn’t send his black key then Alice will
contact the Arbiter again presenting this contract and then if Bob has given
his black key to the Arbiter she will o
btain it. As I said I will tell you
more details about this resolution.
Now what’s important about this protocol? So we still have this orange
encryption that was costly. That’s what we were trying to get rid of. The
beauty of this protocol is once t
his costly step is done the remaining very,
very efficient pieces of the protocol can be repeated as many times as needed
to exchange as many files as needed. So if you want to exchange multiple
files we do this costly step once and the remaining steps ar
e all efficient.
Okay, now the resolutions. So remember this is our protocol. If Alice
doesn’t send her green key what happens? So in this version that I am
describing there is a timeout, a global timeout, not necessarily global.
Let’s say a timeout
that Alice and Bob agreed to before hand. And Bob has
restricted that he must contact the Arbiter before the timeout. So let’s
assume that he goes there before the timeout, he presents these messages from
Alice. So the Arbiter as the first step will ge
t Bob’s black key, he will
store it and then of course this black key must satisfy this contract, he
also checks that.
Then he decrypts this blue encryption and obtains the green key of Alice. He
gives that green key to Bob. If this green key works Bo
b is happy and he
goes home. If the green key doesn’t work as Seny was suggesting then Bob can
take this encrypted file of Alice together with this green key and this
contract, he can prove this green key doesn’t satisfy the contract. Once he
the Arbiter will now decrypt this orange encryption and give Bob
Alice’s coin essentially. So now this turned into a buy protocol. Bob
wasn’t able to obtain Alice’s file, but he was able to obtain Alice’s coin.
>> What did Alice’s encrypted [indiscer
nible] her coin?
>> Alptekin Kupcu: She won’t be able to as in a moment we will see what’s the
underlying encrypted. What if Bob doesn’t send his key? So Alice needs to
contact the Arbiter. In the worst case she needs to wait until after the
Let’s say she goes after the timeout and she presents the contract.
If Bob has contacted the Arbiter before the time
out and has given his black
the Arbiter will send this black key to Alice. If Bob hasn’t contacted
the Arbiter then there won’t be
any black key so Alice won’t be able to
obtain it, but if Bob contact the Arbiter later on the Arbiter will refuse to
help him anyway. So now they both end up obtaining nothing, so the exchange
is still fair. And since this resolution happens in the wors
t case at the
timeout we also have time resolution.
Okay. So what are these nice looking figures, these orange boxes, etc? So
let’s reveal some basic cryptographic primitives that we will use.
Encryption: we will use symmetric key
encrypt the file F
with the key K to obtain a ciphertext C.
>> So what if Bob claims he received garbage, but actually received the file,
can he still get the money?
>> Alptekin Kupcu: Here at this step
>> Alptekin Kupcu: Very g
ood point, normally I leave this outside the scope
of this talk so I can show you the details later on. But, here Bob is
supposed to show that this green key that the Arbiter provided together with
this ciphertext does not match the contract. So the cont
ract in reality
contains the hash of this ciphertext so he cannot claim to use a different
ciphertext here and the hash of the plain text that this green key is
supposed to decrypt this one. So in the worst case in a very inefficient
manner you can think
of it as Bob sending the whole ciphertext, the Arbiter
decrypting the whole ciphertext and comparing with the hash. But there is a
much more efficient way we can do it without Bob sending the whole file.
Okay. So back to encryption, we can encrypt the
file with the key, get the
ciphertext and decrypt it back with the same key to get the same file.
Signatures: we can sign a message with a secret signing key, obtain a
signature and we can verify a signature on a message with a public
verification key. E
scrow: So what’s an escrow? An escrow is simply put, an
encryption under the Arbiter’s public key together with some public label.
So we encrypt some value under the Arbiter’s public key and attach a public
label to this such that essentially decryption
is not possible without the
correct label. Okay, the label is public, but you cannot modify the label.
What’s a verifiable escrow? It is an escrow, okay, so it’s an encryption of
some value under the Arbiter’s public together with the label, but it’s
verifiable in the sense that we can verify the contents of the escrow without
decrypting, with only knowing the public key of the Arbiter, the label and
the relation we want to verify. So without decrypting we can verify that the
value here satisfies some
relation. For example what relation we can use
this endorsed e
cash. So remember endorsed e
cash has an unendorsed coin.
Let’s denoted it with coin prime and the endorsement let’s denote it with
end. So we can verify if the endorsement matches the une
without decrypting, that’s the key.
So this was our protocol let’s replace each one of these with real
cryptographic primitives. So what’s this?
>> The unendorsed coin.
>> Alptekin Kupcu: The unendorsed coin, so coin prime in our case
. Now this
blue encryption is a verifiable escrow. So within the verifiable escrow
there is this endorsement and I slightly cheated by saying this is a
signature. It’s indeed a public key for a signature scheme. Alice just
generates a new public key an
d puts it as the label of the verifiable escrow.
This one is very
Bob has his own black key. Sorry, of course before
that Bob needs to verify if this endorsement matches this coin prime. If it
does then he continues, picks his own key, key of Bo
b, encrypts his own file
and obtains a ciphertext. Alice will do the same, pick her own key, encrypt
her file and obtain the ciphertext.
Now this blue one, the orange one was verifiable, this one is a regular
escrow. So the regular escrow of Alice’s k
ey, so this green key. Now what’s
the label? The label, the contract specifies hashes of these files and
ciphertext and some time allowed to be used for the timeout. Then she also
signs this escrow such that the signature must verify under this public k
This is how we link this verifiable escrow to this escrow.
So Bob does two things: he checks the contract, he checks if the hashes are
the same as he knows and that the time value is not extremely different. We
can tolerate large timeouts in the s
ense that if there is a network failure,
let’s say Bob didn’t send the message, but within five minutes his network is
restored he can just go resolve. So the resolution can be done in five
minutes. But if we want to tolerate larger issues this timeout c
an be much
larger. He also verifies that this signature verifies under this public key.
If so he sends his key and Alice sends her key.
More questions? Yes?
>> What about the coin? I am not familiar with [indiscernible]. So once Bob
has the coin
and the endorsement he can somehow claim it, the money that’s
behind this, right?
>> Alptekin Kupcu: Exactly, so he can combine this endorsement and this coin
prime, the unendorsed coin to a full bank note remember and use it.
> Alptekin Kupcu: Alice can.
>> Alptekin Kupcu: Sure she can. This is one of the major dilemmas of
[indiscernible] schemes. So you either have offline [indiscernible] schemes
where yes Alice can reuse this coin multiple times, but the
n she will
eventually be caught and penalized or online [indiscernible] schemes where
each time a coin is used the bank needs to be involved which is centralized.
>> I have a question about E, because you said verify E, but it’s not a
verifiable E for es
>> Alptekin Kupcu: This E, the escrow?
>> Alptekin Kupcu: So we don’t verify the escrow. This is a regular escrow,
not verifiable. We verify the signature on the escrow.
>> And where do you get the azure of F?
>> Alptekin Kupcu:
These ones, these azure’s?
>> Alptekin Kupcu: So remember the tracker that we mentioned. So the tracker
gives us these hashes in the sense that the definition of this exchange is at
the end Alice will receive a file that matches this hash an
d Bob will receive
a file that matches this hash. When we use it in peer
peer file sharing
it will be even more clear.
Okay. What about privacy? I will quickly skip the signature keys and
encryption keys. They are all random we can generate it ea
ch time we want to
use a new one. If you are using e
cash as the payment, e
cash is anonymous
and resolutions are anonymous. The Arbiter only needs to know if you are
playing the role of Alice or the role of Bob, but doesn’t need to know who
. [indiscernible] for anonymous communication
techniques to enhance privacy if we want.
We also have a generalized version. We can use any form of electronic
payments that can be efficiently verifiably escrowed. So that’s the whole
of using endorsed e
cash. It proved anonymity and an efficient way
of verifiable escrows, but if you don’t care about anonymity we can just use
electronic checks, verifiably escrow them and done. We can use any
verification mechanism. We are using hashe
s to verify that the files we
exchange are the correct ones. If you want to exchange signatures then we
can use let’s say a public key infrastructure. So the contract needs to
contain the public keys.
If you don’t like timeouts, I told you that the ti
meouts are not a big
problem, but if you really don’t like them we have a version without
timeouts. The only difference is that instead of this single costly setup
step we have two setup messages. So it’s twice the costly setup, but the
rest is almost as
efficient. We have implemented all these, I will quickly
go over, but all these buy and barter protocols: verifiable encryption,
cash, etc using C++. We have done some improvements over existing
protocols such as multiple coin denominations
useful if you want to
exchange multiple files at once.
So we just in some sense [indiscernible] them, exchange them as a single
file, but now if it turns out to be a buy version, if I am sending you 5
files the coin should be [indiscernible] in
some sense 5 dollars let’s say,
okay, 5 [indiscernible]. There are other improvements even over the old buy
protocol and so on. This one, ZKPDL I believe Sarah ha
s given a talk here
with all these extensions and improvements what we have ach
as our goal is being able, hopefully,
efficient use of advanced
cryptographic techniques for cloud protocols.
I keep claiming efficiency so let’s see how efficient this is. So for barter
we have this setup phase a
nd then this per file part. T
setups take about
less then 1 second and let’s say 45KB, b
ut once we do the setup the rest is
something like 20MS and 1KB. The rest is extremely efficient. We can keep
exchanging as many files as we want. And if you compare it to the old buy
it’s essentially the total of these. So you would need to do this
for each file.
>> [inaudible]. Is that because Alice is the one tearing the bank note in
>> Alptekin Kupcu: So yes, there is the electronic cash cost plus verifiable
ption cost. Verifying verifiable encryption is faster then really
Okay. We have this efficient and scalable barter protocol, what do we do
with it? Let’s look at the case study as peer
peer file sharing. So
some background, this i
s slightly old, it’s probably around 40 percent
but it doesn’t matter. So,
about half of the whole internet traffic is due
peer file sharing. Probably almost the other half is due to
Okay. So this BitTorrent is the most popul
peer file sharing
protocol so we will take it as our case study. There are these trackers, so
these trackers serve two purposes in some sense. One is they keep a list of
peers so other people who are in the system and these torrent files. The
torrent files are the files that contain the hashes.
hen I go to the
tracker and obtain this torrent file now I know what the hashes are. So if I
am downloading something I can just hash it, verify it against the torrent
file and this is how I know i
t’s the real file.
By the way this PirateBay tracker BitTorrent has many, many trackers. This
one largest tracker, only that one has
about 40 million active users, a
meaning uploading or downloading at any given time. So right now there are
llion people using PirateBay. Of course the way we will use it is fully
legal for example some Canadian Public TV Channel broadcasts are aired, some
Norwegian film makers use it to distribute their films. So it’s a content
distribution system. Linux dis
tributions are using BitTorrent.
So how BitTorrent works is we have Alice, this is our tracker, Alice goes and
talks with the tracker. The tracker gives her this torrent file and a list
of peers. Some of these peers will be seeders, they have the whol
Some of these will be
they have parts of the file. Now files are
exchanged at a block by block basis, not the whole file. So Alice
exchanging blocks, t
he moment she has some blocks she can start also giving
some of those to othe
Currently BitTorrent uses an un
fair exchange system. So let’s say if Bob
wants to cheat he can get Alice’s file without giving away his file. We can
use the buy protocol to achieve fairness in BitTorrent, but this will be
costly or we can
use this barter protocol to achieve fairness where e
remember only used as a warranty system; only if things go bad. And if we
>> So with e
cash you have a bank, right?
>> Alptekin Kupcu: Yes.
>> So how does [inaudible]?
lptekin Kupcu: So bank, there are multiple issues here, you are right.
First of all we can easily think about the bank being there even without P2P
because we are using e
cash. The alternative is you can just say, “I don’t
want any cash value, his is a b
ank only for peer
peer exchanges. It
doesn’t have any monetary
it’s some kind of a credit”. Both of them
>> [inaudible]. So if you use e
cash and some central kind of [inaudible].
>> Alptekin Kupcu: Yes, good. So remember w
e have the tracker as a
centralized entity, but why do we still consider this peer
because the tracker is contacted only once in a while. When I am joining the
system I get the list of peers. So the bank I can withdraw multiple bank
at once. So I need to contact the bank only once in a while. And
remember if you keep bartering no money changes
there are no deposits,
nothing, so still I don’t need to contact the bank much.
So if you compare the previous most efficient proto
col which is the buy
verses our barter protocol you can easily see that there’s an O order of N
efficiency improvement if there are N blocks that are exchanged. The nice
thing about our protocol is that when we are doing this setup we don’t need
to know h
ow many blocks we will end up exchanging. We don’t need to even
know which block we want to exchange next. We do this setup and then we can
exchange what ever we want.
So if you look at this BitTorrent case study there is an average file size of
2.8GB containing roughly 2500 blocks, downloaded from let’s say about
40 peers. If Alice and Bob buy every block from each other for a 2.8GB file
they need to spend extra 225MB just for the crypto and 42 minutes just for
the crypto. So if you use some s
tandard download times this corresponds to
roughly half of the time for just downloading the regular file. So 2.8GB
file I would download in about 1.5 hours, but just to do this fair buy
protocol I need to spend another 42 minutes.
If Alice and Bob bar
ter every block the total overhead for a 2.8GB file is
only 1.8MG and only 40 seconds extra on top of the 1.5 hours you need to
download the file. So I claim that for the first time now we can really use
a fair protocol in a high
churn system such as BitT
orrent because we managed
to obtain these two orders of magnitude gain succession. You can download
the implementation, the Cashlib is already online. We are adding more stuff
to Cashlib currently not related to this, but hopefully we will release them
n our group website.
ny questions about this first part before I switch to the others?
>> So did you integrate your code and plugged it into BitTorrent or is it
just like simulation re
>> Alptekin Kupcu: Some colleagues of us were indeed usin
g our code in
LibTorrent library, but unfortunately these are not the results. It’s not
simulation it’s just measuring the crypto part.
Okay. Maybe you need to erase this part from the recorder. If you download
some movie illegally then this movie, w
hatever association, what was it
>> Alptekin Kupcu: MPA, yes. They will sue you if they catch you of course.
If they sue you they will generally settle down for just the 4000 dollar fee.
This is just to convince people not to downlo
ad by example.
>> If you use fair exchange [inaudible].
>> Alptekin Kupcu: Yes.
>> Who is the other trader?
>> Alptekin Kupcu: So we need that extra entity called the Arbiter.
Unfortunately it’s a proven result that you cannot perform a complet
exchange without an arbiter; you can’t do it efficiently.
>> Well sometimes we use very strong TTP, Trusted Third Party. In practice I
mean, in practice we usually trust some large company to organize world
peace. So this can be very efficient, m
uch more efficient then others; this
kind of protocol. So if we use this protocol we have to have some advantage
or some, in practice I mean, theoretically it’s much better. In practice
many people [inaudible].
>> Alptekin Kupcu: So if you are worried
about efficiency as I said if you
just spend 1.5 hours for the whole file, 40 seconds I claim is neglectable
let’s say. On top of that if you want at the end I can also show some
performance numbers for the Arbiter. So will the Arbiter be bottlenecking
some sense. But let me leave it until the end of the talk.
peer might have multiple [inaudible] so we need to set up for
every one of them?
>> Alptekin Kupcu: Exactly, so remember these numbers assumed that this file
is downloaded on a
n average of 40 peers. So this includes 40 setup cost
Okay. So let’s go to the other works. So I view cloud as having let’s say
two main types of systems. One type is we outsource some job to a more
powerful entity. For example maybe I sh
ould have changed the slide to
Microsoft products. So we can outsource our competition to Azure storage
again and then we can even outsource file distribution, things like
RapidShare. That’s exactly outsourcing file distribution. They have huge
They can handle much more then our own computer capabilities.
What’s the other type? The other option is to ou
tsource to multiple
or example SETI@Home. Did anyone use SETI@Home or any other at
home project? So what are your experiences?
>> It works.
>> Alptekin Kupcu: It works, good. So we can use outsourcing that way. So
what they do is a central server essentially outsources jobs to our own
computers. Wuala, they switched from being peer
peer, but it was a peer
system. So you can outsource your storage to other peers or
for example things like Napster, again we are outsourcing the distribution of
our files to peers; so multiple entities. Of course the problem in both
scenarios is that there are no service
guarantees, resources are
not under our control and the setting is not trusted. We already talked
about this scenario in the previous part of this talk.
So in the next part I will be summarizing what we can do to outsource the
competition to regu
lar users, outsourcing storage and then in all these
scenarios we will be addressing these issues. We will provide security
guarantees even in an un
trusted setting, even though the resources are not
under out control.
So let’s look at current generatio
n cloud computing. What’s Amazon
>> It’s a cloud sourcing platform.
>> Alptekin Kupcu: It’s a cloud sourcing platform so we are actually
employing human contractors. They are un
trusted of course. The interesting
thing is the emplo
yer must be satisfied before paying the money, but what’s
the job? What’s the meaning of satisfaction? These are not well defined.
Another option is SETI@Home. In SETI@Home you earn these credits for
reputation; they have no monetary value. The idea i
s that they outsource the
same job to two contractors and they need to return the same result for the
result to be accepted. Now is this secure enough is a different issue, but
it is a well defined job.
Unfortunately you can’t take back credits and the
re are no guarantees of the
correctness of the results. What we can do for the next generation, this is
slightly old work, although we are working on an improved version currently.
We can use Game Theory and Mechanism design techniques together with
tography such that a boss can outsource a job to multiple contractors.
Some of them are honest, some of them are rational and some of them are
malicious. By properly fining and rewarding them, fining the malicious ones,
rewarding the honest ones we can
all the contractors to act
honestly. Furthermore we can limit the damage done by the malicious
contractors. We can provide
guarantees on what they can or can’t
>> Does this have to be done with fines or can it be done all with
and different level of rewards?
>> Alptekin Kupcu: I believe you definitely need fines. I don’t have an
[indiscernible] result on that, but the previous systems without using fines
all failed to provide such guarantees.
>> How can you fine som
eone in this SETI@Home for instance if you can’t take
>> Alptekin Kupcu: So what we are in some sense suggesting is there should be
a mechanism where they can take back credits. And when I said we are working
on this recently is for examp
le we are integrating this with some e
escrow based mechanisms to be able to guarantee payments of rewards and
guarantee payments of fines.
>> I don’t see anything about malicious computation, but in the day before
computers there were big compu
tation bureaus who would outsource computation
to [indiscernible] of people and there must have been mistakes and they must
have had procedures for dealing with this. The trouble is that all the old
doctrine for doing it is dying as people age out. Someb
ody could cash it
>> Alptekin Kupcu: True, although I still don’t know, I would really doubt
that they have provable results on
malicious guys can do. So we
have results that even if you are fully malicious, let’s say trying to make
ccept incorrect results, let’s say you can only make us accept 1 percent
in incorrect results. Things like those, so we have proven results. And we
will be utilizing an implementation of this next month.
Okay, so this is computation. Let’s switch to
storage. Let’s look at the
current generation cloud storage. These are license agreements saying that
Amazon can corrupt, delete and destroy our files, Google does not warrant any
security and so on. So this is all bad. What can we do in the next
ation? So we have this client who has some precious data to store at an
trusted search. So the client sends this data to the server and
later on can challenge the server to obtain a proof that this data is kept
intact. This work has been do
ne by [indiscernible] and [indiscernible] in
terms of these PDP and POR techniques.
What we did as part of my lunch talk was to make these dynamic where the
client can keep updating her data, get proofs of updates, can later challenge
it, get a proof an
d so on. And again I will claim efficiency here. Remember
this talk is a efficient cryptography for the next generation secure cloud.
So each time the client
to let’s say commit an update, so these are
real numbers from real CVS repositories. Th
ere will be an overhead of about
10KB and 1MS.
Now all the previous works in this cloud storage setting, they consider this
challenge proof protocol, but none of them say anything in the case the proof
fails. If the proof doesn’t verify what should the
client do? What we show
is that the client and the server should be able to contact a judge who can
rule based on the cryptographic protocols proofs that they provide and again
this should be efficient. So since there is no previous work we compare it
ith a naive version of achieving this. Our overhead is less than 100 bytes
and 2 MS for each time we need to
verses a naive one would be 25 KB
and 1 second for each update. So if you consider this CVS repositories that
have use many, many commits
over time the naive version would require 61
and 7 hours of overhead, w
hereas in total it requires something like 2 MB and
Okay. So now we talked about this Arbiter, trusting the Arbiter. So it’s a
central entity we need to trust here.
A natural question is: Can we replace
this Arbiter with multiple entities? Maybe some of them are trusted, but
then some of them are un
trusted, they are evil? So can we do this? There
is a very easy answer, yes we can if you are willing to use generic
[indiscernible] or [indiscernible] type of techniques. If you are willing to
incur this quadratic cost of communication and so on.
So now we want to do it efficiently remember. Can we do it without this
communication only using autonomous entit
ies to construct an Arbiter? Now if
you only use autonomous entities unfortunately we show that this is not
possible in the sense that existence of even a single malicious entity
destroys the whole fairness. And this holds true even if we are willing to
trust some K out of N Arbiter or if we want to trust some particle or subset
of these Arbiters. We can overcome this impossible result if we are willing
to assume a synchronized clock. And there is a protocol by [indiscernible]
achieving. What we show i
s that essential data protocol is optimal in the
number of honest Arbiters required even in this timeout setting.
Okay. This should be the last one. Authentication: So the current
generation, how does it work? Again we have our client and the server.
client registers by sending a user name and password of her choice. The
server stores this in a database and later on when the client wants to log in
she sends the same username and password. The server checks it against the
database, verifies if i
t’s there and done. In the best case currently what
we will do is instead of just sending the password we will send the hash of
the password. So the server will keep a database of user names and hashes of
Now what does it mean? It means a
dictionary attack can recover the
password. And even if you trust the server, even though I trust Microsoft not
to perform a dictionary attack on my password if a hacker hacks in to the
server they can get my password. There was a breech that stole 32 mil
passwords. About half of them were susceptible to dictionary attacks. And a
fun fact, the top password was 123456.
>> How many?
>> Alptekin Kupcu: 300,000 people.
Okay. This is the current generation; what can we do in the next generation?
So for the next generation the client should register her user name with a
verification key. This cannot be a deterministic function of the password as
in the hash of the password. This must be a verification key for a
significant scheme. So the server
stores it and when the client wants to log
in now this a challenge response type of protocol. But we care about
usability. So if the client needs to keep her signing key on her lap top
then she can’t sign in from let’s say her phone, her desktop and so
So instead what we do is we show that we can store this sign in key, encrypt
it in the cloud with a password and we prove, sorry
. We have other
extension that instead of the cloud the client can use a mobile phone, a
smart phone or not even a sma
rt phone just a regular mobile phone will be
perfectly okay. We don’t need enhanced capabilities. And by this method
what we provably show is that a dictionary attack is not possibly and this is
>> Is there an assumption here that if
you do a search through password space
you won’t be able to tell whether or not you obtained the [inaudible]?
>> Alptekin Kupcu: There are very nice underlying assumptions. One is that,
so this sign in key may be depend on the scheme, but for many sche
are in use it’s true. This sign in key is some random value. Now if you
encrypt a random value password there is no way to perform a dictionary
attack because you cannot verify whether or not the password you tried
decrypts correctly. Now the o
nly way to verify your password attack is to go
talk to this server and try to log in. So we are essentially forcing all the
password based attacks to be online attacks. So offline dictionary attacks
>> Alptekin Kupcu:
Exactly, unless this server, the cloud or your cell phone
is [indiscernible]. You can do secret sharing to make it harder though.
>> I mean the verification keys.
>> Alptekin Kupcu: No, this is stored at the server. This is the server this
is the cl
oud, so somewhere else, some other place. So the person who knows
your encrypted sign in key doesn’t know your verification key. The person
who knows your verification key doesn’t know your encrypted sign in key.
>> It’s kind of
s not public, [indiscernible].
>> Alptekin Kupcu: In the sense that only this server knows it. Actually
multiple servers can know it, but
>> So is this just an identification protocol and then
. So you just do
identification protocol to l
ogin and then
>> Alptekin Kupcu: This is like very
you sign the challenge return
and return the signature.
>> Right and so then
>> Alptekin Kupcu: So as long as this server and this cloud don’t join
together against you there is no pro
blem. If you are worried that they will
join together even though let’s say this is Microsoft and this is Google what
you can do is split this sign in key to multiple shares. Store one share in
Google, one share in Amazon, one in Facebook, etc.
then you just need an encryption scheme and identification protocol for
[inaudible] and that’s it.
>> Alptekin Kupcu: It’s not even a [indiscernible] protocol, simple
signature. Of course you can get a signature from signal, but
>> But, I mean, ye
ah, you just need something that’s basically your knowledge
so that this server can’t go and impersonate you later and then you encrypt
>> Alptekin Kupcu: You don’t need full zero knowledge I mean in the sense
that if I give you my verification ke
y you have some knowledge about my sign
in key. That’s not full zero knowledge, but you still can’t sign on my
>> You just need verification that’s weaker then your knowledge.
>> Alptekin Kupcu: Exactly.
>> But that’s basically an [
>> Alptekin Kupcu: Okay. So this has been a long talk. Thank you for
bearing with me. What we have talked about is we started with networking
issues in the cloud in this peer
peer setting and the fairness issues
there. We talked about i
mplementation. We have some work on energy
efficiency as well that I haven’t talked about. We have talked about
computation, outsourcing computation, outsourcing storage in a dynamic
setting etc. And then Arbitration, but if the storage proof fails trus
issues, how we can distribu
te these Arbiter’s and so on a
authentication and usability issues.
Future work: I will quick
ly skip, but you can guess. So, more on outsourced
We have a distributed version that’s been published recently
computation as I said is work in progress. We have another work under
submission about outsourcing databases to the cloud. We have more work on
peer systems, economics, game
theoretic modeling of these and how we
use for example these fa
ir exchange protocols maybe in multi
computation settings or what else we can do in terms of this usability.
t notice about usability here: W
e said you also have a version of
authentication where you can use your mobile phone. If you are re
enter a long string to your mobile phone no one will use it. So we have many
versions of these protocols and we claim all of them are easy to use. And we
have versions where you can for example get more privacy out of your
s, of course in return for some efficiency.
Let me thank my collaborators. So some of these guys you know. Anna you
know, Tolga, Sarah, Babis you know. Roberto you probably know, Mira you
know, Melissa. And these are my collaborators from Koc Univers
ity. I want
to thank them all and of course I want to you.
>> The problem is that like when you are given some signature, signatures are
public even though the verification key is not public.
>> Alptekin Kupcu: Okay.
>> If you are giv
en the signatures can we verify some secret key is the
correct one or not. So maybe I need to check [indiscernible]. So it’s a
different problem. [indiscernible]. The secret keys random or not, it’s not
random [indiscernible]. So some signatures can s
>> Alptekin Kupcu: Yes, definitely we need a sign in key that is
indistinguishable from random essentially here and furthermore in practice
whenever you want to deploy this and use it we are assuming as is in the
current case this is all do
ne over SSL. So we are not modifying this
structure. Essentially what Microsoft can do is can use it only for their
single sign on server and then at the end of this process they can issue us a
ticket where I can use it to sign into other sites. So the
need to change as long as few single sign on servers like Microsoft Passport,
let’s say Google accounts, Facebook. If they change their scheme to this and
now suddenly all these single sign on type of sites are provably secure
>> So going back to the bank thing. So the kind of obvious question: the
PDP, having a central bank just probably is [inaudible].
>> Alptekin Kupcu: If t
he bank has a lot of job to do, l
ike if we are buying
h, we also need to trust this bank to actually be honest and if
[inaudible]. So the obvious question then is can you [inaudible]? Like is
that an easy replacement where you can just say, “Let’s just forget about e
cash as we think of it in terms of crypt
o things”? You know the standard e
cash can we replace with [inaudible]?
>> Alptekin Kupcu: So I guess we need to look at two issues. One, as far as
I know Bitcoin doesn’t have a security proof. I mean we may loose our
provable security here, but you
may say, “Okay, I am willing, I want to trade
it for efficiency”. Now the second thing is we want to check
>> Alptekin Kupcu: Distribution, but we still want to be able to verify the
escrow. So can we efficiently verify the escrow
of Bitcoin? I don’t know,
that may be an interesting thing to look at.
>> So these verifiable escrow things, are these like very structured types of
encryption schemes or what?
>> Alptekin Kupcu: So the reason I talked about a particular e
called endorsed e
cash is because this endorsed e
cash together with
[indiscernible] verifiable encryption they work extremely well. So normally
how can you obtain verifiable encryption? You encrypt something at a zero
knowledge proof to that.
it’s like [inaudible]?
>> Alptekin Kupcu: Yes, so it’s discrete [indiscernible] based actually.
>> Seny Kamara: Any more questions? Okay, thank you.
>> Alptekin Kupcu: Thank you.