Zero Knowledge Authentication

Hi everyone. Welcome to this presentation on zero knowledge authentication. So this is an application of some developments I've been doing on this, your knowledge proofs packlet. And so let me share my screen. Okay, so this is the agenda for today. We're going to talk a little bit about what zero knowledge proofs are in the introduction. Then I'm going to make some disclaimers and considerations you have to do when using this application. And finally, we will do the demonstration on zero knowledge authentication. Right, so what are serial knowledge proofs? So your knowledge proofs are communication protocols by which a program or a person called the prover can demonstrate to another program or another person that we will call the verifier that the prover has a solution to a publicly known problem. But the important part here is that the solution for the public problem is not shared with the verifier. So this seems like an impossible question because of course, if you want to demonstrate that such a solution exists, the easiest way to do this is just to show the solution, share the solution, and then the verifier can compute it on the end and verify that it satisfies the problem. Okay, so even though it sounds tricky and it seems like a really hard task to do, there are ways to achieve this. So there are several new algorithms and there has been a lot of research in this area of how can we make this more reliable and also more. Yeah, reliable. Faster, but also secure. More secure. Okay, so turns out that even though it sounds counterintuitive, you can actually transform any computation into an interactive zero knowledge proof or a zero knowledge proof. It doesn't have to be interactive. And in this way the prover can verify that a computation was executed correctly. And the important part here is that the verifier has no access to, to the inputs of this computation. Of course, this has a lot of hypotheses that must be achieved by the program. For example, you cannot have a while loop program, something that may not hold. That's one consideration. And yeah, there are several others. We will talk about them in the presentation. Okay, so why are zero knowledge proofs important? Where can we apply them? Well, there are four that I've been focusing on with this packlet. And also like most of the developments and the symbols and the functions that you will see here are intended for these applications. One of them is the decentralized consensus. So there are a lot of ways that you can achieve decentralized consensus, like using a blockchain ledger. And in this way you can use transaction in the ledger to act as a vote. To reach a consensus. Right? So everyone will make a transaction in the blockchain and then you will know what is the result by counting the number of votes. The downside of this approach is that, well, it depends. It may not be a downside in the right context, but one of the key difference between this and applying this to zero knowledge proofs is that you can have decentralized consensus that is private. It's a private decentralized consensus, but also it's verifiable in this way. This is very important for things like democratic processes or democratic elections where you want people to vote, but maybe their votes should remain private for personal reasons. Okay, so that's one of the applications of zero knowledge proof. Another application is to digital currency and crypto. This is like the equivalent proof problem to the one I mentioned of decentralized consensus. But instead of using the blockchain for a reaching to a solution or to a decision, you use this to just have a more private way of sharing your money. Because as some of you may know, Bitcoin transactions are not private. They are secure, but they are private. You can see the wallet's information and you can see how much money you have there. So in a way, credit cards are more private than Bitcoin in a way. But you can fix this by adding zero knowledge to the equation. Another interesting application of sure knowledge, and this is especially important I think for Wolfram language and Wolfram research, is code review. You can have zero knowledge code review. And by this I mean that maybe in a research, and this is something that happens sometimes there is a claim, there is a claim that a given model, for example, in the area of machine learning, you have a given model with some weights has a certain percent of accuracy. How can we be sure of this? So the easiest way of being sure of this is asking the research to give us the model and the weights that compose the given model and then to run the same tests that they have been doing in the research and to compare the results. So that is the non zero knowledge approach. A zero knowledge approach will be to create a proof that the research was done correctly and not to give the results to be processed again. So in this way the verifier doesn't have to execute by its own the metrics of the model and also the research doesn't have to share the whole model. Of course, if they want, because it's an open source model, then that's, that's great, you know, but it's also a way of putting a signature of reviewing. So in a research, you could do these validations. Maybe it's a protocol defined by the scientific community, and the scientific community determines some rules that the research must comply to and that the validation algorithms should comply. Then you can create a proof of this and you can, it can be verified by some peer in a peer review process. And finally, the last application and the one that we will be focusing today is authentication. And so let's dip a little bit into this part of authentication before we get to the, to the demonstration. First, let's talk a little bit more about your knowledge proofs. And here I have an example of an interactive protocol that we can do in this session with the members of the audience. But we can also do it if we had a friend. A friend in common. So let's suppose I want to prove to you that I know a coloring of this graph. Well, not this graph, actually. Yeah, of this one. So this is a graph composed of two nodes. And I want to demonstrate to you that I know a coloring of this graph. So what is a coloring? A coloring is a function from the vertex to a set of colors. In this case it will be a three coloring. So it's three colors. And the property that this must satisfy is that any adjacent vertices must have different colors. So there cannot be an edge with the same colors in the ends. They have to be different. And maybe this doesn't sound that hard, but actually it's a very hard problem. And maybe for this graph it is not that hard because we can easily come with an exhaustive search to find coloring of this graph. But imagine that this is a, a bigger graph. Okay, so it doesn't have just 10 vertices, maybe has 10,000 or 10 million. Well, that's just a very huge number. That's not gonna be 10 million, but 100 maybe. So I want to prove you that, but I don't want to give you the solution. So the solution will be the function will be the coloring, the actual coloring of this graph. And since I don't want to give you that, what I'm going to do is that I'm going to ask you to bring a friend. And this is a friend in common. You trust this person. And I also trust this person. So what I'm going to do is that turn by turn, I'm going to ask first your friend to look at this animation. And then I'm going to ask you to look at this animation. So the first animation that your friend will see. And let's hope this is I'm going to move it with the mouse. It's going to be a transformation of the new graph into the graph that we are interested in, the public graph. Okay? So this is a, this is a graph that we all share. Me, you, your friend also. And so what I'm going to show your friend is how I transform this different graph into the public graph. Okay? So now your friend is convinced that these two graphs are the same. Next, I will show you how to solve the problem in this new graph. So to show the problem in this new graph, it's just gonna be the coloring. So we can verify this. Each pair of edges has two different colors. And so this is a coloring. Now you only know what the knowledge that you've learned from this is the coloring of another graph. So you, you have not solved the original problem. And also your friend doesn't know the solution. Because I have shown your friend how to transform one problem into the other one. But I have never shown a coloring of any of those graphs. So each of you does not have the necessary parts to rebuild the solution. But together you do have all the parts to build the solution. Because if you have a solution for this and you have a way of transforming this problem into the original one, then you can just apply this transformation to the solution to the coloring. And what you will end up is with a coloring of the Peterson graph. So there are two important aspects here. The first one was how can I be sure that none of you have gained any knowledge on the original solution? And so this is also a trust, a trust setup. Setup. So, but what I mean by this is that I have to trust you. I have to trust you that you want, after I share the solution with you, that you won't share it between you and your friend. Because if you share it in all these symmetry that we have built, because your friend has one part but not the other, and you have one part but not the other, when you mix them, then you have the whole piece and you can know the exact solution. So this protocol is not that great because of that, because you have to trust that the friend and also the verifier doesn't share information. And the other key aspect of this is that the verifier now knows that I have a solution and it knows just to have partial information because his friend actually your friend, because this is our friend in common. Your friend will tell you, yes, I know how to transform this problem of this new problem into the original one. And now you know a solution to this new problem. So you, you could reconstruct it. If you trust your friend, then you know there is a way of obtaining the original solution. And if I have those two pieces, if, if I have both pieces, then I definitely have a solution. So I have proven to you that I have a solution without sharing the actual solution, just partial information. Okay, so this is the backbone of the interactive secure knowledge proofs that are implemented in this packlet. Of course it's quite different because there is no friend per se, but I'm going to show you that with the example. How is this actually working in the packlet? But let's keep with this in mind, this is an abstraction of how this is supposed to work. Now, before we move on, I have some disclaimer to do. So this project, it has the Apache 2.0 license. So you can download it and you can use it in the way that you like according to the license. And I want to highlight this part of the license because this is a disclaimer of warranty. So what I'm showing you here is the result of now, I think two years of research and it has been very interesting. There has been a lot of improvements on this packlet in this 1.1.0 version. But anyhow, this is shipped without a warranty. Okay. So please use it as. What's the word I'm looking for? The word here? Yeah. Here you are solely responsible for determining the appropriateness of using or retributing the work and assume any risk associated with your exercise of permission under this license. So yeah, I just want to make that clear. And now let's go to the demonstration. Right, so let's talk a little bit about what we mean with serial knowledge authentication. For that I'm gonna go to the packlet repository where the packlet is hosted. You can, you can access this link also. And yeah, so what is the difference between classical and serial knowledge? So I'm going to zoom in a little bit here to this part. What is authentication? Authentication is the process of verifying that a person is who it declares to be. And this has been studied for many years. And you can have password authentication keys, key authentication. Also you can have like biometrics. Now with cell phones and all of the previous dimension methods require to the client and the server to share a secret. So this is important. The server has to register a new user and just to store something that, that will, that will prove that the person trying to access is actually the person that registered. So let's look at classical authentication. And by classical we will mean the One that is set up using passwords. Okay, so there are two parts of this protocol. The first one is registration, and then is login. Okay, so registration, the client asks to create a new account and it gives a username and a secret string password. And this password will be saved into the server, as you can see in the, in the top half of this diagram. Now registration, this could be done in different ways. There are a lot of considerations you can take on the password management. Like sometimes you don't save the password, you save a hash version of the password. But anyway you, you have a register of, of the password. And the way that you're gonna log in is also with this password. Because the client in this case will ask the server to log in and share the secret as proof of the client being who it declares to be. And so the server will do is we'll take the string, the second string, and then we'll compare it with the existing string that there is. Okay, yeah, so this is, this is great. This has been working for several years. But there are a lot of attacks that you can do on this kind of authentication. One of the concerns with this is, for example, password leakage. Maybe you are just registering the passwords in the server as they are. So my secret string will be saved like that, my secret string. And then if there is a hacker and access to the server installs this database or copies some, some of the rows, then the hacker will have access to all my information because he has essentially now a proof of being myself. Okay, so that's like one, one attack that you can do here. Another attack attack that can be done in this kind of authentication is a man in the middle attack. So an in the middle attack is the client is speaking to a third party here between the server and the client. And in one side, this, this new agent is acting as a server for the client. So the client thinks his speaking with the server and also simultaneously she's speaking as the client to the server. So in one side for the client, it's acting like she is the server, but it's actually a malicious agent. And then with the information it's retrieving from the client, it will access to the server. Okay, so the server to disadvantages of using this kind of authentication. And now what is the difference between classical authentication and serial knowledge? So in serial knowledge authentication, you will have to provide a public problem. Instead of providing a secret password, you will provide a public problem. And this public problem is as we were looking here as this Peterson graph. Okay, so this is the public problem. Everyone can have access to this one, and solving the problem is really hard. So that's another one of the considerations that was mentioned at the beginning of the lecture, that you don't want to have easy problems, okay? They have to be very hard. What we mean by hard, that's another interesting topic. But essentially it has to take a lot of time for a malicious agent to solve this problem. And so since you have a solution and no one else has a solution because of of the hardness, if that's something we could say of the problem, then only you have a solution to this problem. And this actually serves as a signature or as a password, because no one else has a solution. So if you have a solution, then you must be the client, okay? And the important part with zero knowledge proofs is that you can demonstrate to the server that you have the solution and you don't have to share the solution because it's your knowledge. This way you are never sharing the secret. The secret will always remain in the client side, but the validation can be done with the server. And so this solves a lot of issues. The first one is that, well, it actually solves the two issues that we were talking about. The first one of the data is compromised because someone accessed the server and got access to the databases. That's no problem, because these problems are supposed to be public. So even if the hacker has access to the registered users in the server, then it wouldn't matter. The second one would be the man in the middle attack. So men in the middle attack, you have the malicious science between the the client and the server, and so you will never share the solution. So even if the hacker is acting as the server, what you will give the hacker is public information, something that will not help him reconstruct the solution. So when the hacker tries to connect now to the server and the server asks for a proof, he won't be able to generate it because it does not have the solution. So these are the two advantages of implementing this kind of authentication methods. So this comes with a good, comes with a cost of storage mainly, and also due to the protocol being interactive, you will have to implement this in a server that can hold a synchronous request and some of those technical issues. But essentially this is the algorithm or the protocol we could say of zero knowledge authentication. Exactly as with the classical authentication, there is a registration step where a client will generate based on a secret, will generate a public problem, and then it will share it to the server and the server will save this Again, there is no risk in doing this because even if this is leaked, you cannot reconstruct the solution from the public program. Now there comes the logging, the logging step. So this is. Since this is an interactive proof, this will take several steps. This will not have with non interactive zero knowledge proof. Those are different kind of zero knowledge proofs that are also implemented in this packlet, but I don't think I'm going to have the time to talk about them. So essentially this is the interactive zero knowledge authentication protocol. You have a client that shares a witness to a server. And so a witness is like our common friend. A witness is a piece of. A piece of data that I can, I can trust and that I can trust in the sense that I am not sharing information of the original solution and that you can almost be certain that you can trust the server. Sorry, so the server can be almost certain that it can trust. I'm going to talk about this. What we mean by almost certain, but essentially is that since the server doesn't have a reliable friend, it can never be sure that the solution is actually a solution to the problem. This will happen again in the example of the beginning of the talk, because if you happen to have a friend, we have to have a friend in common, but you don't trust him, then no matter what the, what I show him, you won't be able to save. If there actually was a transformation of the original problem into the original problem, into the public problem, into the cipher problem. Sorry. Okay, so this is again something that we want to be able to get out of the way. This probabilistic, this probabilistic value of like soundness or that this is, this is actually doing correctly. But we can make it as small as we, as we would like. So maybe if we use a very, very small number that we, we can deceive the server, then it should be just fine. Okay, so the client shares a witness to the server, so this common friend. And then the server will generate a query. So a query to a witness is a way of making sure that the witness is in fact valid. This only happens with interactive proofs. Okay, so in non interactive proofs, the process will end here. The client will serve the witness and the server will verify it. But since this is interactive, and this is why they are called interactive, actually the server will then ask for a query to the client and then the client will answer the query. So this query again is a way of knowing that the witness is actually built correctly. And so the client returns an answer that will be stored in the server. And finally, with the witness the query and the answer, the server will then determine if this is valid or invalid, zero knowledge proof and if the user should have access. Okay, so that's, that's it for the introduction of these two. Again, I'll point out that this is a resource in the packlet repository, so you can take a look and you can also, there are instructions on how to run the server that I'm gonna, that I'm going to show you. So let's, let's jump into that part. Okay, I'm going to run the demo now for these, we have to follow the steps that are laid down here. Okay, so what are the prerequisites? You need Python 2.5 or higher, you need Mathematica 13.1 or higher. And you have to. I recommend you to create a virtual environment for this, but I didn't put the steps for doing that in this technical note. So we will have to install the Wolfram web engine for Python. And this will allow us to create a web server application that runs Wolfram kernel. And then we are gonna clone the repository. This repository, it's public, you can download, has the same instructions. It's here. So we will download it and then we enter that folder and run this command. This command will start the welfare web engine and do the initialization needed for the server. Okay, so let's go ahead. I'm gonna. I have here a terminal. And. And. Here you go. So serial. There you are. This is the repository. And let's run this command. All right, so this is the address where it will be listening to our requests, our HTTP requests. So let's go ahead and open this. Nice. And I'm going to put it right here. Whoa. Sorry for that. I don't know what happened to my screen. Okay, so let's start the classical authentication demo. And what we will have here is we will have access to all the data stored in the authentication servers. Okay, so let's register some users. So I'm going to put. This one, I'm going to create another two and let's update. Okay, so what is doing what is where these commands doing? So they are asking the local host to, in the classical authentication demo to register a user and we are going to share a username and a password. Okay, so what we will have in the server side is both the username and the password. Now I did the same and I added three, three more users. And now let's do the login part. So for logging, as we saw in the diagram we will have to enter here localhost classical authentication login and we will share the username and the password. So in this case it will go to the server, check against the stored password and if they match then. Welcome back. Okay, let's change for example now I want ADA to luin and let's use password. Wrong user password. Introduce the correct credentials of an existing user. So this seems to be working fine. And what happens if you use the correct, the correct password but incorrect username? We again have an issue, right? Wrong user or password. Okay, so this is classical authentication. There are a lot of ways to making this more robust. Of course, you can add encryption, you can add maybe a certification key or something like that to make these kind of processes more secure. But as you can see, it's very easy. And the problems I mentioned before now fior knowledge client demonstration. Here is the interesting part. Let's return and now open the fior knowledge demo. Okay, so first thing we need is tool to install the packlet. Let's, let's take the packlet version 1.1, that's the latest. Then we get the package and this is where things get interesting. So let's run this command. This is the generate zero knowledge proof. And what this is going to generate is are these two objects. So we have a zero knowledge public problem and a sure knowledge private solution. The sure knowledge public problem is green because you can share it with every verifier that needs to be convinced. Right. So this is the public problem. This is like the Peterson graph, the original graph. This is what we are going to send to the authentication server. Now the other part is the zero knowledge private solution. So this private solution is this your knowledge private solution has both all the information from public problem but also all the private information that you must definitely not share with a verifier. So is the solution per se. Okay, now let's take a little bit more more look into the public problem. Let's see what we are gonna send. So let me take the CK proof and let's take this. You're having the sheer knowledge public problem. And let's look at the public problem. Well, first let's look at the protocol. So this is defined as protocol isomorphism. And as you can see, this is one of the inputs for generating this proof. So what is the isomorphism protocol? The isomorphism protocol is very similar to the one that you saw on the, on the first example. Okay, so you, what we are going to do is that we're going to transform Some graphs by isomorphisms. And so that's the way we generate this problem. First we take a random graph and then we make an isomorphism of this graph. So this is the problem. You have two graphs. And the solution is there is an isomorphism between the two of them. Okay? So there is a way of transforming one into the other. That's what, that's what we are looking for here. Now let's look at the actual public problem. So this is the actual public problem. There are two graphs of size 64 vertices and 256 edges. And what we have to do is that we have to find an isomorphism between the two. This problem is thought to be hard. So if we can share this with anyone, it should be hard for third party to find the isomorphism. But since we generated and these problems are based on what we generated, it was very easy for us to create the problem, but it's very hard to find the solution. Okay, now let's compress this object. This is the size of the public problem that we're gonna share. And then let's create it in the server. So this is successfully created the user. If we refresh the server, then we will see. Okay, there is a user Armando, and this is the problem. Okay? And we can make like a double check with the, with the image here. So this is like a signature of this object. It will change depending on the public problem. Great. Now we have registered the user. The next part is to do the login. So as you remember, this is done in three parts, right? One, from the client to the server, then the server to a client, and finally the client to the server again. Okay, so what we are going to do is that we are going to run this function, generates your knowledge witness. And what this will do is that it will create this program that will serve as a witness of the solution. Okay, so for building this, we need the private solution. So as I mentioned, this has all the information that should remain private. And this witness size is the number of homomorphic problems that that will be created. In this case, they are five homomorphic problems. So what is a homomorphic problem? It's a problem that is as a result of a transformation of the original problem as we were looking here. So this is the original problem, but I didn't show you the solution to the original problem. I show you the solution to an equivalent one. Right? So that's why we have to put this the number of witness and then we share it. We share it with the server. Okay, now here I am Splitting. Splitting it. Because this server has a cap of on how much data you should pass. So I'm splitting into pieces to pass it piece by piece. And now we have a query. So this query is the one that the server returns, right? And now if we refresh the server page, we see that we have a cipher problem or a witness. So this is the witness for this public problem. So this witness is a lot of pairs of. Sorry, not pairs. It's a lot of homomorphic problems. It's five homomorphic problems to your original one. And you can ask me for two things. You can ask the client for two things. You can ask either for the solution to the new problem or for the client to show how it transformed the original problem into this new problem. So in this case, the server is acting both as you and your friend, but it cannot be both. Okay? So it has to choose between deciding to have the solution to the new problem or to be shown the transformation. It cannot have both. This way you are only half percent sure that I have the solution. But if we, if we repeat this process, for example, five times, and in those five times I could always give you the solution and also give you the transformation and you ask randomly for both of them. Well, for. Sorry, for one of the. Of the two, and I responded correctly, then you could be sure with a 1 over 2 to the 5 probability that I am not deceiving you. Because if I am trying to deceive you, then I will either come up with a new problem for which I don't have a solution or a problem that I have a solution which is not equivalent to the original one. And the probability of me succeeding. This kind of attack will decrease with the number of queries. Of course, the drawback is that the number of queries is going to increment the size. So here we have also 20 kilobytes of data when we had here just 5 kilobytes of data. All right, so now this query, this query object is the one that the server generated, asking either for the solution or the transformation. And this next piece of code is going to answer this query. So this method answers your knowledge query. What it will do is that it will take the witness and it will take the query and it will return for what the server is asking. Okay, so now let's take a look at the query. So this query is, was generated by the server randomly using Mathematica random functions. And you have one 1, 0, 01 means I want to see the solution. Zero means show me the transformation. No, Sorry, it's the other way around. One is show me how you transform the problem and the 0 is give me a solution. Okay, so now the server has everything needed. Well, except the response. Let's share it with the server. The response. And what the server will do is that it will check one by one if the requested information is correct. And if it is, then it's going to return a true. And what we will do at the end is just ask all. Change it real quick. This is the verification. Oh, sorry, this is N. And. Okay, so we will check everything. Now, just to show you that I am not cheating, let's generate another witness. So these are different witness from the one that we shared. We can see by the image and. Let's ask for another query. No, no, I'm going to use the same query. I'm just going to answer it. I'm going to answer the same query. But with this new witness that doesn't have anything to do with the one that the server has, the query is the same. So let's run it. Huh. Truth. This is something I have to look into. Maybe it's because I run this. Okay, so the idea is that this shouldn't is supposed to happen. Okay, so any new witness will then be checked against the public problem that was shared at the beginning and it will verify that these two things match. And if they do, then this is a successful issuer knowledge proof and you can be sure that the user is who it declares to be. Right. Okay, so that's all I have for the demo today. I am ready to take some questions. Okay, so there is a question from the audience. Do the quantum computers will have these kind of algorithms? Okay, yeah, this is a very interesting question. So I'm not sure how quantum computer will evolve, but what I can say is for different kinds of authenticating that might need to change with quantum computing. And that is for example, the digital signature. So there is in the specification for HTTPs one of the allowed cipher algorithms. It's called RSA rsa. And RSA can help you to do several things including building a digital signature. And so a digital signature is kind of like these boxes around here. And this is like a compressed piece of data on the whole document that can only be generated by the person that has a private key. A private. Yeah, a private key from a pair of private public key of the RSA algorithm. And so the way that, the way that this is being endangered by quantum computers is that if you can break RSA cryptography then you could forge signatures and you could, you could act as someone else when that's not supposed to happen. Okay, so that's what I meant at the beginning of the talk with what are some of the requirements, you know, what are the requirements that we need to be able to cipher any computation? So one of the most important parts here is that this will be an NP complete problem. And NP complete problems are problems that are. Have polynomial time. Yeah have polynomial time verification algorithms. So in this, in this case will be the verifier. The verifier can verify the proofs real fast. And also. The completeness of the NP complete problems is that you can transform any computation to this product. So there are a couple of them NP complete problems. There is one that is called the Boolean satisfiability problem. There is also a finding a Hamiltonian path in a graph. And so all of those NP NP problems could be used to create an algorithm for sheer knowledge. And so that's what we can. That what I can say about that question. Okay, so quantum computers may need something like this. Actually the amount of data that of sorry computation that you need to verify this is actually quite, quite big. That's why interactive proofs are not the go to solution for nowadays. So nowadays there are different kind of proofs that are called CK snarks for example. And CK snarks are proofs based on elliptical for cryptography that allows you to do this the same as this. So you can compile, you can compile any computation into a snark. And the advantage of this is that it will take a long time for the client to generate one of these. But once the proof is generated, it can be shared with a lot of, a lot of verifiers and they can do verification in parallel instead of these kind of protocols that you have to make an interactive proving. You have to, you have to do like async processes because of the waiting for the other end. Okay, let me check the chat. All right, so I, I think there are no more questions. Hope you like this application and if you have any questions, please reach out. You can also make comments on the packlet and you can find these resources in the Wolfram Packlet repository. The links to the authentication server repo for you to try it locally. And there is another question. Will the quantum computers be more powerful and faster than the current computers? That I don't know that I'm really not sure. So there, there are a lot of, there are a lot of research I know in this area. So, but not only in quantum computers. Right. So the idea of pushing the boundaries of computing is being a current topic. For example, Moore's Law and what intel is trying to achieve of maintaining more slow and having the same exponential number of transistors in a chip to make them faster. That's something that it's been running for a lot of time, more than 50 years. So I think computers will get faster, of course. And that's why also this is very important to keep updating our, our algorithm so we don't get to a point where. And this is also important for companies where we don't get to a point where we have a very large operation and we are using outdated protocols. And then, then we have a lot of risk. Okay, another question. This kind of authentication will be enough to keep sure our data from hackers using this new of devices. Yes. And I mean I do believe that this is going to help. This is very, This can help security. But the question of how much is enough to keep secure your data. That is something that it's very hard to measure because there are also a lot of side attacks that does not require. Oh, sorry. Does not, doesn't focus on the protocols. Okay. So there, there's like phishing and at any point you could get an email, a fake email and. And then you fail for a scam or something. Okay. So of how, how much we can do to secure data that has a lot of edges. But what I do think is that for example, this protocol that I showed is good for those two things that are men in the middle attacks when you're trying to log in. And the other thing of not sharing actual data from the user in the server, you are sharing just a public problem, but the private solution remains. So yeah, in a way we could keep our data as your knowledge and in that way you wouldn't be susceptible to an attack because all your data will be encrypted. Right. But there is also the way of how are these protocols defined? How are the. For example, the isomorphism problem built here in my packlet. Right. So all of the, all of those things are good things to do research and you can go to my packlet. There are a lot of technical notes or. Well, I'm planning on getting some more technical notes on those topics of security. So yeah, there is no. A definitely answer that will be my, my input. All right. I think those are questions. Thank you, thank you all for attending. Have a, have a good day and please take out the resources.