Episode 368 - TLSNotary with Dan and Sinu

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, Nico and I chat with Senu and Dan from TLS Notary. We learned about the history of TLS Notary, from some of Dan's early ideas on the Bitcoin Talk forums in 2013 to the project being brought into the PSSE fold. We discussed the breakthroughs that happened along the way that allowed the project to

evolve and how it's being used in the wild. It's inspired a number of other projects that we've had on the show from Pluto to Reclaim. So, it was great to chat with the folks behind this foundational building block technology. We cover how it works, the limitations of the tech, some of the nomenclature issues around these concepts, and more. Now, before we kick off, I just want to point you towards the ZK jobs board. There you can find job postings from top teams working in ZK. And if you're a team looking to hire, you can also post your job there today. We've heard great things from teams who found their perfect hire through this platform, and we hope it can help you as well. Find out more over at jobsboard.zeronowledge.fm.

You can find this on our website and I've added it to the show notes. Now, here's our episode on TLS Notary with Dan and Senu. Today, Nico and I are here with Dan and Senu from TLS Notary. Welcome to the show. Thank you. Thank you for having us. Hey, Nico. How you doing? Hello. Hello. All good. So today we're going to be talking about TLS notary and that's a project or kind of a a concept that's been brought up a couple times on the show before. This is the first time we're going to get to do a deep dive. I think as a starting point it might be helpful for the audience to understand what is TLS Notary. What part of the stack does this live in? What kind of problem does it solve?

Sure. Yeah, I can take this. So TLS Notary is both a protocol and a library. And fundamentally what it's trying to do is take information on the internet and make it cryptographically verifiable. So for example, you go to a website in your browser and the classic example here is you log into your bank's website and that presents to you your bank balance. Now right now there's no way for you to essentially take that bank balance and show it to a third party in a cryptographically verifiable way. You could take a screen screenshot for example, but that's not very secure. you know, we have things like Photoshop these days. So, instead, TS notary essentially facilitates you to connect to a third party and cryptographically prove your bank balance to them without

revealing any sort of uh unnecessary extra information such as your login credentials. Cool. So, this idea has been brought up a few times on the show before. I think a little over a month ago, we had Maddie from Reclaim on the show. Last year, we had an episode with Pluto talking about web proofs. I feel like these are all kind of in a similar category, but yeah, I feel like with this, I mean, as far as I understand, TLS Notary is a bit of an older project and it has sort of more of a legacy. It's it's underlying a lot of these ideas. So, I'm really excited to dive in. Now, before we do that though, I'd love to learn a little bit about both of you. Dan, let's start with you. Can you share a little bit about the start of TLS Notary and

why you decided to work on this? Yeah. Well, the interesting part is that there are like two eras of TLS notary. One which like goes back to 2013 and the other the more recent one. So I don't want to leave out Sinnu but because with him we started working on this like three or four years ago but the ancient history. Yeah. I was like at the at the beginnings of it. So yeah. So, I was wondering how do we uh cover this?

I actually am now curious about your 2013 history. I think we should start there. Even if it's not quite what it became, just like if it was the seeds of the idea, I'd love to hear about it. Yeah. Well, somehow I envisioned you're going to you're going to ask me that. So actually there is a blog uh Bitcoin talk uh forum post and I just went there today re reread the entirety of it to kind of remind myself what my frame of mind was what was the surrounding events. So yeah I kind of reconstructed what was happening back then. So like in a nutshell, Bitcoin was around start getting traction in the media uh on

slash dots which I was following. So there was like this excitement in the air and uh I'm considering myself a libertarian. Well, I considered at that time. So my thought processes was more like uh effect more freedom in the world. how to like uh effect a change so to speak. I wasn't sure which path to take. I I quickly realized that the political path is not the the most efficient ones. So yeah, so the technological one was like probably where it's at. So, and I discovered Bitcoin basically. And so, it kind of aligned with that goal of mine and especially like the community around

Bitcoin cuz it was not like marketed or presented like a purely financial solution or something like that. It was like a tool, you know, to give people more privacy and there were like freedom-minded people around it. M. So yeah, it was like the social effect as well that kind of dra dragged me in. The devs behind Bitcoin kind of I felt the the kindred spirits in them cuz I followed their blog post and whatnot.

Was Blockstream already founded by the time you got involved or was it like just before? Blockstream was founded just when I when I joined and the movement so to speak. Yes. I don't know if you know this. I had an episode recently with Austin Hill who is one of the co-founders of Blockstream. But the reason is he used to have a company called Zero Knowledge Systems. Oh, back in the late 90s. And there's a really funny story there in connection. I'll I'll add a link to in the show notes to these past episodes. We did three on that company. And Austin also went on to do Blockstream. So I actually heard from him recently a little bit about like that history, that period of history of Bitcoin.

Oh, interesting. So Anna, you were not around? Not at all. I mean, I was a startup founder, so I was going to tech conferences and there were sometimes tracks on financial technology and sometimes on those on those panels or in those sort of like tracks there'd be something on Bitcoin, but I was working in video technology and pretty far away from it. Yeah. Okay. So, I'm not going to assume that everybody knows the entirety of history, but neither do I like uh objectively know it because like my memory is kind of foggy from what was happening. But so, so basically from my recollection, yeah, so Bitcoin was

there. I kind of aligned with my uh ideals so to speak and I started to think like where can I contribute to it? And I I think there was a meme floating around like maybe I'm just like making things up but something like don't think what Bitcoin can do for you but what you can do for Bitcoin. And I think that's kind of was the the mentality of many people like we wanted to contribute to to something that that was expecting to make a big change like in the world. So yeah, I started like exploring where can I contribute. Yeah, I kind of dabbled in the source code of the Bitcoin core

client and I tried a few things but what can things popped on my radar? You may you may say it was like coincidental but it actually ties into like my background a bit because I already was familiar with cryptography and like web PKI and stuff like that. So like in that nent times of Bitcoin there was a problem of onramping people who wanted to exchange their fiat for crypto. I might have caught some of that us versus them mentality. So it just seemed like the banks actively ban accounts both of businesses and users try to

prevent the this onboarding process. So it kind of seemed to me like a problem worth uh digging deeper into. So this was actually the initial impetus of TLS notary. It just so happened that Bitcoin was the like the catalyst of why we started doing that. So so this problem of onramping users and uh supporting peer-to-peer exchanges th those started to pop up everywhere peer-to-peer exchanges. But I think they were non-custodial. you would they would just like connect buyers buy buyers and users. I don't think it was like local bitcoins because local bitcoins was custodial later on.

But how does TLS notary fit into that? Because like it's interesting you're talking about it as like a exchange. I think of I think of it as so much more like the web to a signature. It's like I I think of it as sort of a different part of the stack even at this point. Yeah, that's that's a good point. So what were you posting back then? like what what was it that actually like is that start of TLS notary? Yeah, I mean but the way you see it right now is through your current lens when the basically the ecosystem is already developed and there's a clear use of having web to data on chain and things like that but back then we didn't think along those lines and

Ethereum did not exist at all. It didn't exist. Yeah. Yeah. we just had this narrow our blind zone and just the narrow problem to solve and I I didn't expect it would be useful in other aspects so that so we basically we wanted those uh P2P exchanges to basically have a flow where the two parties rely on some escrow only for cases where a dispute happens basically only for cases where the buyer claims that they've sent fiat but they have not actually sent it.

So we thought how can we give like a cryptographic screenshot of their of their bank page. That was the initial impetus. Ah wow. So this is this is sort of this idea though that you're looking at a website. A website has changed somehow. You're trying to show that that change is true and correct and it was for this payment use case. Exactly. That was the initial narrow focus that I kind of started drilling down into. Yeah. I didn't I didn't expect it to be anything bigger than that.

Where did you go from there though? So you're talking 2013. Like did you work in the industry for a while? Did you work more on the payment side? Was this an idea that you had and then parked and then came back to or was it something you've been working on ever since? No, actually I've been in the blockchain space only like the last 5 years. I was so you left or you like explored and you did something else? Yeah, please hear me out. I actually never joined it but hear me out. So I I was basically I was like in the broadly speaking in the IT solution sector like more on the development integration side of things. So some projects that I worked on already include like uh network security solutions,

cryptographic deployments. So with with that background when Bitcoin came around, I started thinking how I could contribute. But like to fast forward, I actually never joined the space the crypto space even though TLS notary came to exist. So I only joined it like five years ago. What year did you join? 2020. 2020 roughly. Okay. Yeah. So, what was TLS Notary working under? Like where was it if it wasn't in like blockchain? Just a passion project. Yeah.

Okay. Basically fueled by the enthusiasm of two guys like myself and Adam Gibson, one of the other devs very passionate about it and like fueled by this idea that we need to give something to the world that that is cool and useful and is needed. So, where does TLS Notary start the 2020 version? Yeah, let's fast forward to that. And I guess it's like Senu's turn to to talk about that cuz that's Well, is that where he joins? Well, actually, no. Actually, I kind of I kind of brought TLS not to a proof of concept state. So, I did my mission and I kind of went back to my day job and then Senu reignited the the movement

again. Yeah. Cool. Okay. So, Senu, why don't you tell us a little bit about what got you started on this sort of project, where you got interested, maybe a little bit of what you were doing before. So, yeah, my background is actually pretty varied. Uh, I started off my career in electrical engineering. I did some years in the trades and then I got back on the computer and got into doing data engineering and analysis around 2017 or so. And that's about the era where I really started like paying attention to crypto. And um I was just like anyone else totally hooked spending most of my time, most my spare time keeping track of what was happening in the space, learning as much as I could.

And it took me about four years before I actually wanted to like dip my toes in to try working in the space. But everything think prior to that was really just like a I was passionate about what was happening. The way that I got exposed to TLS notary was really just I I was interested in identity and like I I noticed that there wasn't very many ways to like leverage your identity information with decentralized applications and actually my my very first introduction was I just wanted to implement something that would issue a POA app by proving something personal about yourself. And I was kind of like looking around the space and realizing there's

no real good way to do this. You know, you have things like OOTH, you have things like Open ID, uh, but those are kind of like permissioned and they they just come with a whole host of problems that didn't seem to like really fit well with like DAPs essentially. So yeah, I was kind of looking into the space and uh at some point or another uh I I got connected with um Justin Martin and Barry White had PSC and Barry White had well actually both of them were very excited about Deco at the time and they were kind of wondering like where's the implementation? Uh what's happening here? Hey, maybe we can build this ourselves. We need an engineer to kind of help get this off the ground. So, uh, got together with those folks,

kind of like fleshed out what we wanted to do, and, uh, yeah, that was in, I believe, the 2022 year, uh, earlier in the year there. So, we kind of kicked off just kind of doing some like surveying of like what are potential solutions here and, uh, came across TLS notary and I was like, oh, this is an awesome project. This does like essentially exactly what we want to do. This is something that like facilitates cryptographically proving information uh on on the internet and um yeah I actually like cold reached out to Dan. I just like opened up a GitHub issue in the TLS notary repository and I said hey we're interested in this problem. Would Yuk be interested in like kind of moving TLS Notary under underneath the wing of

of PSSE and see if we can kind of reinvigorate this project, re-evaluate, you know, the solution space, apply modern technology and things like that. And yeah, Dan got back to me, I think, over email and yeah, from there we were like, okay, like let's take a a full shot at like reevaluating Killless Notary from first principles and see if we can come up with a with a clean solution and one that's going to be Yeah. using just like modern cryptography and something that was also going to be implemented to just like a higher standard something that you know is going to be suitable for handling uh potentially sensitive user secrets and things like that.

Cool. And yeah, that was really the the initial start was in about in 2022. So it started as a I guess passion project for you Dan suddenly goes under the wing of PSC and becomes sort of a a fullyfledged let's prove any sort of TLS transcript. Yeah, you could say so. But it wasn't sudden. It was like there was a there was a big gap like five or six years between those events. Yeah. M Did you then join PSSC as well, Dan? Did you sort of go into the org? Yeah. Me and uh senior we applied for a grant and Okay.

We got a 3 months grant. After that the PSC saw the value in kind of taking it inhouse so we became like PSC members. Cool. So I'm curious a bit about like the different stacks like obviously the first version uh was before we have this deco paper which tells us we can do this sort of client and notary MPC stuff. So yeah what was the first version and then where today's like TS notary efforts going? Yeah the first version was kind of exploiting a a specific peculiarity in like TLS 1.1 like the current most prolific version of TLS is 1.2. So it was kind of a hack but it kind of

worked. But the current TLS noter version it still kind of is based on the same fundamental principles but it uses general purpose MPC and senior. I'll let you carry on from here. Yeah. Um so the term notary um actually just brings this like implicitness that you're talking about addestations but TLS notary really is just a two-party protocol between a prover and a verifier. And that verifier uh essentially witnesses the TLS transfer transcript and then may issue an addestation about that transcript. So in that case you would call it a notary.

But I I think it's simpler to think about it as just like a two-party protocol between a prover and a verifier. And the fundamental idea of TLS notary even back in 2014 was hey we can essentially emulate a TLS client between the prover and the verifier by secret sharing the uh TLS session keys between the two parties in such a way that neither the prover nor the verifier know the full session keys. This is what we refer to as the MPC part. Right. Right. So like the the the older version of TLS notary it exploited the uh RSA like key exchange of of TLS1 and TLS1 the homamorphic property of it and newer versions of TLS use um elliptic curve

cryptography but the the helman key exchange but the idea is still fundamentally the same both the prover and the verifier essentially provide a piece of entropy that's used to generate the TLS session keys and the the critical part here is that the prover doesn't know the full encryption or MAC keys and neither does the verifier. So the verifier can't decrypt the data you don't want them to see the plain text and the prover can't authenticate messages which the server didn't send for example that was the fundamental idea is hey let's let's uh essentially secret share the TLS session keys with the prover and the verifier in a transparent way to the server um except TLS 1.2 2 came out and the cryptographic primitives that were used in the older

versions of TLS uh rapidly got deprecated and TLS 1.2 kind of used different algorithms which made this a lot more difficult and kind of broke the hack that the older versions of TLS notary exploited which allowed you to do this kind of secret sharing of of the TLS session keys and uh that that's where Deco comes in. So around I think DECO was 2019 2020 they essentially took a look at this problem and realized oh well we can essentially do the same thing but just apply general purpose MPC to achieve the same outcome.

So they they leveraged essentially general purpose MPC to enable the the secret sharing of the TLS session keys. So it does sound like there was a lot of kind of different tracks of research happening some of which were inspired by TLS notary some of which kind of maybe came before. Yeah. What what else influenced the work you were doing? Was there like other libraries or breakthroughs that had happened around the time that you actually you know brought this into PSSE that made it more possible to do this? Yeah, there were some. So other than deco there was pad paper which is now Primus and we borrowed heavily some of the techniques they used cuz they used a more efficient MPC. I would say that's

about it. Deco and Pedo are the giants. Yeah. Nice. What about something like Town Crier? What is that? Town Crier is a uh TE based solution which solves the same problem as we do. Okay. Basically, but unrelated unrelated to us. Got it. Yeah. These these were just research papers and and I think what we learned on the reclaim episode there had been some like small implementations of these papers but they weren't really like usable yet, right? They weren't like in production in something.

Yeah, actually Town Crier existed. They had a website. You actually could go there and they would issue an AT station or something and they would actually tweet it for you. But it was like a proof of concept, but it actually existed, but it was not like production grade quality, something that you can plug in. Yeah. Interesting. Just back to the story, we're in PSSE. You've brought it in house. Were you interfacing with existing projects already in PSSE as well? Like were you kind of building for anyone or was it just like the development of this idea?

It was really about just the development of of this idea. There there was a fundamental problem is that you know most of the information that we care about are kind of exists siloed in servers on the web and quote unquote web 2. And the idea was always just hey yeah how can we essentially allow users to leverage existing information on the web in a web3 context using decentralized applications. Yeah. So I mean the the Deco paper was there. I believe that there was a proof of concept available in a GitHub repository somewhere but there really wasn't anything that was kind of like fully developed out. And uh Deco itself also had some concerns about whether or not it was going to be actually performant enough to run on

like a low power user device. So the original Deco paper if I remember correctly used fully malicious secure MPC with uh I believe authenticated garbling and having that actually run on a user device in order to like implement uh TLS notary it it just didn't really seem feasible. So the first part of our project was really just about how can we still leverage this general purpose MPC idea leverage it practically like it needs to run essentially on mobile devices and uh it it at the time it didn't really seem like that was going to be possible.

So we kind of went through this whole research stint of okay how do we implement this MPC TLS protocol using general purpose MPC but without using essentially the state-of-the-art malicious NPC that was available. So at the time it seemed like it it wasn't feasible but after kind of inspecting the protocol long enough we had a fundamental insight which is that we actually didn't require malicious secure MPC semi-honest garbled circuits particularly the halfgate protocol that we were interested in is secure against a malicious evaluator but not secure against a malicious uh generator. And we realized that at at the end of this whole protocol, the only party which

needed to continue to have private inputs is the prover. So at at the beginning of MPC TLS, both of the parties have private inputs. They have to secret share the TLS session keys. But at the end, it's okay for the prover to actually learn the full TLS session keys. After the verifier has been convinced, I'm guessing. Exactly. After the TLS transcript has been committed to the verifier, the verifier is free to reveal their component of the TLS session keys. And then at after that it's kind of just up to the prover to essentially prove that the MPC that they had performed was performed honestly or at least putting some sort of statistical bound on the leakage of those session keys in the case that they did deviate from the protocol. And this kind of fundamental insight allowed us to um reduce the like

total MPC costs of the protocol by approximately a factor of 10. It was at this point we realized, okay, it it is actually practically feasible to run this stuff on a on a low power user device. At this point, sort of how long did it take to run the protocol on like a consumer laptop? um with this kind of optimization figured out. Yeah, it varied a little bit because we had to do some like implementation optimizations, but nowadays, you know, it really it's it depends on the the bandwidth of the connection between the prover and the verifier. But you can expect on the order of like anywhere from 5 seconds on a good connection to, you know, 20 seconds on maybe a moderate connection and then if you have a really slow connection, it's going to take a

while. But that's also a function of how much data actually gets communicated over the TLS connection. By the way, this is super different to what we're used to talk about on the show because usually we have just a non-interactive proof. So I have everything I need on device I prove and however much compute I have, that's how long it's going to take. In your case here, you're talking about bandwidth, right? So like there's there's interaction happening and I'm almost limited more by the bandwidth than I am by compute. Is that correct? Yeah, that's the fundamental like constraint on all of this is that it's an interactive uh protocol which involves communicating a lot of data between the prover and the verifier.

Does the tech stack underly some of the projects that we hear about today in the ZK space? Like we tal, you know, we mentioned the reclaim episode, but there's also like Opacity, Pluto, like teams that are doing web proofs or proof about something on the web. Are they usually using the TLS notary tech stack under the hood? Have they taken what you're doing and and done something else with it and and what's your relationship to those teams? Yeah, there's a handful of teams that are using it. I will actually just correct. I don't believe that reclaim is using TLS Notary. They have their own implementation of of the of the proxy variant.

Got it. Okay. But like he like you said, Opacity Network. Uh there's Vlayer. I believe at some point was exploring using kosis notary but I'm not sure if they're still using it these days and then there's a handful of projects of that we're actually not you're not allowed to talk about well not no we're allowed to talk about but we know folks are using it but we we don't necessarily know who there's a lot of forks of our project on GitHub and then you know we have people experimenting with it that pop into our Discord channel and speak with us but kind of the the main folks that we're uh communicating with these days would be yeah like opacity network v layer there's some like more application specific projects like keyring uh that we're in contact with uh but yeah so ts

notary really just focuses on providing like the core library just like the zktls implementation but there's a lot of tech kind that has to be kind of built up on top of that I was going to say wasn't zk2p using tls notary and almost sort of closing the loop of these peer-to-peer on-ramp offramp things totally exactly Yeah, ZK P2P is definitely one of my favorite applications of the technology. And yeah, you're right. Like in my view, it kind of manifests the original like impetus that spawned Tless Notary way back in the day.

That's so cool. It goes back to your story, Dan, of like your first idea of it just being on ramp. Nice. What is TLS Notary today? Cuz like it's been a PSSE project, but is it something that like basically how do you maintain that? How do you are you still in PSSE? Would you spin this out as a company? Yeah, we're still a project within PSSE. We've tried to kind of narrow the scope down and and maybe not tackle so much of this uh problem. We're really just focused on providing just a open-source option for folks to be able to leverage ZKTLS.

Nice. So, yeah, we're we're we're not really trying to monetize or or productize ZKTLS. We we just want kind of like a vendor neutral option that anyone can build on top of and to uh really just focus on the core library itself. Mhm. It's interesting you talk about TLS notary also as being kind of like it sort of picks up steam when you when you start to use this tech towards connecting you know web two data to onchain data. And yet what we have been hearing is like more and more of these use cases where it's totally offchain.

It's web two to web two proving like you don't even need the blockchain anymore. Is is this something you've noticed as well? Yeah, we've definitely noticed it. I'm actually I'm I'm excited about both cases, but I do think that it does unlock a lot uh in the quote unquote offchain context, however you want to define that. But I mean, there's a lot of data just locked up in data silos that aren't really usable by users. And this is something that I think kind of like hampers applications on the web and kind of reduces market competition because you kind of have this monopolistic effect occurring with people's private information. So yeah, ZQ TLS is

definitely being looked at a lot for just like, hey, how can we just, you know, plug into existing data sources in a permissionless way to allow users to explore just like new applications and new value ad using this their personal information that they already have. Fascinating. As opposed to, you know, potential other avenues such as using like OOTH or open ID. Those are like permission solutions which require the entity which holds this data to actually support that integration with this uh potential new application. Whereas ZKTLS works completely client side. So the user can um you know prove the information to a third party in a transparent way to the server. So as long as they have access to it,

they can make a cryptographic proof to a third party uh about that data. There is one thing I find partic like particularly interesting with the offchain case and this ties back to what you said earlier like these protocols are fundamentally two-party protocols like I need to run this with a verifier and unfortunately like a smart contract alone cannot act as this verifier and so it almost makes more sense to run this offchain with a live party than with a blockchain because this link between like how do I go from this two-party protocol to a blockchain is actually quite hard to do. Right. Right. It It's unfortunate, but the protocol is designated a verifier. It's interactive.

So, you can't like take this TLS transcript and just like show it to anyone. The verifier has to be actively engaged in the TLS connection. So, you're you're in this designated verifier setting. And the intuition here is that the verifier is the only person who knows we split the key correctly. Yeah. Essentially. So I I mean it it's also obviously related to the the oracle problem as well. When when you're bringing things onchain, it's you're fundamentally talking about addistations. Mhm. So you can use something like TLS notary to implement an Oracle protocol, but those are still going to be addestations and you'll have to, you know, build some sort of consensus protocol on top of

that to maybe have some sort of threshold check on like having multiple addistations for that particular statement that you're trying to prove. Right? So I could engage in TLS notary the TLS notary protocol with like four or five different ad stators and as long as they agree between themselves that they all verify the same thing then we bring it on chain. Exactly. Okay. But just to be clear the current way to do it is you would have to prove the same piece of data to each of those verifiers individually. Then they have to kind of collect that data and come to agreement. But technically it is possible to to integrate this N ofM verifiers agree to something into our

core protocol. But yeah, that's a that's a big lift and probably out of scope. So moving from two party to end parties and then we have all this bandwidth issues like even worse and Yeah. Yeah. Yeah. Mhm. Exactly. I see. I I really like the way you presented Senu talking about designated verifier proofs and I think uh there have been a few like debates online about like the term ZKTLS and this this intrinsically designated verifier nature of these protocols right yeah I think that people when they normally think about zero knowledge proofs you know they they think non-inactivity publicly verifiable maybe even succinct things like that but in yeah in the case

of Tus notary it's a two-party protocol all where only the verifier is receiving any sort of guarantees about the authenticity of this transcript and and that's not something that you could just post in on like a public ledger and where everyone would be able to verify that for themselves. It is zero knowledge, right? We do actually have ZK in that sense. It it is zero knowledge in the sense that yeah only the provers like the underlying plain text that was actually communicated with the server. The verifier really only sees the encrypted cipher texts, but the prover does also have the ability to selectively disclose the plain text as well if they wish to.

Huh. Yeah. I just wanted to add like the ZKTLS um may may be considered a misnomer just u yeah because it immediately makes you think about non-interactive ZK snarks and actually we had it happen a few times like people like when we present Telis notary people immediately want to like improve upon it like how can we make it more optimal and they think that maybe there is no need for a verifier at all. We can just make it like a CK snark. Just you the prover do something with the data you receive from the server and turn it into a proof. But yeah, that's the first reaction. But unfortunately, no, that's not possible.

It's not how it works. Do you think there's an issue beyond just like folks asking you at conferences thinking that ZK is in ZKTLS or like using that term? I mean, Nico, you've made a few tweet threads about this. I think C know you too where it's like it's it's a problem but is it a problem? Like are people misunderstanding the tech when they're using it potentially? It would be great to have people using the tech. Oh yeah. Well tech like theoretically. Yeah. Yeah. I mean that's it is a tough question to to answer. It's it's fairly nuanced and it really depends on like who you're talking about and and what sort of mental model they have when they think about you know the ZK prefix being applied to something. I will say that

when ZKTLS is used to essentially issue addestations about the TLS transcript, that should be made crystal clear. You know, if you're being presented with an addistation about about a TLS transcript, you're really trusting the verifier to have uh performed that honestly. And there's nothing stopping them from essentially, you know, generating a fake transcript themselves and and signing that and presenting it to you. So in in in that sense like it's not publicly verifiable and and I think that some people do get they do definitely stumble on that because at at first glance you know if you have that misunderstanding you might think oh wow

this essentially solves the Oracle problem like I can query a server and and and cryptographically prove in a publicly verifiable way this TLS transcript on this bulletin boarding and anyone can verify it when you know that's not the case we're we're in the designated verifier setting. And if you want to do something like that, you really do need to do what we were talking about before, which is run the protocol multiple times with multiple different parties and then build some sort of consensus over top of that, some sort of threshold of of parties which agree upon like the validity of the information that you're that you're purporting.

By the way, talking about the oracle problem, that is that was sort of the source of Deco, right? Deco actually stands for decentralized oracles. So yeah, it's all just just bringing that connection back in. Yeah, I believe that they definitely had that particular use case in mind. Yeah. So what I was curious about is as a user like when I want to use these systems, what happens? Am I downloading an app and then this app is asking me please put in your bank password and I just have to trust it that it's going to do an addestation and not reveal anything or not send anything back to whoever the vendor is.

Right. Yeah. There are multiple ways to essentially deploy this. And yeah, one way in which you could do that is you could just embed this within a mobile application, distribute that for users to install and then present them with your own login form where they'll put in their username and password and they essentially have to trust that you're not just, you know, sending that over the internet to their remote server and giving up your login credentials. This is I would say still a bit of an open problem because one way or another you you are having to essentially delegate your private information to a piece of software in which you're not necessarily equipped to assess whether or not it's doing what you expect it to do. We have a proof of concept which is our browser extension and it essentially does this.

When you install it, it has to you have to grant it more or less universal permissions to read and write to the web page that you're on. you you need to be able to delegate access to like cookies on a web page, for example. This is the first thing I tell my mom not to do, like do not download these extensions. Do not authorize this stuff. Exactly. Yeah, that and that really is kind of a hard problem to address. We we have some ideas that uh we're we're working on right now to kind of try to reduce the surface area of risk there. for example, do you uh install just one extension uh that you know comes from a reputable source and you know the the developers are telling you that it's secure, maybe there's some sort of fresh consensus on the internet that yeah,

this browser extension is legit and it doesn't steal your credentials. Or you could have a situation where every time you want to use an application which leverages CKTLS, you have to install their their extension and you kind of have like this duplication of of of of surface area across different applications. So that that's one one question is just like how do you actually distribute like the ZKTLS prover to the user and how do they know that it does what you expect it to do. I I I regard that as fundamentally still an unsolved problem. Is there a world where we have these provers in our browser like built in?

Yeah, we have looked at that a little bit before. We've talked with the the folks at Brave. Um but you can imagine that like there's still like an apprehension. is still relatively new in kind of experimental software. So, it's kind of a hard cell to be like, hey, here's this new tech that does this fairly niche thing. Uh, can you like integrate this like first class into your browser and distribute it to your users? So right right now we're still in like an early experimental stage and we're kind of limited to yeah distributing in the browser context as a browser extension and in the mobile context application developers have to embed this into their application distribute it to their users directly. Do you think though like will this because it it does

seem really useful. Like could it just be that it needs to be adopted somehow? It needs to catch the attention like is there other larger incumbent players who could potentially adopt something like this beyond browsers who would like push it? That is a tough question. The issue I say here uh that I see there is that like this technology is kind of like fundamentally disruptive and it's more towards you know empowering the user and it actually is in some way larger institutions and incumbents which are already established more or less have a disincentive from seeing this happening for this does happen. It it I feel like it's going to have to be something that is driven by probably

like the startup ecosystem in which you see that articulating the thesis on this is difficult going even like further off a field like is there any connection like is there any use in LLMs or models or AI like is there anything where the TLS notary or like kind of proving things about what's happening inside a system is it useful there yeah in the context of AI I have thought about this a little bit before I mean for for the for the offchain use case you know you can prove the authentic icity of some data at some like origin and uh you know AIS need data when you're trying to train your LLM you need

a lot of data and ideally that data would be authentic and wouldn't be perhaps generated by another LLM. So you could imagine a case where a company would allow their users to crowdsource the LLM data. So say a bunch of users install their extension and they can get paid for going to a website and essentially exporting that data to this aggregator who takes that information and like sells it to you know AI companies which are trying to train their LLMs with some sort of guarantee that you know this information is authentic. I think that there's probably ethical issues with that, but I I do see potentially some application for this and particularly in just the

sourcing of information for LLMs to be trained on. Cool. So, we're okay with like freeing up our data from um data silos, but what if I start using this in protocols where deniability is a good thing? So, we have these like messaging protocols. Mhm. like off the record protocol. Uh, and one of the big properties there is like I don't sign what I say and it's like a real conversation. It's off the record. You can't prove that I said or did not say something. Suddenly, if the person I'm interacting with is doing this NPC stuff, maybe they can start writing proofs or at least proving to this verifier like something that's been said. Um, and I actually saw a ZK hack project going in that direction. And I'm

starting to wonder, is there potential misuse of this amazing capability? That's definitely something that we thought about before. You know, non uh repeatability is potentially very valuable sometimes and you're right. Yeah, you could you could definitely, you know, connect to a third party and prove that you've received some sort of private message in which the sender was assuming that this was going to be confidential between you two. you and like I was kind of alluding to before with the LLM case of like sourcing data for LLMs, really what you might be talking about there is exfiltrating data that's behind access control and the origin of that data doesn't you know doesn't want you distributing this information. I'd say there's defin definitely ethical concerns there, but I

would also say that this is a bit of a Pandora's box being open moment where I I don't see a way of going back from this. Like the the if the internet relied previously on repudiability existing just due to, you know, no one had come up with a clever trick to modify TLS to make this possible. I'm sorry, but that that's not safe. It's over now, right? these technologies exist and I I the internet is just going to have to adapt to the new reality that you know any information that you're distributing is potentially going to be you know cryptographically proven to a third party.

So there's almost like an arms race between deniability and being able to prove everything. Exactly. And there's this fundamental tension as well. You know we we we want authenticity. You want to be able to authenticate the party that's on the other end of your communication channel. But when you do that, you know, you're you are kind of giving up deniability in that sense. Wow. Interesting. Can you share a little bit about where the project's going? If there's sort of a direction, like are there new spaces that you're trying to explore with what's coming up? Yeah, so PSC is going through a lot of changes right now. And actually part of what we're trying to do in our project is figure out what makes sense for us to continue to work on.

Like I said, there's a lot of problems in this space just on top of the core protocol. and we're trying to figure out, you know, like what's actually critical for, you know, us to actually intervene in and to work on. So, at the moment, we're kind of thinking that we're just going to, you know, keep our focus just relatively small just on the implementation of the core protocol. Having a just like a open- source library that people can use uh to leverage this technology that's vendor neutral. It doesn't come with any strings attached. You know, it's just free open source software. and we're going to invest in, you know, improving the quality of that software, improve testing, get it audited, and try to just have something that, you know, is a solid option for people to use. And then, yeah, going going into the future,

you know, we're still kind of evaluating, you know, like where are the key points in this like I guess you could call it the ZKTLS space, which we need to potentially uh invest some resources into to solving some of these problems. So PSC is particularly focused on privacy in in the Ethereum application layer. And if CQTLS is going to be used for, you know, applications that are built on top of Ethereum, you know, these hybrid apps which are trying to leverage web two data, we're going to keep an eye on how it's being used and and and look for areas where, you know, we can potentially contribute to, you know, ensuring user privacy.

Awesome. Dan, do you want to add anything there? Yeah, I just want to say like it was mentioned earlier, how do end users interact with this technology because I mean what we're building is an essential piece of the puzzle but it just it's just not enough to drive the adoption. So we have a lot of builders who and early adopters who like recognize the potential and are hard at work building on top of well I call it MPCTLS. Yeah. ZKTLS. Yeah. And so yeah, I mean the these are the people which actually put their thoughts into how make it more user friendly, discover new like use cases cuz sometimes you need to have like

specific knowledge in a certain area of like the legacy world to know how to integrate MPCTLS into it to know if there's demand there. So I mean it's basically those builders which which do all the heavy lifting. we're we're just providing the the core tools for them. One other question since Anna, you had uh Maddie on the show a few weeks ago. And talking about future plans, Maddie said, "Well, we're right now reclaim using the proxy mode, but we're looking at MPC mode. We're looking at what TS notary is doing uh and how it's progressing." So, I guess I'll flip the question. Are you guys ever looking at the proxy mode stuff? And do you consider adding it as an option to the library or is it completely different?

Yes. So, we are interested in providing the proxy mode essentially as an option and then we're just going to have to, you know, communicate or fest what those trade-offs are between the MPCTLS and proxy mode. But yeah, we're definitely interested in just providing it as an option for applications where that makes sense. Cool. So, it will actually be built into it. Yeah, a lot of the underlying like software that's required to implement proxy mode is essentially the same as MPCTLS. So we'll be able to reload re reuse quite a large part of our existing code for that implementation.

Nice. Well, I want to say thank you Senu and Dan for coming on the show sharing with us the history of TLS notary uh some of the work that inspired it also work it inspired painting a picture for us in where TLS notary lives kind of in the larger ecosystem. Yeah, thanks so much for sharing all this. Thanks for having us. Thanks so much for having us on. It's a pleasure. Cool. Well, thanks, Nico. Thanks. Yeah, it was nice also to get to talk about like the ZKTLS distinction because I I feel quite strongly about making sure people know this is designated verifier and it is truly an interactive protocol.

Yeah. So, thanks both. Cool. Thanks to the podcast team, Henrik, Rachel, Tanya, and Kai. And to our listeners, thanks for listening. [Music]