Episode 177- NuCypher: Bringing Data Privacy To Bl

Welcome to Crypto Knights. Will we help you finally make sense of the trending world of cryptocurrencies? So gather your virtual piggy bank and let's get started. My client, welcome to Crypto Knights. We are just so excited to have you as a guest speaker today. Awesome. Thanks a bunch for having me. Great. Well, why don't we kick it off by getting a little bit of your background

and then the backstory behind new side fault? Sure. So I have kind of a weird combination of both software engineering and finance experience. Out of undergrad, I worked at Morgan Stanley doing investment banking. So things like MLA and capital advisory or tech media and telcos. That was from 2010 to 2012. I left and came out here to the Bay Area mainly because I just wanted to

get back to sort of more of a technical or product development role. And actually, like, right code and build products as opposed to right pitch decks and build financial models. And around that same time that I left, I just got very interested and sort of fell down the rabbit hole of blockchain, obviously starting back then with Bitcoin and Ethereum. I came out here synced up with

Michael who is our CTO and my co-founder. And we were originally just doing a bunch of experiments and little projects in the blockchain space using things like counterparty or color coins. Just made me as a way to kind of learn and better understand, sort of rock and wrap our heads around blockchain and what it could potentially be used for. So this was back in 2013. Not

a great time to be building infrastructure and DevTools, which is what we like to do and what we're good at. So we kind of pivoted away and ended up building something called zero DB, which was an end to end encrypted database. It was kind of inspired by what we were seeing with blockchain and DApps was, you know, if you want to build a DApp, how do

you store private or sensitive information, but have in a decentralized context, but still haven't usable. So what zero DB allowed you to do was to actually query encrypted data without having to share the private encryption key. So this wasn't homeomorphic encryption or kind of these fancy futuristic encryption algorithms. It was kind of just a little clever hack that we did. So I won't go into the

details now, but basically it allowed you to do relatively simple queries. So nothing, you know, too complex or crazy like you couldn't run machine learning or any kind of fancy processing and type on top of encrypted data. But you could do things like, you know, searches, sorts, sorts, range queries, things like that. And then we got to do some sort of, you know, a lot of

things like that. That became actually a pretty popular open source project. But what was the most interesting piece was we built this sort of feature into zero DB that allowed not just you to query your encrypted data, but also you to grant access to other people to query encrypted data. And we had discovered this sort of weird technology called proxy re encryption that we were using

to do that. And after a few months of trying to like convince people to start using zero DB and rip out their existing database, database software and replace it was zero DB, we, which is a difficult thing to do. We eventually realized that that was that proxy re encryption piece was actually the most interesting aspect. So we kind of decided to pull that piece out and

make it this more general encryption layer that we could apply to existing distributed system. So instead of having to convince someone to. Abandon their current database infrastructure in place that was zero DB, we could just go to them and say, hey, you're using her, do or Kafka or some distributed system. Why don't you just layer this encryption later on top and you get all these sort

of security and cryptographic access control benefits. And that was obviously kind of like the first iteration of what we built it in New Cypher. So proxy re encryption tends to be super useful or very well fitted for these distributed systems. Locked. The apps, obviously, in our view, kind of being the most interesting and exciting one. Wow. I have so many questions on that. Let me kind

of break it down one at a time. So you have your contrary to many of the companies that I have interviewed and founders. You've been working on this project for a while then a few years. You would say McLean. Yeah. So depending on sort of how you define our start, I mean, you could define it in a couple of ways. One being when Michael and I

co-founder and I first started working together in a blockchain space, which was back in probably late 2013. Another being maybe when we started the actual company, which was when we launched zero DB as a project. And then another being when we sort of pivoted it back and came full circle back to blockchain. And we're building this data privacy later for blockchain. So we started the app,

which was a little bit over a year ago. When did you start? When did you start the zero DB? So zero DB was, we started that in the beginning of 2015. Okay. So yeah. So almost every couple of years. Either about five years, three years or one year. We've been working on different kind of iterations or flavors of what we have that with New Cypher. So

very familiar with kind of the data. And we've been working on the blockchain and data privacy and encryption space. And you found that one of the key things that was missing was the ease of sharing your data. That is encrypted with somebody else without sharing your private key. Yeah. So one of the things that, you know, we're good at and that we're interested in is building

developer tools and infrastructure. So we're developers ourselves. So it's, it's, you know, relatively easier for us to do. So we're going to kind of see what are the missing infrastructure gaps. And for the blockchain space of the city privacy is a big one. Even over the last probably three months or so, it started to get a lot more attention. There's been a lot of new projects

kind of coming up with an interesting alternative approaches. But this problem of if you're building a D app or really any kind of application. Presumably there's going to be some sort of private or sensitive data. This associated with that application, it could be patient medical records or it could be as simple as patient name or like user names and addresses. And we need some way to

have those be private and confidential. And when you kind of think about the context of the centralized application where maybe you're storing that data on IPFS or swarm or something, you need some way to control who can and can't access that data. So in a traditional centralized web app, it's very simple. You just have some server that says yes or no, you can access this data

or you cannot. But obviously in blockchain world, we don't have that. We don't have some central trusted server that can decide. So there needs to be your some alternative approach. And obviously cryptography is one approach. There's also, you know, with trusted execution environments, some newer hardware approaches that are starting to surface. But I think this sort of access to the blockchain is a very important thing.

This is controlling for structure, data privacy infrastructure is a big one. And you found that the original idea behind zero DB was to see if you could build an entire database with these functionalities in there and see if you could convince people to swap out their existing database for zero DB. But then that looked like a head, a sledgehammer approach. So you decided to look into

zero DB and say, what is the most unique or useful feature in there. And that's where you pulled out proxy reintroduction. Out of it and you built new cypher. Did I kind of get that right? Yep, that's that's pretty accurate. So the way I think of proxy re encryption is really fundamentally, it sounds sort of very fancy, but really it's just a more scalable form of

public key encryption. And it's very well suited for like one to many or many to many data sharing patterns. And it turns out like in terms of decentralized applications in blockchain world, it's a very good primitive for building cryptographic access controls. So we've used that basically as this data privacy layer for blockchain apps, that actually does not care where the data is actually stored. So it's

agnostic as to whether you're storing data in IPFS or swarm or storage IO, or even we have some users putting data in S3. So it can work with centralized file systems as well. So we are sort of taking a very kind of unique style up. So we're going to do a very simple approach where our view of the world is that in two, three years or

so, there'll be a bunch of these interoperable interoperable protocols that work with each other and do one thing and do it very well. So we're focused on doing access controls and privacy very well. And sort of integrating with all the other parts of the tech stack that would be required to build a D app. Wonderful. So why don't we start off illustrating proxy re encryption with

the Alice and Bob example that I have. I don't know website. I want to get it down on podcast. Can you give us a three step use case. Sure. So maybe the easiest way to compare it would be just first to compare it with or first to give an example of traditional public encryption. So let's say you've got Alice and Bob. Alice is a data owner.

She wants to share her data with Bob. What she can do is that she can just encrypt that data with Bob's public. She's a key send it to him across and I work he can decrypt with his private key works very well. Where it might start to not work so well is if she needs to share that data not just with Bob, but with Carol, Dave,

Evan, and so on. Let's say she needs to share that data not just with one person, but with 12 dozen 100,000 people. She has to encrypt that data a dozen or 100,000 times send it across the network a whole bunch as well. It just doesn't scale very well. And what she can do with proxy re encryption instead is that she can encrypt the data one time

under her own key. And then she can delegate and revoke access to that data to pretty much arbitrarily as many recipients as she wants. And the way that works is she will create something called a re encryption key for each of those recipients. And that re encryption key can be used by a proxy doesn't have to be basically an untrusted proxy to re encrypt or rekey

or transfer. So it's a form of data so that it goes from being encrypted for Alice to being encrypted for the recipient. And the magic part about proxy re encryption is that that re encryption re-eachening process happens without ever having to decrypt the data in the middle. So it's a direct cipher text to cipher text transformation. So the proxy that does this re encryption never sees

the plain text data. The store manager never sees the plain text data. So she explicitly grants access to. I see, I see. So I see the I understand it. However, how does Alice specify? How does she specify the identities of the recipients? Yep. So in the system or in the protocol basically every entity, every Alice or every Bob is represented by a public private key pair.

So what Alice will do is that she will be able to identify the identity of the recipients. So that when she decides she wants to share her data with Bob, she will create a re encryption key that targets Bob's public key. So she on her client side, she will create this re encryption key and it has two inputs. One is Bob's public key. And then the

other input is her private key. So she'll create, she uses those two inputs to create the re encryption key. And that's a one way function. So once the re encryption key is created, there's no way to decompose it to get the two inputs. So the first two inputs are the private key back out. And then that's a re encryption key. And then actually what we've done

with new cipher is taking that a step further. And instead of just one re encryption key and one proxy, we split the re encryption key up into a bunch of shares. So it's a split key proxy re encryption algorithm. And then we issue those individual shares out to different nodes in the new cipher network. And then Alice can specify some threshold number of the shares that

are required. And the two, assuming some threshold number of those proxies come together to do the re encryption, then the data will get re encrypted for Bob. Got it. So you have a couple of different ways of doing this. So earlier on that the challenge was here to encrypt it separately for each individual. She is sharing with which is a big chore. But now what Alice

is able to do is to create this re encryption key. And and is there there is no limit on how many people she can share that. So again, yes, it's my problem with. I'm assuming. Is that, is that correct. Yeah. So so a. A re encryption key does target a specifically, so she would create a re encryption key for Bob she would create a separate re

encryption key for Carol. Separately, for example, but she can create as many of those re encryption keys as she likes. So the keys are individual, but only the keys, not the data. The data encryption, they're not the individual. So what you have done is you separated the key encryption what makes this much. Yeah. So yeah. So if we wanted to go maybe sort of one layer

deeper, the way that it works is similar to like PGP where you encrypt the bulk of the data with a symmetric key. Yeah. And that's very fast. So the reason we do that is it's just performance. So you would encrypt the bulk of the data with something like AES or trash ash wanting or something like that. And then you would encrypt the symmetric key with public

key. And then you actually just do the proxy re encryption on that encrypted symmetric key. And that had just a bunch of performance benefits. So like regardless of whether the bulk data is gigabytes or a megabyte or whatever, you're only ever doing the re encryption on that encrypted symmetric key. So it doesn't basically the performance of the system doesn't doesn't really it doesn't care how much

data is being re encrypted. It doesn't care about how much data is being encrypted. And it also the performance does not degrade with the number of people you're sharing it with. Correct. Yeah. Got it. Okay. So can we now go to use cases? Can you kind of give me examples? I read in your white paper a whole bunch of those use cases. But if you could

take one or two use cases and illustrate how you know kind of like a much like if you can give me a before and after. You know, before you could say, you know, what new cipher what would a developer have to do in order to get this functionality in that particular use case. And with new cipher, how will things be easier? Can you give that kind

of an example for a couple of use cases? Sure. So I mean fundamentally new cipher is just horizontal access control for structures of anyone that's building at the app that used to manage private data. Would be a potential user where we've in practice where we've gotten a lot of early adoption. So we've got a couple of different verticals. Maybe the easiest sort of give as an

example would be in the healthcare space. So let's say you're building a healthcare application on top of the theorem. And it's basically an application that allows individual patients to control their medical records. So you want to have you want to store patient medical records to say on IPFS. But you need some way to have those medical records be private confidential and encrypted. And so it's pretty

hard to be shareable with the Valerie Sipi. And so in this case, I like a doctor or a healthcare provider. And so you would use new cipher to ensure that those records are always encrypted. The data owner, let's say they switched doctors. So they would sort of issue a revocation. Man, in the cyber network, they say, hey, delete the re encryption key for my old doctor.

They could create a re encryption key for their new doctor. And so you would use new cipher to ensure that those records are always encrypted. So I think that's the issue that out to the network and maybe combine it with some sort of smart contract that says, you know, I want to grant access to my doctor for six months. And then after that, the access should

expire. And he shouldn't be able to access it anymore. Whereas if you were to try to build this without new cipher, either. Every time you wanted to share, well, either you want to share the data you'd have to do with your computer. You have to download the data back to the patient's client side. You have to decrypt it, encrypt it with a doctor's key, and then

send it to the new doctor. Or he would just have to share his private key with the doctor. So the doctor could go and decrypt the data where it's stored. So in the one case, it's kind of a clunky user experience that requires the patient to come back online. Download the data decrypt it, send it. In the other case, it's passing around a private key, which

is not the most secure. I think to do. Excellent. Excellent. New case. Can you give another one? I think you had Dropbox, Slack, type of use cases as well. Can you pick one of those? Sure. Yeah. I mean, the Dropbox would be just kind of like a decentralized and an encrypted Dropbox would be a generalize these case for that medical records example. So instead of medical

records, any generic file, you know, sharing photos, encrypted photos with your family or something like that. Or just sharing work documents between your different devices. We've also, so just I'll sort of tie it back to actually real world users. One of the big verticals for us is data exchanges and data. So projects like data or ocean protocol that are aggregating a bunch of different kinds of

data. It could be like probably history or genomics data. Or self driving car data and they're encrypting it, storing it on an IPS or swarm. And then they try to monetize. That data by selling it to or renting it to a researcher or an advertiser or some other purchaser. And they can use new cipher to grant access to that data, but conditional on payment. So you

could say something like, I want to allow someone to decrypt this data only if they first pay 5E to my address, for example. Also being used as the accidental layer by somebody to decentralize data. So that's just a way for them to control who can and can't query against their databases. Kind of an interesting interesting news case is we're working with origin, which is the sharing

economy protocol. And they're using new cipher for kind of generalized secrets management. So let's say someone where to use origin to build a decentralized Airbnb. And origin uses the same thing. New cipher to only share the address of a rental or a house. What's the booking has been made? So things like that are some of the use cases. Use cases that we're starting to see in

the wild. Well, very interesting. Okay. Those are thank you, my turn that is very helpful and understanding. Where it can be applied on how great. So can we now move on to some of the practical aspects. How far along? Are you in your development? What do you have out there? Can a developer that wants to try out your application actually tried out now? Yeah. So one

of the cool things about what we do is all of our development happens in the public. Everything is open source. So just go to our GitHub, which is GitHub.com slash new cipher. We do all of our development discussions on discord. So we're very happy to engage with developers with the community there, particularly for sort of like technical discussions. And in terms of what we have available

on our GitHub, all of the underlying cryptography. So the split key threshold proxy encryption stop is done and implemented. So we have our reference implement implementation is written in Python. And that we call that library pi umbral. We recently released a go implementation call go. So both of those libraries are available. That's the underlying cryptos system for the average or typical developer. This building a de

app using cipher. That's those libraries are a bit lower level than what they'll have to use. So they're user relatively sort of more abstracted or friendly API. And we have what we call a mocknet, which is kind of like effectively just a private test that you can run locally. To sort of start building against the actual API. In the next few weeks, we should have a

public testnet where anyone can join and spin up a node. And then our current estimate for actual main net is some time this fall. So everything is happening relatively soon. And we've got a lot of code available already for people to play around with. Well, that's fantastic. So they can engage. With you, they can go to get hub.com slash new cipher. They can engage with you

guys on discord. And new cipher.com would be a website as well. And you see why ppl.com. Okay. One. Yeah, new cipher.com. And then we've got links to the get hub and discord and all the relevant sort of channels on the homepage. Great. So are you funded? Are you going to go to the ICU route sometime in the near or down the road? What are your plans

about funding and growth of this? Yeah. Sure. So we have raised some private funding from professional and operator. So these are, we presold some of the tokens to people who will be running large staking operations for the new cipher network. And we do want and plan as of now to do a public sale. Or it's, you know, we'll see what happens on the legal and regulatory

funds over the next few months. But our current plan is once main net is ready. And we've fully implemented the network in the protocol. We want to launch on main net and hold the public sale at the same time. So that, you know, people who are working on the public sale are able to purchase tokens and immediately stake those tokens to run notes. So that's, that's

the current plan. There's a main bottleneck on, you know, a token sale side is, is really our skin uncomfortable on the legal and regulatory front. And, you know, hopefully there will be some kind of guidance from the relevant regulatory authorities fairly soon so that we can do it in a compliant way. And can you also explain maybe I missed that about staking and, you know, and

running the notes. What is the role that these nodes can play? Sure. So the, the function of the new cipher token is to stake. So it's not a payment token. So if you are, if you've built a D app and you want to use new ciphers proxy reencryption services, you don't have to worry about the token at all. You would just pay for those reencryption services

in E. What the token does is if you want to be one of the nodes, you know, you can't just do that. So you can use those or the proxies in the new cipher network and basically get paid by users for doing that. You have to stake the new cipher token is a kind of collateral or bond. And we use that for a couple things. One,

we use it as a way to coordinate the network. So let's say you've staked 10% of all the stake tokens, you'll get approximately 10% of the work and 10% of the compensation for that work. And then we also use it as a way to make sure that nodes are behavior. So if you stake and you commit to stake and let's say for three months, but halfway

through you just go off on and you never come back. You can potentially get slashed if you misbehave by instead of properly reencrypting just returning garbage or gibberish. You can also get slashed. So we use it basically as a way to ensure that nodes are computing correctly and doing their job correctly through this sort of economic. And so we use that to make sure that we

have a lot of money. Junction itself, it doesn't get takes. So we use that once for some time as a way to get to ensure that nodes arente going out and cutting them out. So we'll need a clip up so as a way to replace such an amount of the money that they are nascentive. And how many of these nodes do expect to be running convection

the many Nicholas mathematical power? For Allah ya Allah peace be upon you sir. So what she through the public sale is to hopefully get several thousand small independent operators coming out of that. So we'll have, you know, individual buyer caps set equal to the minimum staking requirements and hopefully have several thousand, you know, staking nodes that come out of that public sale. If that if we're

not able to do a public sale in the near term for some reason. The network would still work. It just wouldn't be quite as decentralized. There'd be several larger node operators as opposed to many thousand scattered all over the world. But that is really, you know, for us in particular one of the big motivators for us to do a public sale and one of the reasons

why we sort of committed to our community that we want to do that is because we get a lot of value from a very decentralized network of these re encryption nodes that are ideally scattered all over the world. So that makes the network more secure, more censorship resistant and healthier. As opposed to us just selling privately, you know, all the tokens to five or 10 or

something like that big holders. We wouldn't get as much of the sort of decentralization benefits and censorship guarantees that we do. Because that we would through a public sale. Wonderful. And how large do you see, do you foresee the market on your side for the market? Yeah, that's actually a super hard forecast to make because a lot of it just depends on how successful decentralized applications

and blockchain applications are. So obviously the big bet that we as a company are making is that deapse in two, three or five years or however long will end up being a very important thing. And if that happens, there has to be some sort of privacy or access control layer that people are building on. And so a lot of it just depends on, you know, how

successful blockchain applications as a class end up being. Which is, you know, given that we're so early kind of in the in the in the adoption of this space. It's really hard to forecast how big the yet market will be. And hopefully we'll start to see a lot of very interesting for the native blockchain applications. We're uniquely enabled by blockchain or tokens start to come out.

And we've seen a little bit of that with like NFTs and things like cryptokities, but hopefully there'll be a lot more. And if that happens, sort of our vision of new cipher is sometimes we've kind of analogized it to HTTPS, but for DAPS. So, you know, when you're using the traditional internet or traditional web, you'll see the little green padlock at the top of your browser.

Hopefully with new cipher, if DAPS are important, new cipher will just be as ubiquitous as HTTPS is, but for decentralized applications. Yeah, that's what I thought. That's the reason I asked the question is, if we do the DAP market is really your target market and potentially all DAPS could use new cipher and there's a good likelihood they might need it. Is that a fair statement? Yep,

I think we're very much focused on DAPS. So to the extent that that market succeeds, hopefully we will as well. And our goal for new cipher is that it's just a default, primarily for the decentralized tech stack. So almost every application has to manage some sort of private data. And if they are, hopefully we've done a good enough job with new cipher that we're sort of

the default choice for them to do that. So, I think that's a lot of my clean art here. Other questions that I should have asked or other information you wanted to share with our audience. Yeah, I mean, I think the big thing is, if you are a DAP developer and you're either already building a project or interested in building a project that potentially leverage new cipher,

we would certainly love to engage with you. So the easiest way to do that is just to join our discord. All of our development happens there. All of our engineers and virtually the entire company just hangs out there all the time. So it's easy to get a hold of us there. And we're happy to support people that are building on top of the new cipher. We

also actually, as of well today, this weekend, we released our proposed staking economics for the new cipher. So that includes things like the inflation curve and things like that. And we're very interested in getting feedback on that from the community. So that's also, if you just go to our blog, I think it's the most interesting thing. It's recent posts. We're very interested in feedback from that

or on that because obviously the economics and token economics and staking inflation is one of the core components to the system. And we want to make sure that we get that right. Because that'll be an important factor of how sustainable the network is long term. That's fantastic. Thank you. This has been a great podcast. And listeners, I hope you enjoyed the podcast. Please feel free to

share this with all the other developers that you know. So I could find this information useful. And as always,