>> 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,
P2P networks, security and cryptography. Today he will be speaking about some of his recent work.
>> Alptekin Kupcu: Thanks’ Seny and thanks’ everyone for coming. So this talk has two main parts. In the first part I will talk about one specific protocol in a little 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-to-peer 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 exchange we have Alice and Bob; 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 fairness. 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 doesn’t.
Okay. So the interesting scenario here is what’s called an optimistic fair exchange. That was introduced by [indiscernible]. Now what’s --. Yes?
>> In this a natural industry this Arbiter is called an escrow agent. If you 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 say Bob cheats; 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 something 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.
So, with 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 indeed 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. Indeed as part of our group at
Brown including Melissa here. So as part of our previous work we considered 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 party’s 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 have 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 use 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 here.
So in this scenario I will talk specific to this endorsed e-cash 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:
So 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. Only Alice has the matching ripped piece to combine it back to a full bank note.
So what we will say is that the remaining banks note we will call it the unendorsed 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 together with Bob’s file to buy it. Once Bob obtains both the un-endorsed 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 fair 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.
>> [inaudible].
>> 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 color 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 it 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 this 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 obtains the coin, okay, the 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 bartering, so no money changes hands if everything goes well.
So we will see how to do it fairly, efficiently and scalability. 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 barter 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 endorsement and 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, and sends it. Now this is a barter remember, two files are being exchanged, 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 signature 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 signatures; remember our goal is to exchange two files so 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: Green 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; we 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 second one?

>> Alptekin Kupcu: Yes, we will see, 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 --. Sorry?
>> So [inaudible] is garbage?
>> Alptekin Kupcu: Where?
>> In the green, is that what you are saying?
>> Alptekin Kupcu: This green key is garbage or –-?
>> [inaudible].
>> Alptekin Kupcu: Then what will happen actually is Bob will obtain Alice’s e-coin.
>> But how?
>> Alptekin 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 obtain 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 this 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 are 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 get 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 Bob 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 proves that 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 [indiscernible] 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 timeout. Let’s say she goes after the timeout and she presents the contract.
If Bob has contacted the Arbiter before the timeout and has given his black key, 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 worst 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 encryption; we will 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 --.
>> [inaudible]?
>> Alptekin Kupcu: Very good 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 contract 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. Escrow: 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 unendorsed coin, 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 and puts it as the label of the verifiable escrow.
This one is very simple; 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 Bob, 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 key, 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 key.
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 sense 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 can 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.
>> [inaudible].
>> Alptekin Kupcu: Alice can.
>> [inaudible].
>> 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 then 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 escrow.
>> Alptekin Kupcu: This E, the escrow?
>> Yeah.

>> 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?
>> Yes.
>> 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 and Bob will receive a file that matches this hash. When we use it in peer-to-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 each 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
Alice is and who Bob is. [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 purpose 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 hashes 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 timeouts 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, endorsed e-cash, etc using C++. We have done some improvements over existing protocols such as multiple coin denominations that are 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 has given a talk here before. So, with all these extensions and improvements what we have achieved as our goal is being able, hopefully, is 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 and then this per file part. The setups take about less then 1 second and let’s say 45KB, but 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

protocol it’s essentially the total of these. So you would need to do this for each file.
Yes?
>> [inaudible]. Is that because Alice is the one tearing the bank note in two?
>> Alptekin Kupcu: So yes, there is the electronic cash cost plus verifiable encryption cost. Verifying verifiable encryption is faster then really encrypting it.
Okay. We have this efficient and scalable barter protocol, what do we do with it? Let’s look at the case study as peer-to-peer file sharing. So, some background, this is slightly old, it’s probably around 40 percent now, but it doesn’t matter. So, about half of the whole internet traffic is due to peer-to-peer file sharing. Probably almost the other half is due to
YouTube.
Okay. So this BitTorrent is the most popular peer-to-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. These torrent files are the files that contain the hashes. When 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 it’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, active meaning uploading or downloading at any given time. So right now there are
40 million 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 distributions 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 whole file.
Some of these will be leechers; they have parts of the file. Now files are exchanged at a block by block basis, not the whole file. So Alice starts exchanging blocks, the moment she has some blocks she can start also giving some of those to other leechers.
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-cash is remember only used as a warranty system; only if things go bad. And if we --
.
Yes?
>> So with e-cash you have a bank, right?
>> Alptekin Kupcu: Yes.

>> So how does [inaudible]?
>> Alptekin 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 bank only for peer-to-peer exchanges. It doesn’t have any monetary value; it’s some kind of a credit”. Both of them are possible.
>> [inaudible]. So if you use e-cash and some central kind of [inaudible].
>> Alptekin Kupcu: Yes, good. So remember we have the tracker as a centralized entity, but why do we still consider this peer-to-peer? It’s 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 notes at once. So I need to contact the bank only once in a while. And remember if you keep bartering no money changes hands; there are no deposits, nothing, so still I don’t need to contact the bank much.
So if you compare the previous most efficient protocol 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 how 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 about 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 standard 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 barter 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 BitTorrent 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 on our group website.
Any 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 results?
>> Alptekin Kupcu: Some colleagues of us were indeed using 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, whatever association, what was it called?

>> MPA.
>> 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 download 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 complete fair 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, much 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 in some sense. But let me leave it until the end of the talk.
>> Peer-to-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 an average of 40 peers. So this includes 40 setup cost sessions.
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 should 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 servers. They can handle much more then our own computer capabilities.
What’s the other type? The other option is to outsource to multiple entities, for 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-to-peer, but it was a peerto-peer storage 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 securities 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 regular 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 generation cloud computing. What’s Amazon
Mechanical Turk?
>> 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 employer 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 is 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 there 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 cryptography 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 incentivize all the contractors to act honestly. Furthermore we can limit the damage done by the malicious contractors. We can provide rule able guarantees on what they can or can’t do.
>> Does this have to be done with fines or can it be done all with rewards 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 someone in this SETI@Home for instance if you can’t take back credits?
>> 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 example we are integrating this with some e-cash and 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 computation 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. Somebody could cash it soon.
>> Alptekin Kupcu: True, although I still don’t know, I would really doubt that they have provable results on how much malicious guys can do. So we have results that even if you are fully malicious, let’s say trying to make us accept 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 generation? So we have this client who has some precious data to store at an obviously un-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 done 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 and 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 wants’ to let’s say commit an update, so these are real numbers from real CVS repositories. There 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 with a naive version of achieving this. Our overhead is less than 100 bytes and 2 MS for each time we need to update 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 610 MB and 7 hours of overhead, whereas in total it requires something like 2 MB and
51 seconds.
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 secure
[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 entities 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 is 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. The 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 it’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 passwords.
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 million 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 on.
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 smart 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 provably secure.
>> 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 schemes that 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 only 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 are impossible.
>> [inaudible].

>> 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 cloud, 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 secret; verification is not public, [indiscernible].
>> Alptekin Kupcu: In the sense that only this server knows it. Actually multiple servers can know it, but --. Yes?
>> So is this just an identification protocol and then --. So you just do identification protocol to login and then --?
>> Alptekin Kupcu: This is like very simple; 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 problem. 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.
>> So 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, yeah, you just need something that’s basically your knowledge so that this server can’t go and impersonate you later and then you encrypt the --.
>> Alptekin Kupcu: You don’t need full zero knowledge I mean in the sense that if I give you my verification key you have some knowledge about my sign in key. That’s not full zero knowledge, but you still can’t sign on my behalf, right.
>> You just need verification that’s weaker then your knowledge.
>> Alptekin Kupcu: Exactly.
>> But that’s basically an [inaudible].
>> 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-to-peer setting and the fairness issues there. We talked about implementation. 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 trust

issues, how we can distribute these Arbiter’s and so on and finally authentication and usability issues.
Future work: I will quickly skip, but you can guess. So, more on outsourced storage: We have a distributed version that’s been published recently. Cloud 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-to-peer systems, economics, game-theoretic modeling of these and how we use for example these fair exchange protocols maybe in multi-party computation settings or what else we can do in terms of this usability.
One last notice about usability here: We said you also have a version of authentication where you can use your mobile phone. If you are required to 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 authentication process, 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 University. I want to thank them all and of course I want to you.
[Clapping]
>> 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 given 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 satisfy but --.
>> 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 done 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 servers don’t 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 against dictionary attacks.
>> 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 the bank has a lot of job to do, like if we are buying that’s definitely --.
>> Yeah, 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 crypto things”? You know the standard ecash 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 --.
>> [inaudible].
>> 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-cash scheme 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.
>> So 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.
[Clapping]