(electronic music) >> Live from Toronto, Canada it's the Cube! Covering Blockchain Futurist Conference 2018. Brought to you by The Cube! >> Hello, welcome back. Cube exclusive coverage here in Toronto for the untraceable Blockchain Futurist Conference. Two days of wall-to-wall with the Cube. I'm John Furrier, my co-host Dave Valante, we're initiating this Blockchain coverage to all 2018 Cube events all around the world. You'll see us more and more talking to the most important people. Excited to have, here at The Cube, San Kim, CEO of Lucidity. on the front page of siliconangle.com, our journalism team, with news. Also doing the really interesting Blockchain advertising, if you can believe what that could be. We know about Brave and the attention token, a lot of activity going around on what is the benefit to the user around advertising. Certainly having having immutability and data might be interesting. Sam, welcome to The Cube >> Thank you. >> So, first of all, big news today on Silicon Angle. We covered you guys, you guys announced a strategic investor. >> Yes. >> What's the hard news? >> Yeah, well, thank you for covering us today. Today we announced our initial funding and our strategic investor is Pythia. Pythia represents the hard chain foundation, and so we're really excited about this opportunity, We believe our chain represents an incredible advancement of base protocol layers and so, we're looking, we'll be supporting them as we go forward, as we work closely with Pythia, our chain, and that community. >> Tell me about what you guys offer taken specific context, folks may or may not be familiar with what you do. What's the basic premise of your opportunity, technology and problems that you solve, and how do you use Blockchain for that? Yeah, so, we started, we were a digital advertising protocol. Effectively, we are a shared ledger for the digital advertising ecosystem, and if you know digital advertising, it operates at a tremendous scale. And so we have to build this Layer 2 technology that sits on top of the traditional, the base layer protocols, like Ethereum and Archain. In order to address the three challenges. The three challenges, one being scalability, the second is difficulty in sharing privacy, and the third is the high overhead cost of decentralizing a network. And so we've built this Layer 2 technology that uses a plasma sidechain, and we use something called a time series database, that solves those three problems. And, we're looking to support additional chains, in addition to Ethereum, and so obviously our chain is a natural extension for us. >> Yeah, and you guys obviously get, we cover you guys from a broad perspective, that's a big problem in advertising. >> But are you guys charting the user value proposition, or the digital marketer or agency proposition, or both? >> Yeah, so we're not trying to tokenize digital advertising. Our token is basically used internally as a proof of stake token. So, the advertiser, we're asking them to pay in fiat, and we convert that into a stable coin. And on our current instincts, it's the Dai token by MakerDAO. And so, what we are trying to solve is the transparency issue, that's rampant in the supply chain. So for example, when you run a digital ad today, you use anywhere from seven to 15 vendors, and those vendors, each of them have their own database, and they never communicate that data across to each other, and so there's discrepancies, and it also opens itself up to a lot of fraud. And so the industry is a 225 billion dollar industry, and the industry itself estimates that there's, like, 30% of that money is wasted. And a lot of that is because there's no reconciliation of that data, there's no transparency, and so we've created this protocol layer, for all 15 vendors to submit their data. And, in real time, we can understand, which impressions were valid, which ones were fraudulent, and, well, not just transparency, but now that we as industry participants don't have to argue with one another, we'll start to trust one another, and then we can move the industry forward. >> In the market it'll adjust the pricing as a result of that as well, right? >> Oh, absolutely, absolutely, and it's just about identifying where is the value created, right? So if you're a value creator in the supply chain, you could probably estimate that, the advertiser's going to eliminate the less valuable ones, and focus on the valuable and the adding ones. So basically, if you're fraudulent, like yeah, you might get hurt, but the real adders will benefit from it. >> Just to clarify a question, you talked about the overheads of decentralizing advertising. I infer from that that an advertising supply chain, by its inherent nature is decentralized? Or are you talking about more of a disruptive model? Can you explain? >> Yeah, so we're not re-creating a whole ecosystem, >> Right >> We're interoperable with the existing architecture. >> Which, is decentralized by its very nature, you're saying, or...? >> No, no, no, it's not decentralized >> Okay >> It's very centralized, like all the metrics are controlled by a few players. >> So it's no seven people in the supply chain, that form that central entity... >> Yes, it's all central entities, and we're asking them to submit their data, into this shared ledger, that works across all of the different industry structures. >> So it is disrupting that... >> Oh, it's highly disruptive in terms of that, but we're not trying to re-create the infrastructure like a lot of other blockchain architect companies. >> Oh, I see, so you're tapping into the existing, and you're providing good auditing, I imagine with this, right, so the benefit might be auditing. So give an example of how that would render itself. >> Yeah, so, one of the areas that we're focused on today, is just looking at the impressions, in a programmatic ad buying. And so, let's say, let's just focus, instead of talking about the 15 vendors, let's just talk about the four. The four is the advertiser, is the DSP, which is basically the buying platform, the SSP, which also represents the exchange, and then the publisher. Now there is, we were asked that all four submit their data into the smart contract, and we verify whether that impression was valid. If you think of a fraudulent example, like a bot, they will not be able to mimic the data across the whole supply chain. And so because we're looking at the data wholistically, rather than just the slices of it, we can identify those fraudulent behaviors. >> This is the benefit of horizontally scalable, integrated systems. Cloud can help you, Blockchain helps you. How's the uptake been? Give us an update on who's involved, what's been the successes, and how's your success going? >> So we've been really excited to work with the IAB, and the IAB stands for the Interactive Advertisement Bureau. They're the bodies that set standards in digital advertising and we're working very closely with them. We launched our pilot, the first official pilot with the IAB, and we have great advertisers that are working with us, we're working with a lot of the agencies, we're actually even working closely with the publishers, and the ad networks, and the exchangers. AppNexus is one of the major partners with us, and the reception's been really positive because I think everybody wants that transparency. >> Well, some of the status quo might not want that transparency, I mean, let's face it, right? >> The fraud is rampant, it really is. >> A 220 billion dollar industry, I betcha there's a lot of people in it that are like, oh boy, here comes lucidity! I mean, come on, what about that? >> I'm sure that exists, but we haven't really come across it because the advertiser, at the end of the day, has become really aware that there is this rampant fraud, there is this waste. And I don't want to attribute everything to fraud, I think some of it is just wasted, because of the quality of the data. And so, the advertiser is demanding and at the end of the day, we're here to serve the advertiser, right? We're here to deliver value to the advertiser, and I think the industry is mature enough now, to where we recognize that. And so we don't think of transparency as a threat to the business anymore. We think of it as a value enhancement to our customer, the advertiser. >> Yeah, and I would personally totally agree with that, because as I said, the market will correct itself. Higher quality advertising is going to deliver more revenue, ultimately, alone, because there's going to be better outcomes. Right, so if you can increase your hit rate, you'd be happy to lower the clicks, you know? >> Is there any benefit for publishers? >> Yeah, I mean, publishers today have to basically trust what their partners are paying them. There's no way for them to verify and validate it. And so, with our system, we enable publishers to look into, it's our sidechain, right? And so, they are able to look at the events, but we obscure the data, we hash the data that's there so that we make it anonymous. But then they're able to see, like, okay, these are the impressions I've manned, here are the ones that were considered valid and verified, and here's what I should get paid. So the publishers now get the transparency, that which they lack today. >> So much of that industry is a black box, you might have a big media buyer, who's got voodoo, you know, that sprinkles magic dust, sends you a big bill, and you're like whoa! Is this really worth it? >> Bots, fake traffic.. >> You can automate a lot of that... >> And you've been doing this for 20 years! This has been the status quo for 20 years! >> We need a change. So, talk about the company, how big, how much funding did you actually owe? Is it privately funded, what's the funding mechanism? How big are you guys, what's the story? >> So today we announced that we raised five million dollars, we did it in traditional means. We did not do an ICO. >> Venture capital? >> It's a mix of venture capital, and obviously Pythia is the fund for our chain, so, but it was an equity deal. And that's the brow we're going to continue with. We do have an internal token, but we are not looking at doing a public sale. >> So not a security token, preferred stock, classic funding. >> So wait, so you did a security token? >> No no, no, preffered stock, classic venture capital. Well, great! Yeah, that's awesome, congratulations. We'll keep in touch, it's great to have you come on. >> Thank you very much >> Thanks very much, appreciate the time. >> And thank you for covering us! >> Of course! We love innovative things, in advertising specifically because it's freaking broken, big time! We have no advertising on our site, because we want to get the best content possible. Of course, the Cube is supported by sponsors, we appreciate that. Thanks for coming on. Cube coverage here in Toronto for watching futurists, we'll be right back, stay with us, as we start to wind down day one. Be right back with more great interviews after this break. (light-hearted techno music)

>>Hi, everyone. My name is Dan Bonnie and I want to thank the organizers for inviting me to speak. Since I only have 15 >>minutes, I decided to talk about something relatively simple that will hopefully be useful to entity. This is joint work with my students Sabah Eskandarian and Sam Kim. And with Morrissey, this work will appear it, uh, the upcoming Asia crypt and is available on E print if anyone wants this to learn more about what I'm going to talk about, So >>I want to tell you the story >>of storing encrypted data in the cloud. >>So all of us have lots of data, and typically we'd rather not >>store the data on our local machines. But rather we'd like to move the data to the cloud so that the cloud can handle back up in the cloud, can handle access control on this data and allow us to share it with others. However, for some types of data, we'd rather not have the data available in the cloud in the clear. And so what we dio is we encrypt the data before we send it to the cloud, and the customer is the one that's holding the key. So the cloud has cipher text, and the customer is the only one that has the key that could decrypt that data. >>Now, whenever dealing with encrypted data, there is a very common requirements called key rotation. So key rotation refers to the act of taking a cipher text and basically re encrypting it under a different key without changing the underlying data. Okay. And the reason we do that is so that an old key basically >>stops working, right? So we re encrypt the data under a new key, and as a result, the old red key can no longer decrypt the data. So it's a way for us to expire keys so that Onley the new key can decrypt the current data stored in the cloud. Of >>course, when we do this, we have to assume that the cloud actually doesn't store the old cipher text. So we're just going to assume that the cloud deletes the old cipher text, and the only thing the cloud has is on Lee, >>the latest version of the cipher text which can only be decrypted using the latest version of the key. >>So why do we do key rotations. Well, it turns out it's actually quite a good idea for one reason. Like we said, it limits the lifetime of a key. If I give you a key today, you can decrypt the data today. But after I do key rotation on my data, the key that I gave you no longer works. Okay, so it's a way to limit the lifetime of a key. And it's a good idea, for example, in an organization that might have temporary employees. Basically, you might give those temporary employees a key. But once they leave effectively, >>the keys will stop working after the key rotation has been done. >>Not only is it a good idea, it's actually >>a requirement in many standards. So, for example, this requires key rotation, the payment industry and requires periodic he rotation. So it's a fairly common requirement out there. The >>problem is, how do we do key >>rotation when the data is stored in the cloud? Yeah, so there are >>two options that immediately come to mind, but both are problematic. The first option is we can download the entire data >>set onto our client machines. Things could be terabytes or petabytes of data so it's a huge amount of data that we might need to download on to the client >>machine, decrypt it under the old Ke re encrypted under the new key and then upload all >>that data back to the cloud. So that works and it's fine. The only problem is it's very expensive. You have to move the data back and forth in and out of the cloud. The >>other option, of course, is to send the actual old key in the new key to the cloud and then have the cloud re encrypt using the old key and re encrypt, then using the new key. And of course, that also works. >>But it's insecure because now the cloud will get to see your data in the clear. So >>the question is what to do. And it turns out there is a better option, which is called up datable encryption, so obtainable encryption works as follows. What we do is we take our old key and our new key, and we combine them together using some sort of ah kee Reekie generation algorithm. What this algorithm will do is it will generate a short key. That's a combination of the old and new key. We can then send the re encryption key over to the cloud. The cloud can then use this key to encrypt re encrypt the entire data in the cloud. So in doing so, basically, the cloud is able to do the rotation for us. But the hope is that the cloud learns >>nothing about the data in doing that. Okay, so the re encryption key that we send to the cloud should reveal nothing to the cloud about the actual data that's being held in the cloud. So obtainable encryption is relatively old concept. I guess it was first studied in one of our papers back from 2013. There were stronger definitions given in the work of Everest power it all in 2017. And there's been a number of papers studying this this concept since. So >>before we talk about the constructions for available encryption, let me just quickly make >>sure the syntax is clear. Just so we see how this works. So basically there's a key generation algorithm that generates a key from a security parameter. Then, when we encrypt a message using a particular key, we're gonna break the cipher text into a short header and the actual cipher text the hitter and the cipher text gets into the >>cloud. And like I said, this header is going to be short and independent of the message length. Then when we want to do rotation, what we'll do is basically will use the old key in the new key along with the cipher text header to produce what we call >>a re encryption key will denote that by Delta. Okay, so the way this works is we will download the header from the >>Cloud Short header Computer Encryption key, send their encryption key to the cloud, and then the cloud will use the re encrypt algorithm that uses the re encryption key and the old cipher >>text to produce the new cipher text. And then this new cipher text will be stored in the cloud. And again, I repeat, the assumption is that the cloud is gonna erase the old cipher text. It is going to erase the re encryption key that we send to it. >>And finally, at the end of the day, when we want to decrypt the actual cipher text in the cloud, we download >>the cipher text on the cloud we decrypted using the key K and recover the actual message in. >>Okay, So in this new work with my students, we set out to look Atmore efficient constructions for available encryption. So the first thing we did is we realize there's some issues >>with the current security definitions and so we strengthen the security definitions in particular, we strengthen them in a couple of ways, but in particular, we'd like to make sure that the actual cipher text has stored in the cloud doesn't actually revealed a number of key rotations. Yeah, so a rotated cipher text should look indistinguishable from a fresh cipher text. >>But not only that, That actually should also guarantee >>that the number of key rotations is not leaked by from just looking at the cipher text. So generally, we'd like to hide the number of key rotations so that it doesn't reveal private information about what's what's encrypted inside the cipher text. >>But our main goal was to look at more efficient construction. So we looked at two constructions, one based >>on a lattice based key home or fake. Prof. So actually, the main point of this work was actually to study the performance of a lattice based key home or fake prof relative to the existing of datable encryption systems >>and then the other. The other construction we give is what's called a nested. Construction would just uses plain old symmetric encryption. And interestingly, what we show is that in fact, the nested construction is actually the best construction we have as long as the number of key rotations is not too high. Yes, so if we do under 50 re encryptions, just go ahead and use the nested construction basically from symmetric encryption. However, if we do more than 50 key rotations, all of a sudden the lattice >>based construction becomes the best one that we have. >>I want to emphasize here that are our goal for using lattices. That was not to get quantum resistance. We wanted to use lattices just because >>lettuces are fast. Yeah, and so we wanted to gain from the performance of lattice is not from the security that they provide >>eso I guess before I talk about the constructions, I have to quickly just remind you of how >>what what the security model is, what it is we're trying to achieve and I have to say the security model for available encryption is not that easy to explain here, You know, the adversary gets to see lots of keys. He gets to see lots of re encryption keys. He gets to see lots of >>cipher text. So instead of giving you the full definition, I'm just gonna give you kind >>of the intuition for what this definition is trying to achieve. And I'm going to point you to the paper for the details. So >>really, what the definition is trying to say >>is the following settings. Right. So imagine we have a cipher text that's encrypted under a certain key K. At >>some point later on in the future, the cipher text gets re encrypted using a re encryption key Delta. Okay, so now the new cipher text is encrypted under the key K prime. And what we're basically trying to achieve in the definition is to say that well, if the adversary gets to see the old cipher text >>the new cipher text and they re encryption key, then they learn nothing about the message. And they can't harm the integrity of the cipher text. >>Similarly, if they just see the old key and the new >>cipher text. They learn nothing about the message, and they can't harm the integrity of the cipher text. And similarly, if you see an old cipher text in a new key, same thing. Yeah, this is again overly simplified because in reality, the adversary gets to see lots of cipher, text and lots of keys and lots of encryption keys. And there are all these correctness conditions for when he's supposed Thio learn something and whatnot. And so I'm going to defer this to the paper. But this gives you at least the intuition for what the definition is trying to >>achieve. So now let's turn to constructions, so the first construction we'll look >>at it is kind of the classic way to construct available encryption using what's called the key home or fake. Prof. Sochi Home or for Pierre Efs were used by the or Pincus and Rain go back in 99 there were defined in our paper. BLM are back in 2013 the point of the BLM. Our paper was mainly to construct key home or fake pl refs without random oracles. So first, let me explain what Akiyama Murphy pf >>is. So it's basically a Pierre F where we have home amorphous, um, >>relative to the key. So you can see here if I give you the prof under two different keys at the point X, I can add those values and get the PF under the some of the keys at the same point x. Okay, so that's what the key home or fake property lets >>us dio. And so keyhole Norfolk PRS were used to construct a datable encryption schemes. The first thing we show is that, in fact, using keyhole graphic PRS, weaken build an update Abel encryption scheme that satisfies are stronger security definitions. So again, I'm not going to go through this construction. But just to give you intuition for why key Horrific Pff's are useful for update Abel encryption. Let me just say that the re encryption key is gonna be the some of the old key and the new key. And to see why that's useful. Let's imagine we're encrypting >>a message using counter mode so you can see here a message is being encrypted using a P r f applied to a counter, I >>Well, if I give the cloud K one plus K to the cloud >>can evaluate F F K one plus K two at the point I and if we subtract that from the >>cipher text, then by the key home or FIC properties, you'll see that F K one cancels out. And basically we're left with an encryption of them under the ki minus K two. So we were able to transform the cipher text for an encryption under K one to an encryption under minus K two. Yeah, and that's kind of the reason why they're useful. But of course, in reality, the construction >>has many, many more bells and whistles to it to satisfy the security definition. Okay, so >>what do we know about Qihoo? Norfolk? Pff's? Well, the first key home or fake prof is based on the d. D H assumption. And that's just the standards PF from D d H. It's not difficult to see that this >>construction actually is key human Norfolk. >>In this work, we're particularly interested in the keyhole morphing prof that comes from lattices. So our question was, can we optimize the ski home amorphous prof to get a very fast update Abel encryption scheme? And so the answer is yes, we can. And to do that we use the ring learning with error problems. So our goal was really to kind of evaluate obtainable encryption as it applies to lattices. So that's the first construction. The second construction, like I said, is purely based on symmetric encryption, and it's kind of an enhancement of what we call the Trivial Update Abel encryption scheme. So what's the Trivial Update? Abel encryption scheme? Well, basically, we would look at >>a standard encryption where we encrypt the message using some message key. And then we encrypt the message key using the actual client key. These are all symmetric encryptions. The client basically clinic. He would be >>K, and the header would be the message encryption key. Now, when we want to rotate the keys, all we will do is basically we would generate a new message. >>Encryption key will call a K body prime. We'll send that over to the cloud that the >>cloud will encrypt the entire old cipher text under the new key and then encrypt a new key along with the old key under a new clients key, which we call Cape Prime. So what gets sent to the cloud is this K body prime and header prime and the cloud is able to do its operation and re encrypt the old cipher text. The new client key becomes K prime. And of course, we can continue this over and over in kind of an onion like encryption where we keep encrypting the old cipher text under a new message. He The benefit of the scheme, of course, is that it only uses >>symmetric encryption, so it's actually quite fast, so that's pretty good. >>Unfortunately, this is not quite secure. And the reason this is not secure is because the cipher >>text effectively grows with a number of key rotations. So the cipher text actually leaks the number of key rotations, and so it doesn't actually satisfy our definitions. Nevertheless, we're able to give a nest of construction that does satisfy our definitions. So it does hide the number of key rotations. And again, there are lots of details in this constructions. I'm going to point you to the paper for how the nested encryption works. So >>now we get to the main point that I wanted to make, which is >>comparing the different constructions. So let's compare the lattice based construction with a D. D H but its construction and the symmetric nested construction for the DTH based construction. We're going to use the GPRS system just for a comparison point, >>so you can see that for four kilobyte message >>blocks, the lattice based system is about 300 times faster than the D. D H P A system. And the reason we're able to get such a high throughput is, of course, lattices air more efficient but also were able to use the A V X instructions for speed up. And we've also optimized the ring that we're using quite a bit specifically for this purpose. Nevertheless, when we compared to the symmetric system, we see that the symmetric system is still in order of magnitude faster than even a lot of system. And so for encryption and re encryption purposes that the symmetric based system is the fastest that we have. When we go to a larger message blocks 32 kilobyte message blocks, you see that the benefit of the latter system is even greater over the D d H system. But the symmetric system performs even better Now if you think back to how the symmetric system works. It creates many layers of encryption and >>as a result, during decryption, we have to decrypt all these >>layers. So decryption in the symmetric system takes linear time in the number of re encryptions. So you can see this in this graph where the time to decrypt increases linearly with the number of re encryptions, whereas the key home or FIC methods take constant amount of time to decrypt, no matter how many re encryptions there are, the crossover point is about 50 re encryptions, Which is why we said that if in the lifetime of the cipher text we expect fewer than 50 re encryptions, you might as well use the symmetric nested system. But if you're doing frequently encryptions, let's say weekly re encryptions, you might end up with many more than 50 re encryptions, in which case the lattice based key home or fix scheme is the best up datable system we have today. >>So I'm going to stop here. But let me leave you with one open problem if you're interested in questions in this area. So let me say that in our latest based construction, because of the noise that's involved in latest constructions. It turns out we had toe slightly weaken >>our definitions of security to get the security proof to go through. I think it's an interesting problem to see if we can build a lattice based system that's as efficient as the one that we have, but one that satisfies our full security definition. Okay, so I'll stop here, and I'm happy to take any questions. Thank you very much.