ZK Email: Making Proofs Fast

Transcript

[Music] very manual setup now it's uh you know by default in Brave Incognito similarly with TLS went from this spoke default um and you can say the same thing for crypto where basically you have private data private State private Keys whatever and like all of these other pieces of cryptographic infrastructure you expect the adoption curve to not go through centralized intermediaries that store your private data but for you to have that private data locally and so this is why we think private State Management management whatever is not really the end game and we're going to need F side proofs because that's where the adoption curp of all the previous cryptographic infrastructure has ended up um and so why like what specifically can you do

with these proofs anything you can have a digital signature of you can basically prove very easily in ZK proofs and we've seen this a bunch people have done things like Pas Keys um which let you like send money with fingerprints passports which let you verify your farm in certain country and you s your disclosure appest let you execute claim that you know an app exed correctly on your phone and an Apple sign that yep that was the correct binary executing um and of course emails um and so where is a signature and emails um you guys mostly know this but you do uh all emails have a signature on them which is RSA signature of the shot 56 of the contents you can prove that within ZK and that's ZK email this means you can get uh totally selective privacy you can say we're going to reveal only way we

want to reveal you have full Providence of the sender so you prove hey this email was sent by venmo.com and and as a signature from venmo.com and so you're not trusting any third party notaries proxies whatever um and the final thing is it's portable you can verify all these proofs directly on chain and so what are all the Primitives that go into making this kind of proof you need of course RSA and shot 56 you also need partial shot6 where you can start it from the middle um you need substring extraction where you want to extract very simple substrings um you want Rex where you have more complicated substring extraction so for instance uh when you want to extract the from email from uh an email header it's actually fairly non-trivial to do with substrings um and to my understanding Rex is the

only way to do this securely because it's just so complicated um you need quote printable decoding to be able to decode email bodies you want bit masking if you want to do things like whistleblowing you need Basics decoding for attachments and for headers H and ideally you want attachment parsing but attachments are often very large and unwieldy and so in practice we're still working on making that faster um and if you want to hear about specifically the implementation of these Primitives how they compare in no to existing Primitives you should watch Jack and Ian's talk because they're going to be mostly discussing those things um but I'll focus more on the use case and the infrastructure side so you know the the simplest version of what you might want to build with this is maybe like some whist one you can use a simple bit mask

on top of the header on the body and you can just reveal specific data you want to reveal um you can also build more complicated things like for instance domain Marketplace the KB top said if you have an email that says you transferred some domain on name chep from person a to person B you can use that email on chain to unlock esro funds so how does this actually look you say hey I want this domain s. XYZ you send money to the smart contract to escro for that domain the domain seller sends you the domain both of you will get a name cheep confirmation email either one of you can prove the email on chain to unlock the money to the seller and so this is quite interesting because you can build arbitrary marketplaces or uh arbitrary systems on top of these

proofs but the kind of main barrier to this is people making new kinds of proofs quickly for instance if you want to support all domain registar you better now have an email for every single domain regist so the ability to both create new proofs and update those proofs should be very easy and so we've thought a bunch about okay how do you generalize this kind of zkp top technology and the idea is there's a couple of key pieces of common infrastructure one is an SDK where you can imagine people who are maybe not super familiar with proof systems can use any email proof automatically in an app a registry where you can reuse existing proofs and an archive where you can fetch old public keys and so I'll kind of go over these one by one so okay concretely like why do you want some

sort of abstraction uh for people to use Z Emil proofs over any type of proof system in their app well the problem is um like we are familiar with maybe some of these different proving systems but an app developer who is trying to build a domain Marketplace should not be expected to learn the difference between all of these uh and so the idea is that if you can say um and you know we have investigated all of these and we've like made MVPs and like half of them more than half of them and we've like written stuff about what people should build in and not build in but this is not generally um a skill set that people necessarily have so how can you kind of get people to build these proofs without any knowledge of that well you can

imagine that imagine someone can just import say a value in their client side app they can say look I want to prove say the email for Devon rejection they can specify that and they say I want to prove it either locally or not if they want to prove it locally you'll probably be doing a version of Noir or circom or something that is optimized to on the browser and for clients side proving and if local is false like here you might do a service side proof which maybe is you know running an SP sp1 or circum or something where you can hyper paralyze or across gpus um and then you can have everything be sort of intuitive as to what the steps are for your average app developer to to use this you want to parse the email you want to generate your proof you want to verify it on chain and app

developer should not have to think about which proof system am I using how is it happening what is memory uh you know these kind of like what is a witness like these things should sort of be completely abstracted away and so concretely though how do you even get to the step like how do you define enough things related to say a dep con projection proof that app developer doesn't have to think about it and that comes in that's where the registry comes in the idea that you can have this database easy ways to Define proofs and then reuse them so for instance um our our whole thesis was it should be possible to define a new kind of email parsing pattern in five minutes so the idea is you can you know specify what pattern you want to Define and you

can then upload like an example email the idea is if you upload say an example email that you now want to make a proof of we can parse out all the a bunch of information automatically from it concretely we can parse out who the sender was what the selector was what the length of the header and body is automatically the second you upload that email then the user has to Define how they're going to actually part this email so they want to say something like look I want to extract the username I want to extract the talk title I want to extract the amount of money they paid I want to extract whether they got accepted or rejected and the idea is you can just say I want to extract those things from the EML and we can just automatically send that to a Claud API

or gbd4 API or whatever and Define this is what your reject should look like and the reason we have this extra step in the middle and we don't ask users Define this is that we've noticed in practice like we we've had people generate like hundreds of these kinds of proofs and it's like this part is like very tricky because you have to make sure that you're like comprehensive over all possible formats of the email you have to make sure that you can't be spoofed you have to make sure you're using you know deterministic Rex syntax it's a it's like a very non-trivial task to defin these kinds of rexes and we've noticed in practice that you know sticking an AI on top of it actually makes sense and actually makes it faster to Define this um and so once once you've done that then you'll kind of end

up with a configuration that looks something like this Json you basically have something like these are the rics that I want to Define uh this is you know the sender in this case devc con.org this is how long the email is and this basically parameterizes your entire proof and the idea is once you compile this we can now send this to a server and we can compile the ccom the Noir the sp1 whatever it is proofs and when you say I want to do it locally or on server you can choose which language to use automatically um and so conely if you want to imagine say viewing all existing proofs uh the second you've submitted one of these patterns it'll appear on the registry page um you can see all the patterns that everybody else has used what the smart contracts are you can verify the trit set up yourself Etc

um and once you've kind of defined this pattern we kind of Auto deploy an interface for you we want this to be like as easy as like a vercel kind of flow the idea is we will automatically deploy a font end for you where you connect your Gmail account or you upload an email you select the correct email then the proof happens in the background um and so you know concretely once they they sign in with Google then we'll show okay these are all the possible emails that could verify for your pattern so in this case maybe they want to prove their GitHub username or something we'll say okay these are all the emails in your inbox that would validly prove your username we can either Auto choose one or we can let the user choose one subsequently uh you know they they click the email on they hit prove and

then uh they get the finished proof on a page and they can share this automatically like share a link they can you know send this proof to anybody and they can be like ah yes okay this user you know thing verified their GitHub automatically uh with this proof and you know this ties it to either some eth address or some action they want to take or whatever um and this makes it really easy to share these kind of proof you can say you know I'm going to share the Noir proof this AR proof sb1 proof whatever you want depending on the context of how you're sharing this and uh you can do more though than just treat this as kind of like aell a deployment thing you can treat this also kind of like GitHub like the idea that you have repositories or patterns and

people can contribute edit Fork have versions whatever and this is quite interesting because emails update all the time so for instance um you know some some emails like venmo only updated once every two years Devcon sends a different email for every event um and so you want the ability to say look like previously this is how we were parsing it and now this is how we're parsing it and people in their SDK don't need to think about it it just automatically figures out what the latest kind of parsing should be uh and we'll parse the email for you and the idea is that you know if you don't like this you want to change it a little bit you want to parse a different piece of information out you can just hit fork and now you can Define your own pattern on top of that pattern

um and so we're hoping this kind of creates like this very interesting ecosystem of proofs because so far I mean people have done like dozens to hundreds of different kinds of the email proofs and there's no kind of coherent ecosystem where someone can look and be like okay I want to use this proof I want to edit this proof I want to browse all the existing proofs um so we think this is going to be quite powerful um okay concretely what have people built with this um someone built you can verify any document that you've signed from docu signell sign someone prove you took an American Airlines flight and you either came from somewhere or went to somewhere and they reveal those airports um this one proves they part of like a slack workspace and so now you can kind of have an onchain group that

corresponds that's only open to say people in your slack workspace which is kind of interesting you can kind of now start to interoperate between these things in a very interesting way you can oh like if you're part of this lock workspace and you took this flight then automatically reimbursed or something like that to find these very interesting composable systems um someone built something where you prove you exported your LinkedIn data and then you sell it to an AI training company um someone said you proved you exported your open AI chat data and they sell that to like anthropic um someone proved that you automatically resolve some issue on GitHub this is quite interesting for automatic uh know dispersement of Grants I think someone is actually working on

this for Noir um where I think like has automatically gives grants if you close some issue which is quite cool and then um you can also do fun stuff like John put up a proof for you who you ordered a pad tie in Thailand uh you can do this via a grab receipt and just parsing out the words P tie and the location being somewhere in Thailand you can do like very fun silly things and of course you can prove that you got rejected from Devcon proing you got rejection okay sweet um okay and so now you have all these proofs now the SDK makes a lot more sense you just select any one of these find if you want to be local or not and and the proof happens um and if people want to try this out you can go to like beta version

of this at s. proov that email um this should really be like registry. pro. email but the URL later um and uh see it and and we'll upload we'll update this to have the the new UI soon but this should let you like kind of scroll through all the proofs then we have more than like 7080 at this point on the site you can try defining your own it's it's we have like tests and stuff to make sure it's done correctly sweet um now that I've gone over s registry another question is you know how do you actually get to these public and this is quite important because regardless of whether you're using Noir circum F1 whatever you always need to get old public keys this is maybe not true for emails that were sent

yesterday because you can probably just hits or the registry on chain and get that key automatic but imagine you're going to take an email you want to prove an email from four years ago and now that email server has rotated that key out you don't have access to those keys anymore how do you do that um well you might imagine this is not a big problem but this is a big problem um this is for instance Hillary Clinton's emails um or I think like her advisor or whatever that leaked you know something like eight years ago if you try to verify these emails today um more than half of them do not verify because those keys are no longer available um and this maybe doesn't matter as much in the linting case because probably the emails I verify are good enough but you know when you are when you have hundreds

or thousands of people making proofs at scale it better be the case that you can verify old emails okay and so what is the actual logic that's happening here um the idea is that when you want to get the public key corresponding to some email domain server you basically will go to their custom selector doore domain key do that website so maybe venmo.com or gmail.com whatever um and this will let you get the deom key as it is today but the problem is these rotate so you know in six months this key might be gone so um here the idea is we have this basically server that is archiving all of these and it has over a million keys in it right now

you can search any website in this case you know search bmo.com and you can see all the keys that we know about that have been used since we started running this about a year ago um at this point maybe like n months or something um and this is quite nice because this means one of the very subtleties here with getting these public Keys is this selector is actually unknown like if I have the website bmo.com like you'll see this selector like this massive random hash and it's impossible for me to know what this hash is unless I've received an email from venmo with a key corresponding and so you kind of want a database saying here's emo.com and here are all the possible selectors which is not possible to get otherwise

okay so now the big question is how do you actually recover old public keys because of the whole point of this exercise and there's this kind of interesting Quirk that you can do with RSA signatures where if you have two old signatures you can derive the old public key um this is like a little bit mathy but um you imagine when you have a signature it's kind of you're taking the message to the exponent mod modulus um you want to verify you take that signature like m to the D and you take it to the power of some commonly known usually like 655 37 but if you take two signatures um and you express them in exactly this form then you realize that uh if you convert the modulus to being

some multiple of the actual modulus you can kind of say look when I want to verify the signature I'm going to take this value to the power of E and then I'm going to know that's the original message plus some multiple of the module now if we want to get back the modulus we can do is we can subtract and take the gcd of these values and so if we you know use a calculation and now we have you know this this remainder and that remainder and we take the gcd we probably going to get back which lets us rederive old public keys from two old emails quite interesting um right now you have to trust that the archive uh is going to do this gcd process correctly but my hope

is that this whole system can be decentralized in the sense that you can have multiple archive nodes that all sorts of interested parties run and when you want to say do this gcd or when you want to upload emails or when you want to upload public Keys all those archive servers are going to calculate and verified automatically and then now you have Providence from a bunch of different servers doing this archiving And archiving verification process um One Way We Got selectors Is by people kind of uploading their their email inbox and we don't upload the entire inbox the idea you can take a script you can run it client side and you can calculate what the selectors corresponding to some domain should be and then you can tribute the selectors from your inbox into the archive and this public information anyways but it's very hard to get unless you have

existing emails so this is quite cool and a very easy way to contribute to ZK email um sweet and so I guess now that we've gone over the basics and the common infrastructure that all proofs running on all languages will need um I can kind of go into some interesting other applications that will probably spend most of the time discussing in other talks happening around the venues but I'll give like a sneak peek of what they are now um they're not as relevant to Noir necessarily but um so so one thing you can do is you can verify jbts as well like login and I think o is going to give a talk on this later today and so has also built a version of this in Noir but the idea is you can basically sign in with Google and have that trigger any command on you and this

is quite nice because this means that uh instead of having to get an email out of your inbox having to reply to an email just hit sign in and that generate a signature from Google to trigger some onch action um another cool thing is this thing Cil built called stealth note that was also previously built by circom team called nosy and the idea is you can kind of have these Anonymous confession you can prove that say you're an employee of Boeing because you prove you have an boeing.com email address and then you can say something like you know confession I forgot to put screws on the plate um and um the idea is that you can reveal have more people reveal truths without fear of uh getting reprimanded

by their employer or being doxed or you know being shot like in the case of B and you know one of one of the problems here is that you really need good moderation here like if somebody tries to go on this this sort of application and then say fuse hate speech then the whole point of this is lost and so one cool thing we do is that you can send the message before you post through a te uh for moderation and hopefully ideally this will be you know zkl but we're not quite at the point where we can put you know llama 45b into a a snark um that means that you can Define your own kind of lens of moderation you can say something like oh I'm going to browse this site and I want to view everything except the ha you can say you know this

is going to be the prompt that it's going to get verified against a te and that's what I'm going to see in my you can say something like oh I only want to see things related to companies in the Bay Area and then now you know you can verify okay like is this related to that yes or no and it'll let you do this and this lets you kind of have your own view on the kind of content you want to see I this is very important for moderation and Anonymous Forum um and the final thing is you can use either the JWT flow or the email reply flow to trigger transactions um you can kind of have an email based smart contract that will enable things like receiving tokens directly to an email address having emails directly approved on Multi logging in with emails

and having that be session key based um and using your emails as W like audience um we have various talks talking about this but because it's happening on the server side it's not necessarily as relevant to North client side proofs so I won't talk about it here um but I'll give you like the the brief flow of what this looks like um you'll get an email looking something like oh you have received a guardian acceptance request in the case of account recovery if you reply to it um then it confirms you with the guardian you can recover the account Etc and this flow is identical for all of these application you kind of receive an email reply to it and then trigger any one of these operations um and similarly to the generic SDK registry Etc you can have this kind of generic solidity Library which you

define this is the kind of pattern I want to match in the email and you can hit a relayer API any one of the decentralized relayer apis and that can automatically handle getting that Pro proving it on chain and triggering the onchain transaction sweet um and so if you want to learn more you can go to our Twitter on the left our main side in the middle Z out email um and you can look at these slides on the right side um I think we have maybe like few for questions thank you y's let's give y a round of applause we have time for one question one question let's go for one question you have one you raise now if not three two one okay thank you a that

was an awesome talk following the spirit of CK MS we then have Jack and Ian coming up to share more about their C email application around doing CK reimbursements as well as well their contributions to the CK repo come up come up