 Okay, ladies and gentlemen, our next talk is coming up, DP5-PRI for Privacy Preserving Presence, a framework that allows you to have better control of your privacy. If you have a space, a free seat next to you, could you please raise your hand so anyone can find seats really quickly, even for the people coming in late now? Now there will be a notice about the translation. Es gibt von diesem englischen Talk eine deutsche Live-Übersetzung. Bitte das Decktelefon nehmen und Kanal 8011 wählen und unsere Live-Übersetzer übersetzen von Englisch nach Deutsch. Okay, so we are ready to start. Here we have Ian and George and let's give them a warm round of applause. Hello here, dear listeners, here is welcome to PIR for Privacy Preserving Presence. And I am Julian and we are sitting next to each other. Hello, we are Ian Goldberg and George Dinesis from University College of London. And the third person couldn't be here today, Nico Borisov. We want to talk about DP5, PIR, private information retrieval, PIR, and then George will talk a little bit more about DP5. First of all, PIR, what is PIR? Imagine an online data bank. It's not that hard to imagine. There are a lot of online data banks and we have a patent data bank. There are a lot of data banks that you can ask for example in the USA for patents. We are all researchers. Everything wants the patent 62667, the patent on the swing of a shovel. This is a real patent. It was pulled back because of stupidity, but it was first issued. Everything wants to find out this patent, but the database doesn't want to know that the data bank knows that shoveling is a totally new research topic. Chalking is a stupid example, but if you translate chalking through one, three D-metals, blah, blah, blah, then you can imagine that it is important that you want to ask data banks without trying to say where to look. Then the database operator could see that someone is interested. Maybe we should take a look at that too, because we have information. There was a time domain front running. You made a tool to see if a domain is available. And this act of the US front running made a few domain registers to make this domain register before you could do it yourself. So if you want to ask a data bank without asking the data bank, you know what you are interested in. That is private information retrieval, private information retrieval. We don't want to hide that Alice is interested in chalking, but we want to hide that chalking is a hot topic. If you want to add some anonymity to it, then you can just use Tor or whatever it is in order, and that's what it's all about. And of course there are business models that are based on this PIR, that you pay for it, that you do it privately and that someone finds out this question. So everything makes this question, this PIR question, and the idea is that the server has no idea what is being asked. The best of you, I think, are probably not, that is of course completely impossible. Well, it is of course a bit impossible, and the magic of cryptography is that things are impossible and that is just transitive. Everything is connected with the server and says, I want a patent and the server says, here are all patents, look at them yourself. Of course, this version would be completely private and the server has no idea what everything is interested in. But of course that's pretty ridiculous. Of course, that sends way too much data. Data banks with a corresponding size won't be able to send all the data in the right time. And of course there are other problems with it. And with the trivial PIR protocol. So what we are looking for in better PIR protocols is that we want to have more privacy with less data. And what we will see in a few minutes is that it is possible that there are some PIR protocols that can do that. There are different categories of PIR protocols and the first is computer PIR, where the security of the PIR system is based on it. I see that it leaves you. The server tries to find out what you are interested in. And that you assume that the computer doesn't have unlimited data and that it can't find out and can't break any crypto. So Alice takes her request and locks it up. And in contrast to a request where Alice sends a request via the TLS, where other parties can't read it, she tries to integrate the query to her own public key. So what can the server do with this PIR protocol? Well, as you can see, you can use certain types of public key encryption for a certain operation called homomorphism. You might have heard in the news about so-called full homomorphism, cryptography. You can use all the weird calculations that you can do with the high costs. But that's not why it's here. That's the so-called partial homomorphism. It's totally simple. What you can do with it is the server can take the request that is open to the public key and they can connect it to it and send an answer that is still open to the public key. And this is sent back to Alice and that's the general structure of computer PIR. These so-called homomorphisms are a bit more expensive. That's why it costs a lot to do this calculation. That's why there's another type of PIR, the so-called information-theoretical PIR, the IT PIR. What you do there is that the server, you're not going to assume that the server has a limited computing capacity. They are now unlimited. They can do anything. In no time. Alice's query is still protected. Alice's request must still be protected even if the computers are unlimited. We use a different approach, one that doesn't rely on cryptography but on information-theoretical PIR. That's why IT PIR, you need multiple servers and Alice asks each server a question and gets an answer. And then they combine these answers to get her answer. The security property we have is the non-treatment approach. That's a certain number of these servers that don't work together to break everything into a private sphere. And this approach is pretty... There's often in private technology, for example, a goal. If your path doesn't work together, then you're ruined, too. If all the servers are colluding against each other, then it's bad for you. Some kind of electronic voting has this kind of... E-voting also has this kind of approach. So it's pretty... There are many that combine these two. And most of them are combined. That means they're a bit of a computer protection and this information-theoretical protection together. And this is the information-theoretical PIR. And the advantage here is that this technology is 70 to 100 times faster than the computer-based PIR. So we have a certain advantage here. On the other hand, you need these multiple servers. That's the trade-off. So let's look at a... Let's look at a simple example of information-theoretical PIR so that you can get it. And I'm going to do a bit of math now. Please, raise your hands. Who's afraid of math? So let's go. It's going to be pretty easy. In some countries, that's maybe a high school level. In other countries, maybe an amateur level. But it doesn't matter. So about this level. Attention, vectors and matrixes. Yeah, all of them are happy. So vectors and matrixes. So this will be... If you're happy with that, if that's the case, then it's going to be easy. If not, then just do as if you understand it. So we're going to say our database is a matrix, right? A matrix is just a kind of a right-wing block of 0 and 1. Each row is one row. So this is one of the next rows. This is the first row, this is the second row, and so on and so forth. So we're going to say, there's R entries in this database. And each entry has 7 S bits. So there's an R times S matrix. And what the queryer wants to do is to get an entry, for example, the third one, and want to get one of the rows. Okay? So in order for the PR system to work, we need to call two facts from me from the first row. One is, if you take the elementary vector, if you take the elementary vector EI, which is all 0's and 1 and 1 and 1 in the octagonal, in E3, if you take EI, length R, and multiply it by this matrix, remember how it works? So trust me, what comes out at the end is the i-th row of this matrix. That means entry E. Okay? So if you could say, well, that's our protocol, it's that simple. You just make this vector with this index, the entry you'd like to have, send it to the server, the server multiplies the two things, and send you the answer. Okay, that works, but it's not private. The server just has to look at the vector. Okay, the 1 is in the third place. Okay, you want the entry number 3, 0 privacy. So the second part of mathematics is the distributive property. Remember, it works with numbers, but it also works with vectors. It works just fine. So the distributive law, if you multiply i times d plus wi, then you get the sum of the vectors times d. Okay, how can you make a PIR protocol out of it? Maybe you can already see it. Okay, here it works. Say, everything wants entry number 3. Everything constructs e3 and doesn't send it to anyone. And then looks for l server and looks for total random vectors under the assumption or under the condition that they sum up exactly to ei. Modulo 2. The easiest way is to choose l minus 1 vectors and then understand which of the last ones must be exactly to sum up ei. Okay, now we have total random vectors. We can send them to the server and each server only gets a random bit. And if you think about it, it has exactly zero information about this number 3. Okay, so each server gets zero information about it. That means, in fact, i, the same coalition of servers, as long as they're not all, has zero information about i. Yeah, what's the protocol? Yeah, each server gets this vector, multiplies with d, gets the answer and then sends it back and sums it all up. And thanks to the disputive law, the result is exactly... the answer is exactly the sum of the vectors times d. Yeah, wonderful. Okay. Is this more efficient than the naive just download the trivial one? Okay, so let's think about it. How much data does it send? It sends everything here first. And it's one vector length r. And it's r bits. And how much does it get back? So it gets a vector length s back. That means it gets a r plus s bit sent back and forth. And how many bits are there in the whole thing? Well, this is much more than the reasonable values of r and s. And in fact, we get the best protocol if r and s are about equal. If the data is the same, that means the root of the size of the data bit is set to the root of the data bit. So the root of the data bit is set to the root of the data bit times l, the number of servers, as opposed to n. So you get exactly the length of a vector and not the length of the entire data bit. Okay, so that was one of the very first protocols that you thought about from Jordan and others in 1995, about 20 years ago. But there are a few problems, many of which have been solved in the meantime. First of all, let's take a look at this. The shape of this database is rather simplistic. The shape of this database is pretty simple. That means it's exactly a series of exact entries that have the exact same length. In the meantime, there are many other databases that are different, but they have extended this protocol to be able to function properly in the database. You might think, maybe it doesn't work, because you have to say, how big is the number of entries that you actually had? How does it work? With PrivacyAber, we did that. And further work was thought about what kind of request you can make. In this case, which we just talked about, the request is, I would have liked to have number three. In most cases, you don't know that. We know some characteristics of it. We say we need a more powerful request, for example, Keywords or, for example, SQL requests. And it was proven that you can do this. You can ask SQL requests without the server to share what the SQL request is. That's pretty cool. It's already available. It's available in code. Wonderful. So, this is what was done before. And another problem of this simple protocol is that it's not very robust. What do I mean by that? Look at this. What's happening? I'll go over here. OK, I'll go over here. OK, next slide. OK. Next slide, please. OK, there we go. Laser's working. OK. So, OK. What do we mean by robust? What do we mean by robust? Well, imagine one of the servers is broken and doesn't answer. Or one of these servers wants to attack and gives a bad answer back. Well, if all of this is added, then she just gets garbage. And she doesn't know which server you gave the bad answer to. That means a robust protocol would not allow some of the servers to deliver the correct answer, even if some of the servers are broken or damaged. And at the same time, if you identify which servers are bad or damaged, then you can isolate these servers. So, let's take a look at how this works. So, it works on a basis called Shamir's secret sharing. Who has ever heard of it? Not as many people as Matrizen. Who has ever heard of Polynomes? OK, good. Wonderful. We're going to use Polynomes now. So, Shamir's secret sharing. That means we have a secret, for example, the PAI. In this case, this vector, i.e., that means which number you'd like to have. We have a secret, and we want to share some of the secrets of this secret. There's some threat that there's a limit T. That means if you know right to T what the secret is, they have no idea what it is. They have no idea what the secret is. If it's more than T, then you have the secret. So here's how that's going to work. Here, I'll explain how that works. You have your secret, and you have your limit T. We're going to call it T. What you do is you draw your X Y. That means you plot the graph and draw a green point, 0, your secret. And then you look for a random Polynomes from level T that goes through this point. That means one random Polynomes is the level T that's a secret. So that's what you're doing. That's a secret, that's what you're doing. In one is a line, in the other is a parabolic curve, in the other is a random cubic curve. So what you do next, then you hand out other points on this Polynomes and you draw a green point which you do eventually. So what's about that, right? So let's just look at the simple linear case. If you have one dot, you have no idea what the Y-axis of overgang could be. It could literally be n. Right? Okay. And similarly, if you have two dots on the parabolic curve, you have no idea where the Y-axis of overgang could be. Right? Okay. And similarly, if you have two dots on the parabolic curve, you have no idea where the parabolic curve is. It could be anything. But if you have more than T, let's say you have, for example, two, in the case of the linear case, that means two dots make a line. We are, and immediately you have the secret. So this is Shamir's secret. This is what we use. And we use exactly this technique instead of sharing EI in parts. We share it in this more complicated way that the property has. You don't need the answer of all servers. You only need T plus 1 answers. Well, what if some servers give the wrong answer? In this case, we use a filler code, for example, which, if we have a wrong point, which point is wrong? Here's a quiz. T is three. We need a cubic curve that goes through all three curves. Seven, six points. One is wrong. Which one is wrong? Who says the one at this end is wrong? Who says the second one? Third one? Fourth one? Fifth one? Sixth one? Okay. The answer is, in fact, the first one. The answer is the first one. That's the cubic formula. And this kind of error correction is actually quite commonly. It's in CD's and DVD's, in QR codes. Do you probably know what this QR code is called? Yeah, okay. It was just a joke. But the reason why you use QR codes is that you have to do these things. You can cover a part and it still works. Which is, in fact, the homepage. And the fact is the homepage. Okay. So these error correction codes are used all over the world now. You just want to make sure usually that scratch is on your DVD or your QR code. Don't mess things up. You just want to make sure all of them are in PAI. So all of this is implemented in the PC++. Open, open... Quell Open Bludtik. It's a joke. Okay. It doesn't matter. For those of you who like Git, there's a Git. If you'd like Git, here is a Git that will not like source code. If you like to go to HTTP, then someone will find in the Git-Market. Okay. So now I'm going to turn it over to George. about the use of PAI to make private sphere a protocol. Thank you very much. Good afternoon, good afternoon, everybody. The cool thing with cryptography is that it's mathematics, mathematics is cool. But what's cool is that we can protect our private sphere with cryptography against people that we would otherwise have no power. And PR ensures that we can use private sphere in social interactions. We got social applications in the last 20 years, something like Twitter, Facebook. And we have chat protocols. It doesn't work sometimes and not other times, right? No, it doesn't work. All of these have something in common. They have a feeling that some users are connected with other users. And even with Twitter, where there is no secret who follows who, it's clear that who follows who. And when it comes to chat, because we also want to protect private sphere from people, the chat is present. Present means when there is a point that you see next to the name of a user, when this person is online. We are very used to it. In the past, we just called someone and just hoped that someone would pick up. And most of the time, nobody picked up. And when did you last have this frustration, maybe 10 years ago? Nowadays you can just see who is online, you can call and know that they don't answer the most of the time or don't want to talk to you. We just know that. And to prevent the fact that there is a strange feeling, we have improved this presence protocol. We don't only have green and nothing, but we also have orange, which means we are online or online. We are just gone or red, which means we are busy right now. And we have a little bit more information to connect with. We have a little bit more information in the middle. They say, I'm back in five minutes or something. And our presence ensures that we have exactly this information. So we ask ourselves how we create this presence, in services like large commercial services, as well as small services of good people like Jabba.cd. The way we do this is relatively clear. You have a server and you have a kind of social network. And you have a feeling that people here have friends or want to know who is online. And the server just has to know the complete social graph. And that's how you can create presence. And that's how you see that Bob comes online. And everything goes online. Everything identifies with the server. He says, hi, I'm Alice. The service knows that Alice is Bob's friend. And the server sends Alice a list of who is online and who is not. I'm clicking furiously here. So I'm going to move over here. And presence information is written back. And it's rotated back. And there is a fundamental private phone problem with these services, these social graphs. Now, what is the problem with that? The problem is that if your friends are, means a lot, let's know a lot about who you are. If all of my friends are hackers, it's a great chance that you're a hacker. If all of my friends are journalists, then it's a great chance that you're a journalist. If all of my friends are from Sudan, then it's a great chance that I'm from Sudan. And these lists, let's know a lot about who I am, who I have in my circle of friends. They say a lot about me. If I have a lot of doctors or lawyers in my circle of friends, then they say a lot about me. They ask you, why, where is the problem with that? But as we know from the Snowden Libs, if we have services that have this information, that means that the government that wants to have this information, for example, to a service like LavaBit, just goes to this service and says, can we have this information? And there are special programs that spoil these data banks. Either they force these providers or they just spoil the data directly from the management. We had an interesting... We had a very interesting... We had a very interesting... We had a very interesting... We had a very interesting... Michael Hayden from the NSA just admitted last year that we are people on the basis of their metadata. That means, in the worst case, you can land on the surveillance list depending on who you are friends with or the goal of repression. And we want exactly these data to be hidden and to ensure that we can no longer find out who we are friends with. What do we expect from a private scene? First of all, there are some functional features that we won't be able to lose, which we will continue to have. We want to continue to associate with friends so that we can see that they are online but do not wish to share any more information with them. We want our operations-friendly system to be consistent against some pretty serious adversaries out there because we know that they are in the different ways. We see more adversaries out there and a lot more communications on the network. We want to hide information even from a lot of users out there. We want our operations-friendly system to be consistent against some pretty serious adversaries out there. We want to hide information even from a lot of users that we have. How way that we will, even if we have some things up our sleeve that we can still do. For example, that our computer is safe. Well, if that's not the case in your computer, then talk to the people in the details or anything else. And we will, that we will not, we will not take advantage of this particular infrastructure that we do not work with these enemies just as Ian said before. And with those tools, with these tricks, we would protect the privacy of our network. We want that no third party and in particular, you will associate this integrity and also find an additional property, These most noteworthy things we want to be able to do is, for the first time, the unconnectedness, which means it's not possible to collect information that can be collected over time to be able to use them together. That means, and furthermore, to resist very harshly. So, furthermore, some of you already be thinking, hm, a few of you probably think that there is a very trivial way of doing it, and this to implement is not particularly difficult. We simply have Alice, and she basically also has a anonymity channel, like a channel, for example, Tor, to a hidden service, or a hidden service, or a different channel, and then we have Bob, who also registers. Yeah, he also says, hey, by the way, is Alice the pseudonym online? You may think so, but perhaps you think, ah, that's the problem is solved. Unfortunately, it's not the case, because the server can link the pseudonyms of A and B together. And then she knows about the hidden services, and what happens is that the server can construct an isomorphic social graph to the real graph, which means that we only have pseudonyms connected to the pseudonyms. But the form of this graph is exactly one-to-one mapped to the original graph. Despite the fact that these pseudonyms are, for example, A and B instead of all the information. Well, if the server has any additional information, for example, if friends have online video reviews, then it can be that they can use this information to solve these one-to-one graphs. And we have a certain example that you can do exactly that. Yeah, that's not just this problem, and friends can not only go to this server and get this isomorphic graph, which is almost as real as the real graph is. We don't want to do that. We don't want to give no information, not just a high-level overview of how do we actually use it. And you can recognize a few of the ideas that you might mention. So the thing is, for example, if we have Alice and we have Bob, but we have all these friends who would like to use a service on a specific protocol called DP5, and that stands for the last tool privacy-preserving protocol and the extra piece for extra privacy. So they would like to use a service that runs a DP5 protocol to gain as a presence information, but we want all servers that have a DP5 protocol not to be able to extract any information out of it. Let's see how to do that. First of all, the service should not actually be able to extract any information out of it. So we should have Alice and Bob in a certain secret that they have to extract when they need to have Alice and Bob in a certain key, a crystal key, for example, like public key geography. So first of all, Bob has to send a certain kind of information about his status to the server. And then naively, you may think, well, maybe you can think of yourself naively, but you have to ask, you know, is Bob there, is Charlie there, and through this information. However, this would be insecure, I think, because that would lead to the information price that Alice and Bob are associated with each other. Because they would say that Alice and Bob and Charlie are connected. If at this stage we had some kind of mechanism that we would have at this moment for a particular record so that all the server can ask a certain entry, without the server knowing which entry they would like to have, that we would solve exactly this problem and this private presence. This is exactly the protocol Ian talked about before and the Ian side behind the DP5 protocol. And that's exactly the trick with this protocol, is to use these private, so-called holding requests, to use them so that all these requests can be sent without the infrastructure learning what they would like to have. Okay, so it works on a critical level. We first distribute the time in epochs, they can be shorter or slower. The idea is that at every epoch users register their presence with service and after each epoch users can actually recover who's on-line. Okay, when Alice, when she needs to register, first of all, is here with Bob, and you can use the random function, which you can think of, and use an pseudo-accident function, for example a hash function, and basically applies that to the time epoch I, and gets two things. First of all, she needs an ID. Alice is present at this time period, and she will register in epoch, and the second is a symmetric key. First of all, can use the symmetric key, can access the first status using a protocol, and use a certain method, named AED, authenticated encryption with associated data. That means it's just secure encryption, you can think about it. And then she can make a record of the ID for this period, and the encrypted status, and just store it in the database. Okay, now Bob comes along, the next period, and we'll find out if Alice is on-line. So Bob, of course, shares a key with Alice. Okay, Bob has a key with Alice in general, and uses the same function, with the same key, and uses that on the previous epoch, and extracts, hopefully, the same ID and the same key. And under the use of this ID, and the protocol that Alice is using, Bob tries to get this ID that Alice had left behind, and hopefully gets the ID back, and extracts this ID with the same key. And if Alice is on-line in the previous epoch, and for them all, we can get the status. Okay, now, I hope that everybody is half convinced that this just works. And if, under our assumption, this system would work, and these properties would have, and these functions would continue to be filled. However, there is a problem with all this, which is associated with the fact that the database tends to be very large. That means, for every, every connection in the world, you need a request to the database. We would also like to have additional requests, so that we can hide how many friends have a certain friend. For example, someone has a personal, always 100 friends, no matter how many friends there are. The database can actually be very large. That's a problem. The large database is less efficient. And we would like to work really hard to capture what is possible. We would like to have this epoch as small as possible, so that we can have this registration and this request as short as possible. If it's too long, for example a day, then you can find out at the highest that someone was there yesterday. It's not so useful. So we need to do something to improve our efficiency, so that these queries are very fast. And this registration is very fast. And as I said, the problem in computer science can be solved with another layer of redirection. In fact, the problem in computer science can be solved with an additional layer of abstraction. He invented the subroutine of many other cool things, which is indeed a layer of redirection. He would like to applaud, because he thought, among other things, my subroutine, the subroutine, that would be another level of abstraction. He was, in a way, enough that this normally creates another problem. So what we do basically is we run two versions of the protocol that are the same. We just make two versions of the protocol. At the same time, the one feeds the other. We have two different types of epochs, a long epoch and a short epoch. And basically first of all, we have Alice and Bob. Alice and Bob save one kind of entry into their long databank. And as a status, just a public key. So now Alice is basically in a long epoch that we have built. That means Alice is in a long epoch, for example, a day, and just saves her public key for Bob in the databank. And then in the short epoch, Bob can both really use the public key associated with Alice in the long period and the long databank. And at the same time, use the short epoch. Now, the trick here is to share by all friends of Alice. The trick here is that the public key, where we have all friends of Alice, is shared with Bob in the long term. We go from one record per active user, which is a short period per active user. That means in a small databank, you can use that. And you can save the epoch as short as a minute or a few seconds, depending on how many machines you have. And then Alice can use this public key in the short, living databank to save her status. And Bob can use these holes every minute, for example. And then she can make sure that she is online and has an up-to-date status for her. The status is very important to us. We don't think it's just like, I'm busy or something, but it could support other protocols. So you can make sure that, for example, the status of our content could contain the information. Oh, by the way, here is my pseudonym that I can use. Or here is the address of a Tor hidden service over which you were speaking to me. We would like to share this information. We would like to have this information so that we can use even more secure chat protocols with this protocol. So Cypherpunks write code, I believe. Cypherpunks write code. I think that's how you should do it. I think that's how it's going to go. So all of this has been implemented. We use the Percy plus plus code as a kernel. And the rest of the DP5 protocol, I don't know if you can see plus plus. And we use Cypher plus plus. We have Python bindings with Cherry Python work. And we have Twisted to implement all of the networking. So that we can time it and make sure that it works. So we're still working. But it has to be integrated with any client. So the protocol is there. We have the protocol. But we can't find out who is online if not. With real users. We only listen to our test robots. That's still missing. We'll work on it next year. And the cost of running this is surprisingly low because it's not that high. Certainly the cost per user rises the more users you have. Unfortunately, the cost per user rises depending on how many users you have. If, for example, you have 10,000 users, it costs about a small fraction of a penny. If you have millions of millions of users, it comes from the fact that per user it costs a dollar or more. So what are the messages from this? Metadata in chat protocol. Metadata in chat protocol is a goal for the NSA and everyone else. We absolutely have to make sure that if we are serious about our content. We know how to make content. Metadata is not so good as a general approach. Private information as a general service is pretty cool. We can do things that you might not think it's possible. And you can use this protocol to implement a particular protocol about presence. And based on the heuristics of this protocol you can actually use it realistically. Thank you very much. We would like to answer your questions. Okay. Could you line up at the microphones? Can you put up a question here? One question from the Internet. Our first question is, how can DP5 prevent which they don't want to share with her? We can prevent DP5 from getting information about anything or Bob gets with which they don't want to share with him. At the beginning we all had a Bob. He had to share a key. And he shared a key with each friend. With this key Bob can get information about everything. But all of these are non-friends. They can't get this information. But Eve wouldn't have shared this key. So Eve wouldn't be able to get this information. Okay. Microphone number four, please. Hello. I wanted to ask if this price graph looks pretty terrifying. That's a million dollars a month. Yeah, it's exactly right. Yeah, it's a lot of money. Yeah, it's a lot of money. Yeah, it's a lot of money. But if you think about it, if you have a million users and for a cost of about a dollar per month, it's not completely ridiculous. I'm sure that the price per user goes up. It's just because of the PII. The big data bank is scaling with the number of users. That means every request has to go up on a bigger data bank. That means the user for the cost of the PII is proportional to the data bank. You can think about it well. If the server doesn't know anything about the request data bank, that means every request has to go up on a particular data bank. That means if it doesn't touch a particular data bank, it's clear that you're not interested in this request. That means the server has to touch every request on a particular data bank. That's why the costs are proportional to the data bank. Okay, microphone number one is up there. Hi, thanks for the interesting presentation. I have a question about the non-collision as well. In the scenario where there's a patent server, everything is trusted by the one server, but it's not the information that's been added. It seems like in the instance where you put the data, but at least one server has to trust that it doesn't work together. Why is the first patent not meaningful? But the second one is that if you... Why would you trust the one server? The one trust is not... The patent is a bit strange. I agree with that. For many protocols, you can't achieve them just with your communication part. You can't reach it alone or with your partner that you can do this. The general wisdom is that you have to use some certain information. That means if a person is corrupt or under stress, however, if you have one person more than one person, you have to corrupt them all or work together. So, all the logic that goes into why we trust things like onion or mixed networks or so on and what you trust is more than one. Why do you trust more than one person? Because they're in different countries or because they're under different operators that they're under different things and to hide data. Logistically, it's just difficult to go to so many services at the same time to get this secret information. It is perfectly clear. It is absolutely forward secret. That means you have to... That's a post. It doesn't work. You have to do it simultaneously. It's a social announcement. That means these social announcements are a bit strange. They are based on us. And we give this security. And just like other free software projects, it's not automatic. If people like us don't do these things, then it's very unlikely that others will do it. Okay, microphone number six, Daniel. The base effect of performance. Even the sharding, the performance of the data bank... If you damage it in, for example, K parts, then the performance gets better. But then only users in the same shard can be friends with each other. If your user population naturally falls into these shards, then it's exactly the information you're trying to protect. Exactly the information you want to hide. You don't want someone to know in which shard you are. That would be visible. We try not to do that. Even though the performance gets better, privacy gets worse. And two more from the internet then. Hi, quick question. Doesn't the public key that's used to carry the short epoch database, doesn't that allow a third party to reconstruct, again, a graph which represents the real one? Or is the public key also behind a PIR that doesn't really make it public? I understand the question. Can you understand that? Only Alice's friends can learn this public key. That means you have to go through the first step of the DP5 protocol, and then only your friends have it. Only your friends have this public key. That means the key is public in the sense that Alice has the secret half of it, and your friends have the public key. That means it's not really public. It's not part of the query. No, no, no. No one is going to give it to anyone else. The second round is based on their key on the first one. That means it's not going to be published that way. Question from the internet. There are similar questions. The question is, what do I have to do to use the Jabba? And the second question is, can I distribute the DNS system? Can I use this for X? Well, the first question is more easy. The first question is easier. The second question is for you. What do you need to do to use the Jabba? I understand. You have to take some time to integrate it with Jabba, which we haven't done yet. We've already thought about how to do it, and we believe that you can use a kind of Jabba protocol proxy where your client talks to a certain local proxy, and the local proxy replaces this various information and then reuses it so that you can use the Jabba code. We haven't done this work yet. This is one of the most difficult parts of this work so that it's really usable. We haven't done that yet. The second question is, how can we use that to do DNS? It doesn't fit so well with DNS, because DNS is the whole trick. Everyone has to know the DNS information, right? That means it fits better on a SMS system. For example, Alice wants to tell Bob what to say a certain information, which would be the auxiliary, the extra information. For example, DP5 or an X protocol can be used for some kind of more messaging, so for a SMS system where all these specific messages to one person or a small group of people, for example, your friend in this part. With DNS, all the messages don't fit so well with it. Okay, two minutes left, two questions. Microphone number one. Two minutes left, two questions. Microphone number one. In the protocol, Alice saves everything, her connected communication with her IDX and then Bob asks this data bank after this IDX. What's behind the server then for me to find that out? Yeah, the clue is exactly the approach with PER with privacy, on a kind of way so that the server doesn't know what this ID is. That's the model, right? Yeah, exactly, we use this model, exactly. Microphone number one again. Microphone number one. What happens if the data banks are not synchronized? If they run out of sync in a time period and have a little bit of concurring information about the same user? Yeah, that would be bad. But it's not so bad. Because, as I said in the first part, at the end, these PER protocols are robust. That means certain servers are not synchronized as long as there aren't too many. No problem, because the robustness properties of these PER protocols will be solved by thinking, ah, that means that as long as the other servers are not synchronized, the answer to the biggest part of the server will be the answer. It's no value in between. It's the most agreeing number. It's not the middle value, but the main technical value. Okay. So unfortunately, you have to close the Q&A now. We have to use the Q&A session now. Thank you very much. Thank you very much. Thank you. That's the end of the session of DP5 PR.