Recently, at PSE, we have been exploring the field of cryptography, specifically focusing on Fully Homomorphic Encryption (FHE). FHE enables secure interactions with encrypted data between different parties.

In this presentation, we will introduce key concepts and essential information tailored for developers and application designers. This will help them quickly grasp the fundamentals without getting bogged down by complex mathematical details.

Stage 6

Building programmable cryptography in Privacy and Scaling Explorations.

Chih-Cheng Liang

Little Things We've learned About FHE

 Thank you, Teresa. Hi, welcome here. So, I'm C.C. Liang from PSE. We're talking about FHE today. So, here's my selected resume to fit my narrative. First, like in August and July this years, I've been working on ZK-EBM projects with Kimi there and a bunch of many people. And more before that, I was working on different various applications in PSE. So I think in summary, what I have seen is a rise of computational primitives on cryptography. So what does that mean? Like we discovered a bunch of computation legos. This legos starts with gates like this. You can add numbers together or you can multiply numbers together and we call these gates arithmetic gates and if you're coming for a programming world you're probably seeing this N gates or gates XOR gates and not gates and you can fit bits inside it and do operation with it. These are called Boolean gates. So these are kind of abstract models. Once you get this, you get the whole computation you need. You can serve user with different kind of application logic. How does that go? So first you have gates and then if you combine these gates together you get circuits and then if you build language and compilers on top of them and you feed developers some coffees and teas and they'll build amazing applications and to happy users. So I think that's what happened in the ZK past. In a ZK we kind of have some arithmetic gates that allows you to perform computations on secret values and now FHE we are getting new sets of Legos and they unlocked new sets of capabilities and this is what we'll dive into today so before that let's do some recap on ZK calculation So when we talk about computations, we usually start with calculations, and then we build more abstractions, and then we can do computations on actual application logic. like a Sudoku board. They have some pre-filled values 7 and 3. You can fill in some initial value 5 and then you multiply together you get 35. You plus 3 you get 38. You can witness some private value 2 and then you get a result 40. And then you can send input and output to the verifier without sending all the computation trace in the middle. And in this way, you get privacy for your private value. You also get the computation compression for people call this the sickness. And if we accept some more abstractions we wrap developers are very good at turning your application needs into the computational bits and bytes so we can do some high-level logic like this. For example, you have ID 123 that resides in the ID registry. So this computation result tells us this is a valid ID. As this doc, you can insert some secret video in this secret field of ID. This ID has some certain attributes. And then the whole thing is combined together. This shows you know the secret. So you are the owner. This dog is the owner of ID 123. And then furthermore, this ID 123 has an age field, say it's 19. So this dog is 19 years old. But the dog wants to tell people it's 19 years old. The dog wants to tell it's greater than 18 years old with just one additional computation step. So that works well if your user is just one dog. But now, like, if you want to build applications that interact with multiple users, like this dog and cat, and they want to decide what to have for dinner, either khao-soi or pad thai. But their opinions are very sensitive, so secret they need some cryptography that can protect you from state-acted attackers. So they kind of... Let's imagine we don't have any cryptography and we host this computation and trusted third party like the Horse below and then the dog sends their vote one and the preference for pot I 0 and the cat sends the And the cat sends the vote one, and the vote for Pad Thai. Then we perform some computations. We want to add the votes together and to get the final preference for the dinner. But then, you see, this requires the interaction of the dog's secret and the cat's secret, and then it's not achievable by the ZK gate. So that's where FHE comes to help. So FHE stands for, it's short for three words, but I'm not going to torture you with that nerdy details. I'm going to redefine FHE as just one word, and it's a computation over encrypted data. As people say, the ticker is FHE. So what does it mean, like, computation over encrypted data? So you basically get these two new Legos, and then you can have encrypted data from Player 1, encrypted data from Player 2, and then you add them together, you get a computation result. And so when I heard, like, the encrypted computation over encrypted data first time I didn't realize how powerful it is or like a significant it is but it if you see here it kind of builds a boundaries between two players and then you that there are secrets to interact with each other, and you get a computation result. So now, like with FHE, you can do the dinner voting properly. So the dog sends the encrypted preference, cat sends their encrypted preference, and then you use the new FH gate and to add them together to get an encrypted computation result. And then you have to decrypt it to get the actual result. So I think Vitalik has a saying, like, all the technology we have is kind of a simulated, trusted third party. And I think, like think from this example, we're kind of seeing this phenomena. This horse on the bottom is kind of like a trusted third party. And when we're using FHE and without it, the application logic looks similar, but it's kind of wrapping on another layer of security. And from the perspective of user, all they see is the same. They input some value on their browser, and then they got some values from their browser, but there are differences behind the scenes, and there are different security and trust assumptions behind the scenes. So why are we not already using FHE now? We kind of already, like, so in the basement, you have FrogZone from 0xPark I highly recommend you to play it but there are three main problems of FHE right now first is the computation is costly let's say you want to send one bit of plain text from the stock to the server you have to encrypt it and in this encrypted message is a data itself so it has some size and how big is this data so this data takes six bytes is kind's kind of amortized, and it's kind of 100 times of the plain text. And it grows linearly. It means if you have 100 bits, you multiply 16 bytes by 100. This is already very good. But the terrible part is the computation part. You need a server of 192 vCPU. It burns 10 USD per hour. So I highly recommend you to play the frog games in the basement to feel that $10 per hour feeling. So the second problem is the verifiability. So you are getting this computation result, but is this computation result coming from the correct computation step or the incorrect computation step or the incorrect computation step. To be honest, like, you cannot really tell. Like, it needs extra work. You either wrap another zkProof on top of it, you either do some, like, message check or something to either guarantee kind of integrity. It's a problem people are actively solving, but it's still a problem. So the problem number three is the decryption problem. So after all the computations, we're getting the encrypted computation output. But how do you decrypt this? How do you remove that elephant from the fridge? So you need someone to decrypt the message, but you can give the decryption key to a centralized this is like you're not doing FHE at all. But the concern is like if you, like if someone has the ability to decrypt the output, can they also decrypt other users' input? And this, you know, this makes the whole like FHE a security theater. So the other way to solve this is you use some threshold decryption scheme. the whole FHES security theater. So the other way to solve this is you use some threshold decryption scheme. So every encrypted output, you need all the party to derive a decryption key share. And together, they have to collect all the decryption key together to actually see the output so if the dog did not give its decryption key to their input the other people were not able to decrypt the dog's input but the problem here is the cat if the cat ghosted, then nobody can actually decrypt this output. And then this secret will be secret forever. So let's give a quick recap. The message is simple. In ZK, we kind of have computations on top of your own secret. And for FHE, we can engage with other secrets. So you can build applications for multiple peoples. And that opens a lot of doors to many new applications. So I expect you will hear the word FHE in the near years. There will be more talks in the next DEF CON. This is a kind of trending topic. And lastly, I want to direct you to play the Frog Crypto on the basement to feel like how early days of FHE feel like. Also, if you are coming from a developer background, here are some reports you should check. The first two are from Gauss Lab. It's a library for multi-party FHE. Pay attention to the branch because the latest code is living on some branch. And if you want to deploy your frag zone yourself, check the last link. You can deploy a frag zone. And it's early days. Things break. So expect some hiccup from the code. And that's all I have for you. Thank you so much. Alright, thank you, CC. We actually have a lot of time for QA, so feel free to submit questions. Let's go from the first one on the screen. What are the best use cases you've seen for FHE so far? That's a very good question. So for me personally, like definitely not for others, like I'm more from like economic background, and I'm very interested in like auctions and votings. These are very, FFG applications. They are very ancient. But I feel like if we can do proper voting and proper auctions, that would be cool. I think what makes people exciting in the future is if you can build some private state, you can build a, let's say, P2P network. You have a private state, and then you have some state transition function. You can continuously update the states, and then you can build a kind of private blockchain and private application to many, but I cannot say anything concrete at this moment because I don't know. And we have another one. Which optimizations do you see possible to solve performance issue oh so so this is what I heard from our colleagues PA he said like the last so the latest performance update was already in 2016, and there hasn't been new papers for that performance improvement. So we might be looking for a new generation of bootstrapping technique to improve their performance. When should you use ZK, FHE, or MPC? So my over-simplistic understanding of this is if your application involves just one party, then use DK. If you have two parties, use MPC. If you have more than for QA. What do you think of TEs as a solutions for shared state, shared private state computation as a performance solution over FHE? Good question. I don't know yet. I haven't dive into this topic, and so I haven't developed opinions on this. All right, perfect. OK. All right, let's give it another 10, 15 seconds to see if there are any more. Maybe a question for you, like who here have heard FHE before? Oh, okay, almost everyone. Okay. Who here have heard indistinguishable obfuscation before. OK. Oh. Nice. All right, cool. Thank you, CC, for your amazing talk. Our next talk will be in 10 minutes.

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6735c37a9dbb7a90e1fa8ae4.vtt