zkemail: Decentralized ID Verification on Chain Without Servers

foreign [Music] because the Wi-Fi here is not fast enough so we're running this remotely and so we're going to begin that right now yeah so we have a UI build up it's pretty primitive but the idea is that it we know ZK is not efficient now so it's going to take a couple of minutes to run this proof so hopefully it works I don't know if this internet is gonna oh it did click nice so we're gonna let this proof run and then we'll come back to it at some point later and see if it's generated I'm gonna explain everything that we just did uh but yeah I'm some pretty I've been hacking with elix park for the couple last couple of months on your knowledge proofs I'm ayush I'm also hacked with Xerox park for a while and now I help run personally Labs uh yeah and I want to say like this project has a lot of people behind it like we've used a work from a lot of Open Source libraries a lot of people who've helped us and behind the scenes and these are some of the names who are also in the crowd but we can't mention all of them so thank you to everyone again So today we're going to talk about trustless email verification on chain is trust us in the sense that we don't run our own server so we don't see any of your private data but at the same time we are trusting because this is an interoper early protocol between web 2 and web3 we are trusting mail servers and DNS to be operating as they should but we do not operate any of our own infrastructure so what exactly is proof of email or a ZK email well every time you receive an email you have to know that it came from the source that it claims to be coming from and so one might imagine a great way to do this is signatures so what they effectively do is every email you receive is RSA signed with a shot 256 of the from address the two address the subject and a body hash along with uh and this entire hash is RSA signed with the key belonging to the email mail server domain so you can imagine that if a user provides this header or the signature of an email then and we verified in zero knowledge that no one including the mail server or a keystroke tracker on someone's computer can verify that someone is using this protocol there's some small email quirks not everything works like this Gmail doesn't sign self emails and didn't even do this until 2016. uh Hotmail doesn't include a two field um and mail servers have slightly different bit keys so the specific demo that we have prepared today is trustless Twitter verification on chain the way it works is you get a Twitter reset password a Twitter reset email into your email from twitter.com we then create a ZK proof of this email we effectively reveal only the sender domain which is uh something like verified twitter.com the RSA modulus which would be from the DNS record of Twitter and the masked email body which only has in zero knowledge the specific keys that we want to release so like in this case it would be for example it says this email was meant for use G right here so we could kind of use that to extract that part and like use that as like the username the things we want to keep private are all the information that does not relate to what the user wants to release that is specifically the entire Deacon signature would de-anonymize them because a mail server would know who they are the length of the pre-hatched message data or general lens that we pass around to ensure that computation is efficient and all of the raw data so the raw message data the raw slender data the identity is everyone involved in the circuit what we do is we check that that decant signature that we showed you earlier verifies the shaw hashes verify the RSA signature is verify and that all the text is well structured in the message and this requires a little bit of regex parsing finally in a smart contract we verify the things that are very either very expensive to do in a snark or have to be done on a decentralized layer so things like verifying the sender domain is actually the center domain that people trust and verifying the claimed RSA key is an RSA key that people Trust um let me go see if the demo is done so it's still going on so I'll just like talk about some of the innovations that we did so obviously one of the things he noticed was regex and we also had to do a bunch of Shadow 56 inside the proof now since we want this to run in the browser like obviously uh we don't want people to have to send their email to a private server that we own and then we are on the proof so everything has to be done in the browser which means it has to be very efficient so we had to use some tricks to make sure like our proof runs within like a reasonable amount of time so one of the things was shout out 56 hashing so we have like this really long email body let's say like the one that Twitter sends us is like 16 kilobytes and if we try to just hash that entire thing in like inside a circuit then like it'll take like millions of constraints so what we realized was we could only take the part of the message body that contains the username we want uh which is for example the Twitter username which is at the end of the circuit and we can only do that part of the hash inside the circuit and we can hash the first like let's say 10 000 circuit in like and pass it as a private input now this doesn't really break any security guarantees since we still check we just checked that the the final hash is equal to whatever is like signed by the mail server and if you if you if you could break this then you would basically be calculating a pre-image for the hash so it's the same security properties but we don't have to do as many like computations the other one is obviously verifying regex so email headers and email protocol is like a very tricky thing um oh I didn't I didn't even see this so email is a very tricky thing where like it can be in many different orders and there's no specific structure so it's hard to verify that within the stock and like just using IF else checks and obviously the first thing that comes to mind is kind of like when you try to pass the email addresses to use the regex right so that's kind of the most simplest thing that would provide more security but there's no obvious way to do regex inside a snug in efficient way so the thing we used was there's a way to convert uh all regexes into deterministic finite automator so which is basically like a graph and it's kind of like automators graph and you Traverse the state so for example each each Edge has kind of like a letter with it so if the letter is H then you go from one to two and if there's an e after that and you go from two to three and obviously at any point if like a letter doesn't exist then you kind of fail and you just go back to the beginning so in this case if we get to the last state which is 12 then we accept um so it so this is obviously like a very simple regex for hello world but we can kind of build a more complicated regex which is for like checking your email header so for example checking that there's a two and a from and it uh is like valid according to the SMTP protocol um and we can kind of check that and make sure everything matches so and using this also we can kind of use rejects like uh what is it called catch groups or something like that to reveal what we want so in case we just want to reveal the domain which is in this case 0x but in in the demo we want to do we want to reveal the trader.com so we'll see how that happens so the regex for this thing is like a huge graph so obviously I'm not manually coding that in circum so we did some tricks to like automatically generate python circumcode uh given like a graph and you can see in that slide on the right side oh yeah auto-generated circom code um it works I don't know how it works but it works um all right let's go back to the demo hopefully it's done oh no I have to type my password on screen all right maybe we don't do this I I still have a like kind of like a video showing the same thing um because trust me is this this is exactly what happens so after we go through all of this okay I'll type my password if you guys don't believe it okay uh but maybe at the end so anyways as you can see the proof got generated at the end and this proof is obviously something you can send to the smart contract and it also gives some some extra data which is like the public data that we're talking about so I'll just let this play here uh so as you can see like we have all the extra data masked out and only the things we want to show so like for example twitter.

com to gmail.com and then if we go down to the end we have the username which is uh uses username from the circuit so uh those are the things that only the public input from the circuit and everything else remains private and since all of this was verified using a proof you can kind of uh if you submit this to a Smart contract you can verify that this was indeed actually something that happened so some precautions of this technology before we dive into specific use cases or that this enables a tragedy of the commons on institutional reputation now what this means is that using ZK email you can prove processly that you're part of some organization and post or act on behalf of the organization without spending your own personal reputation and as a result for the first time effectively ever you can spend institutional reputation and have no cost to yourself and no account personal accountability um is quite dangerous and so we do think it's important to have something like zika nullifiers or different mitigations to think about how to release this technology safely uh so that we don't enable this uh degenerate spiral one second uh thing to think about is deniability it can be argued that you want to be able to argue at some point in time that you you can deny that you sent an email and so the way that a lot of mail servers do this is every year or six months they'll rotate their mail server keys and release their past keys and some of them will even release the past secret Keys meaning that if you get an email more than a year old that someone could have easily forged it using that secret key that was released and so this poses problems both for the scheme but also is a good question of do we want to enable and encourage this or do we think that this is something that we should hold people accountable to for a long period of time and finally one interesting thing is that if we want a nullifier that is something that would avoid people from claiming again and again and again their identity on chain or possibly selling this identity even then we have to allow another fire which is derived from the information in the email but this would allow the sending mail server to de-anonymize someone and so there's a trade-off here where you can either have uniqueness and anonymity or you can have the mail server able to de-anonymize the people who are interacting with the protocol so I'm going to talk about a couple of different applications you can build that require no server you can build something like proof of personhood and one way you could do this is you can verify in zero knowledge that someone received an email from a kyc provider that checked their kyc but you don't reveal any of the information about their personal information or the kyc information and thus you can prove that someone with an individual human would not reveal who they are you can do something like have Edris Snowden release the NSA emails on chain and prove that they came from the NSA but not that he was Edward Snowden you can do something like proof of company where you prove that you work at a certain company or a certain domain and you mask out all the rest of the information enabling something like ZK Glassdoor ZK blind you can do oracles if oracles send emails to you with information say price feeds or any other information that you want on chain you can simply verify these email headers on chain and not have any centralized server that you trust or decentralized networker verifies that you have to trust to accurately represent this data I can keep going on and on but you can imagine that any data that you can have in an email you can verify on chain using this primitive this is extremely powerful for decentralized and Anonymous applications I mean things are going to enable a whole new era uh of ideas for residents you can do by proving for instance you have a gas bill or a water bill um The oracle's Glassdoor and uh the number of anonymous groups you can create is also quite unlimited you can prove for instance groups of people who have 10 million Twitter followers or people you can prove that you made some call option on Robinhood that went really well or you can prove that you're you have some dollar bill bank account uh dollar bills in your Chase account because Chase actually sends your balance to you in plain text if you request it I just want to point out one thing is like right now the one thing we have to rely on is DNS so either we hardcore the DNS uh the DNS Keys the keys in the DNS in uh in the contract where we get it from chain link now if only we had something called dns6 which had actually taken over because if we could have actually done all of this on in a contract because we could have just verified the certificate like to the root trust but unfortunately nobody ended up using DNS SEC so we can't do that so if you're interested in any of these Primitives we're working on them at Persona labs and we'd love if people reached out and were able to help us or we're interested in talking more we think it's a very fascinating interesting space and is going to rapidly change how we think about decentralized identity over the next year or two if you want to see more updates about proof of email including it's not it's not labia but eventually eventually um if you want to see more updates about proof of email including our website or open source code and experiments as we release them we recommend following us on proof of email and our front end where you can generate your own email and your own ZK proof from an email is live at zkemail.xyz the user flow is you have to go through these four steps but you'll notice that there is no sending to server involved and we had a great brainstorming session in the morning in which we got a ton of these ideas together so kudos to all the people came to the morning session helped us come up with the ideas that you saw earlier awesome thank you so much and we'll take any questions thank you do we have any questions so so the the NSA example is cool because it's like oh Edward Snowden could have done this without revealing his identity but on the flip side a Russian spy within the NSA could also just reveal all the nsa's information and never reveal who they are how are you guys thinking about how to prevent stuff like this from happening or what safeguards can we build yeah this is a great question and this kind of comes back to the tragedy of the comments point that we brought up I think part of this is that you have to enable some amount of accountability ideally in these situations and this can come in the form of say like upvotes and downvotes where if a certain if you have like say a nullifier associated with a certain account or certain address and this account gets a certain number of downvotes then you can hide this from feeds that are being shown to users although the data will forever be immutable Unchained from the perspective of users who might benefit from this or get harmed by this you can at least do your best to Shield them from it but part of it is that it's it might be very difficult to solve these problems and it requires a lot of thought to think about how to do this very carefully that's a great question though is there one is thank you I'm from unipas and finally somebody discovered the emails we are also using emails as a proof of ownership of the Smart Control wallet and my question is how is the cost of the dkp on chain like you know you have to verify Isa signatures you have to verify the key proof so we are building the same solution so I wonder what's your benchmark now yeah um so right now since we are hardcoding the DNS uh Keys we don't actually have to verify any signatures on change so the only thing we verify is obviously the verification of the ZK proof which is across 16 proof and usually that takes about I think like 400 500k gas it's a constant time thing yeah 400k right yeah 400 yes including the rsa's verification uh you have to verify the tcam signature right it's RSA signature oh that's verified already inside the circle from the VP yeah it's a KP covered this right yeah that's that's only verified inside the circuit but why you have to put the tcam publicly unchain uh because then anybody could just take any random like RSA key and just use that to sign their own header and so it's just like a dpki right availability uh purpose so what do you say dpk and centralized public infrastructure it means you just put the publicly unchain to let others can verify yeah yeah exactly and the contract also I think I very five is a simple http request actually yeah so like uh well our front end just makes a DNS request to just check that but okay yeah but like on the smart contract we have to hard code it or we could use a chain link Oracle to fetch the DNS as well so I won't take too much time we can talk later yeah