Episode 362 - zkTLS with Maddy from Reclaim

Transcript

[Music] 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. [Music] This week I chat with Maddie from Reclaim about the topic of ZKTLS. We discuss how he started working on the problem that is central to ZKTLS that is proving something about info displayed on websites or other online content in a secure but private way using ZK. We cover some of the earlier research on

this, the implementation attempts, the limitations they faced, and how more recent breakthroughs in ZK allowed this technology to become performant enough to be used in the real world. We discuss the different techniques used in the reclaim ZKTLS system, the different levels of security of these systems, and other trade-offs to consider when building systems like this. We wrap up the conversation covering tangible use cases for ZKTLS and how this helps to break ZK out of the web3 bubble and introduce it to the larger online world. Now, before we kick off, I just want to highlight our upcoming ZK hack Berlin event. It's our fifth ZK focused hackathon. It's happening on June 20th to 22nd in Berlin. This is part of the

Berlin Blockchain Week. And so if you're looking to jump into ZK and build using the amazing tools we sometimes cover on the show and win prizes while doing so, be sure to join us. You can apply and find out more info over at zkerlin.com. Hope to see you there. Now, here is our [Music] episode. So today I'm here with Maddie from Reclaim. Welcome to the show, Maddie. Anna, thank you so much for having me. A big fan, big fan of ZK podcast. Um, whenever I I feel like like I want to feel stupid a little bit, I probably go back and listen to your

podcast. Like there's so much information on ZK podcast pretty consistently. Um, so it's it's it's yeah, it's amazing that uh you're doing this on a regular basis. Thank you so much. Oh, you're welcome. Well, thanks thanks for being on. So yeah, this episode I think what we're going to be doing is jumping back into the topic of ZKTLS. We have touched on that. I don't know if we called it ZKTLS when we talked about it, but we have touched on like similar concepts in the past. You know, recently I did some episodes on like ZK email and with the like the the projects that the cursive folks are doing all dealing with like web two to web 3 kind of proving something about web two to web three or websites. And I think that's probably what we're going

to be digging back into today if I'm right. If I remember correctly. No, no, absolutely. I've heard the uh episode with Aush on from ZK email. Uh he's he's wonderful. We work very closely with him. Cursive guys as well. I think you had uh the ZKP2P guys on as well. Yeah. So, yeah, it's a small almost a ZK podcast mafia that's beginning to form. Uh so, yeah. Uh true, true. Very honored to be here. Yeah. Cool. Um but yeah so I think as a starting point do you want to share a little bit about your background and specifically how did you discover this problem space for sure um I think we'll have to roll back a little bit uh to answer this question in the specific so in 2020 uh we had launched this

product called Questbook right so Questbook even today is like one of the larger uh grant management platforms out there so arbitrum compound ENS all of these guys use Questbook to give out grants um as soon as we launched in Late 2020, our first customer was Polygon, right? So, Polygon back then was of course very very hot. A lot of developers started applying to these grants. One thing that we heard again and again was, "Hey, we want to apply to these grants, but we want to apply synonymously." Uh, and the grant managers were like, "Okay, fine. These people are claiming they worked at Microsoft. They have contributed Ethereum, but how do we know for sure because these people are obviously not revealing their identity, right? So that's kind of the problem uh that you know came our way almost serendipitously and the initial solution

that we had it was called questbook identity like it was a very stupid solution. The solution was you just dox yourselves to us and we would pass on the information to the grand managers. So basically you be the third party who proves you are who you say you are. Yeah. Yeah. Exactly. Right. So that was obviously uh not a good solution and and of course I was aware of the existence of zero knowledge proofs as a uh as an industry. So I started diving deeper into hey can we solve this problem using zero knowledge proofs right um and it was in a conversation with Eli from starkware actually uh I was discussing this you know zero knowledge for identity and stuff like that he mentioned uh hey why don't you try to generate these zk proofs from https

certificates it should be technically possible um and that is what led me into this rabbit hole in all fairness like uh this was 2022 early 2022 yeah And the Deco paper obviously had come out in uh 2020 I think. Uh I was not aware of it. Uh I discovered the paper um only in 2022. Reached out to the uh authors of that paper uh Deepak in specific and uh we tried to like hack around uh a few prototypes using Deco itself. Honestly, we couldn't get it to work because it was like computationally too heavy uh following the exact specs that were written out in Deco. But one thing that was interesting is in the deco paper itself like in the appendex there's like one paragraph that says maybe you can

get a bunch of optimizations if you use a proxy right and that is where we were like okay there seems to be something that we could try uh try next at least and we tried to prototype that and that worked uh although back in the day um in 2022 it used to take like 15 minutes to generate one zk proof on your mobile phone um but at least it worked at least it worked um over the next few years it's just been about optimizing optimizing optimizing. That paper Deco it's been cited a couple times. Um what year was that actually released? I think it was 2019 or 2020. Uh not 100% sure.

Yeah. But that sort of makes sense that like the kind of concepts that they're working with at that point might not be like I mean in those years after that was published so much research so much optimization to happen just in ZKPs in general. Um it makes sense that maybe like nowadays it makes more sense to implement it. Yeah, I think I think two or three things happen together. I think the uh group a group that published the uh Deco paper had previously also worked on something called town crier and probably also something before that uh basically trying to solve these same problems using different tools. I think town crier was using tees to solve the same problem. Uh so I think that there was that trajectory that was already ongoing but around the 2019 2020 uh time period uh zero knowledge proofs also

kind of matured a little bit and the tooling around it mature a little bit. So maybe they took another stab at it uh using zero knowledge proofs instead of TES. Uh so that that thread is like a long uh long thread. Yeah. Uh and and in fact the first idea pro at least that I know of was by Dan who is now a tails notary. uh he put out a post on Bitcoin talk back in 2013. Wow. Uh uh but that was nothing to do with T has nothing to do with Azk proofs in particular but at least the concept was the same like hey can we use the HTTPS certificates to prove the authenticity of certain data coming from a source. So interesting it's it's a long thread of events that led up to uh what we able to do. That

first implementation though is that using the HTTPS certificates or is it using a different part of the website at that point? No, no, it always had to be the HTTPS certificates because that is that is the one thing that is going to tie the um data to the source. That's the only thing rather in the HTTPS thing that can even broadly u map it back to the source. Um so always it has been using the HTTPS certificates. Are those certificates like do they have a structure like signatures? Is it like a signature of the page? Actually not.

It's a symmetric key right at the end of the day. Uh so it's this okay fine you you use the HTTPS certif or the SSL certificate to derive a symmetric key. Now this symmetric key is what is used for the encrypted uh requests and responses on the HTTPS connection. And the the key problem is that this key is not asymmetric. It is symmetric uh for reasons um that we can dive deeper into but largely to do with the the optimizations that are possible on low-end devices. Right? So symmetric key is what's important otherwise it won't work on low-end like IoT devices and stuff like that. So it uses symmetric key but the problem with symmetric key obviously is that you cannot tie it back

to the source. What that means is let's say I open google.com and we have a symmetric key I have a symmetric key with google.com. Uh both me and google.com have the same symmetric key. So we are both encrypting using the same key and decrypting using the same key more or less. So it is impossible to say if there's a piece of encrypted data uh it is impossible to say whether Google encrypted it or did I encrypt it. Ah right. So that is the the challenge that's the the provability challenge uh that we had to overcome. That that's what ZKTL is is all about. Right. Okay.

Fine. We have this encrypted channel already. Can we use the same cryptography that's already being used uh in this HTTPS connection to add provability on top of the the data that is being transferred? I think that's the problem that ZKTLS specific tries to solve. What are you like so you're kind of saying though you need to show like it would be bad if two entities could have created this or could have somehow been behind it. But like if you're using one of these SSL certificates like what's the problem if two parties could have written it like why are do you do you need it to come from like one party always? Yeah. Okay. Let's probably take a slightly different example not

google.com. Uh let's say citybank.com. Right. Okay. Now on citybank.com what I'm trying to prove is I have a bank balance of whatever $10,000. Right. Now, if that is a claim that I'm making to you, like Anna, as a third person, I am claiming that, hey, look, this is the data that came from citybank.com and it says I have $10,000 in my bank. I I show that to you. There's no way for you to believe this because you don't know was this encrypted by citybank.com or was it encrypted by me myself, which makes the whole exercise like uh meaningless, right? Because if it was just by you then you could have just made it up, encrypted it and said like this is proof but you want to know that it was encrypted by them I guess. So what HTTPS uh is trying to do is make sure that I

am connecting to uh the actual citybank.com and there's no man in the middle or some stuff like that happening. So that is what HTTPS actually tries to solve for. But it's not useful if I am uh producing this as a proof to a third person. Uh like if I'm giving you this uh encrypted data, I'm saying hey this is the encrypted data that came from citybank.com. You can also see that okay this is uh being encrypted by a key that was derived from the correct SSL certificate. Even that is not enough because uh even though it has been derived from the correct SSL certificate, you still do not know whether the data itself was encrypted by City Bank or by me which makes the entire proof kind of meaningless. H so how do you work around that? Yeah, so

there are uh multiple ways to work around this. Obviously there are two modes in particular that I'll probably touch on, right? The first is the proxy mode. The proxy mode is what we have in production right now. Uh what we do is whenever you're opening citybank.com uh instead of routting the uh data packets directly to citybank.com we say hey we're going to route it through an HTTP proxy right this HTTP proxy is going to look at the encrypted data uh in the request and the encrypted data of the response and give an attestation right okay this is the data that I actually saw transfer over the wire in in this specific direction and once I have that at a stationation then I can generate a proof on my end that hey this

is the data that exists in this encrypted uh packet and it was actually the packet that came in this direction attested by the proxy. So you okay now you know that hey uh Maddie is not just claiming that this data has uh so and so information but we also have an attestation from the proxy saying that yes this was actually the uh data that was transferred over the wire by citybank.com. Okay. I have I mean I I want to hear the second one and then I have I and then I want to dig in a little deeper to some of these and see if I can break them a little. But yeah.

Yeah. Cool. The second mode is uh called the MPC mode which is actually what the original deco paper was and it's also the um implementation by TLS not uh that's the most popular uh implementation out there. And what they do is when you are establishing this HTTPS connection, you have to do this TLS handshake right after the TLS handshake is when the symmetric keys are established. Now the claim uh that TLS notary and uh the MPC TLS makes is what if the user never knows the key, right?

So that's an MPC protocol that executes on behalf of the user. Mhm. You do the TLS handshake and you get a a symmetric key but that symmetric key is a part of it is with the user a part of it was with a notary and only both of them put together can either encrypt or decrypt data. Right? So now you can say that hey whatever encrypted data I am revealing to you is actually correct because it was a process of the MP like I do not have the key myself. So there's no way that I could have generated that uh encrypted packet myself without colluding with the um the the notary.

Interesting. So does that make sense? I'm happy to but there's there's something you just mentioned that I think we should define as well which is like that TLS handshake because I think you're making an assumption there that like I know how TLS works perfectly which I don't. So okay sure. I think the MPC part actually makes sense, but it's the part before like why why does the TLS notary why is its kind of like part portion of the MPC so provable? I think between that and the symmetric keys that's the part that I don't quite understand in the MPC mode you have to trust the TLS notary. It's a trusted party. So in the defy helman key exchange now that's a random that is being selected by the client as well as

the server and then they do this diffy helman key exchange and then come up with a key. Mhm. Now to overcome the problem that I should not have the key myself at the end of this procedure what I would do is the random that is being selected is being selected through an MPC with the TLS notary. Right? So I do not know the random the TLS notary does not know the random in full. uh we both know like parts of the random and only when we work together will we be able to determine what the entire key is. This is the other side. So like together you become the client. Yes. Together we become the client. So this converts uh and that makes you trust like but how does the TLS not I still don't

understand where the TLS notary is like even getting into this flow. Yeah. So what while doing the TLS handshake itself? So the server is going to be doing the TLS handshake with a client quote unquote a client but the client in this case is going to be a combination an MPC of the browser as well or the user and the TLS notary. Both of them together are one entity that are going to be participating in this TLS handshake and u both of them have parts of the key. So whenever you're going to send an encrypted request, both of them have to work together to create a request and when they want to decrypt a response that came back from the server, they have to work together to come up

with a response. And you just mentioned so the TLS notary site is is trusted party. So because you trust the TLS notary, you can trust that the client has not acted inappropriately in like signing that that is their bank account. If we go back to an example, the the way that TLS notary that specific project uh approaches this is the verifier itself. Uh let's say you want to verify whether I have $10,000 in my bank account. You would run the notary yourself. Oh, okay. So that that's kind of the architectural assumption that TLS notary specifically makes. But then there are uh other projects that build on top of TLS notary which provide this notary as a service almost. M so you can trust the uh entity

that is providing the service offer notary and you don't run it yourself. Okay. Interesting. Okay. So those are the two modes you mentioned the proxy mode the MPC mode. Before we go back to those two modes I I think I want to hear a little bit more about your story because in the story you were telling the last we heard you'd implemented Deco kind of just seemingly for fun I guess. I don't know if you were doing it as a prototype but yeah what happened in your story since then? So yeah uh look so Deco it was not like for fun per se but we were trying to like improve our uh identity solution that we had. We were trying to see if we can avoid the developers who are applying to these

grant program to not dox themselves even to us right so we didn't want to um be the custodians of uh their identity so that that's kind of the motivation. So Deco was a serious attempt to try to solve this problem using zero knowledge proofs. Okay, that that was our motivation and as I was saying the initial implementation uh just couldn't work like it was the NPC mode. So we couldn't get it to work at least uh using the specification that was there on the deco paper. We implemented the proxy mode that worked. It used to take 15 minutes to generate this proof. And from 2022 through to probably early 2024, we've just been optimizing, right?

Trying to get that number uh from 15 minutes as low as possible. And finally, in early 2024, uh that proving time came down to about uh 2 seconds on the latest iPhone and maybe, you know, five 6 seconds on a mid-end Android phone. What did you have to pull out of Deco and replace it with? like I'm curious if it was like a different proving system. Was it using any of the work that's come out since then? Yeah, the of course I have to uh admit that we are standing on the shoulders of giants here. Um a lot of lot of things contributed to this. Uh the the first is um initially we were on circom we moved to Narc that gave us a lot of improvement but that was also

still not not like uh all of it. The underlying systems also like narc also improved circum also improved. So we got a lot of those benefits. Uh but the the thing that we had to really optimize is what is the minimum amount of data that we need to prove so as to prove the authenticity of uh the the data that we are revealing. So let us okay so in specific what that boils down to is let's say you open city bank's web page. Now, City Bank's web page probably like a few KBs in in length, but all of that is being sent as packets in 64 bytes each, right? So what is the smallest amount of data um that we need to

decrypt so as to it contains the required information and doing a lot of engineering to make sure we are generating these zk proofs on as little data as possible uh was uh probably another major source of our optimization. So instead of generating a zigz proof on the entire you know 100 KB uh response that is coming from citybank.com uh we are probably now just uh doing this operation on know 128 bytes of of data but was that a generic answer or was that like specific to like specific websites like were you picking websites and then optimizing for them for their case this is just like how websites work or how websites is it like website

types? No, the these are completely independent of the website itself. Uh so there are two major implementations uh which are AES and uh cha 20. So these are the two uh encryption schemes that are uh popularly used in HD and they're also part of the standard. Um actually I should mention that another big performance boost we got was using Chacha 20 instead of AES. Right? So initial implementations was using AES. Uh now we move to Chacha 20 which is also supported by like most of the uh websites out there. But uh again to your particular question this is not uh website specific at all like all of them adhere to the HTTPS standards because you know uh those are the standards

otherwise your browser will not be able to render them. So we built a solution that works now for both AES as well as uh Chacha 20. Cool. So this is completely agnostic of the website. Nice. When did the when did you found the company? itself. Was that at the end of that journey in 2024 or was it like at the start? No, it's see that's a tricky question. Uh the company itself was is it a project? Is it a company? I mean it's the the the company is the the same entity that built both quest book as well as uh reclaim protocol. So the company technically started in 2020 I guess. Okay. So it's is the same company that now has like two product lines. Uh nice. What would you say reclaim is today? Like so you talked a lot about

these kind of implementations but when you talk about a product like this is this a library tool stack interface is it like what is it something that an end user would ever interface with or is it like really more for devs what is reclaim yeah I I I think I have a hot take here uh that is I think zktls itself is already commoditized right so it's it's an open- source library whatever that that resides underneath okay fine you can now generate proofs from any website um which which is over HTTPS. So that that's great. Now what we are building as a company is uh verticalized solutions on top of this.

That is uh we in fact right now counterintuitively are seeing a lot of traction from the web two world. Sure. In the web two world people need to verify stuff like hey um what's your education history? What is your employment? Uh what is your financial background? Uh stuff like this. So these are like the three main categories that we focus on and building a verticalized solution just for these three use cases because when we are selling to let's say web two enterprises they don't really care about ZK what they care about is uh hey are you solving the the problem that we have and they need a full stack solution and that is what I think we are increasingly putting our focus on is

there a full stack solution for education employ uh education verification employment verification financial background verification that that that's what um I would say the product itself is now interesting what like in each of those cases though I I think of examples and even actually the original case you used of Chase Bank all of them require a password to get into or like there's a payw wall there's like a block they're not just like automatically served websites where you just like are browsing and you land on it because that that example of where you're just like seeing something. It seems really intuitive about how you would prove that you're there, that you saw it, that something's on that website. But if you have to log into

something like how would you as a external kind of partner or product like see into there? Oh, so um the user obviously has to log in into the uh required system. If it's education, you need to login into your university. If it is uh employment, into your payroll system, whatever, right? And our product that we uh sell to these companies is an SDK. Now this SDK pops up in our browser. Okay? Right? And that is the browser that we control. And all that this browser really does is instead of sending the request directly to the website, it routes it via uh HTTP proxy.

And once we able to do that, we get the attestations. And if you have the attestations from the proxy, you can generate a zero knowledge proof on the client side. Hm. I guess if you're selling B2B, this kind of makes sense. So, it would be like the I'm just trying to picture who this is. So, like if it was the employer, they would have access to this salary portal or something or some sort of employment portal, they would log in, they would use your tool to prove something about what's inside it. But if it was an individual who was like, I want to prove that I work there or have worked there or like maybe use a bit more of a general example. When I thought of employment, I thought it was like your LinkedIn account or something like that. But like yeah, maybe just

explain that flow a little bit more clearly. Yeah. So let's take an example of a job marketplace that we're working with. Now on this job marketplace, you are saying uh hey, you've worked at Microsoft, you worked at Google. Okay. Now, if there are people who are hiring you based on the experience that you have uh listed on this job marketplace, how do they know for sure that you actually work there? Yeah. So using uh you could add a button that says okay it says Microsoft on my profile and there's a button next to it that says verify. Now when you tap on that verify button as an individual this this pop-up comes up. You log into your Microsoft payroll system and we can generate a proof that yes you were indeed paid by Microsoft in the last 30 days and and send that proof to the job marketplace uh server. They

can verify it and give you that check mark or something. Oh, cool. I like that. So it is it's the user it's the individual potentially not like the employer it's the individual who could be like proving this about themselves but using one of these tools and I think that that that's also the reason that uh the product is called reclaim protocol is because you know historically or rather the the incumbent way of doing this right now is in the US the monopoly is with work number uh by Equifax. So you as an employer would hit up work numbers database and ask the question hey is Maddie employed at uh so and so uh and it would respond yes or no without any user interaction and the

assumption over there is uh Microsoft is sharing the data of all its employees with the work number and they have these deals uh and that's why that costs uh anywhere between $40 to $120 per verification right uh and that is exactly what Our market opportunity is that is we go in and say, "Hey, these verification don't need to cost so much. The user could prove it about themselves." Wow. And you could do it for like pennies. Yeah. Interesting. Okay. I want to go back to your So, cuz I think we dug into a fair bit of like the MPC mode. There was like a few questions I had on that proxy mode you had explained earlier. I do want to understand though with that MPC mode, is

that sort of the the future step? because it sounds like you first tried MPC then decided nah it doesn't work let's do proxy but are you planning on going back to MPC? Uh that that's kind of an open question at this point. Uh so in production right now we are on the proxy mode. Okay. Right. So internally we keep uh prototyping the MPC mode because there are like uh better trust assumptions on the MPC mode and there are like a few other uh optimizations that are possible in the MPC mode. But the problem right now at least from our internal prototype so far is it takes about 30 to 35 seconds to generate a proof and and much worse if it is on a 3G connection or stuff like that which which is where a lot of our users are.

So that does not work for us in production but uh credit where it's due that's also like fast moving. So in fact uh TS notary recently made a a major improvement with this implementation called quicksver which which improved it significantly but still not good enough for you know a web two use case where it uh anything more than like a second or two is too much friction in the web two world. Yeah. So it's I don't think it's production ready at least for our use cases at this point. But we do keep a close eye on it because there are some benefits that we could get if that proving time al if today you say hey both of them take exactly the same amount of time I would pick MPC. You

would pick NPC. Let's talk though about those security assumptions like proxy mode like kind of going back to what what exists today. You walked us through it. So you're using a proxy who makes an attestation. One of the things I thought as you said that I'm like what happens if the proxy gets corrupted or like who is the proxy like you know who controls this thing. So yeah, dig in a little bit to the proxy and also why do you consider that like a lower security degree than MPC? Uh from from that particular lens that that's that's not where the security uh differences are whether it is uh the proxy or the TLS notary the trust assumptions are exactly the same that is the okay uh notary and the proxy both of them are not colluding

with the user to help generate these proofs. So in in that aspect it is absolutely identical the trust assumptions the place where it gets a little tricky and this is more practical than than theoretical is now if the data is being routed through a proxy to let's say citybank.com now citybank.com is always going to see that all the requests are coming from this particular IP address. Oh uh and no most likely this IP address is uh that of an AWS server or something like that right and know cloudflare and all of these firewalls actively block out requests that are coming from AWS so if you're using the proxy we need to do one more step that is after the proxy there's going to be a residential proxy uh layer

so that uh we are able to mask the IP address of the uh AWS server and that is where the trust assumption comes in that is you you need to trust the residential proxies to be not compromised. Uh more more than uh the the security trust assumption. I think it's it's not the neatest solution, right? Like uh that's like one more entity that not only you need to trust but for for security reasons, but you also need to kind of rely on for the functioning of the product itself. In the in the MPC mode, what is it? Cloudflare. And so what do they see for that? They they don't see everything coming from AWS, I guess. Oh.

Uh, on the MPC mode, the nice thing is, uh, all of the data will appear to be coming from the, uh, user's IP address itself. IP, which is what you want, which is what we want. Yeah. So, it sounds a bit like the proxy mode. You're kind of maybe in the style of like ZKP2P has done where it's like you're relying on a system existing as it does, but you're also kind of working around the web two entities that are kind of trying to actively block like a actions like what you're doing. And so inevitably there'll be like a cat and mouse game that you're kind of playing against. Uh it's it's kind of yes and no. The reason that we would get blocked by a cloud flare is not so much that the the servers don't want us to do ZKTLS in specific but it is more of all

these bots that try to do DOS attacks are usually you know AWS farms or something like that. So that is what they're really trying to defend against and we get kind of caught in that uh blanket protection. Yeah. What did you call it? You said that this there was this other proxy. What did you call it like residential or Yeah, residential. So, so is that something that lives closer to the bank's interface? Is it on a different server? Like why would they why would that allow this this sort of message or this these things to go through? Yeah. So, residential proxy the way that works is anybody in the world can you know join this residential proxy system and route uh traffic through it.

So, think of it like to right. Right? So anybody can spin up a to server uh at at their on their computer on their phones or whatever and now data is being routed through uh their IP address. So a residential proxy has just like created an IP address. So it doesn't look like it's an IP address that uh yeah that belongs to a consumer device in specified. I see. I see. Is it yours? Like would you be running that potentially? Uh potentially yes. Uh so this is still an open question. I think that we are still trying to figure out whether we want to invest in owning that residential proxy layer ourselves but that is also subject to the question around does the MPC mode get off fast enough for our prod. Yeah. Yeah. So we

don't have to. Interesting. Cool. Um I'd sort of asked a little bit about this like could you corrupt the proxy or like could the proxy be captured? I do kind of wonder like is maybe maybe the proxy doesn't get captured but like could like you talked a bit about this like proxy and then the re residential proxy which gives you an IP address but is there like ways for something to get in between there like just the fact that there's these hops like does that actually offer like more attack space it it it does it does and so there are two attacks that are possible the first attack is a DNS compromise so the proxy itself does rely on using the correct DNS server for facilitating the requests

and responses. So there is a uh an attack called the ARP poisoning attack in which basically says if you have physical access to the proxy while it is booting up that in that small window of those few seconds there is a possibility to do an AR poisoning attack and like corrupt the DNS that it is uh using for this procedure. Right? So that that is an attack that is possible. The second attack uh that is possible is something called the BGP hijacking. So basically all the TCP requests that are uh routed over the internet use something called BGP roots. Now every node on the internet kind whenever you're sending a

request to whatever website citybank.com it's anyway going through like six or seven hops before it reaches citybank.com. Now how does the packet know which route to take? that is defined by the uh BGP route. So each node knows where to send this packet so that it reaches citybank.com at the end. True. And there is a way to quote unquote announce. So it's called a BGP announcement saying that hey the route to citybank.com has changed because let's say the transatlantic wire broke right. So you have to now take this new route. So that is the the use case for the existence of a BGP hijack sorry the BGP announcement. Okay. Um and so BGP hijacked. Yeah. So you could use that

BGP announcement to say hey instead of rooting all of these packets to the actual citybank.com route all of these traffic to this fake citybank.com. Uh and that's like proof here's a proof and so on. uh uh there are a lot of nuances to like actually pulling off this uh attack but it's very very impractical like there there are two things I would just like highlight on why we we consider it impractical enough to bother about it is number one is BGP announcements usually take several hours to propagate okay throughout the entire internet um and even if they do propagate most of the uh important nodes in this uh route uh only accept

announcement from trusted sources. True. So it's very very unlikely in our uh in our kind of use cases that we have to bother about this problem. Like people are trying to prove that they worked at Microsoft um to a to a job marketplace if they are willing. Yeah. If they're willing to do a so nation state level attack to uh hijack the BGB. I mean um seems extreme. It seems fair enough. So you you probably need to be uh a state actor to do a BGB hijack and it has happened in the past just to be uh completely fair is there was this uh BGB attack I think through the state actor in in Russia in which uh a bunch of nodes in the on the roots were compromised and yeah some some attack

happened. I mean, I think it's worth mentioning this, too, because like, yes, the use cases you've talked about don't seem like highly sensitive, but if technology like this gets propagated and used much more, you could see it starting to be used for much more sensitive information or or like Yeah, if you're what you're always trying to do is prove something about something. So, like massive fraud, maybe becomes worth it at some point. I think I think there there's always going to be this trade-off between user experience and uh security. And my take is if there are use cases that are very sensitive to these kind of attacks, I think it might be worth spending 30 seconds to generate the proof instead of 2 seconds. So you

could just use NPC for that. Yeah, fair enough. I I'd asked you a little bit about how the user kind of gets behind the payw wall. You'd said like, well, you do have to log in. Is there ever like login information that's flowing through something there? Like is there any sort of information leakage possibility like or are they just logging in themselves and then making the proof? I'm just wondering if they're going through any other kind of application or something that you're building. No. Okay. No, no, no. So this is just a a web inapp browser and they are logging in into the regular browser just the way that you would log into a browser. And we obviously see none of that data. The only thing that we see is the encrypted request and the encrypted

response. I see. Um and just just to be fair for the listeners uh is there's a trust assumption. There's a trust assumption that we have not added any backdoors inapp web browser so that we can get access to your to your login information. uh but the code is open sourced and uh it's been audited and there and also to be fair there is a lot of restrictions that is imposed by uh the Apple and Google you know SDKs itself so there's only limited things that we can do but yeah there is a trust assumption that the SDK that is being used is not sniffing for um any of this information cool I have one more question here which is about the website itself I I always thought with this like

I and maybe it's because I have a bit of the ZK email mental model where it's like ma it's like you're looking at exactly how an like an email is formatted and then grabbing information from that and I realized with ZKTLS it's not because it's more to do with like that SSL certificate and it's like more about these sort of like a code that's attached to the website it's not really about the website itself but I did have this question about like what happens if a website changes or if the website gets corrupted so maybe we'll start with like what if the SSL certificate changes I guess And does that does it matter the SSL certificate even if it changes it will also be changed on the certificate authority. So uh we we can always verify that this SSL certificate it belongs to

this particular domain name as of today. I think that that's a that's a slightly different problem that I think ZK email has in which the I think it's called the DKM keys which get rotated over time based on the formatting I think often isn't it? Yeah. So, so in in DM uh certificates or DM keys always uh get updated I think every 3 months or something like that and once it has been changed there's no way to go back and check if is the DM keys that belong to that actual sender but in ZKTLS we don't have that problem because we're trying to check the certificates as of today not in the past so we don't have the problem even if the uh SSLs change anyway that brings us to the second part of the question which is what if you know something changes on the email for

Zik email's case And for the website on our uh ZKDLSS case there it is a cat and mouse game that is you need to make sure that you are always using the latest uh response types that is coming from that from that website. So if that changes you need to quickly adapt and uh say that yeah the the website changed and now here's the new configuration on how to generate a proof. Okay. So given that it it poses a big challenge for pushing this into production. So there are two approaches that we take. The first is uh we try to use APIs. The APIs change much less often. The UI might keep changing like once in a while, but the APIs don't change as often. Okay. Uh but that's not

to say that never change. They do change sometimes, but at least it's like far and few. And that's one. The second and uh this is the more ambitious uh effort that we are um undertaking is we have an AI that automatically figures out Yeah. it automatically automatically figures out that the you know website has changed. Uh we know that until yesterday we were able to generate a proof from here. So we know the structure as it was yesterday. We know the current structure. So the AI is the AI knows what you're trying to find and then looks for it again in a way. Yeah. And and creates this configuration on the fly uh and then generates a ZQ proof for it. So interesting. I I would say this is where we have the edge right now in the sense like I'm not I'm not talking

about it from the competitive perspective but we have the uh the ability to be able to sell to a web 2 enterprise because stability is extremely important for them. Uh so not only are we saying that hey these websites APIs don't only change very infrequently but also even if they do change we have this AI mechanism uh that will uh quickly fix it on the fly and your users will not be affected. Um this makes me think though like when we talk about those different websites we've talked mostly about the SSL part of things like just the certificates but you are always looking for a particular type of information as well like you're not just proving oh I've logged in.

Yeah, I have a relationship with this bank. You're trying to prove a number. Yes. And so how do you initially like do you have to go for each major website portal? Do you the company reclaim have to go and like kind of understand the APIs of all of those beforehand before a user can actually interface with it or is it the minute someone tries to engage with the system it sort of maps it? I guess with the AI it could map it but like init like right now how are you doing it? I I have to give you a very nuanced answer to this. There are multiple um multiple takes here. The the short answer is yes. For every single website you need uh what we call a provider uh that needs to be defined for that website. Only if there's a provider

we can generate a zk proof for it. Okay. So the short answer is yes. We need to go figure out the provider for each of these websites. Um, of course you can't go do this at you can't do it as as an exercise for all the websites in the world. So, uh, okay, answer number one that I have for this is we've built something called a dev tool uh, in which you're not dependent on us uh, to add this provider, but anybody in the community can go and add this provider themselves and we have like a pretty elaborate tooling for that. So, that that that's answer number one. The answer number two as you pointed out is using AI and the AI of course theoretically speaking it should be able to figure this out. It's a it's a problem that I do suspect will be solved very soon but as of today it's

not good enough. So we use these AI systems only in the three verticals that I mentioned that is education employment and financial background verification. So because we know very specifically that for education you need to accept this this this is what web pages usually look like. So, we're able to like really fine-tune our, you know, prompts or whatever to uh make sure they're able to uh get high enough accuracy. But for an open-ended program, I don't think the AI is there yet. Got it. And that's why like even the example you had initially given was like in that case like you already had some sense for the template or whatever like the the API is supposed to work like and then the AI could go in to like understand the change but it's

quite defined. Yes. Um and now and and you're saying if you focus that AI on the three verticals then it's doable but if you try to go outside of it with current capacity or current it's also I feel like it would get really expensive at some point. Okay like at this point let's ignore you tried to map the internet with AI. Yeah. Yeah. Let's ignore that uh cause for a moment. But I think uh yeah, as you mentioned uh as long as the problems are more structured in the sense that you know it worked till yesterday, now it does not work. That's a very structured problem or we are looking only for let's say graduation year or something like that.

Very structured problem. AI is really good at it. And just just to like double click this is something that is working in production like right now. It's not not in the future. Uh the open-ended AI is what is probably in the future in which you give it any website and say hey extract so and so information it automatically tries to figure out how to do it. Uh I think we're a little bit far off from that. Uh we we have internal prototypes but that's like at some 50 60% accuracy which is okay whatever. Uh but for education employment where it's very structured we get like 93 95% accuracy. Cool. I want to move on now to some of the use cases. you've you've mentioned the ones that you're focused on, but I actually like just looking at some of the material that Reclaim has uh

released, I also saw, you know, an overlap with DeFi, talk of prediction markets. You you mentioned like very nonblockchain use cases in the form of education uh proving something about like your employment history or credit score, although I feel credit score could also be somewhat on chain. But yeah, let's talk about all these use cases. What's the focus right now? And do you do you actually see this as sort of a blockchain like a web two to web3 product or is it more like a web two to the world product just proving stuff about websites? I I think I look at this as know one of those technologies that crypto is exporting to the world, right?

Uh I think I feel so not specifically for ZKTLS but like ZK in general, right? I I don't know if you saw the news. It goes beyond. Yeah. Yeah. Like Google Wallet now has integrated uh ZK proofs uh to you know show your age in the bar or something like that. We may have we may or may not have them coming on the show soon. Okay. Awesome. That that's little little alpha for the listener. Yeah. Awesome. Yeah. So, okay. I I have an interesting anecdote here. Like we have been talking to a lot of large web 2 enterprise like these are Fortune 500 companies. Now, my job in all of these sales cycles is to go whiteboard with their engineers and teaching them ZK.

Like uh I should probably just introduce them to ZK podcast maybe. But I'll keep that in mind next time. But but my job is to just go educate that hey ZK is a thing. It it looks magical but it it actually works. Uh and those those are conversations that I was having for like weeks at at these enterprises and the moment the Google announcement came out. uh send that blog to all of these people that I was talking to and immediately see yeah and and doable yeah from a business standpoint those sales cycles have visibly uh progressed the the question that they were asking even like one or two days before that announcement are very different okay now they're like

okay fine okay we get it zero knowledge proof work now how do we uh implement this it's also very I mean it's such a it's such a validation in a way like it's a vetting yeah just the fact that it's been like kind of it's passed through all of those checks in such a big company. Oh, that's so exciting to hear. Yeah. So, so coming back to your uh original question on um the the use cases, right? So we are right now focusing as I said on those three verticals as as a solution offering and then we ask ourselves the question hey um who are the people who need these three offerings and right now our focus is uh again on three verticals that is job marketplaces background verification companies and uh lending. These are the

three categories that that that we work on. Um and this is although wait didn't you say education too? You didn't list that. Oh yeah. So, so we do education verification, employment and financial background verification. So, those are our product offerings and the uh use cases that we are going after are background verification, job marketplaces and lending. That's where this data is actually being used in that sense. Understood. As as I was saying, this is like I look at ZK as a way to like export whatever we've invented in the blockchain space to the world. So we internally at the company we do not have uh any categorization as web is this a web two company or a web three company.

We we care about hey is this in the lending space like we work with web two lending uh companies we work with the web three lending like 3J for example is a web three lending company. Uh but from an internal ops perspective they're the same like for us it's a lending company and they need very similar kind of data. they need uh know credit scores, they need income verification, they need a accredited investor status uh stuff like that. So it's the same set of information that is required for uh use cases across the board whether web 2, web 3. So we don't distinguish between that internally. So but yeah, these are the three verticals that we go after agnostic of web 2, web 3. Very cool. I want to talk quickly about the competitors because I feel like there's been I mean so the team that I feel we

did the sort of deepest dive into this topic with so far would have been Pluto and this was like a while ago and they are they're web proofs are similar to what you're describing. Other competitors that I've seen listed would be Opacity, Primus Labs and ZK Pass. Maybe there's others as well, but I'm just wondering about that like competitive landscape and how you see yourself differentiating if you also see them kind of aiming to solve similar things or different things. Yeah, to be fair, I think the from a technology standpoint, all of us are trying to sell the same problem that is, hey, how can you make uh data over HTTPS verifiable for for us, I think the most important thing that I think at at least from the outside what it looks like is we are

focusing more on web 2 enterprises as compared to the others a little bit. So we are I think building very verticalized solutions. Again going back to my uh hot take that is ZTL is already commoditized. My view is there's no business to be made at the ZKTLS layer itself. You can't sell ZKTLS and make money because it's already commodized. Like uh if nothing else like we are open source, TLS notary is open source. I mean it doesn't make any financial sense to uh you use a service that is actually charging for that service. Our take internally at the company is uh this technology exists as a base layer but the question becomes what is the vertical solution that we can actually provide uh to web to enterprises that

they can plug and play into that services and it needs to solve the use case work very very specifically like something as stupid as uh being able to retry by sending them an email if something fails no like those are like things that a web two company would care about. um and being able to do that and also the AI system that I'm talking about. Okay, fine. The ZKTLS thing exists, but do you support all the 25,000 universities that exist on the planet? Um if not, I can't use you. Like it's it's no use going to a job marketplace and saying, "Hey, we can verify if the student went to Stanford."

Wow. That's not helpful. But nothing else. Yeah. Yeah. But nothing else. Is that true? By the way, that fact is 25,000 universities worldwide roughly. Oh, interesting. Cool. Uh, at least that is the amount the number that we have been able to support so far. Cool. Wow. Amazing. Right. So, and the same is true for like the number of payroll systems. Of course, they're not in the order of uh tens of thousands, but maybe, you know, 5,000 6,000 payroll systems at least 200, you know, tax portals. So, having that verticalized solution, I think, is extremely important. And I I I I I would really wish that not not just our competitors but also crypto as an industry uh would take that more seriously. That is okay fine you're

solving this problem with a particular technology but it's not really sellable unless it's a verticalized full stack solution and we can't just like test our hands off saying oh we've built this amazing infrastructure layer built the infra yeah yeah go figure out what to do with it. I think we the story of this industry like yay. Yeah. We have to be extremely opinionated about um so for example like we we know that there's one more category that we care about which is loyalty uh and like shopping history of of users and stuff like that and we explicitly had to say no to that and saying okay we know this demand exists but we're not going to focus on it because we're focusing on um

verticalizing the products for these other three. Um I think that is the kind of discipline that is required to make this happen especially in the web two world. Yeah. Cool. So you know you you talked about using AI with ZKTLS in order to define some of these websites but could ZKTLS also be used in AI? Like could you use any of these tools to sort of prove things about what is happening within an AI platform? Or maybe you don't need the website stuff for that.

I'm almost like bordering into ZKML here but yeah I I I have a broader take on this which might answer your question. Look ZKTLS is a stop gap solution. Uh that is we want to verify information but right now uh there are no asymmetric keys that are being used for providing this information over the internet. So we have to like almost figure out a way to come around it. In an ideal world, um you would have all of this data being signed at source, right? So whether it be there's an RFC called RFC 9421, I think uh which is all these APIs should uh respond with a header that that also gives the signature of the data that is

being sent. If that exists, then the ZK proofs are very very simple to uh create on the client side. Uh but but of course there are a lot of uh reasons why it's not being implemented already. uh but that that would be the ideal future. So now coming back to your specific question uh of how do you prove uh that an AI is operating correctly? There are two ways to do it as you mentioned. One is ZKML which I think is like honestly uh very very far from being uh practical. The other is using the ZKTLS on the HTTPS connection that is used for the API calls so that you know at least that it's coming from from cloud and not from that specific thing. Yeah. Yeah.

for that you could surely use it. Although you can't look within the model with that you're just sort of saying like the call is coming from there. Yeah. At least you can trust that this came from cloud and it's not something that you you've built yourself even on that. I'm not like super bullish on that either at this point because there's already this effort inside the AI circles to know add digital signatures to the responses and in fact it's already been launched and you don't need it. Yeah. Okay. It's already been launched on claude like uh for for not exactly the uh inference itself but at least for the chain of thought reasoning uh they have a signature that's already coming. So that's awesome. Yeah, I I hope they do the signature for the uh final inference as well very soon. But

that is what I'm more bullish on. I think before ZKTLS scales on all of these API requests like at global scale uh I would expect OpenAI uh Claude all of these people to just add a signature. Yeah. And okay probably this a good good way to like end this is if we do a phenomenal job uh over the next 5 10 years we will make ourselves irrelevant. that is if we've done a good job at making the case that hey the the users data should be provable um and if we've made a case for that very strongly people will probably just start signing uh data at source thereby making zkls itself kind of uh irrelevant and we can

just uh go on to the more fun parts uh upper uh further up in the stack. That's so interesting. I I love this kind of it's sort of doing a bit of a throwback to what we were talking about last year with like a tested sensor data which was very real world but this would be like signatures on websites, signatures on sort of these portals or whatever. So that it's it's serving the same purpose. The minute you have that signature is the minute you can do more advanced cryptography on the thing without having to do these workarounds to transform it into a state where you can do the advanced cryptography on it. Yes. Yes.

Fascinating. the cryptography will probably still have to be the uh the same, but uh the trust assumptions will be much stronger. It'll be much more efficient. Yeah. Amazing. Maddie, thank you so much for coming on the show and sharing with us your journey into sort of the ZK TLS world with Reclaim, how it's been used, but also just like digging in deeper to this topic in general. I feel like for me it's been a little bit of a black box until now. So, yeah, I really appreciate that you that you helped to sort of open that up. It's a big honor for me to be in the position to like help you navigate some concepts in this space where as I I use the podcast to navigate the space myself.

So, thank you so much for having me. Sounds good. All right. I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Kai. And to our listeners, thanks for listening. [Music]