Why Privacy Tools Keep Failing (and How to Fix Them) - Nanak Nihal Khalsa / Co founder human.tech

[Music] Hi, I'm Nanak Nahal. I'm one of the co-founders of human tech and Holland Foundation. So, we build cryptography for digital human rights such as privacy, security, personhood, access to finance. How I got into this space was my co-founder and I were originally building tools that were not private at all. We were building identity for uh for scientists on the blockchain and we started to get really worried right before our product launch that we were just letting people put this information on a public ledger because blockchains are all public for the most part.

Most blockchains have no privacy. So we were super concerned at what we were about to launch the world and we decided let's let's delay this. Let's study privacy enhancing technologies and then build a better version. And so then we got really deep into privacy. It was really fun learning about these tools.

If you're a math nerd or always wanted to learn math uh like me but never did, uh learning cryptography is a great way to to dive into that and really really fun challenge to actually build really meaningful tools. I think there's so much to be built with cryptography to enhance privacy that hasn't been explored just because the sheer complexity of it. Um, but these tools are getting easier and easier to use and it's becoming more accessible. So now is a really great time to be building privacy preserving applications. And so we got really interested in this, started building more products.

And I'm here today to share some tips and stories uh obstacles to avoid um help to find a direction and like how to actually get started. And I think the first most important step is decide which tool you want to use. So you know there'll always be a hot new word like right now I think FHE is a little hotter than ZK. MPC is not too hot but really you know these things change all the time. So I would look at the different tools and find whichever is best for your particular use case.

So ZK for example if you're in a situation where you want privacy on you know the user can see their data but you don't want any server to see the data um and you don't want anybody to have to be online all the time then Zika is really great um so ZK lets you prove any statement about any private data you know so it's really great for identity you have an identity you want to prove that you are over 21 in order to get into a bar you want to prove you're from certain list of countries for compliance. This is something ZK is very well suited for. Um, now if you want to do something more collaborative like let's say you want to jointly train a machine learning model with other folks, you want to use MPC perhaps or FHE. So MPC the the main downside uh is it requires livveness of every party. NPC is multi-party computation.

Um so multi-party computation you're going to do computation together with one or more parties. Um a really great subset of this worth exploring as well is uh two-party computation uh because that has a really cool trust model. You can have a computation share between a user and a server. Um and that way you're not like trusting some some network to have all the data. The user always has a share.

So so two-party competition is great. also uh two PC MPC uh which is like the user and a network together make a computation. Um so yeah this is very good for for situations where for example you want to share this computation and you're okay with other parties having to be live for the computation to happen. So user has to be live the parties have to be live. Um, now if you don't want the user to have to be involved in the computation, let's say it's a really expensive computation, you don't want to run it on the user device, but you want whoever is doing the computation to not have access to the user data, that's where FHE, fully homorphic encryption is really helpful.

Um, so this is really useful for uh some machine learning applications as well. user has an input you want to do some machine learning computation but the user doing it in ZK is just too expensive on the device FH is going to be slower more expensive but you can run it on a very very big server uh because the server doesn't have to see the user data um whereas in ZK whoever is doing the computation has to see the data so whichever one you choose um you know just depends on on your use case and it's going to be a very different paradigm in programming so we're used to programming uh like programs These will run. You have instructions and the CPU will just like jump to certain instructions. Um, you know, they're all compiled down to assembly and then binary and there's RAM. You know, we're used to this sort of model and a lot of the concepts we have intuitively when we write code don't apply because this model doesn't apply.

So like if statements and for loops and wall loops, um, these will be different when you're working with privacy enhancing technologies for the most part. um unless you're using um enclave which is one thing I didn't mention TEES. So TEES are less of a cryptographic innovation more of a hardware innovation. Um and TEES are very um you know they're more accessible to the standard paradigm of programming. Um there are some issues in that TEES are often compromised.

um they're not secured by math in the same way that cryptography is and so tees get exploited very very frequently. So it's important to be careful if you're using tees. Um I think tees can be a bit easier to develop. Um but to do tees correctly you have to be aware of stuff like uh replay attacks um side channel attacks. I'd say these are the two main um issues.

Replay attacks and side channel attacks. Um so replay attacks for example let's say you're you're building uh t so tees you know they they will take a computation and run it in a private environment um so Amazon Google Microsoft all support in their cloud services so AWS Google cloud Azure they all have private computation using tees and I actually think these are are pretty good because they're not even though they're like decentralized companies they're not exploited um because they have both, you know, really um really strong hardware and trust assumptions uh so that even employees at these organizations will have a very hard time accessing it and there's never been any inach of these TE. So I actually uh counterintuitively do recommend if you're doing TES to do it in a cloud provider like AWS, Azure or Google Cloud. Um and

yeah be careful of u you know if you do it this way you don't have to be careful of side channel attacks because side channel attacks what hap what happens here is that sure this computation is private but let's say you're working with a private key in the TE only the G knows this key so it's safe the rest of the device can't see it the cloud provider can't see it you can't see it as a developer um but then there's a question of um maybe there's a computation that takes slightly longer if one bit in your private key is different. So you can measure the time that this computation takes. Um you can even measure like the electricity usage um of the machine if you have access to the machine but in this case you don't um because it's on a cloud provider and and you can extract information about the private key. Um you can do like one bit at a time and after enough computations you can eventually extract private keys. You can extract secrets.

Um, sometimes people use rather than timing, they use like a cache access patterns uh to extract this data. And you know, again, this stuff will only be possible if you're like self-hosting the TE or or some untrusted party is hosting a TE. But if it's in a cloud provider, then it's generally better, which I hate to say. Um, but uh, you know, I think this is the way to do TE's. But you still have to be aware of stuff like replay attacks.

Replay attacks are where say you're building private voting application and it only reveals the vote. So the TE runs this computation, it tallies the votes, gives you the output. Um but even though TE is isolated, the input to it is not. You're getting the voting inputs from outside. So someone outside can say okay let me try to give the votes in a different order.

I'll remove this vote. See how that changes the output. Um then I'll remove this vote. And then by removing the votes in particular patterns you can see what the actual votes were um or at least like you know um you can extract a lot of information about the votes because you've just restarted the enclave run the vote again u and the enclave doesn't know votes are missing. So enclaves also have no persistent storage.

Um so this is another challenge like you can't have you can't easily have a key that only the enclave knows. There is a technique called key sealing um that makes it a more possible to do this um but still you have to um worry about persistence of information. So with all this in mind, whichever model you choose, whether it's ZK is um FHE or MPC,

yeah,

there are going to be different paradigms in in programming, especially for ZK MPC and FHE. Um you'll have the circuit paradigm. So instead of working in CPU and RAM and the standard things like if statements, for loops, you're actually going to have this predefined circuit. Um, so we're not talking about programs necessarily. We're talking about circuits where you have to have input that satisfies this circuit.

You can think of the circuit a little like a program, but it's not dynamic. Like you're not going to be able to to jump to different instructions. You're not going to be able to do if statements. You're not going to be able to uh have a for loop stop on certain conditions. Um, you're going to have to if you do a for loop, you're going to have to have every single possible um iteration of the for loop.

And if if you stop um somewhere by conditional, the circuit's still going to be as long as long as possible for a loop.

Um because you have to have every step um defined in the circuit beforehand. Um and then there's also this paradigm of public inputs and private inputs like which inputs can be public, which inputs can be private. These are important to specify because you often want some data public um but you obviously want some data private because we're working with privacy. So for example, maybe you want it to be public like um which government signed your ID. If you're working on a government ID verification program, you need to make public okay this is a US um government ID and my age is over 18.

So that's a public output. Um but you want to keep the rest private. So you have to define public and private inputs. Now there are lots of programming languages that have made it easier to build circuits. So for ZK you have like noir, kilong, circom um and you have um uh stuff like uh why am I forgetting the name?

Uh Halo 2, you know. So you have all sorts of ways of building circuits and some are easier than others. Like noir, for example, is doing a really good job actually at being both easy and starting to become pretty performant. There's often going to be a trade-off between ease of use and performance. Um, so you might get the best performance working with circom and using a custom backend or maybe like even working some new framework uh hand coding your circuits.

Um and you know with with circuit programming there are also lots of um you know it is a relatively new space. So don't expect your circuits to be um perfectly bug free. If you're using ZK for a very security sensitive application definitely have some backup mechanisms like maybe do ZK plus an enclave or something uh if you're for example handling funds uh based on a circuit because circuits do get compromised um and they're very expensive to audit. One important thing to look at is scalability because you'll be surprised how soon once your application takes off that the scalability concerns in the beginning um that you may have overlooked or maybe not realized actually become a problem. So we never realized that using a Merkel tree for example would lead to scalability issues.

So Merkel trees are a common paradigm in ZK identity. Uh, Merkel trees are essentially um, you can think of it as a way of compressing a set of values. Um, it's called an accumulator. Um, so essentially you have the set of identities and you prove that you're one of the identities in a set without revealing who you are. And so Merkel trees are really great way of doing this really fun concept.

Definitely recommend looking into it if you're building a ZK identity, but be very careful about using them. Uh because once you have enough users, for example, once we got to about 20,000 users, downloading the Merkel tree and reconstructing it um using these expensive cryptographic hashes that are ZK friendly uh was taking users like 20 minutes um especially in countries like Africa where the devices were not very powerful. So um so yeah, scalability is definitely something to look out for. Um, another important concern to look out for is is nullifiers. So, nullifiers are what we use.

If you're not familiar with nullifiers, nullifiers are used to prevent somebody from doing an action twice in a private way. So, the term started with tornado cash where tornado cash would um they'd have these notes. So, you deposit money and you get this note. This note says, you know, I've deposited this money and there's a certain key linked with it. And this key is used as a nullifier.

Um, so nullifiers prevent you from doing the action twice. So then when you withdraw it, you actually spend this note by by revealing the hash of your nullifier. Uh, so you're you're saying, okay, I can never use this nullifier again because it'll hash the same value. Um, and I'm revealing the hash of the nullifier. Um, so that way I can never spend this note again.

that prevents you from withdrawing infinite money. You deposit money, you have to make sure it can only be withdrawn once. Um, and with identity, for example, in voting, you want to make sure you can't vote more than once. And if you want to do proof of personhood, prove somebody's like unique person, you want to make sure they can't prove more than once. Even if you want to prove you're over 18 or from a certain country, you want to make sure somebody can't prove this multiple times.

Um, you know, or like do the proof, send it to their friend, the friend does a proof who's not in the US or not over 18. like you have to make sure like one identity leads to one proof otherwise people will abuse the system and let other people who don't do not have valid identities make other valid proofs. So nullifiers end up being really important but for identity it's actually very tricky to make good nullifiers because you want to have something that um you know you have to make sure that one identity only leads to one nullifier. So the most straightforward way of doing this is using a centralized database saying and this is where privacy starts leaking. Um and and actually there's no perfect solution to this.

Um we're working on a solution that can solve it in many use cases which is oblivious to random function. You can check out human network for that network.hum.te. Um and this this could help making more private nullifiers um depending on your use cases.

So nullifiers if you're working with identity you want to make sure that a person um yeah like cannot make multiple nullifiers uh with their ID. So most straightforward way centralized database you store who has verified their identity before and you make sure that they can only choose one nullifier. If they try it again you're like oh I see in my database this person has done it before I won't give them a nullifier again. Um, but then there's a privacy leakage here because you know which IDs have verified. And sometimes this is okay.

Um, because it's only revealing who has verified and that might be okay for your level of privacy. Um, I think in most cases this is fine, but sometimes you want to make sure nobody even knows who has registered. Um, so you might think, oh, we can store a hash of the user's nullifier um, sorry, of the user's identity instead of storing the actual thing. Well, hashing identity isn't very secure because you can always reverse it. Um, there are not that many identities you can probably brute force very very quickly the different names, addresses, phone numbers, whatever that lead to this um, this hash.

So, yeah. So, with the oblivious pseudo random function, you can hash in a more secure way where it can't be reversed. And this uses a key of either a decentralized network or a third party that never sees a user's data but can help the user generate a deterministic key uh based on their identity data. So this is worth looking into um as well and uh in case it's helpful we have human network to help with that. So for building private tools in a hackathon I would look at existing frameworks that make it really easy to build private apps.

um you know for a hackathon it's gonna be it's gonna be really hard in a short time period to build you know fully featured extremely private performant app that scales but you can start with a prototype and even start with less privacy but just look at the text and say hey I'm going to build this um you know and make sure tech actually works for what you're going to do um and you can use it to validate the product idea um and then go very deep into the the privacy to see later, make sure it's scalable. Um, and you can also use their frameworks that make it a lot easier to build private apps. Like for example, I think uh Noir is not like a huge learning curve. Um, also you could, one thing that might be helpful is doing a lot of research before the hackathon. Um, maybe you just want to start the research at the hackathon, that's cool, too.

Um, but if you do a lot of research before, you'll be ready to build. Um there's a lot of a lot of planning that goes into a private app because it's not easy to build this stuff. Even if certain programming languages make it easier, um you still have to think in a different way when you write the code. So the more research you can do beforehand um on the text stack you might want to use and how to build with that tech stack, you know, whether it's TE, ZK, MPC, FHE, um you know, the better.

We have this myth right now That's it's it's three-pronged. One, uh, companies always want to take user data. They never care about privacy. Users um are fighting this. They don't, you know, they they don't like that.

They really want privacy. And three, you know, those are three things. Like one, companies don't, you know, don't want privacy. Two, users do. And three, it's really hard to fix this because the incentives are so strong for collecting user data.

Um, I actually think all three of these are somewhat false. There's there's definitely truth to all of them, but I think one, companies are more willing to adopt privacy than we think. Two, users are less motivated, but still motivated um to to act on behalf of their privacy than we think. And three, there's more hope than we might imagine for a more private future.

So let's start with companies, you know, why why companies actually do care about privacy sometimes. So certainly advertising data and some other types of data are very profitable to collect. Um and a lot of companies have this as a primary business model. A lot of big companies, but also there are lots of types of data that companies don't want to collect. And you actually see uh big companies such as Google, you know, Google just releases ZK identity system that they put a lot of work into.

Uh Apple has been doing a lot for privacy as well and Meta has intended encryption in WhatsApp. Now there are lots of improvements they can make into encryption to make it more private. Um there's like you know and obviously these companies are some of the biggest offenders of privacy as well. Uh but it shows that there are cases where companies do care about privacy. So looking into their motives for doing that might be a good way of of finding new avenues to make privacy more popular cuz if these giants see money in privacy like hey maybe there's actually something that can scale uh in building private tools and the other is that there are other types of data that are not an asset to hold or actually a liability.

So for example social security numbers I don't think anybody wants to hold social security numbers. you're not going to use them for advertising. Um, but they add a huge risk. You could have a data breach. It's going to look really bad for your company and it also costs a lot in terms of compliance and cyber security to to hold this data.

So these types of data, you know, this is something where ZK, FAH, all these privacy enhancing technologies can really help companies save money and help users uh, you know, have their data at a significantly less risk of data breaches. So I think there are some good avenues to increase privacy here. Um and other somewhat sad thing is you know people think users are very motivated to uh preserve their privacy and users do have motivation for that but the amount is surprisingly small like in our experience we have two private options of verifying government ID. One is a lot more private than the other and people choose a less private one because easier to do. Um it's actually more expensive.

Um, so there are two options are NFC enabled passport. So passports is actually um, you know, if you're looking for hackathon ideas, there are already projects doing this, but there could be some new interesting takes um, on on what to do with this because there are these passports that 170 countries support with signed data from the government. Um, and these, you know, you can you can do completely private ZK proof of this. So you tap it to your phone, the phone can read it via NFC and then the phone can do a private computation saying, you know, I am over 18 and doing a ZK proof of that or I'm from a certain list of countries. So we support this option.

Um, and that's completely free because there's no third party involved. You just need to tap on your phone. Now for people who don't have these passports or don't want to download a mobile app because sadly web browsers don't yet support web NFC um to the extent it's necessary to read these. So you have to download a mobile app. the UX is worse.

Um

so for for other folks we also offer the option to just verify in your web browser scan your ID with the third party you know a standard like web two uh ID verification service do the selfie check and um this is yeah it's easier to do because don't need to download an app but also we have to pay the third party so we have to charge for this and people will still do it right because they download the app. So, it's really important to make sure this balance of cost and benefit is aligned for the user um because users do care like once webin is uh supported. You know, I think this will be a big unlock cuz the UX will be on par. I'm sure users will choose the private version um any day. You know, if you could if you could use social media without all the advertising, without all your data being like shared with all these people, you would definitely do it.

Um but just not an option. So making an option lowering the cost of privacy to the user in terms of friction, money, time. This is a really good way of um of helping users prioritize their privacy because they do care but the cost and benefit is just not aligned for them to actually act on it. So for learning ZK uh in particular, especially want to get into the math of it, I highly recommend I mean Justin Thaylor's book is very comprehensive. Um and yeah, it's a great read um and great reference.

Vitalik's blog posts are also quite good. He has a knack for explaining these things in an intuitive way. I also really like Dan Bonet's ZK whiteboard lectures. Um, I think these are rel none of this stuff is super accessible as far as the math, but I think they're relatively accessible um as a way of learning some of the math behind um ZK programming.

Any course in cryptography actually is is really helpful um even before diving into a specific technology whether it's like MPC, FHE, ZK, TES, just learning the cryptography basics. So starting with divy helman RSA elliptic curves um and there are lots of resources online that have been published over the past uh decades about these fundamentals and then once you get a good grasp of elliptic curves stiffy helman RSA um some of these signature algorithms like you know EDSA ECDSA um threshold cryptography I think these are good starting points And then these more complex technologies like ZK, MPC, FHE will make a lot more sense. Um, as you learn these things, there will often be math concepts that you might not have learned like maybe finite fields, abstract algebra. Um, and then, you know, you can quickly learn those on the way. So, I think definitely starting with um an objective um of learning, you know, one concept and then when there's a subconcept you don't know, looking into that.

um you know it might take a few months to get all the prerequisites but I think it's it's really helpful to to learn these these building blocks um and then everything will go a lot smoother. You don't necessarily have to learn that in that order. Like you could start with a advanced concept and then once there's a subconcept that is u unfamiliar then you can dive into that you know take a break from the the more complex thing dive into the building block and then once you learn that go back. Um I think that's also a valid strategy. That's generally how I like to learn these things.

Um, but yeah, there there's a lot out there and and don't get overwhelmed. Like the math seems really complicated, but really the complexity is more in the number of concepts you have to learn rather than the difficulty of the concepts. Um, so you can learn the math. Um, you'll just have to dedicate some time to it. Yeah, I think you know now is a great time to be building privacy because there really are starting to be good incentives for companies and maybe even users to value privacy and the technology is getting to the state where we have all these tools like TLS.

We use it all the time. Whenever your browser says HTTPS, you're using TLS for privacy. It's the most ubiquitous privacy tool and it's done so much good. like we could be sharing our credit card information in plain text. People would be reading all our emails if it weren't for these basic cryptography primitives like encryption, um, defy helmet, etc.

And and these were invented a really long time ago. Um, but it just took the right moment for them to actually get adopted and become practical for use. It took some legal battles as well for encryption. You know, encryption was almost illegal in the US. Um, but luckily it's not.

And you know we see this with current privacies tools now. History is repeating itself. Um there are legal battles about should privacy be legal with newer tools especially in finance. And you know obviously I think that privacy being legal is very very important. Um, and sometimes though it's it's important to to convince people this to show them, hey, look, we used to think that email uh encrypted email was a bad idea or, you know, encrypted websites, but now it's saving, you know, it's preventing people from sniffing our credit card data.

It's preventing people from snooping on our emails. And uh you know it would be ridiculous to say that encrypted emails are enabling you know like terrorist activities or or anything like that like encrypted email is obviously a good thing but back then it didn't seem like it right. So it's like that now and we just have to keep fighting the good fight and eventually I think people realize that privacy is super important and a net benefit to society and you know we just have to keep building and we have to keep uh being activists for privacy. [Music]