DAPPCON 2025: TLSNotary Make Web Data Provable - Thomas

Transcript

Okay. Hello everyone. So uh my name is Thomas and today I will yeah present TLS notary to you. So TLS notary the title is make web data provable. And uh yeah before we have a look at what TLS notary does. Let's first have a look at the organizations behind. So TLS notary is a project inside of privacy and scaling explorations. and privacy and scaling explorations or PSE is inside the Ethereum foundation and what PSE so it's a sub team and what what we do is basically like make cryptography like easily usable for developers like open source it and also some applied research and yeah TLS notary is one project

inside of PSE okay so first we should probably like uh yeah make clear what TLS notary tries to solve So what's TS notary? So it solves the problem of the portability of web data. So um think about for example URLs now and you're going to visit some website. So then you're probably using the HTTPS protocol and you get some data. So now what you currently cannot do is like forward this data to some other party in this example Bob in some sort of cryptographically verifiable way. Right?

think about you could do some screenshot and so on. But yeah, so that's not really a reason why Bob should trust you, right? On the other hand, there are yeah quite a lot of use cases why this might be interesting or why you might want to do that. So for example, think about your government has some data about you and maybe you want to use that to go to some KYC provider and use it there. Or same with banks. banks have like some information about you about your maybe about your uh uh I don't know credibility score or something like this and you want to get a loan from some other creditor so you would like to use this score there are many many use cases um yeah also think about like just

proving you own some social account Reddit Twitter or even maybe you want to prove that you like so you want to like help the internet archive scraping for some data and you would like to attach a proof that this is really the website that you found, right? Um yeah, or even in web 3, you might maybe you want to trigger some smart contract function uh but dependent on some valid input from web two, right? So yeah, it would be nice if this is possible. So let's first have a look at the internet today, right? So nowadays you have basically the TCP IP stack which ensures that you are like connected to some computer that

they administers the connection and meters the data flow. Um and on top of that you have this TLS transport layer security protocol and that's so to say the cryptography layer of the web and this ensures two things. So the first one is authenticity. That basically means that the data you send and the the data you're sending out has not been tempered with in transit. The other thing is yeah confidentiality that it's encrypted what you send and receive. So when you go to some website you're probably using HTTPS which is just HTTP together with TLS. I think it's yeah like I don't know 95 or probably 99% of the servers support that nowadays.

All right. So coming back to what I said in the beginning you have this authenticity and confidentiality but what you don't have is portability of data. There's a crypto cryptographic term for that which is called nonrepudiation. So Bob has no reason to believe that the data that is sent to him yeah is really coming from the website or just made up by her. And the reason for that is that in TLS the yeah the keys you use to encrypt the data they uh yeah they are symmetric keys. That means if you have a look here the yellow keys Ellis basically has the the same key the website uses for sending out the data like encrypting it and creating

authentication tags. So what she could do is she could just yeah like uh come up with some data and then just encrypt and authent and or yeah create the tag herself for these data and then send it to Bob and there's no way for him to differentiate between those two scenarios. Okay. So how can we fix this? Welcome to the bright world of TLS notary. So when you use TLS notary you get also authenticity and confidentiality but what you yeah you get some sort of like many other things also on top. So if we have a look at the picture, we'll see here that Ellis is still connected

via TLS with the website and there's something like going on between Ellis and Bob in the back operating this TLS notary protocol. Um so what you get now is authenticity, confidentiality and now also this portability of data. But it's not only portability like forwarding it in a credible way. You also get some like yeah like some some sort of privacy or like control of what you want to show to Bob in this case. So for example, you can do some selective disclosure where you only show some parts of the server response or so. And you can also do like ZK proofs on the data.

So for example like think about it like you just want to prove you're over 18 without disclosing anything else coming from a government server. So just simple example. Okay. Um and in if you have used TLS notary in this kind of setup where Ellis is the prover and Bob is the verifier, there is no trust assumption. Alice simply proves some assert assertions about the about the data. What's nice about it is also that it's invisible to the website. So if you look at the picture for the website, it just looks like an ordinary TLS connection.

And this is quite nice. So there's we see that there's no way for the website to really differentiate between if TLS notary is now run in the back or not. And this also means that yeah so when you use TLS not there's no like you don't need to change TLS in any way right you can use the current deploy deployment of TLS which is quite nice because changing such a standard probably takes decades if you even succeed. All right. Okay. So before we now have a look at uh how TLS not achieves this portrait of web data let's have a look at some other solutions. So basically most there are like three solutions to

this problem and the first one which is also yeah the most elegant solution or straightforward is just signing the data at the source. So think of you have some web server and you could now sign the data. You could either like uh change or adapt TLS to do that. But you could also do it on the application layer. I think there's an RFC for this in HTTP which is called uh I think sxg which is just basically like uh yeah hash the hash the response and then sign it. Um so this is in some sense like the right solution but there are some problems with this because it requires the website to implement this and yeah there are some like business business models

which uh rely on that yeah that they have basically the the sovereignity of over the data while yeah so this is a yeah it's a it's a problem. So there is some disincentive to to adopt that or to do that. So what you could also do is like yeah like use use oath protocol and then we we would just delegate the access. So if I go to some website the website requires some data about me then I can send it to some data provider and then authorize the data provider to forward data from myself to this website. Right? But yeah there are problems. So first now the

data provider knows exactly what you're going to do with your data and if he um if he doesn't like it maybe he wants to censor you or like doesn't allow it also the website needs to implement it. Yeah. And the last thing you can do is um the proxy approach. So if you have a look at this picture, what you could do is well you would move Bob the verifier in between Ellis and the website and then you would send the requests to Bob and Bob forwards them to the website. Website responds and Bob sends back a response to Ellis.

So the nice thing is that yeah the website doesn't have have to to cooperate in this case but yeah you run into other problems here because now Bob is basically the proxy and always uses the same IP so it's easily to block at scale and also uh yeah your protocol gets some other like security assumption which rely on the network topology like think about if uh yeah if if think about If Ellis, for example, wants to prove something, but she is like an internet service provider who controls the network topology in some way, she can maybe sneak herself again in between the proxy and the website. So, you run into problems with that. Um, yeah, and also

even if it's only encrypted traffic you sent through the proxy and then do a zero knowledge proof afterwards, you still have that like the proxy knows uh to which website or server the data are sent because it has to forward it. So this is like what you can do in like the like the maybe the solutions which directly come to your mind. Um now we have a look at TLS notary. So TLS notary uses uh an entirely cryptographic approach to this problem and that is multi-party computation.

So multi-party computation is if you have two if you have two parties or like even several parties and each of them has some sort of secret input and they want to compute a function which is like the output of uh yeah with the two on these secret inputs. So like Alice has an input X input Y this should remains this should remain private during and after the computation and yeah like you compute a function on that and this should be public or maybe only returned to one of the parties or subset subset that's also possible.

Um yeah and this is exactly exactly what TLS not does. So um yeah, Ellis is connected via TLS with the website and in the back she runs this MPCTLS connection together with Bob. Um yeah, you can think about like that they in some sense do what is not what is necessary for TLS together as the client now split between two parties and they compute everything together like the the key exchange the the request encryption response decryption all that kind of stuff is now done in MPC that's basically the idea how it works all right

so this was like the general introduction from like the bird's eye view to the problem. Uh and now I want to go a little bit more into the detail. So like for the rem remaining part of this talk we have like basically two chapters. The first one is like a little bit about the techniques and cryptography involved and yeah then we'll have a look at the phases of the protocol. So for the techniques we have oblivious transfer which is some like of general uh yeah like some construction which is used or which is necessary for all other protocols we are using. So specifically garbled circuits for like yeah general MPC computations

for binary stuff. Then we have this oie or volley we'll come to that in a minute for computing uh yeah doing computations which in with larger prime fields um and then also we have to run some interactive zero knowledge protocol in the end. We'll have a short look at what that does. Yeah. And for TLS notary, yeah, we start with some pre-processing phase. Um, that's basically doing computation before the connection is online. And then you have the so to say the the TLS phases like you have the key exchange.

uh then you have the pseudo random function to to stretch the premaster secret to the master secret and then you have the actual traffic phase like uh encryption of requests sending out and yeah getting server responses decrypting them and in the end we'll have to do some proving okay so I suggest let's first start with the techniques and have a look at oblivious transfer so what is oblivious transfer um high level what's the idea of the function funality like you have a sender and a receiver. The sender has two messages m0 and m1 and the receiver has yeah a selection bit c which is either zero or one and now basically PS sends m0 and m1 in a way in I say in a way

because that's important to PR so that PR only learns the message which belongs to a selection bit. So if C is one M he will only get M1 and vice versa and uh yeah PS will learn nothing especially not the selection bit and if you think about it you need cryptography to implement that you espec especially you need public key cryptography for that and there are yeah there are different variants of that so this is what I just showed here to you is one out of two oblivious transfer there is random OT where the messages and the selection bits cannot be like chosen by the parties.

There's correlated OT where these messages have some sort of correlation and this we will see in a minute where we'll need this but this is think about this as a basic building block inside of TS not which is basically used nearly everywhere. Okay. So now we have had a look at OT. So now we need to talk about garble circuits. So gabble circuits is a general purpose MPC protocol. So that means you can compute any function with it. Um and especially you want to use it if you are like in a binary context.

Think about like a binary just zero and one because then it's pretty efficient. So especially we don't use that for large prime fields because then it becomes very inefficient. So in its general purpose you can compute any function with it. And the what's especially nice uh about garble circuits is that um so usually when you do MPC I mean there are other ways to do MPC the problem is that most or many protocols are not very efficient because you have many many like uh messages sent around and the number of messages you have to send around depends on the function or on the circuit depth so to say and this is not true for garbled circuits and this is very nice so it gives you some

like Nice performance, right? Because you send something in the beginning and you send something in the end and that's it. Yeah. So, okay, how does this work? We have two parties, the Gabbler and the evaluator. So, each of them have some sort of secret input XG and YE and again compute some function on that. So okay I think to get this from a high level perspective we need to think about as the function as basically as a like a circle to think about x or or end gates right and um then you have like many many gates in a circle like think about your circuit as

an array of gates and every gate think of it as a truth table. So for example an endgate yeah you have like this truth table would basically for an endgate consist of 0 0 1 right and you have four rows and depending on uh yeah the row is basically determined by the by the by like if the input is 0 0 then you get a zero 0 1 0 1 0 0 one one that's basically you get the idea. So from there we go now to a gate with wire labels and you can think about these wire labels just as some sort of random strings right. So we will see that the gobbler will gobble. We say he

gobbles the circuit. That means like he will do something with this circuit and what he will do is like he will come up with these wire labels. And think about now not zero and one flowing through the circuit but these random wire labels and only the gobler now knows which wire label belongs to either zero or which wire label belongs to one. This especially means that an end gate here and an end gate there in the circuit don't have the same truth table. Yeah. So right now the evaluator already doesn't know uh which values flow through the circuit but now we have to do one more thing. We have to like encrypt it so that basically the

evaluator can only like evaluate the circuit on the correct path which is like dictated by the choice of inputs. Right? So for example, this especially means for an endgate, let's just focus on the first row, you would like encrypt the wire label belonging to the clear value zero with a wire label flowing in I and J belonging both to the clear values of zero. And you do that for all the four rows basically. And then you have so to say a garbles gate, right?

And then think about the circuit as like a huge array of these garbled gates. And basically that's it. So now what does the gobl do? Now the gobl he gobbled the circuits. He sends over all these like encrypted or garbled gates to the evaluator. Then he sends over his active input labels the WI because remember like only he knows to what to if they belong to either zero or one. the evaluator for for him it's just like look like random. Um and now the question is how does the evaluator get his own input labels?

Because remember we have a function the the gobler has some input to the function but also the evaluator right and here you need then oblivious transfer for this so that the evaluator basically gets his input wire labels without the garbler learning the clear values behind it and that's it. Then the evaluator will start basically with a first input layer of the circuit and like work work himself through the circuits doing encrypt uh doing decryptting gate by gate on the right path through it and in the end you will arrive at the active output wire labels right still the 128 bit like random numbers. So what do we

do now? Now we come basically to the output dec decoding phase and what happens here is now you can now it depends on yeah who should learn the output of this function. So what you can do is you can uh send the decoding information which is the mapping from wire uh labels to clear values can send that to the evaluator then the evaluator will learn the output or you can basically have the evaluator send his active output labels back to the gabler and then he then the gabler will learn it and if you do both parties learn it and this is like the gist of behind garbled circuits how it works.

Um so what I should say is uh let's say for example you want to gble an AES circuit so you have to do all of this per one evaluation right so if you want like compute an AES again on some different input you have to goble all of that again so this is not FHE right it's different okay so and because you have to do all of this again and again like think of we have many many circuits in TS notary with many many more gates so we want to have this as efficient as possible and there are some optimizations you can use for it

I don't go into the details here but think about like going from uh if you think about about one gate with this truth table like four rows you can get down to two rows yeah so there are these techniques which are called row row reduction and half gates you get to two rows with free X or you basically even don't have to send X or gates to the evaluator you can just so so to say incorporate them and there's even something you can do to improve the the performance of your gobling by using a fixed key AES cipher.

So again this is used whenever we want to compute something like something in a binary field. This means especially AES and SHA. Okay, that's it for gabble circuits. So now we have a problem because I mean we have done now like we have a tool for general purpose MPC for binary fields. But if you think about TLS for example the key exchange there's also like there are big prime fields involved because you deal with elliptic curves. So what do we do here? That's where oblivious linear evaluation or oi comes into play and you can think about it as a tool to like compute with with these big numbers

and prime fields efficiently in a way. So you have again two parties pa and pb and they have their inputs a and b these are like from a elements of a big prime field and what you get out is this x and y. Sometimes x can also be the input but yeah let's not not focus on that here. What you get is the output in such a way that it fulfills this equation. So that you have like y is equal to a * b + x. And if you rearrange that you get you arrive at y - x is equal to a * b or y + - x is equal to a * b. And that's why this is also called like m2a. You should

think about it like you can basically convert your multiplication into an addition right? And if you now also have the vice versa as a building block which is called A2M like going from an addition to a multiplication you you have to think about like you have to some big equation and by using either M2A and A2M iteratively on this equation you can basically shrink it down to some into some result and that's exactly what we do whenever like we are forced to deal with big prime fields we're using these two to do computation.

Yeah. And they also play a big role in our interactive zero knowledge protocol. So especially as a vectorized version of it which is called volley. Yeah. That's basically like think about just doing this several times but the B is fixed. All right. And and in a way that's yeah that's like the the the the b the big building blocks we we we use in tless notary like from the conceptual idea. So now we can have a look at tless notary what it does and yeah like okay pre-processing so what does mean what what is

pre-processing so when you have uh like we're doing multi-party computation and that's like takes a lot of time to do the computation right but you have to remember I mean there is a server waiting for requests and responses and many server implements some sort of cut off so if they don't get like an answer in like I think a minute or whatever they just shut down the connection. So what you want to do is like not run into that and that's why you move all the parts of your computation you can move into an offline phase be before the online phase. Yeah. And that's what pre-processing is about. So first we ask the developer to specify

the expected traffic amount. So we have these values max send, max receive, max receive online and this basically we ask you tell us how many bytes you're expecting to send to the server and how many bytes are uh basically yeah are you expecting the server to respond and based on that we do like the pre-processing because we need some sort of gauge of yeah like how uh how much do we need to pre-process and if we know that we'll start our own machinery like remember from before OT very important needed needed nearly everywhere.

So there's a problem with OT. So like OT can only be done with public key cryptography and public key cryptography is yeah like considering the the time it takes or the performance not that great. Now we need many OT's like think of millions. So what you can do now is basically use some sort of base amount of real OT's and then do like a blow up like an uh increase the number like think of you start with 100 real OT's and then if you use an OT extension you can get like thousands of OT's from these bootstrap OT's

okay and that's what we do here. So we use like CO5 as an as a protocol for our base OT's and uses elliptic curves and then we use an OT extension cost 15 which is uh yeah it's just like a random oracle model protocol. It helps basically to like uh yeah it uses symmetric key cryptography to like uh get many many OT's from that and that that's why it works because it the extension works without public key cryptography. So it's very efficient and we use this OT extensions nearly everywhere in our protocol um except for inter for our interactive zero knowledge protocol because that's

even more OT hungry and there we need like think of much more powerful OT extension and there we use the ferret protocol which is based on learning parity with noise assumption. Okay. So now we have run our OT machinery. So now the prover because we already know roughly how what's the amount what's the expected traffic amount. Now the prover can garble all the circuits and send them to the notary. So this is especially the encryption and decryption circuits for the traffic but also the PRF circuit and there's also a small garbled circuit involved in key exchange and we also prepare our interactive zero

knowledge protocol. Okay, so now we are in the key exchange. How does this work? So the general idea here is so in TLS you just have client server and the easiest picture to think about this is to split now the client between prover and verifier right. Um and this is also the exact reason in some sense why TLS notary works because you split the client key between prover and verifier. Now the prover hasn't the full key anymore. So that means especially that Alice cannot like encrypt or decrypt anything without Bob,

right? That that means like she cannot make up some traffic and like claim it would come from the server. That's the general idea of why and how it works. Okay, let's we quickly go through here. So the verifier comes up with some ephemeral public key sends it to the prover. The provers public key to it and sends it to the server. Now the server can like der the elliptic what's it called this ecdh secret the premaster secret uh right then he also sends his public key over to the prover forwards it so and now prover and verifier each on their own can basically come up with an ecdh share of the secret now this these

shares are just like shares under elliptic curve point edition which is not ideal because remember we want like the now these you have these like PMS shares under uh EC point edition but what we would like to do is like we I mean we need to feed that in the PRF to get the master secret and ultimately the session keys but if you reme if you remember the PRF is SHA basically SHA circuits in some sophisticated way uh which is binary so we'll use garbble circuits but these are like uh big numbers. So what we do here is we com we like compute that's in this MPC box. We

uh compute a sharing just we go from this elliptic curve point sharing of keys just to a binary exor sharing and then we can feed it in the PRF to compute the session keys. Right? Okay. So now basically we have computed like we have done this key exchange then we have fed all this uh as an input into the PRF the PRF of course computed with garbled circuits like into PC and now we arrive with the set we are arrived with the session secrets right so and we can use them like in now in the online

traffic phase for the encryption and decryption so how does it work so the prover has CWK is client write key and of course he knows the plain text he wants to send to the server. The verifier has his client right key share and now they use it as an input for AESCTR. So maybe one one thing so the encryption and decryption in TLS is mostly AESGCM. So that's the most common cipher suite. Um I've put into this box ASCTR because ASGCM is like the just normal ASCTR with some sort of authentication mechanism which is Gash and I don't want to go into the details of Gash in this

slide. So let's just focus on like how what happens to the actual uh you like to actual requests and responses. Yeah. So as is then here like uh executed between prover and wire verifier again as binary circuit. So we use garbled circuits to compute that between prover and verifier and out pops the cipher text. Cipher text both parties get it. Prover sends the cipher text to the server and uh yeah verifier also gets the cipher text.

So for response decryption, it's kind of similar. So now you use the server write key share from the prover and verifier server write key share as an input. So the prover got the cipher text from the server then forwards it to the verifier and they both supplied as a public input to the ASCTR circuit. Again, like garbled circuits, they decrypt it and they get a plain text. But no, sorry, not they, only the prover gets the plain text because yeah, we we want to hide it from the verifier because he shouldn't know the plain text.

All right. Um there is an optimization you can do here which is called deferred decryption. And that's basically if you only have like one request, one response, there is no reason to like decrypt the response in the online phase because you can do you can do it afterwards and then you don't incur any MPC overhead on that, right? Um so why can you do that? And that's because after the closing the TLS connection, that's pretty nice. the verifier has no secrets anymore. So think about these SWK and CWK. So after the connection is done, there's no

reason to keep them secret anymore because the connection is closed. And that is quite nice because now we can use that uh and prove the correctness of our computations. So think about now uh yeah, let me think about it. Okay. So first yeah so we prove now the correctness of the computation because the verifier has no secrets anymore. For that we use an efficient interactive zero knowledge protocol that is quicks and you have to think about it like from a high level perspective like we are going to redo all the computations or all the garb

circuit computations from the online phase. uh but we do that like not in MPC it's like you create these max these M I and you create the keys KI uh and you have to think about it like you create the max for the prover and the keys for the verifier and they always fulfill fulfill sorry fulfill this equation and then the prover and the verifier works through the circuits of the online phase and In a way this is a check for the verifier to check if the prover like cheated or not because in if everything is correct then in the end this equation will also hold on the circuit outputs

and that's the idea of how it works. I mean this was a little bit simplified but it's a general high level idea right so and you do that for all garbled circuits computation in the online phase and you we also prove the knowledge of the clear text for the server responses for the prover so there's one thing you can do you can uh you can decode the server right key for the verifier which means like that's the key the server uses basically to encrypt the messages and you can decode it already in the online phase if and

only if you have no secrets uh or if you if you don't expect any secrets in the server response and this gives you gives you like some it's more like efficient and gives you like a better and more easy commitment but you can only do that if there are no secrets expected All right. So that was basically the gist about how TS not web works. I mean there are of course a little more some more details but that's the high level idea. So where are we currently? So everything works quite nicely I would say we are in the moment like doing some performance improvements and adding additional features. So in the last few

months like I don't know the PRF was improved and also like the number of round trips. Um so we are in this phase where developers reach out and ask us to implement some features. For example in the last weeks we added different commitment types. We also added support for mutual TLS which is basically client authentication. Um and also in our notary server we added JWT authentication. So think about like we we're in this phase where we stabilizing improving performance and adding some features.

And the next big po point on the horizon for us is adding a plug-in system to give developers some sort of fine grain control of how exactly they want to run the prover or how exactly in which environment and which with which settings the verifier or notary should be run. So it will be some sort of yeah plug-in system and also an onchain verifier is still interesting. So think about this that's this case where you want to use web two data to trigger something in a smart contract. Um of course the smart contract cannot participate in this MPCTLS connection.

So uh you you get a trust assumption there in the form of a notary. Well, so and then it's still not like it requires some more research of how to do that because if you then haven't verify in a smart contract, it's still the question of how you like uh check the correctness of the certificate chain. So it's like ongoing research to some degree and also we want to add support for TLS 1.3. Currently only 1.2 to is supported and I'm sure there are probably some other things which will pop up in the coming months.

Yeah. Uh thanks. So this is our team. Um, I've put some links here like our website and our documentation which we definitely need to improve and also uh links to some GitHub repositories, the core protocol, JavaScript bindings and also our browser extension. Yeah thanks. [Applause] Yeah. So questions. Yeah. Okay. Thank

you. So just cryptography but the verifier doesn't need to be online. He will provide his stuff and it will be later. So so yeah. So I mean it depends on how you how you operate it. So if you like um so basically uh you can have a direct verifier like I showed in all these pictures then it needs to be online because it participates in this MPCTLS phase which is exactly at the same time where the connection is open to the server. What you can also do is like you can sort of outsource that to some notary and that's basically a server which does like

uh where you create commitments for this session or for the TLS session in some form and this is signed by the notary and then returned to you and then you can util sorry you can later use that then for some verifier. So these are basically the two modes you can do but for this MPC TLS uh stuff you need to be online. Yeah. And do you have some users some? Yeah there are some uh like like some startups I would say which use TS notary to I mean yeah for for various use cases. Yeah.

when you explain the proxy approach. That's what uh Yeah. Mhm. We are also thinking about implementing this as a mode of operation. Yeah. Because I mean it's like it's just like it depends on what you I mean if if you want have like the best of security you should probably do MPC but if you maybe like yeah you're more interested in like performance and honestly there's not so much to lose in what we do depending on the use case where you use it can be a viable alternative to to use a proxy approach. But isn't it so if the between the

client and the Yeah. Well, yeah. The client is now the the prover. Sorry, can you say again? Yeah. And the prover. Yeah. Yeah. And the other one is not Yeah. Okay. So I have to trust that your notary is right. So honest, right? Right. So if you that's exactly the thing. So if you have a notary then uh who basically

helps you to create a commitment and then signs it so that you get an attestation which is later presentable at some with to some verifier. In this case you had a trust assumption. Yeah. But if you have like only a verifier like there is like you basically you directly prove something about the the cipher text or like in this case there's no trust assumption because the verifier I mean it has to trust himself. So yeah, right. Okay. No, I'm just coming from the point of view that in NBC it's cool to have more players than just Are are you talking about like maybe

having more like notaries in this? Yeah. So that was some some topic quite some months ago. So the thing is h gobblets you can do goblet circuits with multiple parties like not only two you can but it's like some sort of little bit esoteric I mean like it's like it there are like papers about that it works in theory but it gets complicated and also you always have to keep an eye on the performance so it's it's like yeah you try to um Yeah. Yeah. Yeah. I mean

actually thought that we played a little bit with it but this would be some sort of like an effort in its own and there are like more important things currently like Yeah. No no but but it's definitely interesting. Yeah. Or also the other way which is the origin server sorry or also another attack vector would be that the app sending the data it will forge its own certific yeah but I mean then you need to like like uh fake the DNS

yeah something that like Maybe maybe and the computation does actually happen in the verifier. Yeah. So I mean the the heavy computation part is on on the parties who are involved in this MPCTLS connection and that would be prover and verifier. Yeah. Or prover and notary. And then if you later present the proof to some verifier, this way verifier has not to do the MPCTLS part. But yeah, still there's some computation and verification to do which makes it hard to run in a smart contract. So but but the the majority of computation is this

MPCTLS stuff. Yeah, I guess that's it. Thanks. [Applause]