ZKPodcast: Proxy re-encryption and FHE with NuCypher

Transcript

[Music] Welcome to Zero knowledge. A podcast where we explore the latest in blockchain technology and the decentralized web. The show is hosted by me, Anna. And me, Frederick. [Music] In this episode we sit down with John and Bogdan from New Cipher to talk about proxy re-encryption and fully homomorphic encryption.

[Music] Before we start, I want to let you know about an event we will be hosting next month. The Zero Knowledge Summit will be held on March 22nd in Berlin. This upcoming edition will again be about zero knowledge research, ZK snarks, starks, cryptography primitives, privacy and maths. But we'll also have a special focus on the use of ZK systems for scaling blockchains. If you're a builder, researcher, founder working on these topics and want to join us, registration is now open. I will add the link in the show notes.

Here you can also submit a talk proposal. Please note though, space is limited, so do apply early. Cool. One more thing, if you want to stay in touch with us, please have a look at the links in our show notes. You can find us on Twitter and Telegram. Hope to hear from you. And now here's our interview with New Cipher. [Music] Today we're sitting with two guys from the New Cipher team. Um, Frederick, hi. Hello. We're in three different time zones, which is kind of a This is a This is a new one for the for the podcast.

Um, we have ourselves in Europe, we have Tux in Salt Lake City, and we have Bogdan in Melbourne. So it's not only three different time zones, it's also three different seasons. So in today's episode we want to talk a little bit about the New Cipher technology stack. We want to talk a little bit about fully homomorphic encryption, which we're learning how to pronounce better and better every day. Um and uh and yeah, I I'm really excited to finally sit down with you guys. You guys have been participants at the summit.

We've We've actually come into contact with you a bunch of times, but we've never actually dug into what you're doing. So welcome. Thanks for having us. Uh, why don't we start off with a quick intro? Why don't you tell us who you are and what you're working on exactly? My name is John Pacific, aka Tux. Um, mostly in the I'm mostly called Tux in the hacker circles as well as just my professional life, I guess. Um, I am a cryptography engineer at New Cipher. I joined when the project was first started. I was one of the first hires. We've been building New Cipher. So I focus on um, building and working on our proxy re-encryption network as well as doing some research for fully homomorphic

encryption. Uh, some of my work was uh some of our research I would say has been demonstrated at EthBerlin uh where we made Sputnik, which was kind of like a a assembly assembler type language for fully homomorphic encryption that would just allow us to prototype uh building some schemes out of logic gates using a library that Bogdan uh wrote called DuFE or something. Okay. Well, I joined New Cipher last July uh to work specifically on FHE and um I tried to improve the existing TFHE library by putting it on the GPU and it worked pretty well.

And now we're now I'm working on um on some other FHE related projects which I'm not sure I'm supposed to disclose, but we can just leave it at that. Oh, exciting. We I think we're probably going to leave a lot of a lot of the details the implementation details out of the conversation, but we will share a lot of what we the problems we've encountered for sure. Yeah, like Anna said, we've been in touch with you guys a bunch of times and in both the summit and and otherwise around Berlin at various hackathons and other places. Um, and you didn't really start in FHE land or like this this

wasn't what the project was, you know, originally around. Um, you're doing a lot of proxy re-encryption and and stuff like that. Right. How how did New Cipher come to be and then maybe we can kind of lead down the path of how that led it into the FHE work and other stuff. Yeah. So um New Cipher originally started as a company with from Michael and McClain called ZeroDB, which was like an end-to-end encrypted database. Um, that evolved into what New Cipher is today where it was proxy re-encryption.

So proxy re-encryption was just this really novel piece of tech that we had known about and and ZeroDB had had actually implemented. And so building New Cipher, we decided to originally build a key management system using this technology. And so we started on that. Um, and as we got more and more into it, we also have many other interests in cryptography as well such as fully homomorphic encryption. It's been something that's kind of like a dream. Uh, kind of like a like a a moon shot, if you will.

That we that, you know, we have these research projects open. And the more and more we looked into it, the more and more we saw how practical it was, at least for what we wanted to do with it. Um, it's always been kind of like an idea in the back of our head. Um, and the most big driving factor for me is has been seeing uh a lot of competitors and people using trying to implement private smart contracts and sort of not doing it good enough or over promising and under delivering very very hard. Uh, so FHE has just been this kind of really interesting research project to see what is possible, what's not and how far it can take us. And so

we do both actively more so on the on the proxy re-encryption on this side, but we are hiring more for research and and actually have quite active research going on right now for it. Feels like fully homomorphic encryption is sort of the I don't know if the word is last bastion or something. It's like this this end goal of a lot of the whole It's the holy grail exactly. Um Yeah. So you guys are tackling a pretty big problem with that. Yeah, it's it's it's funny for it to be called the holy grail in my opinion because it's there's so there's a lot more problems out there that I think are very just as interesting as FHE. And it's when you start kind of digging into it, there's

like a few use cases for it that aren't great and there are some that are great for it. Uh, so I think it's kind of has like built up a quite a huge marketing hype around it, perhaps more so than it probably should in some cases. But I still think it's very cool nonetheless. Mhm. But before we jump deep into the FHE stuff, what if we do talk a little bit about what what the main core New Cipher product or technology is, this proxy re-encryption?

Sure. Uh, so proxy re-encryption is a variant of asymmetric cryptography or public key cryptography. Essentially, we have everyone's probably familiar with Alice and Bob in the cryptographic narrative where we can encrypt data with Bob's public key and Bob can decrypt it. So Alice and Bob can communicate through this channel like that. Uh So essentially, if you it's what proxy re-encryption is really fantastic for is access control and and delegation.

Uh, so in this very classic case of this, what proxy re-encryption allows people to do is, for example, Alice can encrypt data with her own public key. So Alice encrypts data with Alice with her own public key and then Bob can go to Alice and say, "Hey, can I have access to this data?" And Alice can actually transform or a proxy can actually transform uh this data from Alice to And without Alice needing to reveal her private key. Exactly. Yeah, all she she just generates a re-encryption key in our in our scheme at least. She generates a re-encryption key using uh her private key and Bob's public key and we can create

a so just a re-encryption key from that that allows us to atomically or like in one single operation transform cipher text from Alice to Bob just right there without ever decrypting it in the first place. But you also have this you have this threshold proxy re-encryption scheme and I was looking into it, but I didn't quite get that. So maybe you can explain it a little bit. So traditionally, uh the the proxy in proxy re-encryption comes from having a third party, the proxy itself, actually perform this re-encryption or the transformation, right? So normally, you'd see that Bob if Bob wants to get access to Alice's data, Bob would go to the proxy and the proxy would normally delegate access to

Bob himself. That way Alice can tell the proxy to delete her key and no and Bob doesn't have access to the data anymore. So Bob doesn't have to go to to Alice uh directly. So it's kind of like a triangle there, right? If you can if you can visualize that. So, the problem with that kind of proxy re-encryption is that where it's only stored on one key is that that's a very trusted situation. You have to trust that the proxy is not going to store the re-encryption key or hand it out because the re-encryption key itself actually is somewhat of like a private material. Not as much as like a private key by itself would be, but anyone with access to that

re-encryption key could potentially reveal some information about uh the grantor or even the delegator to an extent. Right now, like in that basic example, what is a proxy? Like, where does it live? Is it Where Where What is that exactly? So, the proxy, you can imagine would actually just be like any traditional cloud server or just a trusted machine, you know? So, the For example, uh there are some companies out there right now uh that do use proxy re-encryption uh as some sort of like access control system, uh but you essentially have to trust that they're never going to reveal it, right? And And given some threat models, that is not acceptable because that can actually in a in an information leak,

that can actually reveal some information. Uh depending on who gains access to that data. If I understand it correctly, when I looked at it it I think it is that um like if the proxy and Bob collude, they can uncover Alice's secret key. That's right. Yeah. And And that also goes And And depending on other schemes, that also goes in the in the in the other direction. So, for example, the the seminal uh work by Matt Blaze and Blum and Strauss, I think BBS '98, uh which was this uh proxy re-encryption algorithm when it first came out, uh it was bidirectional and interactive, meaning that you needed both Alice's private key and Bob's private key to to create this re-encryption key. So,

Umbral, our scheme, is non-interactive, and that doesn't need We only need Alice's private key and Bob's public key. So, that way Alice can grant without having to take any his private information from Bob. So, let's go back to that problem. This So, this proxy, it sounds like it's a it can be a relatively centralized body. So, this is what you're trying to make safer. Yes, exactly. Yeah, so like in a traditional uh setup, you could imagine uh yeah, like just these two parties and there's a central trusted service, like a SaaS or service provider of some sort that you can say, you know, I'm going to trust that they're not going to collude and everything's nice and dandy. Like, if you're moving this to a blockchain space now and your proxy is like a

blockchain miner, there's not really any trust or there's not supposed to be any trust or you know, there might not be civil resistance mechanisms or whatever else, yeah, you obviously have a problem. So, that's that's where the thresholding comes in. Yeah, so what what do you mean by thresholding then? So, thresholding Yeah, so what we mean by threshold is simply like a kind of a variant of secret sharing. And we actually use uh Shamir secret sharing, and that's where that threshold uh term comes from. What it precisely means is that Alice or Bob, when Bob wants to gain access to Alice's data, he has to perform a number of re-encryptions on the NewCipher Network. So, what we do is we take a re-encryption key and then we

split it using a secret sharing scheme, and we split it into n frags. So, we split it split it into just an n number of fragments and distribute them to different nodes on the NewCipher Network, okay? And then we have a threshold, which we call which is called m. So, you can call this m of n threshold cryptography, uh where we simply need to perform n or m re-encryptions of those n uh fragments that have been distributed to actually gain access to that data. So, in a in in more uh practical examples, we say uh we need three of five. So, you can distribute five fragments, and then you only need to perform three re-encryptions to actually gain access to the data. So, that's where that

threshold comes in, and that's where we get that trustless uh security. So, now it's much more difficult to collude with three nodes uh three on semi-honest nodes or semi-trusted nodes, as you may call it, than uh out of those five, right? Instead of having to just find one there. It's almost Is this a bit like um So this Is this a little bit like a multi-party computation cuz you have like five bodies that have pieces of data and then only three need to be honest?

Yeah, so it it can be viewed as it um So, for example, it's the security it's not really put inside of the MPC context. It can be viewed similarly like it. I wouldn't say it is an MPC computation, Okay. but it kind of is because we actually perform opera- mathematical operations on the sharded fragments of that stuff. And then uh when you get it back, there is an assembly operation to kind of uh reconstruct all the operated text back together. So, another big property is that uh when Bob wants to get these re-encryptions performed on the network, uh the proxy nodes do not reveal the re-encryption fragments to Bob.

Otherwise, Bob can always gain access to the data, right? So, uh those are kept somewhat secret. That's why we say that semi-honest context is because uh the nodes are expected to behave in a non-malicious kind of uh manner, where they should not distribute this uh information. Uh so, there is somewhat of like an MPC operation going on there. I wouldn't consider it MPC because it's not really defined uh in that context, but yeah. Sure. How do you define So, when I was looking at this, I I saw that there's this lower threshold, but I didn't understand exactly how What makes What's the threshold that's safe? Like, is there a percentage that you need to reach, and how did you figure that out anyway?

Yeah. So, um it is my personal opinion and in an active area of research that I think that there is a potential uh golden ratio, if you will, of like uh of a threshold uh that where it's like you maintain a good balance between security and performance. Um but that we have yet to perform that research and and figure out what that may be. So, I I have a I there might be the existence of this of this golden number that is perfect, uh but as far as we know now, there there we don't have that. Um if we're talking about traditional secret sharing schemes, well, there are numbers that should be

used more than other numbers uh because if you uh don't If you If you do some of the weaker numbers, for example, I think I I can't remember the actual definitions right off the top of my head, but it's something like um sometimes if you if the threshold is too low, then you can actually leak bits of the of the plain text out through the through each share. So, you're like leaking a one bit from each thing from each fragment. Um I I don't remember off the off the top of my head what what exactly that that security is. Uh but there are some The way we look at it in the NewCipher Network is uh essentially that security versus performance, where obviously the smaller

threshold will allow you to have more performance on the network, less time of network operations. Um I just did some analysis and I found that it's roughly around uh 1,400 milliseconds for a three of five operation, at least on my network connection. Um so, that's from time from access from uh from request to access, right? Um so, it's it's still fast, uh but obviously if you're using it a lot, that can be a a major bottleneck. Um another concern is uh obviously if collusion of those nodes is in your threat model, then you need to start worrying about exactly uh how many nodes you have that that key those that re-encryption key distributed to,

and how many of them actually need to collude. So, in a three of five scheme, you would be expecting that three of these nodes will not be able to collude. And if three do collude, well, then they gain they can potentially gain access to uh this re-encryption key, right? Which, you know, is arguably not a big deal in this in the setting that we've created because all only it can it can only allow access to be granted from data that's already been encrypted. So, that's kind of where it's at there. You're trying to mitigate and think about and reason about uh what collusion uh is is possible and your performance.

Yeah, so I'd say it also comes down a lot to threat model and just like how valuable is it to get these uh people to collude. Like, if you're trying to decrypt NSA's database, then uh it might be pretty easy to get three people to collude. If it's, you know, selling some like my weather sensor data here, like, no, probably people aren't don't care that much. Yeah, so a big problem with the Tor network, for example, is that you can just spin up any node, and that the longer you're online, the more and the more reliable you are, the more favor you get, the more uh data that gets uh transmitted to you. The reason why NewCipher has our token is so we can have this game theoretical security component to it, so we can actually uh

create a barrier for entry uh for governments or or for other people to get online. So, for example, if you want to take control over a ton of nodes on our network now, you'd actually have to put a lot of money down and actually drive the cost of the token way up uh just to get an access to enough tokens to actually even begin performing these re-encryptions. Uh so, it's much easier for us to actually build models in that case and and do that. But, exactly as you said, uh threat modeling is such an important thing here in many cases uh in the most cases I think for blockchain and decentralized applications, NuCypher is perfect uh for what you're trying to do with it for access control.

Um for other people, it may that may not be a great threat model for you depending on the information. Obviously, for something like state secrets, if it's not if the servers are out of your control, maybe that's not such a good thing for you, but that's always up for you to decide, of course. What's the history of proxy re-encryption? Cuz you guys didn't invent that, did you? No. So, where where was that coming from? What era? And like what else has it been used in? Um so, essentially, we we're actually like one of the first practical as far as I know actually applied implementations of proxy re-encryption.

There's We have some centralized competitors that are building tech on proxy re-encryption. Uh but we are the first, as far as I know, uh to actually have used this in in this manner. We have We haven't seen any other companies use proxy re-encryption like this because like I said, when it's in that centralized trusted scenario, it's really has kind of like a weaker security property cuz you have to force essentially have to trust somebody that they're not going to try to screw you over or reveal some of your data. Um but now with uh blockchain applications and decentralized computing, we actually have the option to the opportunity to

make this a very secure environment. And actually have like a very nice threat model enabled for it. But uh where it came from is 1998 from that BBS 98 paper that I talked about before. Uh essentially, it's It was called atomic I think it's called atomic proxy and atomic operations or something. Um it's an interesting name of the paper. We'll definitely we'll add it to our show notes, so we'll find it and add it there. Yeah, yeah. It's a It's a It's a It's a really really cool paper. The the scheme the BBS 98 scheme itself for proxy re-encryption is exceptionally simple.

The mathematics behind Umbral are very easy. It's nothing complicated at all. It's not I wouldn't even It's not even anything like new math like you'd see with the ZK-SNARK or anything. Um the the most complex stuff we added in are just secret sharing and and actual proofs of proof of proofs of correctness, which are like a zero-knowledge proof. A very simple protocol one not nothing like a ZK-SNARK again that essentially proves that re-encryption was done correctly. That way we can prove that a node didn't try to maliciously just gain not just do nothing just to gain money from you.

Uh but yeah, the history is that it's just it came from 1998. It had schemes I think some original schemes in it were for mail forwarding secure mail forwarding where you could encrypt mail for one party and then forward it to other parties as well. Um of course, that never really took off and and in a lot of cases where proxy re-encryption has I think been proposed, it really just hasn't taken off. But now, funny enough, we're seeing a huge like just a huge upstream in in in more PRE projects out there.

At Real World Crypto, there was a paper there was a talk on proxy re-encryption by Visa Research. Um and there's a few other companies out there that are doing proxy re-encryption as well. Um and as well as I think there was also a proxy re-encryption paper submitted in another pretty large conference as well just recently. Uh but now it's just now gaining a lot of traction and and ground movement here. So, what do you think like what are the use cases for it now? So, you just mentioned like back in the day they were thinking about it for email forwarding and stuff. Now it's more popular or at least there's more attention focused on this. What is it for and who uses it? The best applications in my opinion are access

control. Essentially, once something has been encrypted for a specific key, it can't not be not encrypted for it, right? Um so, given some threat models, um it's much easier for another a third party to just grant access to that data and you go through it and access the data in like an access control pattern very similar to how you'd see with like Google Cloud KMS or Amazon Web Services KMS where you go to the Google services or the Amazon services and say I want this piece of data decrypted using this key and it decrypts it for you and hands it back to your your service.

Um so, that's been that's a very scalable and very like secure model that people are building on top of now where they don't have the keys stored on their own machines. They have the key stored elsewhere and they can gain access to it as long as some conditions and rules are met. Um so, uh with that's kind of where I'm seeing it being used a lot more now. And that's as well as what some of our competitors that we've seen come up that are even in more centralized contexts are still building on top of this access control system uh where they can essentially gain access to this data that you grant uh grant them access to and then revoke it when they don't need access to it anymore. I I was wondering, is this Frederick This is actually a question to

you. Is this similar at all to the Parity Secret Store? It is, but it's a I don't know. It's a pretty long explanation. It's The goal is similar. It's achieving the same things, but in quite different ways. I see. I see. I think that Parity Secret Store also does like You do distributed key generation Yeah. Yeah, that's right. Yeah. So, they do distributed key generation along with I think a threshold cryptography variant as well that allows you just to gain access to it and then revoke access from that. Yeah. So, NuCypher and proxy re-encryption actually goes a bit beyond just the key management and access control.

So, for example, once a policy is on the network um you know, you don't have Alice doesn't have to be online to actually keep the encryption or the data from being shared anymore. She can pretty much just be like, "Hey, I want all data from this from my from my key to be decryptable by this person." And then she can just disappear from the internet entirely and this encryption can keep happening and as well as all the data can also be re-encrypted for this new person. Um so, there's some other properties that allow us to get that allow us to gain far more than key management. So, when I say we NuCypher started off as just being called the NuCypher Key Management System, um we actually removed the key

management system part because of this cuz the more we actually started building with NuCypher, the more we started realizing that the key management was kind of limiting in its capabilities and that there was so much more that we could do with it. So, that's kind of where we've where we've gone from there is is working on and focusing on those things. Uh so, how did it go from this focus on proxy re-encryption and then dealing with blockchains and and stuff there to fully homomorphic encryption, which sounds like it's a completely different thing.

You know, how did that gap get crossed? So, it's just you know, there's this appeal to FHE where you can essentially say, "Oh, we're we're researching the holy grail of cryptography." And I think every cryptographer is interested in it to an extent. Um it's a pretty hot button topic in my opinion. Uh but it's something we all have I have actually been witnessed to a fight involving Oh really? someone arguing for FHE versus TEE. That is true. Uh-huh. I would actually be in favor of FHE and I can I'm very violently in favor of FHE over TEEs. I I can join that argument so hard.

But um there's uh yeah, the from NuCypher from going from proxy re-encryption to FHE, we're not transitioning at all. We're not moving our product from proxy re-encryption to FHE. These are just two separate products and one's more of a research activity for us now until we can finalize and figure out exactly what our end product will be. Like we know that we can make this possible. We know we can we can build a product out of this. But of course, we want to be able to deliver the best product we can and something that's usable and not you know, overselling what we can actually do. So, we're spending a lot of time trying to figure out this is possible, this isn't possible, and this is very

possible. And we're trying to we're kind of like going and just figuring out where it fits best before we start moving on and developing that product. So, we've hired researchers to work on that. We just mentioned this earlier in the episode that fully homomorphic encryption seems to be the holy grail. Maybe we should explain a little bit what that is for our listeners. And then I want to hear a little bit more about how you guys plan on tackling that. Sure. And Bogdan, I'd love to hear from you, too. I don't know if you want to since I know you're you're the FHE researcher as well, so Yeah, well, the thing is that I only got into this topic when I joined NuCypher.

So, I may not know as much about it about same areas of it as Tasos, for example, but I can try to explain what I know. Uh Why don't you explain Why don't you just help us understand what it is. We We sort of briefly explained it in a previous episode, but I think it would be good to to say it again here. All right. So, FHE is a way to perform computations, pretty much any function, on a data without actually knowing what the data is. And uh well, that is what's called the fully homomorphic encryption. When you can perform any operations for any number of times uh losing losing the data and it can be

decrypted at any time after that. There are weaker versions of homomorphic encryption that which are called somewhat homomorphic encryption where you are limited where the length of the function that you can apply is limited. For example, or the operations that you can apply are limited. That is also possible and they may be faster or they may have some other good properties but you have to be aware of the limitations if you don't want to lose your data.

And the feature is that we are working on a fully homomorphic ones. So so that you don't have to worry about that. Well, there are different schemes now available. The major ones I think is the TFHE which is the FHE on the torus. What is this? It's TF TFHE So that's the TFHE torus fully homomorphic encryption This is the one that we uh sped up with a GPU. Then there's HE which works well, TFHE works with binary gates. So all your data have to be split into bits and you can apply gates on

them like and gate and gate or gate or gate and this kind of stuff. With HE which is the other version, you can work directly with integers which may be easier. But it has other limitations as well. The gate thing sounds kind of similar to what the gates in a ZK-SNARK construction is. Is that at all related or Okay, that maybe Taxel will be best to answer that because I don't know know much about ZK-SNARKs. ZK-SNARKs I think are and I'm not super knowledgeable in zero knowledge applications quite yet. I'm still trying to gain a considerable understanding there so I can dive in and apply that to FHE as

well. But as far as I know, those are built out of QAPs or quadratic arithmetic programs or something. They're very they're kind of very similar where essentially except in FHE it's much more I'd say binary for certain operations. So as as Bogdan said, we have like FHE that allow us to work on integers and FHE that allows us to work on binary gates. So I'm actually not sure how the QAP fits in with ZK-SNARKs but essentially one just a lot literally lets you call a function called like for example and it would just be an and gate and given two encrypted bits you can get the and the encrypted and of those two bits.

And then there's also one that you would just let you do an encrypted multiplication where you could just multiply two integers or multiply two encrypted integers. Then you're just literally calling exact functions on these. As far as I'm aware [Music] ZK-SNARKs are quite efficient but I actually have to think there's probably reason to believe that there may be more efficient schemes out there in the form of of of lattice cryptography whether or not the research has been done yet. I think that the the the reason to if I'm going to actually answer this question technically, I would say that literally FHE fully homomorphic encryption actually implies that zero

knowledge cryptography exists. So we can actually we can imply that zero knowledge exists through FHE but not the other way around. Huh. If that makes sense. Is it like a subsequent step in the Kind of. development? Kind of because it just and I'm I'm kind of I don't want to say something wrong and be crucified for it. But essentially if you if you start reading Gentry's paper his his 2009 paper on FHE itself, you'll start seeing the applications and how similar they are but what are the major differences of it. And so FHE is just kind of thing like if there is an FHE scheme, then there probably lies an efficient zero knowledge scheme as well.

And we've already known that zero knowledge was a thing since Goldwasser and I think McCauley as well. But yeah. They're they're kind of you have to think about building programs in a similar manner and with ZK-SNARKs I think and QAPs but they're it's much more binary I'd say. Bogdan, you just mentioned this torus FHE. Maybe we can explain what that is. It's a I mean as far as I understand it comes from it's like a research paper that comes from a different group. Yeah, it's a mathematical thing sort of I guess a metaphor for for the structure that is used in the FHE because uh I think most of them or at least TFHE are based on polynomial arithmetic. So

you have polynomial coefficients which belong to a finite field which is kind of a ring. And then you have the polynomial itself which is also a ring. So it kind of becomes like a torus. two rings Wow, so it's cuz of the two rings. That's where it comes from. of a torus. Is that the idea? Yeah. Interesting. The these polynomial operations are in the base of TFHE and they're actually the main bottleneck. And that's where the name comes from. the new the you have the new cipher FHEs which you've named new N U FHE. Well, it is new and it's not new at the same time because it is the implementation of TFHE just faster.

So it's it's actually updated FHE but you've called it new as a new cipher so like the new Yes, it wasn't my idea. Very modern spelling of new. I actually think that was my idea. I'm sorry. I don't know I'm not mocking. I think it's cool. But so it's new FHE so that is based on this torus FHE. Yes. And it's just made better. Sped up by GPUs I suppose. Yeah. I I wouldn't go as far to say it's it's literally made better. It's just It's made faster. It's made faster exactly. Okay. It's a new implementation of it. Yes, it's a new implementation.

So I can imagine this sort of gate structure like conceptually I can imagine how this gate structure would be parallelized pretty easily on a GPU. Just because we had Howard Wu on this show a long time ago to talk about distributed ZK-SNARKs and they were doing the same thing for SNARKs where they took a subset of this circuit and deployed that on a on a separate machine. Now for SNARKs like this is non-trivial because it requires so much GPU blah blah blah. You can't really do it on a GPU but I imagine like the the structure would be similar like you take a subset of these gates and execute on one core

of the GPU or how would how would that work? Well, the main parallelization that is happening is actually the parallelization of polynomial operations. Of course, if you have several gates well, several bits that you need to apply gates on, that helps because for like powerful GPUs like Teslas, just one gate is not really enough to fully load them. But still the polynomial operations are essentially FFTs which are well researched topic for GPUs and there's a lot of stuff that can be made that can be used to make them faster on GPUs.

So yeah, that's the main thing. But of course, the maximum speed that new FHE achieves it achieves on on a lot of gates. I think I measured on like 4,000 bits at once. Okay. To reduce the overheads. So what what's the limitation? Like what kind of size computation can you describe and execute efficiently? I think we measured it and it's kind of like was it ENIAC? Uh Oh, yeah. Yeah. Yeah, it's kind of it can be comparable to like a an ENIAC.

old old computer We we pretty much the reason why we we came up with that number is cuz we we essentially were like oh, this is it's slow but it's actually perfect for decentralized computations. Cuz we don't nobody is in you're not using the blockchain if you need a fast computation, right? Yeah. Yeah, so it was like a it was like an ENIAC but I would say it's like the really the real power from it comes from like if you wanted to perform an encrypted computation on one piece of data like that that's fine. You can do that. But like the GPUs can be fully maximal like completely utilized if you have like 100 or 200 or even thousands of the same

piece of data and you need to perform or different types of data but you want to perform the same algorithm on it but encrypted, you can do that and you can do it very quickly. So that's it's that's yeah, we've measured it to be around yeah, ENIAC and Yeah, so you can you can essentially you can't describe a large program but you can describe a small program and execute it many times very quickly. Yeah, if you wanted to describe a large program, you could. Runtime would obviously be slower but there is no limitation to program size.

It's just how long you're willing to wait for the output. Yeah, like there's there's a practical limitation of not wanting to sit around. Yeah, exactly. But I think we will see speed ups on this soon enough and whether that be through TFHE and and hardware implementations or for number theoretical breakthroughs and research breakthroughs. I think I didn't I have a bit of a zero-knowledge question here, but I didn't I don't know if you defined it, but what is ENIAC? What do you mean by that? I actually don't get the reference.

It's the first computer kind of in popular terms. Yeah. Yeah, it was one of the first computers. I think it was used for Cold War I think it was used during the Cold War for targeting artillery. like ballistic trajectory calculations, something like that. So, you've come up with you've come up with like a sped-up version of Torus FHE that you're calling new FHE. Um what I what I am curious about is is there any relation to the proxy re-encryption with this? Are you going to be using this in tandem? Is it just a brand new research project? Like what's the what's the connection? I'm not willing to answer

to the extent how we may combine our current proxy re-encryption technology with our fully homomorphic encryption research. Uh however, I will say that FHE does indeed use a form of proxy re-encryption. In fact, if you read if I referencing back again to this paper, Gentry's 2009 paper, he describes a proxy re-encryption algorithm to achieve fully homomorphic encryption. Uh so, essentially, what happens is to like Bogdan brought up the topic of somewhat fully homomorphic encryption, which allows you to perform what a a certain sized function or certain sized circuit on an encrypted piece of data, but the moment it you exceed that, then

it's no longer decryptable anymore. Uh so, Gentry had this problem with how do we make it so it can be used for any arbitrary sized a circuit. Uh and that's where that proxy this form of proxy re-encryption came in in the in hand there, where it was actually applied. Essentially, you're you're calling an encrypted This is going to get really freaky, but you're calling an encrypted version of a of a of a key. You're calling an encrypted decryption function on the encrypted data. Uh so, you're essentially decrypting the data while it's in the encrypted domain. So, we call this the homomorphic domain, meaning that it's been encrypted, and now you're performing the operation on

it. So, what you're doing is you're calling the decryption operation on the encrypted data in the homomorphic domain, and then you're re-encrypting it again under a new key, which allows you to bootstrap that's what his term was called it's called bootstrapping, uh which allowed you to now perform further operations on it uh on this piece of data that that allowed you to, you know, keep operating on it without increasing the noise level so that you could still decrypt it later on. That's interesting. Yeah, so all the all the best forms of fully homomorphic encryption are essentially based off this bootstrapping. Uh there's some that don't require bootstrapping as far as I know, and I haven't really looked at a whole ton into those. Uh but there is a

there are some security problems that lie with with FHE and this bootstrapping operation uh that we don't fully understand. Uh we just know that it may not be preferable, and we don't really know how it affects the current security of it. Uh for example, we have this operation of uh this notion of circular security, where we can have a key uh encrypted with its own key, if that makes sense. Uh and we actually don't know how that affects security in many ways. We can actually build a CCA2 secure encryption scheme that falls apart uh when and when this happens, when the key has been encrypted with its

own key. Uh Matt Green uh made a great blog post on this, by the way, on I think it's just literally called on circular security. Um and it's a fantastic blog post if that notion interests you, but essentially, bootstrapping uh FHE requires that you follow this notion, uh where you have to encrypt your uh encryption key with the encryption key itself so that it can be used in the homomorphic domain. Um and as far as we all know, we don't really have a great understanding or grasp of what that may affect. Uh so far, everything seems okay.

Uh but it's certainly far from preferable. I I have a question on the domain stuff. So, when I've looked into FHEs, there there's fully homomorphic encryption, somewhat homomorphic encryption, and then there's this domain argument. I always thought the domain was was like what's the domain of of things that you can operate on. So, like in fully homomorphic encryption, it would be anything in in like an integer like where you have multiplication and and addition or something. That's your domain is like those two functions.

Well, it can be it can be used in both those ways. I'm speaking in domain abstractly, where you can essentially say, yeah, you have the plain text domain, and then you have the cipher text domain, Mhm. Uh which you could also refer to as the homomorphic domain, I think. But essentially, like in the plain text domain, you have the the ability to perform any arbitrary computation you want. Obviously, you can add two numbers together, you can multiply two numbers together, you can do whatever you want. In the encrypted domain, you may traditionally, you don't have the the ability to do that. Uh but fully homomorphic encryption sort of grants you this access to at least uh the uh at least the multiplication and and and an addition. Uh whether that be with those two things,

uh you can abstract that into binary NAND gates as well as just regular addition and multiplication. So, you mentioned before that the work you're doing is all finite field, but as far as I know, like there's there's like you could be in a prime field or something and have different properties. I really don't know yeah, like enough about homomorphic encryption, but when you're talking elliptic curves, you have like finite groups, discrete groups, algebraic groups. You have all these different groups that you can work on, and um they have like the encryption actually has very different properties and performance. Uh sure. Yeah, so with FHE, it's it you can actually build specific

FHE schemes for a lot of these different for depending on what you may want to do. Um so, there's FHE for modular arithmetic. Um and more recently, there's FHE for approximate arithmetic, uh which has really great applications in machine learning. And then there's FHE for just binary operations. Uh so, it's I think I would say it's a bit like whereas you could construct elliptic curve operations to be for a specific field and for a certain very specific operations, uh FHE might be a little bit lower than that lower level than that, where you can actually construct very uh primitive operations to perform and carry out on different pieces of data, depending on what you what what depending on what you want to do. I see.

So, I have sort of a an application question here. When we've talked to groups that are working on STARKs or SNARKs, there's new like a lot of people are now using these for off-chain computation and scaling solutions. Do you think that the FHE work that you've done, could that ever be used for the same in the same way? That's something we're very interested in. Um I'm not really I'm not actually willing to uh elaborate exactly on what we're on what we're thinking about maybe applying that to. There is I would say that there's a high probability that the it will have some applications to some things here.

To the extent of change that it may have in the space, I'm not ready to put a to put an exact estimate on yet. Interesting. So, I guess that's like a sort of a vague, yeah, maybe it can be used in that way. Maybe. That's fine. Cool. Like I know said SNARKs are used for scaling in the sense that verification is, you know, exponentially faster than computing the thing itself. And you had mentioned that you guys have built in like there is a verification possibility in FHEs. Uh what does that verification look like, and like how how long is verification compared to

computation time? Um so, it actually depends a lot. Uh so, what I was saying more or less just meant that FHE implied the existence of zero knowledge, not necessarily that it can be used for zero knowledge, but it of course it can be also be used for zero knowledge. There are zero knowledge schemes using FHE. Um as far as I know, there isn't much um efficient verification for FHE out yet. Uh there is some new research coming out um that I'm really excited for, but it is a very fundamental problem with FHE in my opinion for trustless computations, where in verifiable computation, uh where you want to prove that this

computation was performed on this piece of data. How do you do that? Uh well, you need a zero knowledge proof for that, of course. Um so, there's work being done in that regard. I don't have any metrics for performance off hand. Um I would say it's slower than any zero knowledge system being used today, uh but I do expect it theoretically, it is faster. Um I do expect to see it get much faster with more research in the in the near future. So, I know you can't speak too much about what's coming up for the company or what have you, but maybe you can tell us what's exciting to you right now in terms of like the tech or what's coming up. It doesn't only have to be within the New Cipher space, but also kind of

in general. What are what are exciting topics coming up for you? Um something that I've been thinking about a and I'll speak for myself and not for Bogdan. Uh, but something that that I that I'm really passionate about is privacy. Um, the ability to own and control our personal data and give consent to its use. Uh, this is a term I've I've kind of been being I've seen get thrown around. Um, and it's the idea of digital consent. Uh, this idea that we have consent with our data and who uses our data. Just like you'd have consent in normal everyday IRL uh, social situations. You give

consent for various things. And the fact that we have to argue for uh, consent in online uh, data and online act uh, social situations even is appalling to me. So, what I'm really excited about building technology like FHE that allows us to gain that allows us to reduce trust and allows us to actually give consent more appropriately to what can be done with our data and who has access to it and when they have access to it. So, NuCypher answers the digital consent problem uh, very strongly with proxy re-encryption and access control and FHE

answers it in a very different manner for computations. Um, so I'm very excited to see the applications for trustless computation, verifiable computation, as well as you know private uh, cryptocurrency as well and other applications like that. Um, so yeah, consent is the coolest thing about this in my opinion. And Bogdan, what about you? Uh, I just wanted to add first to what Tax has said. Uh, I'm not sure if you read it, but there are there is a recent science fiction book by Hannu Rajaniemi, the Quantum Thief series.

So, it describes, among other things, a society which actually does what all that Tax just proposed. They have the system called Gevurah, which means boundary in Hebrew. And uh, all everything that every person there does is recorded in their um, external memory. And is signed by your with your private key. And you can share whatever you want. You can make yourself visible or or invisible to other people. You can, for example, require that your conversation is forgotten after 5 minutes. And, you know, all this all this kind of stuff. So, this is like the end point of what Tax is talking about.

This is in fact, when I heard about NuCypher and proxy re-encryption, I thought, that is it. That's that's how they do it. With proxy re-encryption. Cool. Well, and um, as for me, I'm not really I don't I still don't know much about um, cryptography world. So, I'm mostly excited about uh, more programming style things. Like metaprogramming, that's that's what I'm that's what I'm interested in. Uh, the way to write a GPU code easily because now it's kind of a very uh, slow and painstaking process, hard to debug, hard to reason about. And you know, all those transformations,

uh, metaprogramming can help with that. But I can't really say much about, you know, cryptography. Uh, that's something we haven't really touched on, but a lot of the code, I don't know exactly what or what isn't open source, but I do know that you have a lot of open source code. Can you speak more about like what is open sourced and and like how you think about that and maybe also where to find some of that? Uh, we have a GitHub profile called NuCypher and we have a lot of stuff in there including NuCypher itself, the Umbral proxy re-encryption system, new FHE, and supporting libraries. So, it's all accessible. You can you can file an issue.

Uh, I can't speak for everyone, but I will I will try to answer pretty quickly. And we also have a Discord server which you can join and ask questions there if you want to because uh, someone is always always online there. So, when you're saying like, yeah, I can't really talk about that, it's not necessarily, you know, the code or that it's that it's closed source code or anything, but maybe future plans. Uh, well, we have some closed source code which may become open source in future. Yeah. Which we're working on now. Yeah, as far as like we do have some closed source code as research projects.

Um, and most of the time I actually I think I made our spun it code base private. Um, and I'm perfectly willing to actually distribute source code for that. The the problem that what we really what I feel as as a cryptography engineer is the moment you build cryptography, somebody's going to use it. Um, and whether you whether it's ready for it or not and that terrifies me uh, because a lot of the stuff we build is just research and we don't it's not meant to be secure. It's not meant to we don't even understand the security properties of it until we implement it and see if it's secure or not. Uh, so when we talk about actually implementing some schemes or or something like that

we have to understand it before we release it to the public. It's like a sort of like a a a public duty to be like, before we make this available for you to look at and use, we want to make sure you can't shoot yourself with it on accident. Um, I've like I made this library called Hazmat Math, which was to be used for cryptography.io so that you could actually perform like scalar or like elliptic curve arithmetic using that library which they didn't expose probably on purpose. And so, I just built an API around that. It was like, I need this to prototype Umbral when we were first building it. And uh, when I did that, a bunch of people contacted me like, hey, we're using this

now. And I'm like, oh, wow. All right. That's cool on that one. And uh, yeah. So, there's there's a lot of problems with open sourcing cryptography. Um, not that it's bad to open source cryptography. It should always be open source. Uh, but what it should not be open source until you're ready and you're willing to take responsibility for it. And for so for a lot of our closed source stuff, I I think we're mostly just like, uh, we're not ready to take responsibility for this yet in the public domain. That's a very interesting angle on it. I hadn't heard that before, but it actually makes a lot of sense.

Yeah it's cryptography is a difficult thing to code for. People will use it if they'll cuz they'll just be like, I want an FHE library, for example. And then not only want an FHE library, they want the fastest FHE library that may have some weird property that other schemes don't have. And so, they may find a security they may find an implementation of FHE that has this property, but oh, it's not secure. And they're not reading the fine print that it's not secure. Like the the the typical like super bold uh, huge headline in the read me of this is experimental, please don't use this does not work. People use it anyway, for sure.

Yeah exactly. And especially like in a like maybe it's not so bad right now, but especially in a hype market like if you know, there's someone that's going to try to build a blockchain and launch a token around it. It doesn't matter if it says don't use this. Yeah, as for my feelings on open source tech, I'm a hardcore GPL person. I I mean, I I go as far as to be like, I'm a software communist. I I think all software should be free um, to the extent that it can. Uh, I think everything should be GPL as as far as we can make it that way.

Uh, not only I've actually published a blog post on this uh, that was actually kind of controversial in my in our own company because people in the company don't have in NuCypher don't have the same views as I do on open source tech. Uh, whereas I'm very radical in that where I where I think it should all be open source. Uh, but essentially I just think that in the space that we are in in the blockchain community, uh, we have the ability to start a movement and to build something amazing that we haven't been able to build before. Uh, imagine if if we could build an entire new technology stack around open source ideals and and free software ideals, right? Um, and I really don't want people like Google or Amazon or

Microsoft or other people like that to come in and and take what we are working on. We, the the community, not just NuCypher, but but what Parity is working on, what Web3 Foundation is working on, what NuCypher is working on, what uh, Zcash is working on. I don't want those people to be able to just come in and go, oh, cool. Thanks for doing the research. We figured out a new application of this and we're going to develop it all in our way and maybe advance technology and make some research in in this direction. And next thing you know, now it's all that kind of closed sourced thing and it's also licensed in this weird way, but it has awesome work on it. So, everybody has to use it now. Everybody has buyer lock-in.

I think for the first time, we now just have this ability to be able to say, hey, if you're not willing to participate in the community and if you're not willing to contribute open development, if you're not willing to say we don't need to take a profit on this, we just want to be able to build trustless computations for privacy uh, and and and governance, then just stay out. If you're not willing to to give up trust, just stay out. Well, on that note. [Laughter] That very radical note.

Thank you guys so much for coming on the show. Yeah, thanks for having us. Thank you very much. Yeah, nice talking to you. Nice talking to you guys, too. And uh to our listeners, thanks for listening. Thanks for listening. [Music]