Episode 372 - zkPDF and zkID with Vikas Rushi and Ying Tong

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week, Kobe and I chat with Vikas Rushi from PSSE and Ying Tong. We dive into two topics at the intersection of ZK and real world data. That is ZK PDF and ZK ID. For the first half of the episode, we explore ZK PDF, a project using ZK to prove something about the content of a PDF file. We dig into what makes PDF so tricky to work with, as

well as the project's journey of implementing ZK PDF using ZKVMs. We wrap up this part discussing real world use cases that could benefit from something like ZKPDF. For the second half of the episode, we switch focus to ZKID, specifically the efforts being made to satisfy the EU's digital identity framework requirements. Ying Tong shares what these requirements are, the response from the cryptography and privacy communities, and how the EF's PSSE group is working on a ZKbased proposal. We have covered a couple other ZKID projects recently on the show, so it was really cool to expand on that.

So, I hope you like this episode. It's almost like two episodes in one. Let us know on Twitter or in our Telegram channel. Now, before we kick off, I just want to point you towards the ZK jobs board. There you can find job postings from top teams working in ZK. And if you're a team looking to hire, you can also post your job there today. We've heard great things from teams who have found their perfect hire through this platform, and we hope it can help you as well. Find out more at jobsport.zero.fm. You can find a link to this from our website and in the show notes. Now, here is our episode about ZK PDF and ZK ID. Today, Kobe and I are here with Vikas Rushi from PSSE and Ying Tong. Welcome

to both of you. >> Yeah, thanks for having us. >> Thank you for having us. >> And we have Kobe back as a co-host. Hey, Kobe. What's up? >> Hey, I'm really happy to be back. >> Yeah, it's been a long while. >> Yeah. >> So, for today, what we're going to be exploring is ZK PDF. It's a project that I heard about a couple months ago. Uh I'm really excited to dive into it. We're also going to be talking about the larger ZKID space. Um we've already done a few episodes on various ZKID projects like self and RARO. We talked to the people at SUI who are working on SEM identity. There's also like the ZKTLS work and the local first work. So I'm

really excited to continue on that topic and and learn a little bit more from both of you. Let's do some quick introductions. Ying Tong, you've already been on the show. You were actually on the show last year >> talking about a framework for programmable privacy in distributed systems. We recorded that in person. Now we are recording virtually but I remember we got a chance to actually catch up and it was really fun to do that. So yeah, welcome back. What's what have you been up to since then? What kind of research have you been working on? >> I've sort of explored privacy on the application layer. And so in February and March this year, I co-organized this community privacy residency in Taipei.

>> Oh, nice. And yeah, this brought together members of marginalized communities who were building for themselves and building to yeah resist surveillance. And at this residency, I found out about PSA's ZK ID project and that's how I met because and started to work on privacy preserving digital ID. Cool. You've been in the space for quite a while. Have you ever worked on any other ID projects before that? like you worked on Zcash, you've worked on like I know you from so many different

projects, but I guess with ID just never one of the the topics. Yeah, this is my first real uh deep dive into ZK ID and we'll discuss this more later, but it is very much inspired by the EU digital identity wallet >> and it's impending roll out as soon as 2026. And this digital ID is very different from ZK passport and from some of the other ZK identity projects that we're familiar with.

>> Interesting. >> It's very different in terms of registration and verification. So, we can get into this later. >> Sounds good. That's cool. I actually didn't realize it was super different. I thought it was sort of in the same category. So, yeah. I'm really excited to hear more about it because let's learn a little bit about you. It's your first time on the show. Tell us kind of what got you started on this path and then I want to talk about ZK PDF. >> Yeah, sure. So, I did my bachelor degrees in computer science. While I was in college, I was exploring like different domains in web two. In the process, I started like attending lot of web two hackathons. So I stumbled upon

like a distributed systems and a consensus hackathon. So where they asked us to implement like a consensus algorithm which is like a draft that's the first introduction for blockchain for me. So then I started like looking more into blockchain and what are the different application related things I could like work on. So after that point like I started attending like lot of web web3 hackathons also. Then there is this project I I found out which is called Anonadar in one of the hackathons. >> Anon Adar.

>> Yeah. >> Which hackathon? >> So I think it's back in 2023 ETH India. So the project is like so they have this Aadhaar cards in India which is like a digital identity card in India and they're like trying to snarkifying this digital identity uh using zero knowledge proofs. For me it technically sound like pure something like really magical and the first look was like really interesting for me. So I began like started exploring cryptography zero knowledge proofs that was my initial introduction to CK and then I started while interning at a D5 company I was also working with ZK email and open passport as like a in few grants >> mostly we were like focusing on

implementing core crypto cryptography primitives in various CKDs something like circom no halo 2 yeah then I started working for PSC on security standards and I don't know that >> cool yeah I mean the some of the folks you just mentioned the ziki email folks Floron from open passport that's now self we've actually had them on the show in the last 6 months or so we'll try to find those episodes if people want to find out more about those projects but where does ZK PDF come from I guess we have to find out what ZK PDF is but is it coming out of just sort of creating primitives and then you're like oh here's a here's one path we want to go on or was Is there some goal that was put in front of you?

>> So CK PDF is like a proof of concept. >> Okay. >> Where we developed within PSC. So the one of the important aspects was like you have like primitives like ZK rejects and like something like Zikk TLS and like you have like all web proofs and things like standard like this thing. So the CK PDF focus focuses on proving f facts on the PDF digitally signed PDFs. Let's say if the PDF is like digitally signed, you could able to snarkify this entire digitally signed PDF and you could like prove facts from the PDF itself. So that was like a major motivation for us for the PDFs I mean snarkifying PDFs in general. Was there a specific motivating use case? So you

know for anonadar it was a specific digital ID from India but was there a specific PDF that you were looking into that would be exciting? So one of the interesting things we found was like in India there is this app called DG locker by the official government. So let's say you wanted to download any type of document which is related to you like regarding from healthcare, education, loan, banking sector. So all of these PDFs are digitally signed by Indian government itself.

>> Wow. >> So and also the the interesting part is like they use the same signing key for signing all of the PDFs. >> Okay. >> Wow. So the other scope the other card scope is like they issued like 1.3 billion other cuts by I think the number was in 2023 and the initial motivation for us is like we could snarify larger scope of Indian citizens like we can prove like a more data statements within like a diger app PDFs that's really cool >> so this is actually you were looking at like a particular real world case where PDFs are being used and you had a a better idea idea I guess than how it's done now. The the name of the system you said was Digi Locker.

>> Yes. >> Okay. And is it is Digilocker and the Adar system are they the same system or is it more like Adar will use this Digi Locker? >> So I think there's like a different two different departments by Indian government. So I think Digi Locker has like different like sectors like tax department. So all of this integrated into this dig locker app itself is like a different project which is managed by NPCI and digital identity by government itself. Okay.

>> Do you know if digil locker is widely deployed like is it something that's been used by old let's say tax authorities banks and or >> so it's mainly used to store certificates and the second one is like the one of the emerging use cases with from dig locker is like there >> let's say anyone wanted to do KYC it's being done by dig locker so all of the OTP stuff which regards to ADA or taxation. It's done by DC Locker, OTP or KYC verification.

>> Very interesting. >> On some level, this sounds like kind of great cuz it would be great if there's like some something that's consistent when they want to do KYC. I feel like this is a conversation that comes up a lot right now is like how terribly fragmented and dangerous all of these KYC >> checks are with these different companies. But at the same time, it's kind of scary for like one org or one, you know, government agency to have the full control over it. I think now would be a great time to define what ZKPDF actually is. I want to understand a little bit how it's different from something like Digi Locker. Why the way that Digilocker does it like what's wrong with that that you wanted to create something like CK PDF? So whenever I think of like the ideal data

sharing mechanism let's say I I have like this document I wanted to share with some provider I wanted to prove some factual data from the PDF itself. So in the DJ locker or any mechanism where you are allowed to send this entire PDF or like sensitive data to the provider and you have to prove that this is like a correct content. So in a way you are like kind of you're leaking all of this data to the provider and like who are issuing the KYC. The way you use CKPDF is that let's say you have this PDF and you wanted to snarkify some content and you wanted to prove to some issuer that is first thing is like issued by certain government or some personal or not and the second thing is

like you wanted to do selective disclosure on some parameters I have this salary of like this amount in my CTC something like this. Yeah. >> So proving factual statements within PDFs that to in a privacy preserving manner it's all about CK PDF. So >> but what like the actual storage of the PDF could still be just like in an enclave or on your computer or something like that. >> Yes. So there are like a two major hurdles like while developing CK PDF. The intuition for us to build any CK ID or like CK projects is identity projects is that you have this data and you are you you're doing signature verification and you're doing some hashing and signature verification and then you are doing selected disclosure. This is like

the standard intuition for us. Let's say what if the data is like really big something like PDF. So the average size of PDF is like I think 500 KB to 1 MB. M >> I think the average size is like 500 KB and the DJ locker PDFs are like somewhere around 2 MB to 5 MB. >> So putting all of this information inside snarks this is too much. So >> and also the second thing is like you can't derive like a client side proving because the constraints are too much. So >> so that's like one of the hurdle for us.

So we have to utilize ZKVM tech for the hashing and signature verification and the proofs which are being generated C 16. So yeah >> I think the second hurdle the first hurdle is like hashing and verifying the signature because let's say comparison with any CK projects let's say the CKD projects have the input size like few thousand bytes versus the PDF is like megabytes. So that's like a huge difference for us to prove this in any CKDSL. So yeah, >> I mean it sounds to me that the parsing, hashing, and signature verification could basically all be done offline. a one-time proof that we pre-process

and then at actual proving time on let's say the client's phone they could prove simply selective disclosure of the parsed values and link that to the premputed proof. >> Yes. As a it's like you generate a commitment outside the circuit and you kind of like link the same stuff we do with CK currently. Is that how it works or that's how it could work? Uh >> that's like one of the optimations like one of the really good optimations we can think of.

>> Yeah. The second part was like parsing this huge PDF text because the PDF is like 30-y old tech and they keep on adding updates with the original spec. >> Yeah, >> PDFs are so old. Wow. >> Yeah. So parsing this text is generally like a lot of headache and it's like very tricky and it uses somehow it uses like hierarchal data structure. It has like cross border references, different fonts, any number of encoding compression algorithms. The funniest part was like they use like different language also. Let's say they use some Chinese, Japanese, they you can embold like all of these languages. Yeah.

>> So for us it was really hard for to build like something really native which has like very minimal dependency and the the reason why we stressed on minimal dependencies was let's say let's say we wanted to take any ZKVM and we wanted to run our circuits inside ZKVM. The point is like all of the famous Rust crates like which are related to PDF parsing libraries they use native C libraries. So it's like the Rust wrappers on C. So all of these libraries are doesn't work pretty good on like native ZKVMs like SP1 or risk zero. So we had to like rewrite the entire PDF lo PDF passing logic with only one dependency which is

like compatible with SP1. >> Wow. >> So so PDFs are can be pretty complex and I think you also noted that in the Ziki PDF blog post that you guys wrote. So they can contain text and can contain images. that can contain very different complex objects. Are the PDFs that you're looking at mostly textual or do they have images? What are the ones that you're focusing on? >> So currently we are focusing on extracting text from the PDF even though you have like multiple images in the PDF it doesn't matter. Okay.

>> So the way the parsing logic works is like >> let's say you have like different pages in general in PDF. >> Mhm. and and each page has like different fonts being used in that PDF and you have like cross border references and they use like different encodings on different PDF pages. So you do like PDF passing by one one page to one page and then you interpret like different fonts and then you decode all of this from byes to text within like if if it's like Chinese or Japanese you could like decode all of this stuff inside encoding and you could omit out the strings >> with like a page output. So >> so generally you would hash the whole

PDF let's say but you would choose just specific segments that you would parse. So the entire PDF is not digitally signed. There are only the all the main content in the PDF is signed. There are like few headers which are not being signed in the Ps. So we tend to focus on the content which is signed. >> Okay. >> So >> and what content is usually signed? >> So all the page content the textual content is signed. Even the images are signed. So it's it's almost like 90% 95% of the PDF is like signed. there are like few headers and like few unnecessary content which are like not signed because of the optimization. So and it's by the PDF spec. So >> I want to ask about like these different

kinds of PDFs that we see though because there are sort of like modern PDFs quote unquote modern and then there's like really old PDFs. There's just like scans of like crappy documents where you can barely see anything and others are like text readable. So like are you thinking differently about both of those or in the process you have does it work the same? >> So I think the initial intuition for like any parsing is like same for the old PDFs and the new PDFs. The only difference was the type of encodings you get. So let's say the the old PDF has this they've been using deflate and like standard encodings and the new PDFs they have like forms they have like different structural the structural like

hierarchal data structures within PDF itself. >> So it's like more of like you have this initial like version and then you also support like different encodings like yeah and like different compression algorithms. Yeah. Do you in order to create something like ZKP PDF, do you have to build for each of those encodings? Like is that kind of the work that you're like you're looking at all these different kinds of PDFs and you're like okay now how do we deal with this kind and then get it into a format that we can do parsing and then proving.

>> Yeah. So the funniest thing was we thought of like so the initials uh the timeline for the project is like 3 weeks. So we thought well like the parsing logic would be like fairly simple. We could just like import like rust crates and we could able to generate snark pro. >> So famous. Yeah. >> Yeah. So so after a point I've realized the pdf spec is like really complex. I started reading like all the Python C and like Rust libraries in order to make it like compatible with SP1's like CKBR. And the one of the important things I have to keep on like stressing was I can't use like all of this like original crates which are being used in that

library in my library in my crates. So because they have like few other like clean level encoding compression algorithms but I have to implement all of this parsing logic my by myself. So it was really hard currently the parsing library for text it's only has like one dependency. So, can this library take PDF that is pretty complex and just run the part that you're interested in? It takes like I tested with like almost like 15 to 20 PDFs in different languages like Chinese and Japanese as well. So, it was able to pass like all of this text like by page one to page 10. So, it parses by page. So, >> yeah.

>> Yeah, it does. >> And it ignores all the rest of the complex stuff that it doesn't know. >> Yeah. So something like images, something like code, something like that. So for example, does it work on the Digi Locker stuff already? >> Yes, the demo was on DC Locker. So >> that's amazing. That's cool. >> Cool. Are the files that are in Digi Locker though quite consistent? Like is it always sort of forms and templates that look very similar? So it's very easy to like create a very custom ZK PDF system or are those very different? the the format they're using is like pretty similar because the fonts they're being using is like almost all the same. Uh but the famous PDFs is like one is like Aadhaar PDF second is like tax PDF is like PAN card. So the most important

document they follow the standard pattern they use the same fonts and luckily all of these documents are one page. So >> okay not too crazy. >> Yeah. Also they use like RSA and SH 256. So >> things we're familiar with. >> Yep. >> How long does it take to generate a proof for a digil locker search? Even if it's very slow, it's an acceptable one-time cost. >> Yeah, the demo PDF is like PAN card which is used by taxation. So luckily this PAN card is like 104 KB and >> it uses like SH 256 and RSA. So it took me around like 31 seconds to generate a

gross 16 proof >> which is like 21 29 million cycles in SP1. That's like the SP1 prover network. >> Yes. Okay. >> What if we're dealing with like a much bigger PDF? You sort of said the ranges can go into the megabytes. So have you like what's the biggest one you've tried this on and how long does that take? >> So what I did was like I took like one of the Japanese I think Chinese PDF. I signed it myself. >> So I kept like a longer I kept kept on adding pages in that. I think it was around like five megabytes.

>> So it took me around like few minutes maybe like 3 minutes. I'm not sure but like around 3 minutes. Yeah. >> Still kind of manageable though especially if these are like oneoffs like doing this work running this system. Are you you're not running it multiple times, right? You're just you do it kind of one time to parse it to get the signatures you need. Then you can prove what you need about the the PDF. >> Yes, exactly. >> Yeah. If you're using groth 16, the rerandomizing is free and opening certain values in your commitment is cheap. And another interesting thing is the issuer. So the

digil locker signer could also take on the role of producing these proofs for you >> because the threat model is that this issuer can forge PDFs. So >> but they have no reason to do that, >> right? And it can also already see all your information. So since it can forge PDFs, you could potentially use a groth 16 with a designated verifier set to the issuer.

And in this setup, the issuer could very efficiently generate growth 16 proofs for the holder. It's just I think a better threat model than using remote prover because we're not introducing any new trust assumptions besides what we already trust the issuer to do. In this case that you have the issuer collaborating with you though, would you want to produce a ZKP like growth 16 or would you maybe just want them to sign the statement or you want to produce a ZP to keep the same format? Like what was what

is your thinking? >> I'm trying to avoid having to upload my PDF to the SP1 prover network. Mhm. >> So I would like the issuer to cheaply generate the growth 16 proof for me along with the signed document. >> Yeah. I mean but if the issuer is already creating the proof for you, can they instead just sign the statement that you want to show to the third party?

>> Yeah. The advantage of having them create a proof for me is that in subsequent verifications and presentations, I no longer need the issuer's cooperation. Yeah. >> And this gives us the property of issuer unlinkability where >> the issuer is not able to observe how I'm using this credential >> because I was also curious what are other real world use cases that you've seen already beyond digil locker. So for example I think you mentioned on the website docy sign and other platforms do they naturally sign PDFs today?

>> So there are like few different sectors they sign PDFs in general. So the one of the important is like bank statements. So let's say you have you wanted to fetch few bank statements. So generally in India few banks like signs the statements and they send it to you via email. So that's like I'm not sure how the outside like other countries does that. So invoicing is like one of the key areas invoicing and bank statements that is mostly related to banking sector. The second sector is like >> digital identities in general. So there's a PC as well like on the project where they they're like snarifying Portugal digital identity PDF with the same tech. So yeah that's like one of

the use cases as well. Hm. It's starting to have a lot of echoes of like ZK P2P and ZK email. By the way, as you're going through this, I'm just like, it's just like you're you're dealing with a different part of an email or a different part of like an output from some third party to prove something about it. That's really cool. Oh, also I think one more thing I was like forgot I forgot to add was let's say you wanted to prove email attachments which are PDFs you could generate like something like CK email proof and you could generate like CK PDF proof >> and you could like generate like more data statements.

>> Oh it all comes together. >> Would you do them at the same time? Would this be a single proof? What does that look like? I think it depends on the use case we are trying to targeting. So let's say something like I wanted to do like something like CKPD P2P where I wanted to verify this payment was successful. So generally I scrape out the information maybe if I don't find like enough information within email I'm guessing they might send like a invoice or something like that within like email attached.

>> So yeah I'm just like thinking like you're brainstorming. Yeah, >> that that's very interesting because in this case you don't even have to have the PDF signed. You will use the ZK email as your signature and then you would do the rest of the parsing with Zik PDF. That's really cool. >> Oh, nice. >> Exactly. >> Yeah. I feel like that's how docuign would have to work. >> Oh, really? >> Guys, how does docy sign work? Do you know? I'm pretty sure I don't have a docy signing key. Yeah. How does it work? So I did like a little proof of concept with CK email people like back in last last year.

>> So the way we did was like you have any docuign content. So they generally they attach signatures within PDF. Let's say you scrape out all of this PDF information. The the way they does is like they have like chain of certificates like so one guy signs one thing and the second chain of authority signs like a they have like a different key. So they have like a chain of authority from like top to bottom. Let's say you wanted to verify few signatures. You have to verify all of the signatures with the respective public keys. >> So the PC what we did was let's say you have any type of docuign or like ASN like abstract syntax notation one content. So you could able to generate proofs on based on that. So let's say if

the ASN information contains like public key or issuers public key or like some oct strings which is signed by US government or something like that you could verify you could do basically do string matching thing sorts of things like this so yeah >> very cool >> so you mentioned some benchmarks that you've made on PDFs like digil locker and a few others that you've generated yourself and those are reasonable documents that people would want to use in the real world. Do you have any wish list from the ZKVMs that would make your life much easier? Like I don't know pre compiles, proving environments.

The initial thought process for us was like not to use ZKVMs and like use like any client side language >> but we were like forced to build this entire thing in like ZK VMs because the hashing all of the things in mobile or like in browser it's technically not feasible. So in that like we want something like as per the developer experience we want the largest support for like the rust grade which whatever ZKVM they have so all of the rust crates should be compatible not all of the crates the famous crates should be compatible >> so the people who are doing it was like sassync and risk zero it was >> that was back when you started cuz now

there's lots of them >> yeah yeah yeah true >> yeah So am I understanding correctly that the motivation to use a Zik VM was not mainly for the developer experience, not mainly for the Rust compatibility or was it? So the main motivation to build the project inside CKBM was to we quickly wanted to generate like a proof of concept whether this thing works or not and if you see like a good community support we'll try to roll out an SDK and like try to generate the create a setup where we could have like client side provings where you premputee all of the stuff outside the circuit and you could

technically do passing and like selfcorer inside the circuit. So that was like the further re research directions we were like looking into. >> M so do you imagine that if this continues you would still continue with something like a ziki VM or would you consider implementing a whole parsing circuit yourself? >> So there are like few research directions we were like going into. So one of the things is like running CKVMs in inside mobile. >> Mhm. So in within PSC like we have like more pro team like working on that. So we were like still figuring out but whatever like the developer developer experience is really good and as long as we are generating client side pros which

are really important for us we are like open to try uh switch cdsls or like any proving schemes and at all. >> Yeah and if you had like a client side proving zik VM that would be something that would be really useful for you. Yes, we we were like dreaming of that from so long. >> Got it. >> Yeah. >> So in many deployments of ZKVMs today, the proofs are wrapped in growth 16. Sometimes it's for fast verification on chain, right? Are you imagining that this is something that is important for you guys as well or let's say for non-crypto use cases you would be able to have slower verification time for

example. >> Yeah. So there are like two criterias I we thought first was like you have this proof system where which supports like onchain verifiability where the proofs are smaller and you could generate like something like grass 16 and like faster verification times. So the second use cases was let's say even though you don't care about the proof size as long you are generating the proofs are like the proofs are like faster. >> So that are for like especially for web two use cases. So I think for like a the ZK PDF is like currently focusing on onchain verifiability because we wanted to bring a large amount of web two data like data rich statements into like blockchain. So yeah.

>> Okay. So one of the considerations that you have today is like it's it's very understandable that you're in a proof of concept phase and you use a Zikvm and you submit the whole PDF to the prover network but that has some privacy implications and you don't really want to do that long term and I think you mentioned somewhere that you would consider for example proving delegation or using tees in some form. Can you talk a bit about how we would do that? >> Yep. So the two main important things where if we didn't solve I mean if you didn't like pursue like client side proving exploration within CKPDF so the second the obvious direction would be

like something like private proof delegation so or like using something like T. So I think there are like few companies who are like looking into uh like something like provenet something like I'm not sure there's this company called format so they do like private so they I think the inputs are private and they also give you the proof at the end so that's like one direction and the second is like in the t as well we could like technically have like attestations at the end but that's like the not that's not the direction we want to take because there's like a lot of scope in like running CKVMs inside mobile or mobile. So that's like a good direction

we wanted to explore. >> Cool. >> I just want to clarify one thing cuz I think in the conversation like it wasn't entirely clear to me like at present ZK PDF it's a proof of concept like you described. So I'm guessing it's like libraries documentation. It's like a technique. But is it is it currently taking the entire PDF into the ZKVM or because I think Ying Tong you had this idea of like oh you could do part of it offchain and but like what is it today? Is it currently all in the ZKVM?

>> So currently it takes like all of the content as a input. So all of the content. So initially it asks you to select some stuff in the PDF you wanted to generate like you it will ask you to drag some content or like you wanted to prove some content in the PDF. >> So once it verifies this signature inside PDF and then you could able to verify what's the content using like string matching. Yeah. >> And so and what is the project today? Maybe you can also share that. >> So it contains like SP1 circuits. SP1 circuit it has like a little demo where you could like generate proofs on your local. So whenever you set up all of these things there will be like a little demo you where you upload a PDF

>> and then you could able to select few of the contents in the PDF and then you could able to click on generate proof. So it will do like a generate proof with the substring you want to check in the PDF or like which page you want to check in for and then it does like a string matching in the PDF. Is it the type of project today that you are looking for people to build with it at hackathons? Do you want companies to incorporate it? Like kind of what where do you want it to go? >> So for me it's like pretty clear. So I want like ZK PDF to be as something like primitive something like ZKTLS or ZOX which has >> email maybe.

>> Yeah. Yeah. ZK email. So it has like a lot of scope in like proving like larger set of statements inside like ZK and privacy presuming manner. So yeah so in institution level we think of like PDFs are like we want to make this as like some kind of like standard or like some kind of like SDK where people will be using in hackathons this like downloading all of these SDKs and trying to generate proofs. So >> cool. Well I think we've done a good job covering ZK PDF. Thank you so much for sharing all of that. But we're not finished for this episode because we wanted to talk also about ZKID sort of the larger project. And stop me if I'm wrong, but is ZKPDF sort of part of that

ZK effort in a way? >> So the initial ZK PDF project was inspired by like anonadar like kind of projects >> but it's mostly like the same core principles with like ZK team. So we merged like anonadar and zk teams and yeah. >> Nice. Okay. So let's switch over to talking a little bit more about the ZKID side of things. Ying Tong, I know you've been very involved on that side. At the start of the episode, you talked about kind of the thing that got you excited or interested in this was the European Union's digital identity effort. Why did that interest you? And I think I have most importantly and this is a question I've I've been curious about. What is

the connection to this EU like ID and the Ethereum Foundation or PSC or any of these kind of efforts? >> So there is no official connection between the Ethereum Foundation PSSE and the EU commission. >> Mhm. However, the EU digital ID wallet has set forth a list of highle requirements and these will be widely deployed as soon as 2026. And because of the far-reaching scope of these requirements, we are very interested in making sure that our solution conforms to these requirements.

So we can understand the EU digital ID wallet as a set of guidelines that inform the direction of the ZK ID project. Yeah, I think what got me interested in it was first and foremost the flaws in the existing design. >> Okay. >> Um and >> you saw it was problematic and you had some ideas on how to fix it. Yeah, there was document by this consortium of concerned cryptographers pointing out to the EU commission that their solution was not unlinkable and was in fact fully linkable by both

issuers and verifiers. And so there have been many efforts to address this. I think the folks from Google have a very good solution. Longfellow ZK and I know they were on the podcast as well. >> But is the is the EU's effort is it similar to having something like ADAR is it trying to emulate that the Indian system or like what is it actually? >> Uh it is very different. Okay. Um so the main point of difference is the requirement for device binding.

>> So it is not sufficient to have a static signed document on your phone and make proofs about it. You also need to prove the live possession of this device at the time of verification. >> So you'd have to be doing constant face scans or something. >> So it's something like that. Um one example it's a highly interactive process. So one example is the verifier would send you something like a session nons a challenge and you the holder you would sign this nons with the secure element in your mobile phone >> and the public key of this secure

element had better match the one issued in the credential and so this interactive process achieves device binding This is a requirement uh in the e digital identity wallet that is not present in say an ader zk passport itself. >> M yeah I'm just trying to think about how to even approach something like that. >> It is quite different even if it's slightly subtle. It introduces a interactivity and verification time and it introduces reliance on secure element.

>> Is that interactivity one of the main critique points that was raised or is that a good thing do you think? So this interactivity is necessary to achieve the device binding requirement and the motivation behind it is to prevent transferring credentials. So if I made a proof on my phone and sent it to you via email, that would be of no use to you because you wouldn't be able to sign a fresh challenge with my secure element.

So what do they want instead? >> So this livveness, this interaction device binding is just feature of the EUI wallet and it's not going anywhere. What the cryptographers had originally proposed was replacing the salted hash design, the very naive selective disclosure design with something stronger. um such as zero knowledge proofs something that would actually achieve the anonymous credentials primitives.

>> Does this derive from the earlier work that I think was in the ITF around verifiable credentials or is this a distinct effort or how does that look like? >> They very much point to earlier efforts both in the IETF and the W3C. >> Yeah. So work around verifiable credentials as you said and two very common formats are SDJet selective disclosure JSON web tokens as well as MDL mobile drivers license >> and under the hood they look very similar they use salted hashes primitive

>> and I think one of the goals that you mentioned mented in your talks was it's being part of the cryptographers feedback that they're requesting and what is the feedback that they're requesting like what what are the things that they're interested to hear? >> Yeah, the EU commission has this open discussion on GitHub inviting feedback from interested parties. very often they are seeking just cryptographic expertise.

It's very practical needs. So they want to know how long this proof will take on an average mobile phone, how large the proof will be, how much storage is needed if there's proven keys involved. >> Mhm. >> Yeah. They want to know what issue or behavior needs to change if any. So it's very much as cryptographers about communicating your knowledge in a practical way that's actually helpful >> for policy makers and for developers.

>> Are they open to these proposals that involves EKPS? Like is that actually something they want or is that something that just kind of came up through this call for feedback? From what I've seen, they are open to zero knowledge proofs. I think this effort by Google Longfellow ZK is one of the leading um >> options. >> The other camp is a primitive known as BBS signatures that have been around 20 years.

>> Yeah. >> And both approaches have their respective tradeoffs. Um, but I think after the cryptographers feedback, there is very much the acknowledgment of the need for a stronger privacy. That's cool. That's actually kind of amazing to hear the reverberations of that Google, you know, inclusion of ZK. Just the fact that they that Google has taken a chance with it and and has decided to to build it into one of their systems. It's such a I feel like it's such a stamp that governments can now look for and be like, "Yeah, well, Google used it, so maybe we can try it." I sort of wonder if it would have been included before

that or without that. I think very much like demonstrating a large scale deployment, it makes it very compelling case. And I think another factor is standardization. When you're working with these like state level entities, they are looking for primitives that are well understood, battle tested, well specified. >> Cool. And what is the timeline for the effort? You mentioned 2026, but what does that date mean?

>> Oh, that's a good question. So, I've heard that the 2026 rollout will in fact be the original Salt and Hashes design. This is just because of time constraints um and because they haven't picked zero knowledge solution yet. >> So I've also heard the suggestion that the 2026 rollout be limited to a specific class of use cases that require no privacy. So for example, getting married, you need to tell like everything uh to the registration authority anyway. So I've heard this

proposal to limit 2026 roll out to use cases with no need for selective disclosure. >> And this would be a way to test out the larger infrastructure, you know, key management. There's many many other issues to solve besides zero knowledge proofs and then this would buy us time for introducing zero knowledge proofs and stronger privacy in see 2028. Interesting. Does any of this have like you think of Europe and you think of privacy and then you think of GDPR and some of the things the previous efforts is this related to that effort? Is it

meant to sort of like yeah interact with those laws? Do you are you thinking about that? >> That's a good question. I'm by no means an expert on that. I can say a lot of this um digital ID is motivated by age verification laws >> um that are coming into effect in many places both in the Europe and the US. But yeah, it is interesting that the EU commission in their high level requirements have put down very very strong privacy requirements. So unlinkability >> for instance is enshrined in there >> and that is why the cryptographers

feedback was so damning >> because it showed the failure to abide by their own requirements. >> Wow. I'm curious what your work is with this. So it sounds like I mean thank you I want to say thanks for sharing with all of us kind of what's happening on the EU front their requirements some of the critique but yeah what are you doing and like why is there the ZKID effort there are you building products that sort of emulate some of the things they want are you proposing are you just interfacing with them yeah what's that connection >> yes we are building a proof of concept that we want to be compliant with the EU dig digital identities high level

requirements and furthermore we are involved in a wider standardization effort for generic zero knowledge proofs. >> So this effort really is motivated by the need we see for a credibly neutral implementation and standard underpinning the digital identity infrastructure. Hm. You mentioned sort of the difference between this effort and things like self and raro and one of the things you highlighted was the interactivity. Are there other differences between like what you're working on in terms of a proof of concept and what they have?

>> I would say that is the main difference proving systems maybe. >> Yeah, I did this survey of ZK ID and ZK passport projects. I would say most of them still use groth 16 >> and then the only one that doesn't is uses nor. But yeah, we are using a different proof system. We're using Spartan Hierox and we chose this because firstly and mainly it gives us randomizable commitments and so we can preserve the pattern of precomputing large part of the proof and then secondly

it we don't need pairings so we can pick more convenient curves and fields. So we had the circom implementation of ACDSA verification on P256 that is just native field and then behind the scenes it uses like Hyrex on T256 which is like a curved tower. >> So the T256 scalar field is the P256 base field. M and the issue with pairing friendly curves, I think you mentioned somewhere that this is something that would be less acceptable or is it or is it something else?

>> Yeah, this is the main hurdle that the BBS signatures have faced >> is that they would require the issuer to do operations on pairing friendly curves. And in other words, this requires the issuers secure element to support pairing friendly curves. >> Uh and that's a big hurdle, >> right? Because secure elements have very specific curves today. >> Yes.

>> Okay. >> P256 is no problem. >> Is wanting to be postquantum also one of the reasons that you're avoiding that or Yeah. Is is that factoring in? Like is that are are people even thinking about that? Yes, I think it's come up. I'm not sure if it's appeared as a requirement, >> but yeah, my understanding of postquantum is that it is absolutely crucial when it comes to encryption and less so when it comes to authentication.

Mhm. >> So I think NIST recommends that for encryption use cases we switch to postquantum now whereas for authentication we can switch when there is a cryptographically significant quantum computer >> and maybe standards are a little bit more sure. >> Yeah. Yeah. >> Interesting. >> So other work that you've done as part of this effort is a lot of benchmarking and you've tried many different proof systems. I think I've seen Binas and you probably have tried Blancfellow and and others Fl I I I would guess that you ignored for

other reasons like the deployment considerations what was guiding you in those benchmarks. So our colleague Alex published this benchmark of the SHA 256 in postquantum proof systems. Um so we didn't include long fellow there because it wasn't open source at the time. >> Uh but I can say long fellow is by far the fastest. >> Okay. >> Um yeah and the second is Benny's. So yeah, it is always a good question that of what to benchmark. I think basically there's two kinds of designs

for a ZK ID wallet. The first is something like Google's wallet which computes the whole proof at presentation time on the fly and they can do this because they have a very fast prover. >> Mhm. The second approach is our approach which is to premp compute most of the proof and then do a small linking proof at presentation time. And the benefit of this approach is in the case of multicredential presentations the increase in prover work would be marginal. Mhm.

>> So in our design paradigm, it makes sense to benchmark only rerandomizable commitments. So right now we're using hierax. I think an interesting research direction would be aai commitments. So let us based commitments >> to retain some structure in the commitment scheme but also get a postquantum alternative. >> What did you call that? Antai.

>> Yeah. AJ T ai atai. >> Oh, I don't know if I knew it. >> It's used in lettuce fold. >> Cool. Is that acceptable enough when compared to pairing friendly carbs? So the problem with BBS signatures was it ch the the signature itself >> required an operation on a pairing friendly curve >> whereas in our case the issuer could still sign an ACDSA >> which I will point out is not postquantum but the point here is we would avoid having to support pairing friendly curves in the secure element.

Yeah, that's a good consideration and as part of the work you mentioned that standards are really important and that's part of the work that you're doing. So what kind of standards have you worked on? I think there was the work around the polinomial commitment scheme standard and that's part of this effort or is it a more general thing? Yes, the polomial commitment schemes standard is one of about four documents we're working on. My colleague Janabel is working on IOPS or actually IS interactive oracle reductions.

>> Um and we have another colleague Mcklli. He's uh working independently on Fiat Shamir >> Mhm. >> transform and then some of my former colleagues from uh Zcash are working on arithmetization. So they've actually written up a lot of the plunkish proving system in lean. >> Oh, cool.

>> But yeah, they're also targeting IETF. So yeah, the vision here is a modular approach to specifications. >> This is definitely less straightforward than say specifying your whole protocol end to end in a self-contained document, >> but it makes more sense for this space. It sounds like >> yeah I think from what I've observed many projects do want to retain this flexibility the ability to swap out polomial commitment scheme but I will say that for any low-level optimization

you have to break abstractions and so there are also many cases that do not >> fit neatly within our abstraction. >> So what should people keep an an eye out for? Should they look for the implementation with Spartan and Hierrex? Should they try to contribute to the standards? What what should people think about? >> Yes, they should look out for the implementation for sure. All this is open source on our on the PSA zkid repository and when it comes to standards absolutely the more the marrier. I think

standards efforts predominant failure mode is just a loss of momentum. So in particular this modular approach still requires multiple concrete instantiations. So the modular PCS spec would still benefit from specifying fry, specifying hierarch like just illustrating how this API can be instantiated. So I would encourage anyone who's interested in the standards efforts to contribute a specific instantiation of some proof system that you're familiar

with or you want to learn about. >> Bringing it back to the ZK ID project and the proof of concept and everything. Is this a client side project? Are you moving sort of the proving and everything closer to the user's device with this or is it still living kind of further on a server because you mentioned you're not using the pairing based stuff and and I know that this is changing but like I've always associated the pairing based stuff with the client side. So yeah, I'm just curious how how you're thinking about that.

>> This is absolutely a client side project. Um, okay. So, the holder of the credential should not have to reveal it to any third party besides the issuer who already knew it. Um, and the holder should be able to generate proofs about this credential independently on their device. So yeah, I think Longfellow ZK is a good example of something that runs very fast client side without using pairings, just using hashes. And yeah, I think for ZKID specifically, it's usually small circuits. Like even

though we're doing SHA 256 that it's not nearly as complex a circuit as ZK PDF and yeah, the sizes of the credentials we're dealing with do not approach anywhere near 500 kilobytes. Um yeah so yeah it is very much this application is the scope of it is client side. >> Cool. I want to ask about the concept of revocation in both context in the zk ID that we just talked about but also in zk pdf in zkid because I have had some of the other ID projects on we we have touched on some of the problem space

there but let's start with that. What are the issues and how are you thinking about them? And then after that, I want to I think we we're kind of curious if there's any revocation for CKPDF. Yeah. But let's start with the ID. >> Yeah, revocation is definitely a tricky one. I think right now the best we can do is to make proofs of inclusion in a white list or exclusion from a blacklist.

And what this does is it puts a an online requirement on the holder who's generating the proof. And depending on the size of the white list or blacklist, this could have repercussions for proof size for storage of course and almost for frequency of checking, right? Like cuz if it revocation to me is like say you lose your passport, you lose your ID, you lose your phone, you lose a thing and you need to take it off that list. It's almost like okay but when does that list get updated? When does whatever's kind of verifying that update

itself as well to match it? >> Absolutely. I think a lot of this update window can be decided by the verifier. So, let's say your verifier is the bouncer at a nightclub. Maybe maybe it's okay that your proof of revocation was updated last week, let's say. >> Yeah. >> Um >> or last month. >> Yes. Whereas, if your verifier is your bank, >> you should update the proof of verification link live. So I think there's a lot of interesting research to be done here.

For example, optimizing the generation of this inclusion or exclusion proof, how to cache, how to have smarter data structures that require us only to download like some delta, some bridge of the set. Do you also imagine going past just the whitelist blacklist concept and doing something else? Because I mean you what you just described is kind of the simple form, but I feel like even in some of our conversations, there's been at least some ideas for for other things.

>> Not that I'm aware of. I saw this new paper called ZK Promises. >> Oh. >> Or you could call it ZK callbacks. The concept of it was almost like a call back. H >> but under the hood it pretty much is a livveness requirement on the prover to check the status of their credential at some regular interval some call back interval. >> Cool. >> Yeah, I would be very interested to hear about other approaches to revocation.

We'll add those those to the show notes. The previous interviews all about the ZK idea. I feel like it's come up a bunch of times. That's cool. What about CK PDF Vikas? Like first of all, do you ever need to revocate and have you thought about that? >> So, initially when I thought of revocation, the initial intuition was like what if the documents expire? >> Oh yeah, >> maybe something like expires after X time stamp. >> So they don't really have like user side revocation. They have to do like a issuer side revocation. M >> so in this case issuer holds the power not the user so I was thinking in that direction but yeah >> I almost wonder with the PDF where it's

like there's also kind of a lack of power by the user in this case like what if there is a document but you for whatever reason want that document to not be part of your file or whatever like you want to get rid of it you don't want this you want to destroy it you kind of can't it sounds like like the issuer has the control and >> so that's like a similar threat model with all of the passport as well, right? So the issue is like technically the government. So in other it's government is passport is like the country government. So yeah, >> expiry is also subtly different from revocation in what you describe like you could think of revocation as let's say invalidating it before it expires. Let's

say you committed a crime and the government says I I will now revoke all your diger searchs. Can it do that? It seems like no. >> So it it can >> interesting. >> Might be a problem space to explore though. You're right though, Ying Tong, where there's a difference because if there's an expiry date, that could actually be like it's predetermined with that document. You can I'm assuming you could like actually code that somehow. You could say like this will no longer be valid after date XYZ. But yeah, if you had to do it before, you'd still have the proofs, >> right?

>> Yeah. And and there is no currently public nullifier list of the PDF documents, so you know, >> maybe there will be. >> Cool. Well, I think that's a cool place to to wrap up our discussion. It sounds like a little bit of an open problem there, too. So, could be interesting to think about. Thank you to both of you for coming on the show, sharing with us ZKPDF and the ZKID efforts coming out of PSSE. Yeah, thanks so much. >> Thank you. It was a pleasure. >> Thank you.

>> I also I love how this conversation also kind of like went into like I feel like it touched on a lot of previous episodes that we've had over the last 6 months. Like it's kind of a bunch of things are tying together. Now ZK ID is like one of the biggest possible deployments of ZK. >> The culmination of ZK. >> Totally. >> Yeah. But I don't know for me like age verification it this is like I don't know one level down like even that premise is very scary. Like you sprinkle ZK on it. I think it does not make it that much better. Like a little better but >> I don't know. ZK ID makes me existential for that reason. I'm like, "Yeah, but

it's ZK, but like what are we using it for?" You know? >> There's definitely two sides cuz you're going to be part of a registry. But you I mean, we are already IDed on some level if you want to move from place to place. You need to have your passport and stuff like that. >> Yeah. But they're trying to gate access to like YouTube in Australia. >> True. >> To under 16s. It's crazy, >> by the way. I know that that's like that's like very contemporary. I have this weird feeling that's just not going to work.

>> I I I because I think I think people like just I think it's just not going to work. I think that's like a proposal they're trying. I think I don't know. I think it's going to fail. >> I want to say thanks Kobe for coming back on. I think it's been like over a year since you co-hosted. So I'm Is that possible? >> Yeah, I think that that makes sense. And yeah, I'm very very happy to be on the podcast again. Good. I'm just It's really cool to have you. I hope we can do another one very soon. Thanks to both of you again. Thanks, Kobe. I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Kai. And to our listeners, thanks for listening.