ZK11: ZK Email: Novel ZK Applications Unlocked by Portable Provenance - Aayush Gupta & Sora Suegami

Transcript

[Music] hey um cool one of the big problems with crypto and onchain data is that it's very hard for it to interoperate with the systems that we're used to the web two systems currently in order to do that you often have to have an attester this Central third party often undercuts the decentralization of whatever on application you're using and so it's very difficult to actually bring that data on chain in a verifiable manner without having to trust things like NPCs oracles or enclaves with the security of your

application but instead of attestations what if there was a way you could use provenant data instead so today we'll be talking about ZK email portable Provence and how you can use that to power wallets account recovery and more I'm aush and I'm s and thank you to the literally dozens of people who helped this project happen um we wouldn't have been able to ship account recovery today without the help of all these folks so during this presentation we'll talk about a few core topics first we'll discuss core ZK email and how the cryptographic Primitive itself works then we'll explain how we use ZK email

to build email wallet which lets you send money to email addresses and use emails to trigger transactions then we'll explain how we generalize that to do account recovery which allows you to have a signer which is an email wallet Guardian on your existing wallets if you want to follow along with the slides feel free to scan the QR code and then you can pan forward backward wherever you want in our slide deck as well so how exactly does provenant data work well the idea is that because the email is signed by the offchain service that sent it we can actually verify that data directly giving that data Provence now if we prove that email

signature within ZK email we can make it portable that is we can prove it on chain directly we can also make it programmable we can decide if we want to reveal certain information or not reveal certain information for instance maybe we want to hide the from email but we want to reveal the two domain and we want to hide parts of the subject we can use arbitrary logic to program it with ZK Rex but how does this actually work well the idea is when any user on any email domain server sends an email an RSA signature is automatically attached to every single email that you've sent or received since 2017 we can verify this email by the recipient in a ZK proof where the

recipient can then prove that they received an email from say at ZK summit.org without revealing anything else about the email then they can directly post a ZK proof on ethereum to do whatever they would like with it cryptographically how precisely does zkl work the idea is that every single email is signed according to the Deon protocol this is effectively an RSA signature of the shot 256 hash of all the data in the email this would include the from email the to email the subject of the email and the hash of your whole email body including the attachments this shot 86 is then signed with the RSA by the RSA private key of the domain to verify this in ZK email we verify this entire process we verifi the

RSA signature and the shot6 has in order to verify that the dkim was done correctly and then we run Rex in order to mask only the data and reveal specific pieces of information when you want to verify this whole thing end to end you verify it against the RSA public key which is found on DNS so for instance for example.com you might find it at selector doain key. example.com so for a concrete email how might this verification look you could imagine that often on chain people want to prove information about identity for instance what is my Twitter username how many followers do I have something like that so to get that Twitter username on chain without having to trust any party except Twitter we have an email here from

Twitter any email would work but in this case we have an on demand password reset email you'll notice that at the bottom right it has my username in order to prove this value on chain with ZK email we would first take the headers the subject the from email being verified twitter.com the timestamp ETC we'll hash that for you and then we'll verify that hash was done correctly and verify the deim signature then inside the body if we want to prove things about the body we can take the point in the body that we want to proof on and hash that forwards and ensure that that value was in fact signed by the header then we can run our Z Rex proof on that to verify that the data we're looking for is in fact in that email and then we use Rex to

extract a specific value you want to prove on chain in this case this proof would at the end prove that I am the username USG you can build a number of things by this primitive that allows you to prove any email in your inbox for instance ZK PTP which most ZK Summit folks are familiar with allowed you to build decentralized on and off ramps by proving a confirmation email from venmo UPI or guarantee which allows you to move Turkish L US dollars or rupees directly on and offchain you can use similar technology to do email wallet which allows you to basically by proving that an email was sent send money to any email address and allow them to claim it by simply

replying to an email if you want to see links to these projects you can go to pro. email or ZK pp. XYZ or email wallet.org directly let's dive in a little bit to email wallet and how precisely you might do a system like this you imagine imagine that offchain what is happening is say I gmail.com I'm going to email a relayer which could be myself um or uh any third party relayer and that relayer can then send a confirmation email to the recipient in this case my friend at outlook.com in the web two context it would end here but with ZK email the relayer can simply make a ZK proof that they received that

email and subsequently prove that on ethereum this can then gate a trans action in this case three usdc going from my account to my friend's account you can try out email wallet.org on the bottom right if you scan the QR code and the core idea is that by replying to an email you can trigger a transaction so for instance when you log in you might get an email that looks like this in order to create your account just reply to this email with any text and one of the really critical things here is that there's an account code in this email it can be in the body but in this case we have it in the subject and this account card is a

critical feature of email wallet for its privacy protection and R decentralization specifically our dkp circuit computes the hash of the email address in the front field and the account code and this hash is used as the cre to sort of the users corresponding eum address so our adversary cannot estimate the email address in the corresponding to the public es address because this account code is a random value also the Tate checks if the users account code exist in their users email header so it ensures that the user can actually access to the account code and

this allows the radio decentralization because it prevents mer R from withholding the account code to users in other words as long as the user can access to the account Cod the user can use different rayor just by shelling the same account code to a new rayer even if the current rayer with sensors the users transactions so we go back to the thr of the email wallet after creating your email Wallet account you can log into this account just by pushing this button in the Rus email and this will out fill the account code into your front end and on the front end you can transfer tokens

from your email Wallet account by filling the amount of token and the kind of token here and specifying the recipient either by the ism address or email address so in this way you can transfer tokens directly to your email address and by pushing this send confirmation email you you will receive a confirmation request email for r and just by replying to this email or your transaction will be complete and your token in the email wallet contract will be transer onch and similarly red demonstrated or demo of the sending nfds to the to two email addresses at e

number so the background background FR of these applications using email wallet is realated like this one so the sender Alice gmail.com first sent email or to the layer's email address and the rer creat the D proof using the given email and the users account CES and this proof this proof is verified by the email wallet contract onch and if the proof is wallet and actual tokens are actually transferred onch and after that the layer sends email not only to the sender Alice gmail.com but also to the recipients and if the recipient does not have an account yet or it will create a

new account code for this recipients and the ReUse email contains this account code so the recipient can so the recipient can or claim this receiving token just by replying to the email and even if this layer goes down or sensor the users email and transactions or the user can start using different radius just by sending her email with the account code to a different reuse email address so our so our R of email wallet can be already decentralized so uh this is the description about the background of

email wallet and now we are ready to announce our new product that is onch email or SD C it generaliz the features of email wallet and it allows the developers to build email based onchain application without writing new circuits just by writing 30 de contracts so specifically your smart contracts can handle an email as a kind of onch message with confirming that the message senders ISM address is corresponding to the users email address in the front field along with some account Cod and at the same time the given parameter values in this message are actually contained

in the user subject and this subject is following some format PL defined by each application and the magic to handle application specific subject format without preparing new ciruit is this subject template so this is the example of the subject template you can see there are some valuable pets like this m or strings whose values are depending depending on each subject and which has the some types like these wordss and also there are fixed string Parts whose value is a static and you can Define your custom subject template

by combining these valuable paths and fixed parts and you can Define this subject template directly on the 3D contract without lighting any circuits just lighting 3D contracts so for example our if you want to make a application like or to transfer a specific amount of tokens or you need a confirmation by the email or emails confirmation uh then or to construct such two Factory authentication system using emails or you can put the uh information of token amount or uh name of the token or some or transfer ID into this into the

subject by defining uh defining or each uh uh each good subject template in this way and uh in this way our email SDK this SDK or converts or uses interactions to contracts into your task just to send email and after defining your custom subject subject template our SDK will automatically verifies this subject or specifically or we verify that R SD can verify that the subject is actually included in the users email and at the same time it follows their predefined subject

template and how to do that is first it circum circuit receives email header and outputs our entire email subject with masking some private data like email address and account code and in contrast the contract will rece parameters for the variable part which is just a call data for the 3D function and the subject template itself and based on that based on this datas the contract will construct expected subject and if and only if this m mask subject mask the entire subject and and expected subjects are equivalent it passes the

verification so for example if the subject template is a kind of a swap this m string to string your ISM address then or the second circuit will output the entire subject without modification and contract will receive the parameters of each variable part like 1.23 for decimal part and is for the string bir and it it applies this valuable parameters to the valuable valuable parameters to the valuable path of the subject template and in this way it can construct expected subject and you can see this mask subject and the output of the circuit and the output of

the contracts are equivalent here so uh so in this way or you can easily Define your custom subject template uh using our SDK and uh one big or one of the big killer application of our email o SDK is email bestas account recovery this is a kind of social liity but guardians Guardians only need to use emails so the problem of existing social liability is uh the guardian should be transparency person for the wallet owner but not all of them are always are e eum users

so our email bestas account recovery enables any email users to work as a Guardians so you specify or most of the your get most of the your trustworthy person uh such as your Palance your best plans and so ear as a guardian of your eum wallet so in this in this sense our we make social Li practical solution to describe more about how the specific account recovery might work you could imagine that when a user wants to set an email Guardian that Guardian will get an email asking them to confirm when they reply the email off subject template would be confirmed and proved

on chain similarly when the user wants to recover the wallet they might get an email like confirm that you want to recover the wallet from one address to another address they would simply reply they would get proved on chain and the wallet would recover we have a demo of the proof email recovery with NOA safes on Bas ofoia right now and we'll walk you through how exactly this might look from a user perspective you can imagine that for Nosa safe we have own website and people can integrate with it um and you'll need a noza safe with uh on base aoia to try out the demo but you'd imagine that for an existing account abstraction wallet they could embed this directly into their application for Nosa safe you would have to email enable the email recovery

module which would add this email signer as a signer on your multisig then you would simply set all the different Guardians you want to set by just entering their email address and then a recovery delay the purpose of the recovery delay is that you want Guardians to request to recover the email and then only say a day later the account gets recovered this means that it allows time for all the Guardians to take time to agree to recover your address at the same place um and if a specific Guardian has been compromised it gives the wallet owner time to override the compromised guardian's actions once you've configured this guardian and the delay that Guardian will get an email like this it simply asks if the guardian

wants to be Aigner for this account when the user confirms we would parse that email on chain and ensure that the email address from that email corresponds with the wallet address specified in the email and add them as a guardian on the multi- Sig now let's say you've lost your wallet when you want to recover it you would simply you or the guardian can enter the guardian email address the previous wallet owner and the new wallet owner into the UI and when you hit trigger recovery then the guardian will get an email asking if they want to confirm this operation it would ask them if they want to update the owner from one address to another address and again if they reply then it's confirmed on chain again the

email subject parsing parses those two values and recovers the owner from the old owner to the new owner automatically now this account recovery is quite easy for new account obstruction walls to integrate the way we've abstracted it is there's only five functions that a new AA wallet or multi need to mement on their side you can see the full spec of how we do it and the technical details on the right side if you want um but this makes it very easy for a new account abstraction wallet to automatically add email Guardians now this email off package and SDK is extremely generic and Powerful it doesn't just handle account recovery you can trigger any transaction you want on Chain by sending emails this adds quite

a lot of power because the ability to both authenticate the email was correct and the operation they're performing in was authenticated by them in plain text gives you a whole new field of operations you can do with existing wallets for instance you can ask users who aren't onchain users to confirm certain transactions maybe you're working with banks or maybe you're working with governments or whatever it is you can ask them who may not be chain native to still interact with your application just by confirming via email you could also secure different contracts for instance if you have a bridge you can say any transaction over a million dollars has to be confirmed by a set of email addresses in order for it to pass and the general ility for anybody with an email address to interact with an onine application fundamentally means you have a whole new

space of users and a whole new space of operations that you can enable on your smart contracts for account recovery specifically we also have the SDK that lets people integrate the like the version of this package that works just for account recovery with only solidity functions we've currently built it at ether email off we'll release it as a more formal npm package once our audit is finished this month over the last year to year and a half our ecosystem has massively expanded uh this is quite an overwhelming graph so I'll just go piece by piece the purple stuff in the middle is the thing that allow you to create a new ZK email proof or ZK email mechanism this includes the core ZK email

contracts uh deim Archive of all past deim keys so you can verify old emails and ZK jwt's that allow you to verify for instance that you own uh an ATZ summit.org domain without revealing Who You Are um and of course the ether email off package various things have integrated this for instance email wallet proof of Twitter and the account recovery that we mentioned um there's also a number of Primitives on the far left side that you can use to build apps that are generally for proofs of ZK signatures and not just ZK email for instance you can use Rex to parse any information uh in a structured language offchain and bring that information onchain for instance um you could use this on uh different data you

get that you already have a digital signature on outside of ZK email we also have W benchmarking code and we have a ZK PSI library that we use for Rel layers to communicate private information to each other this is one of the things that allows decentralized Rel layers to be much easier to do because they can have a private way to share that private information without revealing the entire thing and we have libraries that allow you to do this ZK PSI operations this can be quite powerful for Rel layers outside of the ZK context where you still want to decentralize them we also have a number of string parsing and signature Library that allow you to make new ZK proofs um a number of projects have integrated various parts of this including ZK PP nosy for anonymous discussions um proof of passport and a whole host of other

applications um if you want to see a deeper dive into the ecosystem you can check out our blog at proof. /blog where we describe in depth how each one works um for the core ZK email circuits if you want to use them um we've currently published circom and Halo 2 versions why circom and Halo 2 we published a Long blog post explaining how we had uh decided if we want to be in production uh what is the most both battle tested uh fast and easy to interact with libraries we expect this to change over the next six months to a year as new proof systems get audited and put into production but if you're interested in looking at the tradeoffs with different proof systems we made to understand which ones to focus on we have a long summary here uh this is also uh expect to to to change over

time um for circom it's extremely fast on the server side for us and uh it's been audited once and we're going to audit it again this month um and this allows you to build of course the ZK email circuits and the ZK Rex uh compilers and apis Halo 2 allows you to have super fast client side proofs and that will be audited soon uh if you want to see uh these repositories integrate with them or import them you can check out our GitHub on the right side everything is MIT licensed open source we have various tooling we have the historical Rex registry that has over 100,000 Keys now that lets you verify past deim keys and stores them um and there's still dozens and dozens of applications you can build

with ZK email we've only scratched the surface you can imagine that any email in your inbox can be proven that includes maybe you took a flight and you want to prove you took a specific flight that was say carbon neutral or something you can make a ZK email proof of that or you can prove your credit score onchain by proving you got an email from a credit organization saying a credit scor was some value you can Bounty whistleblowing you can put a bounty on anybody posting an email from a specific sender with specific text on chain to incentivize people to whistleblow you can donate to papers or githubschool of project ideas um and we would love to

just chat if there's a cool email in your inbox like we want to hear about it let's let's make some proofs of it um is again a QR code to our GitHub if you want to check out more of these ideas so what's next for the ZK email team after our audit this month we'll be focusing on integrating account recovery into as many wallets as we can so if you are a wallet or you know a wallet we would love to add email Guardians to them um after that we are thinking about doing oo with emails in the sense that you can now log in to any website and authorize any specific Scopes by just responding to an email in a web3 native way for instance maybe you're logging into a website and you only want them to access your ER c20s for one specific

contract or you only want them to be able to operate between the hours of 12 and 8 every day you can specify that information as an oath scope and the user can just confirm it by replying to an email this can be super powerful for logins working in a completely decentralized manner where you define your own scopes and we'll be working that May and June if you're interested in integrating email login generally into your app we would love to chat more about that we'll be doing a signature Singularity residency in which we know that ZK proofs of uh General signatures are super powerful even outside just ZK email and so we're working with a number of teams doing ZK signatures uh in order to run this residency including cursive is doing the cards that we're signing uh at ZK

Summit and then finally we'll be focusing on universal reject verifiers which all you to have a single contract on chain verify any zkl proof with any Rex by using axiom's pass through verifiers where you can just simp specify the uh the verification key of that specific Rex and use the same onchain contract if you want to chat more we would love to chat our telegram is on the top right and these slides are on the bottom left um definitely let us know if you have any questions and we would just love to jam on different ideas thank you so much okay thank you thank you we have a few minutes for questions any questions there's the mic on your seat

just make sure it's on [Music] oops okay um hi thank you for the presentation that was very insightful um one question I have is what are let's say the um possible ways to spoof this uh for examp especially since we're uh medling with things like Guardians and wallets right um anti spoofing should be a big concern so um I'm not an expert in this but I've heard of DK spoofing before so is this something that's a challenge uh with the current stack and what are the ways uh you think uh you

can tle this yeah so the it's a great question about how do we get around things like dekm spoofing um so if you look at a number of the deim spoofing libraries and techniques for instance the One released at Defcon last year um often these deim spoofing techniques rely on changing different headers to disable the dkim check and that's how they get around these checks um but nobody in order to spoof dkim in reality you would have to have that domain's private key and when domains find out that somebody has their private key they will often just rotate that value and so it's actually the case that most deing is not faking the deom signature that we verify and we've gone through tons and tons of different email exploitation mechanisms and we found that zkl actually still verifies um every single one of them because nobody can fake the

deim RSA signature um but it's a great question and if you find a way around it we're happy to chat um but from what we can tell domains will immediately rotate okay we have time for one more question just press the button make sure okay great uh really nice work really exciting project uh I had a question about how do you agree on the public keys of the of the email server on chain to do the verification of the signature yeah it's a great question um that de public key is usually sored on DNS and so getting that value on chain uh there's a couple of different ways we can do it um one is that you can delegate that responsibility to the app so for instance if people trust that the

app wants to say verify that deim uh deim signature they can trust okay the app has set my Dum key correctly other cool thing is that we can have user specific overrides on that deim contract so if you don't trust that the app has set that deim public key correctly a user can specify for instance if you want to verify anything with this address it has to be by deim key that I've authorized and so folks who don't necessarily trust their infrastructure or the app to put those keys on chain correctly can simply say I only want you to use these keys that I've allowed and so for privacy conscious folks or security conscious folks that might be a better option and so the idea is that that deom key value is usually punted to the user as the apps or the protocol it's a great question though okay thank

you so much and Sora from ZK email give them a round of applause