Hashing It Out
Hashing It Out

Episode 26 · 4 years ago

Hashing It Out #26: NuFHE - Michael Egorov and John "Tux" Pacific

ABOUT THIS EPISODE

Great Caesar's Ghost! NuCypher has demo'd a practical fully-homomorphic encryption (FHE) scheme that leverages an Ethereum smart contract for a proof mechanism. We get to go over FHE: what it is, how it works, how it commits to the blockchain, scaling issues, and the future of encrypted computation. This will enable new privacy mechanisms on layer 2 solutions which interface with the blockchain cheaply and efficiently. Very big stuff for anyone trying to use blockchain as a resolution mechanism but wants to hide their business rules in the process!

Links https://blog.nucypher.com/releasing-nufhe-library-b5f9345dc1fbhttps://github.com/nucypher/nufhe

Entering. Welcome to hashing it out, a podcast where we talked to the tech innovators behind blocked in infrastructure and decentralized networks. We dive into the weeds to get at why and how people build this technology the problems they face along the way. Come listen and learn from the best in the business so you can join their ranks. All right, big news today. Remember that news, but the fun podcast, Episode Twenty Six of hashing it out. I'm Dr Cory Petty. My Co host, Collins. Say Hello Colin. Hello Colin Marcarc what I can get you to say with that? That lead in from here on out. Just to change it up, today's episode to see is King Man. Now never they's episode. We have new cipher team on to talk about a POC. Well, they've been working on it for quite a while, but they did a demo of a fully, hope more for concription library written python at f Berlin a couple weeks ago and I liked it. It's liked what I saw. I wanted to get them on the show to try and talk about what exactly it is, where it's currently at and what to it like. The implications maybe so Tux Mike, nice to have you on the show. Why don't you give our audience a quick introduction as to who you are, what new cipher is, and we can start talking about the weeds after that? Sure. So I'm Tux. I am a cryptography engineer in new cipher and work on our proxy encryption network. Can also been doing some research in fully homomorphic encryption lately. And I'm Michael, the CITEO of a new cipher, and I guess I probably need to cover a little bit about what new cipher is what we are doing. So our first product as proxy re encryption network, which is probable, which is like you can say that it's something which allows to manage permissions for encrypted data in sent decentralized networks, but doesn't have to be decentralized networks. So I imagined that all of the data is encrypted and you can you can define who can read your data and who not, without trusting any central server to do that. And to achieve that we use proxy re encryption, so something which allows to transform psipher texts from being encrypted under one key to be encrypted under other key. But while we've been doing that, we've been asked many, many times whether we can not just share encrypted data, but whether we can compute of encrypted data, whether we can do something like private privacy preserving smart contracts, and we thought whether we can do it, there are multiple approaches how one would be able to achieve it. Like, for example, once we talent pointed out that multi party computation can be used for privacy preserving smart contracts. or You could use secure enclaves, which is kind of a popular approach right now because because of being practical performance wise. But there is another thing which is called fully homomorphic encryption, which I think can be used for this kind of stuff. So and what fully homomorphic? So we actually try decided to try this path. And what fully homomorphic encryption is. It's the specific source of encryption which allows to do arbitrary computations over encrypted data. So you can run your program with encrypted data as an input, you have encrypted data as an output and who where execuse the program doesn't know, while the plane tax data is ever and and you you can have this program defined in one of two ways it would be. It could be a logic circuit, so then you can prysmash implement anything, or you can make it a little bit more practical for for some subset of applications, more like for data and analytics, where you can run it so that it can do let's say, editions and...

...multiplications Comomorphically. In principle you can convert logic circuits to into this way of operation, but then it will be a little slower. So, but logic circuits somewhere universal. So that's why we are we've tried fully holomorphic encryption with those and, as I said, the hope is to be able to do privacy preserving smart contracts using fully homomorphic encryption. So for the general audience, can I can I try and explain fhg like the way I understand it is that you have this program, all right, this this piece of code, and this code operates on encrypted data. I know you said this, but I just want to reiterate it. On encrypted data and does general purpose compute on this data and will give a encrypted output and at no point does this program know what that encrypted data originally was and and it doesn't know what the meaning behind the encrypted output is. And so you can, as a person, go I'm encrypting my data for home, fully homomorphic encryption, cryptic Ip. You send that packet or send that package to the the decentralized, let's just say decentralized, the unknown compute system, that the untrusted compute system, and it will do the compute for you on your behalf and then send you a result back which then you can not only decrypt but also verify is correct. Is is follow the rules of the original encryption correct? Are the original system? Yeah, well, that is correct. It's doesn't necessarily include the very five parts, but, as probably we know, with any deterministic computation you can do the very five part on the in kind of in a different way, let's say. If you look at true bit, what what it is intended to do? It's it provides and sentives to do computations while ensuring correctness of this computations, provided that they are deterministic and coming of the encryption quite face center. Is that? So you can, you can implement the Verifi part totally independently of the of the Fah Sheet, although there are some cryptographic ways to do verification also. We could you also send an expected result over and if you get that expected result back in part as part of your results, then you know that it's been done. Properly, because it won't be garbled or wrong or anything like that, like just a pastor even with those kind of things. Work to verify? Yeah, well, I guess you can. Even there is just one certain way which you need to run the the homomorphic circuit in, so if there is any other node which runs this exact circuit, it should arrive with exactly the same seifertext. So you don't even have to download this result and decrypted to verify. In principle you can have this verified totally independently by the network itself, just because if you repeat this same computation or encrypted data, you should get the same side at text. Whether this side at text is correct or not, of course, depends on how well you assemble the circuit. Maybe your homomorphic program has a bug and but this is then. This is up to you as a developer, and the compute, like however computes that you can, has no ability to know whether whether you did have a bug in it or not. They just executed, they got the result. Here is the results. I'd like to try and frame us a little bit. First off, I want to say if you are interested in the proxy rein Christian aspect of what new cipher does. We've had Tux on previously, episode eleven, of Hashing it out. Check that out that I'll tell you all about that part of the company and to frame the context of fully home warfare concription as it applies to decentralized networks, which is basically what we focus on in this in this podcast, that that Gus. The standard kind of analogy people would use here is like looking at see cash, and that is defining a set of rules, growing up with primitives that allow you to then sin transactions. And the nodes that verify these transactions don't understand all of the variables associated with a transaction, such as who it's going to, where it's going and how much, but they're doing it properly and you can beat you can you can be guaranteed that they're doing that that validation properly without them knowing what they're doing. And so if you extract light that to private smart contracts, a big Bain or downfall or...

...problem that a lot of people see with public blockchains is that all of the information stored in the smart contracts are open and public to see. So imagine, if you will, adding privacy to something like that where you can have the decentralized trust that's associated with public blockchains and the privacy associated with not public blockchains, so that nodes can validate and do proper computation on deployed smart contracts, but you could never see the data inside of them. That's kind of the goal here. If I'm if I'm not mistaken, can you? Can you talk to that? That's pretty much the the concept of another point that I would like to put on as well as that on a lot of people have problems with putting encrypted datea on Blockcha, on public blockchains, because the data will sit there for a very long time and it essentially it's always going to be there. Right. It's non malleable. It's going to be there for the years to come. Who knows how long certain blockchains are going to go. But the point is is that eventually, at some points, maybe some of this encrypted data will also get within range of practical attacks, such as like quantum computing, right. And so what happens is if that, like for example, everything on Bitcoin right now, ECDSA and things like that may become vulnerable in the future and will have too hard for it to do those things with fully homomorphic encryption. The Algorithms we use there are actually also post quantum. So if things are put on the blockchain, they are also quantum resistant now. So it's a one of the cool components of it. So just by happenstance, that happens to be a little more future proof in terms of being able to be hacked later on down the line. Yeah, just a bit more future proof cryptographically. A who knows what the future wholes in terms of cryptanalysis. But so far the assumptions that Fagi makes, if you want to look into this, it's called the learning with errors hard problem, if you want it turns out that this is a really strong assumption and it's actually very difficult in the quantum and classic setting. Can you repeat that's a learning with errors? Yeah, learning with errors. So yeah, there's several variants of it, but the assumption is that it's without getting very, very in depth on it, it's essentially if you have some vector plus some noise or some airs, it's called, it's very hard to invert that figure and learn the secret from it from some vector. So yeah, and so this just assumption has been very strong and strongly held in very improven time and time again now. So it's looking very good for the future for this. Okay, I think I could a good I guess next step here would be to talk about why has this not done before? been done before? Why is this difficult, and what have you done that makes you believe that you could? You're pushing it on the right direction. Yeah, right, and to kind of head tug onto that a little, we do use some form of homeomorphic encryption right now. Corey mentioned Z cash earlier. So what differentiates this from those other things? Right, so the main component of Z cash is also like Z case marks, right, like and zero knowledge proofs in the cool thing is all fully homomorphic encryption is that fully homomorphic encryption implies that zero knowledge proofs exist, but zero knowledge proofs don't imply that fully homomorphic encryption exists. So we can actually start constructing primitives and things like zero knowledge proofs in the homomorphic setting to build things like that. But if you're asking why this has not been done before, it's because previously there are several large, fairly large, problems getting in the way of actual utility of these homomorphic schemes, like ciphertext size and performance feed as well as the one thing that new cipher has done is that we have demonstrated that it is a very strong that there is a very strong ability to improve the performance of this using gpus and a sex as well. So that's one thing we've done with new FAG was construct a very optimized variant of another library called Tfag, and it has shown that it is very performant in this domain and we've gotten it to around six to seven thousand opera logical operations per second, depending on the graphics card, and it shows that we can actually make a very performant, usable scheme in term of smart contracts, because you may not mean anything much faster for that. Another problem at that would be ciphertext sighs, because the CIPHERTEXT actually expands greatly. So to encrypt one bit you're talking around like a sixteenzero bit or...

Sixteenzero x expansion. So one bit equals around to kill bytes, and so that's the next problem spot that you need to go down on. Their schemes that actually enabled that as well and and also keep the performance. So that would be like the next step is in research has to shrink the CIPHERTEXT sighs get a better performance merging still and research how to actually get these primitives out there and build more primitives. But it was actually an interesting story. How how we discovered that it's actually possible to accelerate this. This scheme the library called tfach appeared in I think two thousand and fifteen or something, and while just which is being curious, I looked at it and it's seemed like the main bottleneck over there was fast before yet transform and it was all happening on a CPU. But then I remember that's actually I was doing. It beached in physics. I was doing experimental physics and a friend of mine was doing theoretical physics. And theoretical physics is not just doing formulas, it's actually doing computations on trying to simulate physics. So anyway I was doing like doing work on quantum gases, Bozi instein condensates, and a friend of mine back done worked on simulating those. So and actually he managed to accelerate those simulations by factor of a hundred because, like he actually tried to paralyze that on a GPU. The main bottle neck over there was fast, free a transform. So I remember that and sounds like the bottle neck is very similar here. So I talked to I talk to him are like pretty much this year and he said yeah, sounds like it's possible to accelerate. So we hired him and in a couple of months he accelerated the Tfah Library. It proved out to be also like fucked of a hundred acceleration. It was a little bit it was a little bit more complex than just accelerating fast free transform because if you if you do just that, you well, it takes time to transfer data to the GPU and back and you you will not gain any performance if you do that all the time. So you need to keep everything on GPU. So you need to re implement the whole Algorithm on GPU. But when you do that it's apparently pretty fast. So turned out to be exactly the same acceleration as far as I remember, like fft was accelerated on by and vidia itself, but just the library which friend of mine road was a little faster and he exploited some some properties of the data which is worked on in this encryption algorithm. So you don't have to do certain things in FFT. So it's not like standard fifty and then it's even faster than than it's actually it actually is when it's centered. But I can certainly imagine you can probably do some hardware to accelerate homomorphic encryption. But what I think it's probably it probably makes sense to to take what is there, using gpus implement something practical and very, very useful like privacy preserving smart contracts, and then they will be economic incentives for people to create fast implementations of of comomorphic encryption, whether in software or in hardware, and the than we probably will have kind of a kind of economic competition of like whoever makes it faster will learn more money by mining and at the same time making there the platform foster. So it wouldn't be like useless a proof of work, it would be probably some useful computations which I incentivized to be accelerated. Wow, so explain to me a little more about this fft problem. I actually want to know more about how this, this actual encryption works, how it from a more basic standpoint. I wanted to a little more of the technicles that and can you kind of describe to me what what a lot of this looks like and why why this...

...is a revolutionary and maybe even provides some analogies on what the real revolution is that that that happened. Well, was it two thousand and fourteen or something, when the first page he was created, the first effort she was created in two thousand and nine by Craig Gentry. And Yeah, it was. It was a very interesting, interesting way. How he managed to do it, I think John, correct me if I'm wrong, but I think there was homomorphic for the kind of morphic encryption which would do like finite number of operations. But then yeah, so the thing is is the Craig Gentry didn't create the first homomorphic scheme. He he is the one who made a practical in his thesis. If you if you read his thesis, he talks about how we can take a somewhat it's called somewhat homomorphic encryption, meaning that it allows a both addition and multiplication. Right. So we have like everybody's familiar with, like Pia, the PIA cryptosystem, which allows out like additive homomorphic encryption, right, so you can only add stuff. With Craig Gentry, He created this concept of bootstrapping, which allows you to take a scheme that is also that allows additive and multiplicative and he figured out a way to have it do arbitrary number of computations. Before this we had schemes that would allow a certain number of operations, but it would they kind of they weren't that great. They're very bad. Had horrible performance. Again Limited in the number of operations you can do, which obviously limits the number of the type of allidoms you can do as well. So Craig gentry created was this thing called boots trapping, which allows you to just essentially encrypt your your private key or your secret key for this homomorphic scheme under the same key. This follows something called the circular security assumption that you can look more into there. And what it does is that then decrypts the data in the homomorphic domain and then re encrypt it again with the key so that it refreshes this this text. So the problem with schemes up to the state where that you, as you would, add more data to it, it would or, as you do more competitions to it, would add noise to the ciphertext meeting at some point the like, you just can't do any more computations to it. It's it's like too much signal, too much noise to signal. Right, and so he did. He call this thing called refreshing the cipher text. That just allows you to drop that noise ceiling below or to drop the noise below the sea oft the threshold again, so you can perform mark more computations. And so where we are at right now, and research is that this bootstrapping component of it is beginning to take the majority of the the majority of the of the computation in the performance. So there's a lot of room for it to be fixed there. But yeah, there are schemes like leveled homomorphic encryption, where you can like define and, you know, rotate the knobs of it and the variables and and make it so you can perform arbitrary number of competitions up to a certain point and then after that you can have no more. So the ideas that maybe you could construct a leveled scheme that only allows the number of operations you need to perform this one algorithm and you can do it in like a CECA secure manner rather than a CEPA secure matter now, but I guess for what privacy preserving smarts contracts, it's actually pretty important to to be able to do unlimited number of computations because you. Maybe you have out vote, but not necessarily. You want the original that original users to decry the south. Maybe you want to execute some more and more mythods using that as an input and leveled comomorphic encryption probably wouldn't really work with that. So you need to do boots tripping at some point, and that's I guess that's why we we're so excited about this, this scheme, because it does do boots striping and can do like arbitrary complex programs. So okay, so you're able to do these arbitrary complex programs. What are your current like requirements to actually execute this, meaning, like I didn't see your fth Berlin talk, so step me through what what that was like, what you can do with decentralized networks using this, and what are the room what kind of improvements in roomants you see coming forward in this? So it's really we won the youth brill and Hackathon, but building what was called spot nick spot like was just like a proof of concept kind of demo to demonstrate that, you know, there is a language that you can write, there's a parser that can parse that language and then there's a virtual machine that can execute homomorphic instructions. So it's...

...very, very primitive and kind of hacky still, but essentially what it allowed us to do was just define a a program state and operations on that state. So you can do logic operations like Xloor and not, etc. And every time the program would execute, it would output the state and a Miracle Tree. So the common the idea at the time was that you could use this mircle tree to kind of as like a verified computation kind of thing, where it's like, Oh, let me take you wouldn't be able to prove that some logic was done, of course, because you can't. That would require like zero knowledge proops and stuff to prove that logic was performed. But what we can do is prove the flow of logic. So if you have given, if you were given a ciphertext, you would be able to prove that a the output of that ciphertext was on the was always performed on chain, for example, where you can look it up on the blockchain, Hash your cipher text and use it and just like see like Oh, where, when was this done? If somebody gives you like some output of data, you want to know that a computation was done on it so you can look it up in the blockchain and see it. Furthermore, with distital decentralized computations and networks like that, the solutions probably lie and verifiable computation and things like that. I actually did quite fully understand that. So you're saying you submit you you have a system of Vm that does the fully homomorphic computation correct right, yeah, and that was separate from the Evm, I take it. Oh, yeah, separate. Is just a python program that was powered by new FAG. Okay, and then you committed mercle mercal trees. Are you basically to the blockchain, which then died proof that the execution was done. How do you retrieve your results from that and like it decrypted? So you'd have a client which does the encryption of your your data. You'd on board that data somehow. I don't know what that mechanism quite as basically you want to. You kin think of it as you store all that encrypted states off chain, right, some off cheese and some off chain storage, and you bag every step in the computation to the blockchain. Something like that. I feel like I feel like this is like maybe summed up as like a fully homomorphic auditability. Yeah, that's pretty much what it's computation on ability. You can. So all we did was just commit the mercle room to the chain and then we can pick any ciphertext, any points of the way it work is the way I I imagined it was like. You you look at it is like a mercle tree. You put out to perform an X or. You need to ciphertexts to perform an xmn. So you have been put a in it would be, and then you X or. What essentially is it just creates another side for text which is right above it. Right. So you can do that. And so if we put this in the form of a mercle tree and Hash everything together of that of that way, then the mercal route and everything would essentially be somewhere similar to like the output of the actual program state. So the ideas that you can take your ciphertext that you want to know if this was actually used in the computation, you can't. Like I said you, this doesn't prove how it was used. A provve it proves that it was used, though. So you can take the CIPHERTEXT, Hash it and it say, okay, I just generate a mercle proof for me that says this is that was actually used. Ye, I would say it was. It would it was probably the first step to to implementing this kind of privacy preserving blockchain as a side chain to etherium. And let's say, if if something went Ron, if some computation was done incorrectly, then in this mercle tree proving proving the results of the computation, you would have some some disagreement. So you probably could have the network of nodes recalculating all their dependencies of the broken parts, while leaving everything which was computed correctly still in place. Of example. That that's could be what this marcle tree could be seriously work being able to generate fraud proofs for various things. Yeah, right, right, so, but it's not like fully, not fully working, fully colomorphic side chain or whatever. It's just a proof of concept. Another important thing is that it was, it is using the state. So it's like a state based platform kind of, and this is an important distinction from from ze cash. So Zee cash, since it actually it's, since it's uses your knowledge, proofs, it has to have utx, so...

...kind of model for transactions. So you have all the Ze Cash Blockchain, you have some, you know, coin transfers between users on the network. And if well, basically now body can read coin transfers of other people. So if you observe this blockchain and you never transacted on Ze Cash, you just see some encrypted garbage, although you can verify correctness of that. But if you'd ever transacted on Ze Cash, you need to parse through all the blockchain and say, okay, so this transaction and that transaction were my transactions, so I can look at those and figure out how much money I have right. So that's kind of what Ze cash allows you to do. But you have to have all the blockchain downloaded and in etherium or like smart contract platforms like that, you actually have to have states, so you have every use they're having. He is State. Oh well, you have a global state actually, and the state shows like what is the current situation on the blockchain, so you don't have to parse through all the history. And with full homomorphic encryption you also have state, although it would be kind of state pro user, but it's still states. So user doesn't have to Parse through whatever happened. The user just can see what what the user actually has. Right now. I'd like to try and rephrase a bit of what you just said the way I understand it to see if I'm getting it correctly. And that's that's that's focusing on the difference between Ze Cash and what you've what you're working on now and and and Zee cash is done the way it is is because, and especially with utxo model, is because the way you do that type of homomorphic encryption is completely different. And so, yeah, in order to power, yes, it's yeah, it's it's your ledge proofs. So I just want to I want to like framenes and like a in a way that people can understand. Like that, the differences here and the way that they've done it, the way they implemented it, is done by you have to basically constrict the rule set down to a for efficiency purposes, a small number of possible rules in order to generate, do the do the trust and set up and generate all the primitives necessary to then construct proofs. And the way that you're doing or you're implementing homework encryption is a much more general approach that doesn't require you to define a very small rule set in the beginning. Is that necessarily right? I feel like. I feel like they've been will zee cash uses partial homomorphic decryption multiplicative specifically in the zk a proof. So yes, I'll just go ahead and I said I think that's that is correct. Right, Michael Tux, I would like you guys to expand a bit more on what exactly you're trying to get at that rule set. Okay, so that you in order to like verify something has done right, like the way I've always defined, I guess the Zero Knowledge Proofs or somebody is that you define a rule set. It's very like, it's very axiomatic and in order to in order for you to verify that something is done properly in a homeworfak set, you have to then encode all of those rules using fun math to create primitives that you then use to then verify stuff. That that like said, yeah, it followed all of those rules and and the more rules you in introduced into the system, the more difficulty it is to create those primitives. Arrived Ry. It's yeah, and I guess I'm guessing what you trying to say. And in full of come of morphic encryption, you can these rule you're going to have these rules running totally. I'm like, I'm sure the complex. Yeah, arbit's rear of the complex, and then you, if you want to, you'll may prove your control something involved, the result of God, but not necessarily about the whole process. Yeah, yeah, pretty much. Yeah, you can build like this rule set like you're talking about it. What you're defining our logic operations on literally just encrypted data. So the way you can do this is you can build protocols. It's very low level, like you said. So you can. You can build protocols that allow for certain things to be done like zero knowledge proofs and and other forms. So, for example, in the case of like Z cash, if you need to build a z like just as your knowledge proof of like some some amount of money, there's probably there's an algorism, like a logical comparator that you can build to be like is it greater than this amount? Right, and so, yeah, I'm trying to like trying to like expand on why this is so much more fundamentally generic then something like z your...

...and all the weight dewight ze cash, if with your knowledge proofs. Well, I still think of it myself as the difference between partial and fully homomorphic encryption. When you can make that distinction and I I call it partial. I'm not sure it's that the official term for it. Yeah, but you can do homomorphic encryption on a subset of operations. So Z Z can starts uses multiplicative operation. is fully is homomorphically encryptable. So that's how it does. It's your knowledge proof. It only focuses on the idea that you can homomorphically encrypt on the multiplicative property. So a times be equals C, encrypted a times encrypted B equals encrypted C and then you can decrypt C and get your actual result. But that only works for multiplication. You could do that for other things, addition, possibly. I Guess Division would probably be an inverse case of multiplication. Mushure if that would make a difference in the scheme. But you could do this on specific gate specific things that you can do. The hea differentiator, as I understand it, with fully homomorphic encryption is that is general compute. You can do multiplication, you can do addition, you could do x or logic, you could do literally any and by the way, it's probably better to think of it as as a logic gate than it is. From a logic gate standpoint that it is like the Mathi standpoint of multiplication. Whatnot? You do and you don and well with Nand you've got an universal gate. Basically, it's an and or nor whatever. You can do x or like. You could do these gates in a completely generic way where you encrypt the input data, operate on it, maybe even take multiple sets of encrypted opera input data, operate on all of them and return an encrypted result, and then you can, as the person who sub admitted the data, can decrypt that result. But you don't need to set up. Hey, this is only for multiplication. Hey, this only works for addition. Hey, this only works for Exhor you know you can. You can literally go this is just takes any piece of encrypted data that uses our scheme and outputs an encrypted output using that scheme. Is Is that answering your question, for clarifying it enough, Courri or did I do that wrong? So what you were getting that? Yeah, yeah, I think you're think you put it really eloquently there, because the way you have to think about it is is like this, this logic gate, right, it's it's building like that. It's much easier to think of that than addition and multiplication. And so, yeah, we and by the way, you said Nan and or. I think both you can actually use for universal gates. But yeah, so the way I've actually started looking into how to construct the stuff is to look just a digital circuits, just because they use the exact same things and I'm just like reading back and forth on how to, like you would construct some sorts of like some of these algorithms, and it's pretty simple. The only problem that we have now with with our current fag schemes is that like branching, for examples, actually fairly difficult. There's a lot of research in branching fag and but the problem is because it's encrypted and you would be breaking CPA security if you were to be like if this, then that, like that's just something you can't do right. For so you've said CPA a couple times and something else. Actually don't know. Those algorithms that I feel like I should are that acronym and I feel like I should. Could you explain that? Yeah, so it's just means. It's semantic security. It's I. It's indistinguishable under chosen plain text attack. So essentially it's like if an attacker has the ability to encrypt certain messages, can they leak some information? About about the key or something like that, or about the message. It break confident ally like that. So the idea what I'm saying by branching is like usually be like if this, if this, do this else, do that. Right. So with that FAC you actually can't do that because you have to do it. You have to construct programs in a linear fashion. So if you were to do it if else, then it would you would essentially have to have two different programs operating at the same time and concurrent to say like, if this is the output, do this and if this is the output, this right. And so it's complicated. There's a lot of research on this too that we've been meaning to do some more research on. But yeah, it's like one of the major problem sposible. Yeah, I guess. As a simple example to do it, imagine you have a for loop which loops hundred times and you have some eve conditions happening inside the fore loop. So you have two possible branches and you eat that hundred times. And imagine if you if you really had it going one or all the way, than possibly you could say, okay, the branch is executed faster than the branch. So and when you would it hundred times. It's multiplied by hundred times. So you can figure out that if it went this way,...

...is different by the execution time from when and when this way. But it should not happen. If this happens, it breaks your security. So you basically have to execute two branches and if it's in within the fore look, you have to execute basically to two branches to the power of a hundreds. So this is of course a problem. So yeah, so that's that's kind of a problem with full common worphic encryption, and that's why, like what we usually think of over normal during the complete program probably not necessarily is not necessarily always practical there, because you have to execute all the possibilities you just just described. Why most compilers are all compilers can't optimize loops on these some loops pseudon like tilers like you. If you compile something. I'd come from scientific computing. So like if you try and have your compiler optimize various loops to be more efficient, if you include arbitrary logic in there, like if statements, than they just they just basically ignore them because of that branching, because of the all of the possibilities that can go from each loop as you iterate through that loop, and I guess it's the same aim for like these types of things. You can't deterministically figure out what the possible space is if you have like these kind of branching out possibilities as you iterate through a loop and if you get to like the final execution state that, I guess people in the space into it what mercle trees look like. Each each level of the loop creates another level of the tree and you get to the very bottom, that thing is possibly incredibly large and searching that space determineistically is very difficult. Yeah, and then we also expand on this with the other problems of home or for encryption, like ciphertext expansion, and suddenly this becomes a very unmanageable problem. So does this limit the amount, the size of the computation you can actually do on your proof con concepts? Limit the size of the competition? The Not Nice? Yeah, but so like I'm complexitil the proxy is a right what I'm looking for. Okay, yes, so circuit. Know, there's absolutely nothing that limits the size. Are the the complexity of our of our logic. It's mostly just the language implementation. It's not really it's not a real programming like whige. So it's just a list of logic gates that we perform, I guess. I guess you're going to still practically say that's yes, that's dozz limit what you can do because, like if, imagine you have are for a loop with if condition inside, then I guess the circuit for that would be increagibly large. Of course you can still do it, but it will be very, very slow, and the intuition about writing normal programs is a little different from intuition about writing programs for fully homomorphic encryption problem, exactly because of this problem. But at the same time, if you want to just process a very, very large amount of data, maybe in my produced five fashion or something, then I guess it's it's actually still practical because you can have not necessarily is your pro complex program being executed being executed once, you have something simple being executive multiple times. And because of this too as well, it's like, as you start encrypting more and more data, obviously your ciphertext gets much, much larger. So one bit gives you to kill by. It's like right now. So if you want to do like something like matter is right. You'd have to encrypt a lot of data this and we're talking about a huge cyber text right. So it's not that practical for large data sets. Yet it's more or less practical for very simple executions and research right now is mostly would what we're trying it geting and trying to use this for, and I said earlier, this is a massive step forward in the efficiency of doing the Algorithm and necessarily the efficiency of the output of the Algorithm. And and it's for and public blockchain contexts. If you're going to be storing all these ciphertext in the blockchain, that then becomes quite a big deal. You need. You need that other part of the research to move forward as well for practical application. Well, your at Berlin thing. It sounds like you can actually prove computation to some degree using the blockchain. So you can do allfulay or two solutions which do the FAG and sit and share the data around, and what you've built is...

...basically a proof construct. So you can use the blockchain for what it's really meant to be used for and nothing else, which is really what we want to strive for. Anyway, everything hearing this. If you don't want to put your cipher text on the blockchain. That's clunky and nasty. What you want to do is prove that the result you've gotten from somebody doing an off chain calculation is correct. So what this is is kind of like an alternative to true bit, only kind of like more. I don't know if all turnamers right where, but all times have you now? Yeah, it's more it's just a yeah, a way of sort of verifying and now, I guess. Yeah, now I guess, maybe even like a compliment to true bit. So true bit as the problem right now where you'd have to share your input data, literally gotten everybody in order to get your your challenge results and whatnot in the bounties collected in Yadayada, Yada. With this you can do those bounties, in those challenges, improve them, prove your prove that somebody's, you know, mucking around with the system or doing something in an incorrect way, through consensus mechanism, consensus layer, like a blockchain, and it would basically allow you to sort of, you know, not broadcast your results to the world, but still have people be able to calculate on your data. If you give it to them and prove that they did a at least these steps, and if somebody also wants to run calculations on this data and come up with their own proof and it contradicts yours, then there could be a resolution or Yada, Yadayada. But right now what you've done is is said, hey, we could prove that I did this and I'm obeying these rules that you've provided on this layer two solution. You gave me the ciphertext and this is my output, and if somebody else were to do the same thing, they would be able to prove that there was something wrong, if yours not correct, or something like that. Okay, yeah, so basically you've used it as a truth, like truth Mechotis, which is really what a block supposed to be. Just talk a little bit about the higher implications of this kind of work and where you see this, this project going. What do you think? What do you think? When do you think people will start using these kind of things? How far are we from, I know that you said on the last program or at least ten years out from really good homomorphic encryption fully home? Now we that we said for at least ten, ten years out to start asking good questions about where we'll be. Okay, sure, then where do you? Where do you are? Ok then that really puts a hamper on my question. Their Corey. Sorry, where we gonna BE? Where's where are we? What's next? How was how who do you think is going to be interested in this right away? I think a lot of people are actually going to be really interested in mainly because people are using solutions like trusted execution environments, which are actually really horrible and not good for decentralized environments because they are trusted execution environments, not trustless execution environments. FAC represents a software based control in this respect and it is a is a trustless compute computation environment really. So it's like the one thing that we're that I'm at least really excited about, for it whether or not an even as ends up having amazing blockchain use cases, it's just this idea that we can have trustless computations at the software level, not the hardware level, and that's huge just by itself. Yeah, okay, abstraction, like sorry, allowed you to abstract away the trust and not put it in like we should. We should never care about the hardware if we can write right. And the problems are that there is the notion of security and fag where it is like it's not the greatest security, because the schemes for order are obviously valuable. So given a side pretext and the key, you can actually change the ciphertexted it and give you something that that may be dangerous for you to reveal this to the same party that computed it. So there's a lot of room for research here. And you're asking where are we? I think we're honestly good, two, three years out maybe from this being like the seeing wide scale adoption, maybe already, or even the first practical implementation of this stuff. Yeah, well, I would say that in at least that performance of Fahi feels already practical for something like privacy preserving smart contracts, whether you kind of have practical privacies to preserving smart contracts, that still kind of needs to be researched a little bit, but I think we're very, very close. But of course, implemented is one thing at in that adopted is another thing. And Yeah, and if you basically what's what options do we have right now for for private computations? We have full homomorphic encryption.

We have multiparty computation and trust that execution environments, trusted execution environments. They they are fast, but they currently broken and in simple you always probably will have a hardware site. Channel attacks possible. So you cannot really fully trust a stranger to execute the thing for you. You you can make it harder for the strange you to figure out what's going on, but I think it's still possible. With multiparty computation it's a little bit better, but first of all you, if you, if your computersclude, they will figure out what's going on. And also also it's it's actually currently requiring a lot of data exchange, like Gigabytes, if not stero bytes of data for executing, let's say, a simple smart contract, especially if you have more than three parts is computing your think. So multiparty computation is a little bit not practical yet and it was believed that fully homomorphic encryption is not practical yet, but we show that at least we can do seven thousand operations per second, which I think is at least performance wise practical for for privacy, preserving smart contracts, and so yeah, I guess performance wise it's there, but there are some other things which need to be worked on and the I think it's it's probably it's probably a couple of years until until we have like a practical platform for doing private but not really fast computations, which are all right for smart contracts. That kind of starts off with like why you do how anything slowly gets better and better, is that it's practical for a very small subset of things that really really need that type of functionality and over time, as it's developed, then the efficiencies gains, which then opens it up to a broader audience or broader use cases. Yeah, exactly. So maybe, I think that probably will work for smart contracts first, and then there will be economic consentives to accelerate that. Some ASIC manufacturers jump on it and make it, let's say, another hundred times faster, and then we are suddenly at about a mega hurts. Mega hurts performance and and maybe we can do something more complex like, I don't know, fingerprint recognition or like face recognition without exposing exposing anyone's privacy to to some strangers. And and then like a whole a whole bunch of applications which are currently done by central services probably could be done over encrypted data, but still still, even even then, I wouldn't use that to to do like performance critical applications because, let's say, if you if something takes a year or like, let's say if something takes several days to analyze all like real cpus in unencrypted form, even encryptic form, it would be, it would be actually way slower to do, even if you accelerate it in any possible way. So you really need to see us still be focused on some subset of operations which really require private data. So let me give you letting ground this fur them a minute, and I know we got to wrap this up in a second, but one problem that was presented to me that I think this could immediately kind of solve is people want to use cryptocurrency for royalty management and possession of assets in terms of, say, the music industry. So if you have a music if you're in the music industry, do you want to use cryptocurrency as your backing mechanism for actually, you know, licensing a particular piece of work? They can't do that right now with the current smart contract system because, guess what, they don't want to expose what their their licensing agreements are. They don't want to expose who gets a percentage of what. They don't want to expose who, you know, who gets to take. How much does spotify get? How much does a music label get? How much does the artist get? Nobody wants the world to know that data. This doesn't just apply to royalty management. It also applies to, say, bills of lading and supply chain. When you're doing trade, it transport from point A to point B. They don't want to expose their deals to everybody, but they still want to operate on the data and they want to do it in a trustless way that's backed with some sort of token security. Right now they can't do that because they can't keep it private. They can't do it in a way where they unless, say you...

...something like threshold relay, where they're passing the documents around, but even then, like they would rather do it in some automatic, automated way and prove that it's been done correctly. HMM, fully home more for your cryption and a very minor scale, just calculating percentages, just basically saying you get this cut, you get this cut, you get this cut. Can take the rule set as a ciphertext and output the result as necessary, and nobody necessarily knows what exactly is going on in the little black box of the virtual machine. And they can still in the fact that they can prove it on the truth mechanism and even make changes to to two balances that maybe eat exist off chain and could be reflected on chain through some resolution layer which is also hidden and also kind of a black box system. To me sounds really, really interesting, because then they can do their calculations in aggregate, they can have their total balances committed in aggregate, but they don't actually have all that information exposed. And this is not complicated programming, this is not a varied this is not fingerprint analysis, this is basic multiplication and addition problems that are all over the financial world and people want to be able to use cryptocurrency to kind of back this because they like the features that it has, except it doesn't have privacy, and so I see the fully homeomorphic encryption, the stuff that you guys are building, to be kind of the thing that might bridge the gap and make some more broad adoption into this space, because it will enable these kind of transactions to occur through a trustless mechanism such as a blockchain and resolve out on the blockchain as a on the resolution layer. So, yeah, really interesting stuff. Yeah, looking forward to seeing how this progresses. Is Anything we should ask you that we didn't? I think we got our basis culvered. Yeah, I feel much better about where you like, what you've done, where you're at, what the maybe some of the potential issues, if where I'm moving forward and kind of the timelines associated with it, and I hope that audience can to how can people reach out and get a hold of you with respect to this work or even the proxy re encryption stuff? You can you know me a John at new CIPHERCOM or you can use my personal email at me at John Pacificcom. Yeah, all you can give on me and mine call it Nsifi, docom or actually I would recommend to go to nesciphlecom websites and find a link to all of these cords and then you can ask all source of questions and every any of us will be hype you to respond. Thanks, guys. Appreciate as great and, as usually, you can reach US Corey at Corpetti on twitter and myself at Colin Cuche on twitter, and yeah, thanks, thanks, come on, guys,.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (127)