The Cryptography behind zkTLS - Xiang Xie - zkTLS Day @ Devconnect 2025 (Buenos Aires)

Transcript

Okay. Um hello everyone. My name is Sean from U Primary Labs. So yeah, this talk is about yeah a little bit about like cryptography behind DTS. But yeah, I'm not going too deep in that part because too complicated and I'm going to show something like maybe new in this space about how you like extending zls to other like tools or like applications. Uh yeah, I think uh like Thomas already like introduced the background of TTLS. So essentially like enables uh the problem that you want to like the client to prove that they have actually have some data from like web two servers without changing or modifying anything

about the server side. So this is the uh this is the uh most challenging part because if you want if you can modify the server side just sign everything and uh it's done. So yeah, so that's why we focus on now uh on TLS. So like 1.2 or 1.3. So the the the one of the main like uh uh standard use case is that can I prove to another person that I have enough like ETH in Coinbase. So this is kind of kind of like a very standard use case. Um yeah, a little bit don't be fed about this kind of cryptography side. uh a little bit about uh uh TLS because we're going to show why it's important like we choose this kind of technology there. So

essentially like TS has two part. The first part is handshake mean that the client and the server have to uh negotiate with a session key. So it's kind of like um keys change and after they get the same like key material they have to expand this kind of keys into a very long key like session key. And the second part is the record phase means that the client the server who has a symmetric shared key they can communicate encrypt and decrypt with this symmetric key to uh you know uh send and send message and receive messages. So essentially that we are considering this kind of like KDF key expansion or as GCM these two parts. So why I'm saying this thing is that yeah

just one single like they look like this way is all I'm to say that they are very complicated and another thing that if you are familiar with ZK so these kind of things functions are building circuits so which means that all existing like ZK stock is not like flex it's not that suitable for this kind of circuits so that's why we in a lot of cases we don't want to choose like existing in zigs. So we have to develop a new text to make it much more efficient.

Uh sorry. So yeah uh there's like like actually three modes but I don't know I don't want to talk about TE right now. So I'm not I only talk about like NPC or proxy. So that's very simple uh like uh uh differences between these two modes. So like MPC means that the client or fire or like uh uh uh the the tester they act as a TLS client by running this C two PC protocol like MPC protocol and the proxy model is that the verifier sit between the client and the server. So all the traffic goes uh goes from the verifier to the server. So these are the two main differences but yeah but we

have different uh like trust assumptions and we have different performance uh in these two modes. So essentially just very simple like uh uh uh explanations of this. So when you're using MPC so why is so expensive because you have to run like two pieces between the verified client to uh can compute these kind of uh kick expansion circuits as circuits and at the end of this computation you also has to run zero proof systems to run that to prove that the KDF and AS runs correctly. So it's kind of combination of like NPC and ZK steps. So it's it should be like very

expensive and very like uh inefficient. So like the very original like deco paper. Oh yeah, I think that's a very nice paper. So they kind of use a very complicated like authenticated GA circuit or zig snacks. So it's it's quite slow. So you can have like memory problems like uh communication problem problems. So uh one of our contribution is that okay we improve that by like more than 10 times faster like using much more simpler circuit and quick server. So everybody is using quicks right now but quicks is a a zero food system but it's not like zigg snacks.

I'm going to introduce a little bit later but the thing that for MPC TLS these are the two like the the most expensive part so we are like trying to improve that part and uh so in the MPC part so what's the most what's the bottleneck of MPC? So we're kind of now using gober circuit. I'm not going to introduce what is gober. It's kind of like a two-piece pro two-piece protocol. So they have few features. First of all that cost around which is is a benefit because uh you don't need to care about more about the latency and um the second part is that for every

single booting circuit like end gate or x or gate you have for one end gate you have to send like um two uh 256 bits to the to the to the verifier which is very which is very very very large and um In our paper I think it's the the most efficient one that for one KB request you have send like more than 20 23 like megabyte. So this is actually the main bottleneck there here. So essentially like in your like uh real applications the uh bandwidth is very small. So you have to send a lot of like data there.

And uh for the proxy there is a lot of like ways you can use a proxy mode and it's very simple. So first the verifier get all the cy text between the transcripts and then the prover the client just prove in zk that I know everything about them. So this the the the the framework is very simple but the details we have a few like applications we have few like choice there like in our gazen proof we prove that the KDF and as from the very beginning. So this is okay because quick server is very efficient in proving like booting circuits. So it takes like less than one second to prove that and like different versions like maybe I think uh reclaim

they're now using like prove as using stick not using gro. So it's kind of like maybe you have a few like memory problems uh when you're proving like a large content and also they have want to use to like um a recursive proof that so it always has like uh performance issues in the pro side when we want to generate with dy snacks. So that's the problem and um why quick silver is so good for details because quick silverware is interactive gener system. So interact means that you have to the prover have to interact with the uh the the verifier and uh it's not public verifiable. It's

not but it's very suitable for this case because in zls it's not necessary to be non interactive it can be interactive and as I said before for kdf and as using zig snack is very very efficient but they're all booting circuits so we can use the quick server to prove it very very efficient and um there's no memory issues there is no like proof size issues and even you can run everything inside uh chrome extensions mobiles very single like uh uh uh you know uh sourc limited environments. So that's why we choose like uh interact zk or like why that's why we choose like quick server.

So here's kind of numbers. So like when you proving like n gates you can use like less than $2 to prove one trillion gates. So it's very very cheap. It's it's super cheap and you also can prove like arithmetic circuits but in zigas you don't need to do that. So and we have different like versions to running different like paraphones and it's that's that's the main reason we now want to use quick receiver and they actually have a better version right now maybe.

So let's forget about all the details. Let's talk about that the comparison of these two modes. So first of all let's uh take a look at the efficiency. So of course proxy TS is much faster because there's no like MPC things which is the main bottleneck of digs. It's much much faster more than 10 times faster and um for the trust assumption there is a there's there's different first of all you have to trust the server otherwise there's no way you can solve this problem. And um yeah there's always a assumption that there's no collusion between the client and the verifier. So that's the main problem I think all of the projects want to solve and we have

some solutions I'm going to introduce later and uh for the proxy TS there's another like assumption means that the verifier has to ensure that he's connecting to a server otherwise there is kind of in the middle attack. So a mic a malicious a malicious uh a malicious client can then sit between here. So it's like the client talk to himself and he has a private session key then he can like sign everything. So this is the major like I think uh transumption and the the debate on how to choose NPC or proxy model of these two of the two

ways. Um so if you are not proving that very sensitive data and you are care about the performance maybe you can choose TL uh proxy policy TLS because it's kind of harder that you the for the for the for the client to sit between you know to to uh to u process this kind of main middle attack and uh there is few uh performance numbers. So actually we have a paper about that and u we uh experiment do the experiment that uh for like in in in 18 uh like uh areas that we show that all these kind of MPC tests can work well with quick silver it's there's no like

timeout issues and also we push the limit of using proxy TLS that we can prove very large content like 200 kilobytes image that is actually generated from CGBT in under like two minutes maybe. I think it's much uh uh faster right now using like bronzing stations. So that's why I think in using like server you can prove very very large like content and I don't think I don't think we can do that with zigns because you always have like memory issues there.

Um also we yeah we do have new ways to improve the whole improve uh efficiency like garber circuits. So the main bottleneck of garbber circuit is that you have send a lot of like message to the to the to the verifier. So we have a new paper what we call bit GC mean that you only need to send the five bits which is which is like 50 times fast uh smaller communications but it's not practical right now because the computation time is very slow. So we only have like 55 end gates and now using the original GABA circuit we can do like 10 million end gates. So it's kind of very impractic right now. And we also have a nin non-interactive version

of P server. We call it NPC in the nerve. It's kind of version of MPC in the head. So you can see it as a non-interactive version of P server with the same performance. So this means you can make the proxy TLS line interactive and then you can reduce a lot of like five to six four to five runs in the MPCTLS. So it's kind of ongoing like work we're going to like deploy maybe in the next year. Um also yeah I I want to in our in our uh actually there is kind of uh requirements from our customers and there is kind of I want to show that there is restrictions of these two modes

especially for IP restrictions. So in a lot of applications when you like connect to a server there is kind of like IP restrictions for that server side. So in the proxy model the IP is always from the proxy. So be careful. In some cases the data sources will block it if it's not from the real users. And for MPC if that depends on the phone uh of your product if you are running a chrome extension so it's the IP is still from a proxy. The reason is that like standard chrome or saffrey there's some set the raw AP uh TLS API there. So you have to

use like a proxy to initiate the TLS session. So there's kind of be careful about that. But you are running like a customized browser or you run it in the back end. So it's okay because the IP is actually from the from from the client. So this is actually some restrictions we got from our customers. So when you like deploy your product service to be careful of this kind of uh uh IP restrictions which is very important and uh yeah here goes to the I think the most interesting part is the collusion of clients of the tester or malicious testers because

all the existing like ziggles solutions actually uh doing this way. So the client prove to the verifier or the notary or the tester that he has some kind of data. After that the verifier will issue a test tension which essentially like a signature or that. So which means that the verifier or the tester had a secret key. They can sign the attest tension. So if the verifier is kind of malicious so they can sign everything. So if you're using zigs to secure fund so be careful that who who is the a tester because otherwise they can just sign

everything and get the money back. So in all these cases now a tester is too powerful and um especially when you're using them to secure fund then it's is very dangerous. So we need decentralized the testers. So that's the main problem we want to solve and we try a few solutions. First of all, I think it's similar to like um to maybe uh reclaim their their solutions. So yeah, we can we can like we can have multiple testers. So if the client want to uh do this ticket as proof, they actually do uh one ticket as proof with each test

and um as long as the majority of the test sign okay is okay then you get the like uh uh uh the the the the valid attestation. But there's a few questions there. First of all, so you have to run multiple times of DTLS which means that the performance is like uh the number of test times fast uh slower. You have to run like independently and the second part is that this is not suitable for like frequently change changing data because you you have to spend some time to run the DS protocol. So during this time the data may change. So you don't know which one is the which one is the the correct

one. So this is not very like uh practical in in in real use cases. So we we explore that but it's not like quite suitable for our cases. And the other part is that it's kind of uh theoretically it's kind of perfect way means that we also have multiple test test there and uh when the client talk to the test they actually run MPC means that there is like fire party they run a five party uh uh computation protocol to uh just like it's a extension to the two PC protocol and this is theoretically doable we actually

have algorith doing try to explore the performance there. But the the the the issue is still like the performance very very bad performance for like it's like 10 times the number of tests times slower in terms of computation and the communication. So uh in high probability it going to be like timeout of the data session. uh theoretically it's doable but in practice is very very hard for our fast to deploy. So when you try these two things so okay how to solve that maybe the thing is that we use TE.

So we actually build this network and it's already alive. So first of all we put all the testers in TE which so means that there is uh you cannot do bad things inside TE. Second thing that we are not running like MPC or something that we are using blockchain we're not deploy on base. So there is kind of smart contract. So every single user want to use this kind of TS service they go to the blockchain and a smart contract we are randomly select one of the testers and then you run the executive service there. So in this case

it's is it's not just simply put your tester codes inside te there is kind of more like requirements of doing that. So first of all even the manager of the testers cannot get the signing key. So they cannot see anything about the signing key because otherwise they can sign anything they want. And the second thing is that um they has the ability to deploy multiple instance without changing the signing key. This is the most difficult part of using TE because the original TE actually generate the uh the the the secret key in the hardware. So when you deploy mod instance the key will change.

So this is uh in in order to like to enable one a tester can deploy multiple testing multiple instance without changing the signing key or the address. You have the support inside the TE here. And um also you need to a very strict like uh version control to make sure that okay even a third party who is deploying this tested a tester software they have to be strictly like follow the open source code uh in case that they can change anything and they can do bad things. So the challenge here is that we need properties of TE to uh we need uh TE to support this kind of properties we

can make this network to be secure and now yeah we have a solution that we use for D stack. So this stack support all of these features and is open source and you can deploy in different like T like providers. It's not just like uh Intel or something or other like uh uh uh uh uh providers there. So we're using like combinations of the stack and our proxy model, MC model to build this kind of like uh zig test network. So this makes sure that okay we can bring in third party testers. Yes, that's what we are now doing. So we are calling call for testers. So the goal is that we want to

build a more decentralized network and the good thing is that if you if you can be one of the tester we uh like we can share the revenue of the network. We now 80% of the network fee goes to the testers and the 20% of the fee go to network. So this means that you have the chance to get the revenue to cover your cost when you're running the TI. So we now have a few like testers like succinct or fella. So we are now like talking to more like a testers that it can uh uh ask the uh testers in the network to to secure the network. So that's that's our solution for make it like more decentralized.

Yeah. So yeah I'm going to something new right here. So I think people did not mention about this is that in real applications TTLS is not enough. It's not enough at all. So [snorts] why so let's take a look at like a test tension here. So essentially like you have a lot of URLs means that what kind of data or the the source of the data the the the the link there and you can use sticks prove like you have different data here and also you have address and signature this kind of very standard like a test tension uh when you're like uh doing this uh uh

selective like disclosure. So the thing is that in the test tension the data is public and um there's a there's there's no very efficient way or very like developer friendly way that you can do further computations on that. I think Thomas also mentioned that you can like do uh actually in the paper we had do like you can do like hash or you can do like different like uh uh commitment on that. But when you are thinking about this very complicated like business logic, quick server right now is not enough because we do not have a VM and when you goes to the uh like real applications you have

to handle circuits using quick server which is not developer friendly. So can we the question is that can we combine zigls with other tools like zm like mpc that we can extend this ticket part the data verification part to a computation part so that's the thing we're now doing so we came up with this new thing about what you call data verification and computation mode especially that not only that you can authenticate at the source of the data and everything is private in the test station and you can also do more computations and for any

kind of customized functions. So this is the thing we want to combine together. This is actually needed in the real applications not just like authenticated some kind of public data in the in in a data source. So this is what we're now uh promote to our customers and it's already deployed by our customers and also we have a few things about this like combined with MPC and combines with FH stuffs. I think Dimmetry is going to introduce more details about this. We have a paper about this. But the thing I want to choose I want I want to say is about how to combine with like ZKVM or any kind of ZK DSL you can com can use.

So in our network you can actually using inigs to uh generate this kind of uh a test tension and all the data is actually hashed or commit me committed by using hashbased commitment here and um you can also apply you know different ZKVM or ZKDSL to um customize your own logic business logic. So in this program you have to uh prove three things. First of all the signature there is valid.

Second the hash of the pentext is valid and also you have to prove that this kind of data actually satisfy the customized function or customer logic. You can define that you can use zkm and use dtls dsl sorry to customize the logic. So this is kind of a new framework we we we came out that we we we when we talk to our customers they actually want this part because the logic is always hard is always very complicated. It's not just comparison. It's not like just like very simple like addition. It's very complicated functions here. That's why we like we we're going to like use these kind of things for more like uh new

applications there. And we now support uh we succinct they have a private proven network using KVM and also we have supported like a new executive VM. I think Michael going to talk more about this uh this afternoon and we also have like a techno to be integrated and this is collaborating with like hashok so it's it's already open source right now. You can actually in general you can combine any kind of new like zks or zkm to zk ts together to this dvc like mode and uh yeah this is also like one of challenge in our tutorial if you want to try. So we have like uh very detailed

steps to help you to understand and to build this kind of new things. Uh so at the end I'm going to like showcase some use cases using this DVC mode. So a very standard use case is that we actually provide this privacy preserving proof of reserve for stable coin projects uh to prove that they have enough assets offchain like in a centralized exchanges. So why dest? So the first yeah first of all is privacy preserving means that the stable com projects not need do not need to like to leak in their positions and the

strategies in the centralized exchange accounts and um first of all they can get their like asset distributions I think it's multiple URLs it's not just one single like data it's multiple it's multiple data because they have multiple CS using the ts and we also use Zikvm to filter aggregate um the amount of different assets. You don't know what kind of assets they have. So you have to use a write a Rust code to filter to aggregate everything. So it's it's not possible right now for using like just server. It's very simple like to use dqm rust to do that and also like we have like info file with personal trading data in centralized

exchanges means that uh in a lot of uh in this uh application they want to uh want the users to prove that their average trading amount in the last three day uh uh 30 days is larger than some threshold. So first of all you have to use zikas to retrieve all the trading data. It's very long list but it's okay using p silver to uh all kind of like uh uh uh history like trading history there but you also like use sticky VM to analyze okay I have enough like the average of everything is is is is okay and gener some kind of proof

there. So it's always combinations of the source verification and you know the logic of your business and we put this kind of business logic into ZKVM or any kind of ZK data sale. So this is kind of real applications are real like solutions deployed in our customers uh to show that the power of DVC. So yeah, essentially the goal for us is that we want to build a decentralized ZK test network and essentially like we want to combine this new like text ZKVM like MPC FG so to unlock the future private data driven applications web

three. So I think this is actually the future of uh leverage and other texts to build a new like especially like financial related or data related or private data related applications in web3. Yeah, that's essentially that the the the presentation. [applause] Have you thought at all about um the

issue of the client needing to trust the atttor um with their data that they're sharing with them? So say for example it's a sensitive piece of information um how are you like able to address that? >> Sorry can be more specific. >> So like let's say I'm uh visiting a site for example that contains sensitive information. Let's say I'm a journalist or something. Um and the the plain text data that I'm sending to get uh a proof generated from the client is having to trust the atttor um with that plain text data um because it's effectively acting as a ZK middlebox. Um how are you like looking to approach that sort of problem

of like uh reducing the trust between the client and the tester? >> Oh essentially you don't need to send the client don't need to send the print pl text data to the tester. So when you generate the uh the hash of the data you actually using like u uh good server to generate about that. So you just send the hash of the data and you prove that the hash is correct. So in all these kind of uh uh scenarios the testers uh does not know anything about the data. They just like verify there. So that's why it's secure. >> I have a question. Uh you mentioned that there is this need for decentralized testers. Uh could you go into depth a little bit more? What does that mean or

look like specifically? Is this multiple like creating redundancy in terms of the data being attested multiple times by different parties and then you need to build some sort of consensus around that or yeah if you can >> uh yeah so uh for that there's no consensus. So we actually bring different parties like uh uh we kind of like different projects can be one of the testers. We whitel list the their address and um when the users goes to use this ticket service they kind of initiate a transaction in base to a smart contract and that smart contract we randomly select. Okay you're going to talk to which kind of re which tester.

So after that off uh the client and and the selected a test can run a ticket test protocol offchain and they can work in this way. So there's no there's no like consensus you every single time the client only talk to one single tester there. So but this tester is running sected and everything is running s. So even the manager of this tester cannot do anything about that. So that's the main because we have to balance security and performance. So we do not for now we do not need the consensus. Yeah.

>> And then the goal here is to avoid the collusion between the Got it. >> Yeah. Correct. >> Thank you. >> Thanks. Um, do you think this scheme can be made to work with client certificates like MTLS? >> Uh, sorry. >> Do you think this scheme could be implemented using client certificates with like MTLS, you know, >> a client client >> client side certificates for TLS connections?

>> Um, no. So the problem is that um the problem is that you don't because in the in the traditional like TLS uh the client server always has a session key. So if there is no way that to commit the cy text before they get the before the client get a cy text there's always some ways that client can change because they have the they have the session key. So that's the portability of you know it's not portable for the for TS. So essentially that that's why we need like MPC or ZK to avoid that. So pure like client sign certificate cannot

solve this problem. It's very hard >> maybe using NPC to set up the key previously >> uh then you don't need the certificate for the client side right just use NPCs is sufficient. Yeah, we we tried that but it seems that it's not quite suitable to solve the problem using MTLS. Yeah. >> Don't don't you see in the future some way to do it maybe? >> Uh I think it's very very hard. So our direction is that we still like using like MPC stuffs. We still like to improve the MPC protocol just not using like different TLS protocol. But maybe test 1.3 may be a good choice. Maybe I don't know.

>> Thank you. Um, if I understand correctly, the authentication of the server still depends on the TLS certificates, which basically means at some point those TLS root certificates. Do you publicly commit to which roots you trust there? Are they stored in a smart contract? >> Uh, for now you just trust a cert trust that certific certificate sorry. So yeah in all of these uh digitals protocols the verifier has to verify that the certificate from the server is is is valid.

>> Yeah and this happens via checking this uh tree up until some certificate authority. >> Yes. >> But there are many different ones and you probably like which set of those do you trust? Do you publicly commit to which ones you trust? >> We actually bring all these kind of roots and check all the ch the chains of the certificates. Yeah, we bring all the roots there. So essentially that you have a root there and they have a chain of certificates. So we we check every single like the chance there in the the verify side. So essentially like you you trust the CA, right?

>> Yeah. But there there are many CAS, right? I mean I could just be a CA and set up my own uh tree of certificates and at some point you're on my route and then you trust me like >> Yeah. before before you deploy things you have to make sure that that the the the root is actually the the the correct root of the website you are accessing. So you have to check that before you deploy everything. Yeah. >> Okay. And this you kind of have public like which are the CAS that you trust. Is this like do you publicly commit to this somewhere?

>> What do you mean by public commit to this? I mean like it could be like let's encrypt for example right as one CA and you could decide whether you trust them as a root CA or you don't like Firefox for example has them stored in the browser directly in the binary or the roots that they trust. >> Yes. So first of all you have to trust the the the data server right. So then you have to trust the certificate of that server right and um then [snorts] uh you can enable the verifier to check the certificate of that server during dictls. So this makes sure that okay you are talking to the correct server. So that's the main method you can do.

>> Okay. Yeah. Thank you. Perfect. Is it possible to use ZKT TLS for AI user data privacy and private uh uh inference in AI? uh depends on the applications do you want you want to build. So essentially it's very easy for you guys to prove that this this data is actually generated by AI. You can prove

that you take a t list very very efficiently but you cannot do that like zk ml stuffs like mean that you there is kind of proof should make sure that this data is is is is generated or inference inferences by some kind of mode you cannot do that use dls so that's different thing >> and can you hide the user data >> uh you only there's only you use dls you only can do that the data is generated by this like chat GBT server this is the only thing you can you can you can prove yeah it's like yeah because you access TGBT using HTTPS so that's

>> original user input data >> you cannot >> oh you can you can because when you access to JGBT you actually type your content in the web and send the send to the server so you also can prove this part. It's it's exactly the same about like uh using ziglas. You can prove that this data is the input to your mode and this data is the output of that mode. Uh depends on this input. You can pull this part.

>> But the data is open to the chat GBT. >> Yeah, data is open to chatbt. Yes. Um, sorry I'm new to this ZK stuff, but I would like to ask like is quantum computing a threat to ZK or we shouldn't bother about it. >> Uh, that's a good question. Um, yeah, first of all circuit and the quick silver is quantum resistant. So there is no quantum computer can break that. But like is ECDSA like ZK stuffs you have such risk theoretical risk. So yeah

maybe in the future you have like quantum secure like ZK proof systems maybe latis you know. >> Thank you. Uh, thank you so much.