 One, two, cool. So, hello everyone. So, as Pierre-Levis says, I worked on the CTF, and now I'm doing this talk, and also work for Tor project. So, this is why I'm doing this Tor engine services talk. But first of all, I just wanna know, who knows what Tor is, ShowVan. Okay, basically everyone. Now, who uses Tor daily, ShowVans? Okay, who runs a relay? ShowVans, one, two, three, four, five. Okay, so, I have some hot sauce here, and I would like to give the hot sauce to the fastest Tor operator. So, the five of you, come see me at the end, and then we do this kind of a contest of who has the faster relay. And then you get a nice hot sauce, it's amazing. All right, so deep dive into Tor engine services. If some of you were at OAP last year, this is the engine services talk, but a year has passed in between, so I updated the slides. We've made humongous amount of progress in terms of development, so we're gonna go through it. But this is fairly technical. I'm gonna go through what is Tor, what is Tor engine services, and then what happened with the next generation engine services? What's the attacks and the breakage between? So first of all, I'm just going to do a small overview about what Tor is. I do work for Tor, I'm a full-time employee for the Tor project, and it's a non-profit organization based in the US. It used to be in Boston, now it moved to Seattle. We basically do online privacy, anonymity, lots of research. We are basically operating around $3 million budget, of all based on grants, donations, and some funding from, as you know, different governments. It's a huge, kind of a huge and diverse community, I think I have a slide for that, there you go. So the bigger outer layer of the onion, it's, we have around 7,000 relay operators around the world, 3,000 bridges. I'm not going to get into bridge, but if you have more questions, feel free to ask them after the talk. So this will be a bridge-free talk. We have a lot of applications, actually. We have Tor browser, Tor messenger, Tor birdie for Thunderbird. We have the Tor, little T-Tor, we call it. And we have many other things around it. And it adds up to around 50 different projects. So right now, at all time, in the Tor network, it's 2 million users. So the thing with, when you build anonymity network, you cannot really measure who is on the network and when they log in or whatnot. So this 2 million is an estimate, and it's at all time. So we don't know if it's 2 million users that just come back or just 2 million users, it happens to be right now. But we do know that there's around 100 and 150 million unique download of Tor browser every year. So whatever you can do with those numbers. Employees, volunteers, we have a huge amount of contributors, lots and lots of research centers around the world, that basically our university is doing full time anonymity network research. So, to understand onion services. So I'm mentioning onion services because a year and a half ago we discovered that it in services was kind of a really bad for us in the press. And the journalists just are just interested in this bad side of it in services, and this is all they show. So we decided to move away from it and call them onion services. And it happened to be also that we're creating this next generation thing. So when I say onion services, it is it in services, the same thing. To understand them, we need to understand what our Tor works. So I'm assuming that you are basically familiar with the three opting in Tor, but I'm still going to explain it quickly. So Alice wants to connect to Bob. We have 7,000 relays in the network. All those relays are the ones with the small onion. And imagine all those nine servers are the internet. And when Alice gets in, she picks a guard, then a middle, then an exit, then she exits to Bob. And in this case, when you exit, Alice, if Alice choose an insecure protocol, well, the link is unencrypted when it exits. So this is why it's very important to understand that Tor is an anonymity network. It's not a secure network. And by that, it means that if you use an insecure protocol, you're still going to get the exit still going to see your content. Now the exit doesn't know where Alice comes from. That is where you get the anonymity. So this guard context, this guard notion is very important here. So the M3 point in the network is a guard. Let's remember that, then the middle and the exit. In case of onion services, as we'll see later, there is no exit at all involved. And the reason is because onion services stay inside the network. So you can spawn a website, whatever it is, and then join the network, and then you'll be reachable only inside the network. It will never exit the network. So this guard, middle, let's keep that in mind. Some brief statistics, as I said, this is since 2011 up to 2017. We have many relays. So you can see this gap in 2015 at the end of 2015. This huge dent. So it happened to be during the Congress at CCC in Hamburg. Not me. And some people from Lizard Squad, maybe you heard of those, they decided that it was a good idea to show the world how good they are, and they spawned a thousand relays from this Google Cloud app thing, whatever. And we quickly figured it out. We rejected them for the relay and that was it. But they did brag during the weeks that they were able to take over the Tor network, but they actually didn't understand what it was. So that's what it then is. And the 2014 one, I believe it's the art bleed. I'm not sure. I think it's around those time. This bandwidth thing, we're around 330 gigabit a second, and what has been used is around 100 gigabit seconds. So we still have some margin in the network. Okay, now I'm done. Now you know what Tor is, and how it works briefly. 100 services. So back in 2004, so it's been a while, it's been 13 years, the first commit was made in Tor, 00.6. And it was in services. So at that time, Tor was under the EFF, so this is why you have this banner, tor.eff.org, and it was mostly experimental. So, but the point is, is that it's been a 13 years technology, if you will. And it's based on 16 character long addresses. So it's base 32. Here's an example of what a non-unit address looks like. You all, I'm pretty sure you're all C1 or no one. CNC, a button at CNC loves those, and they have those amazing properties that I think I have a slide about that. Client server either locations, everything stays inside the Tor network, and it's, of course, it's only TCP. There's no UDP, there's no other protocol. Tor is only TCP. Now, with onion services, you get interesting properties. So the self-authenticated, what it means is that if you have this onion address, and you got it from a secure source, a secure channel or whatever, and you know that this onion address was given by the right person who runs the service, when you reach the service, you're sure that you're authenticated. You're sure that you reach the destination, and it is done with some fancy crypto. So it's very nice as long as you have the onion address. Oftentimes, it's given the onion address to the other people, which is the problem. Now it's entwined encrypted. So with onion addresses, for instance, you don't have to run an HTTPS server. You can just run an HTTP, and from the client to the server, it will be completely encrypted through the Tor circuits. Remember, our Tor works in a normal case when you exit to get to Gmail. Now, the exit sees the connection to Gmail, and if it's unencrypted, sees the content. In the case of onion services, impossible. Isolation and not punching. And that one, the not punching, is one of the use cases that people use the most. So they basically run their onion services at home, and SSH, and the way onion services work is that it punches through that, and then you can connect to the services. You don't have to do any firewall fanciness or whatever. Limit the attack surface, of course, because it's a very narrow attack surface where there's only one port open, and you have to do this onion services dense through the Tor network. You cannot reach all the ports in the machine, and so on and so forth. And one of the lasting that is, we've seen onion services being used around the world is censorship resistance. So we live here in Canada, which basically, instead of controlling the internet in some ways, they're just surveilling it. But there are countries that they're doing both, and when they do control, it means that if you get caught using Tor or you get caught using Facebook, well, you get some police to your door. In this case of censorship resistance, many countries, and I mean, the list is very exhaustive, but Iran, Pakistan, China, and so on, for Blangle Dash, even Australia does that, they block Tor. So the way you want to reach your destination is to use onion address, because it's unblockable, you cannot censor it because it stays in the network. Now, Bridge comes into play because you still need to reach the Tor network, but I'm not going to get into Bridge, but still, the point is, you cannot censor an onion address service. So back in 2015, we started to create statistics about what was happening in the network in terms of onion address. Right now, we have around 70 to 80% of all the relays reporting statistics of it in services. It is being, there's a lot of research involved in how to collect those statistics so that privacy preserving matter. And you can see right now, there's around 60 to 50,000 unique onion address at all time. We have no idea what they're used for, but they're just there in the network. So that's a lot of services registering to a Tor network. Now, this is the traffic in megabit, and all those fluctuation, we have no idea what's going on. For instance here, did they'll speak? It could be some attackers or some researchers or new botnet, we have no idea. In this case, very little traffic, one gigabit to second, a little bit below that, which means that the entire Tor network as an onion service traffic, it's around 3% of traffic. So when you hear on the news that Tor is only used for bad guy through this onion address, through onion services to distribute whatever, it's actually very false because the traffic is extremely low. Now the question is that fraction how much is used for bad and good, that is actually very impossible to know. That's an overview of what are hidden services. So in this case, we're gonna see how it works because over time, those onion services are getting weaker, for instance. So I'm gonna show you and explain to you some attacks and some problems we're having right now and to deal with them. So, but first, of course, I'm gonna show you how hidden services works. So there's six steps. Basically, I broke down that in six steps. Imagine you have Alice, the client, wants to reach the service. So the first thing it's gonna do is the service is gonna start up and select three introduction points. Those introduction points are relays. Remember, there are 7,000 relays across the network. So randomly, the service will pick three relays and consider them introduction point. Oh, I have that. Now the service will create what we call a service descriptor. A service descriptor is a text file, basically a signed text file of which introduction point I've picked, how to reach them and how to reach me and some keys, some encryption keys so we can have this nice end-to-end encryption. Now this descriptor is gonna be uploaded to directory. Those directory, we call them hsdir, hidden service directory. Those directory, again, are relays. Every relays, if it's up for 96 hours, 96 hours of uptime minimum, becomes an hsdir. And then the service, take this descriptor, upload it to the directory. Now Alice gets the onion address of the service and then the first thing it's gonna do, put that in Tor browser, for instance, and then the Tor demon will ask directory what is the descriptor and it is descriptor. Now you may be asking yourself, how does Alice know which directory contains the descriptor? Because the service doesn't upload the descriptor to all 7,000 relays. It's only uploaded to six. I have nice slides to explain to you this because there's actually an attack that is being pulled every day in a Tor network due to a flaw in the design, but I need to explain this more thoroughly in the directory. So just keep in mind that Alice can know which directory the service is associated. And then, getting the descriptor, it knows where to reach the introduction point. And in the meantime, the client will also pick what we call a rendezvous point, which is also another relay. Introduction point, directory rendezvous point. There's a lot of things there, but they all plan together at some point. Now Alice connected to the one introduction points which the service has a circuit. And now they can introduce saying like, hey, I wanna connect to you. So what the client Alice will do is send to the service through the introduction point where to connect to the rendezvous point. So come see me at the rendezvous point. And our service connected to the rendezvous point. Alice is connected to the rendezvous point. And this is how they actually supplies the circuit and then the traffic goes in. Now there's a reason why this dense is needed. And I'm not going to go through in the detail of the research about that, but the point is to keep anonymity and being reachable. And there's multiple amount of attacks that you can do if we didn't have this dense thing with the introduction point, a rendezvous point. I'm gonna just show you a couple today, not the entire catalog, which also we're trying to fix. Now back to the Direct3. The reason why Alice knows which Direct3 to get is because it's predictable. So here the first rectangle you see it's descriptor ID. We call it descriptor ID. So to remember the descriptor is the text file as the service publish and contains information how to connect. In this descriptor ID, it's basically an hash of the onion address and then time period, descriptor cookie and replica. Descriptor cookie, it's empty because it's for client authentication. So we're not going to talk about that. But then the time period and replica are known. So this time period thing is basically you know what's the number or the value tomorrow or in two years. So it creates a descriptor ID. And this descriptor ID is just base 16 and then it gives you a big string and then this is how you pick the relay. You're gonna pick the relay with a fingerprint closest to the descriptor ID. So it's basically an hash ring like this. Descriptor ID number one and then you just pick the closest relay next to it and this is where you upload your descriptor. And then this replica thing, it's one or zero, literally. And the reason is just to move away the kind of split the hash ring in some ways. So six diary three. So it means the service as uploaded is descriptor to six diaries and this is how it knows. And Alice can knows which is dear because she can do the same calculation. Now this is problematic in many ways and I'm gonna show you how. As I said 13 years and crack started to form. For multiple reasons. At first it'll be weak cryptography. This is supposed to be a super nice give with the guy and an operation swordfish hacking but whatever. So in Tor, since a year or two years ago, 024, 0.0024 and then we had 030. So maybe six version. Everything, every relay stock with elliptic curve cryptography ED 25519, if you're familiar with that. The only remaining RSA, weak RSA is in Indian services. The identity key of the service, that's the onion address is an RSA 124. So this is really bad and we do know about that. And the second thing is the Shawan. Tor still has Shawan here and there but Indian services also rely on that. So obviously if you wanna do a rewrite for next generation, I'm gonna get rid of that. So because of this weak cryptography and how old the design is, what we've started to see more and more is attackers running relays and they become dark three. So they get a lot of descriptor from different service. Remember that 50,000 service around the network. And then getting that descriptor because of weakness in the protocol, you can get the onion address in plain text in the descriptor. So descriptor looks like this. Rendezvous service descriptor, some yada yada yada. And then here is the permanent key which is the identity key which is the RSA 124 we talked about. And this becomes your onion address. So which means that people sit on the network and can list and harvest onion addresses. And what they do is that they get those onion addresses, they crawl them and then sell the data to some whatever corporation, law enforcement or military. We've been blocking those people for a year now. So we have some way to detect that which is a very clever system that we actually keep hidden because we don't want people to understand and just go around it. I wonder if I have a slide about that. I think I might have a graph showing how many battery relays we remove. But it's a non-stop issue for us. Now there are multiple problems with letting people to know onion addresses. So by design, onion services are supposed to be hidden. So if you wanna run an onion service, you should have this assurance that if you don't give out the onion address, nobody will discover it, nor be able to reach it. And remember with onion services you only need the onion address to reach it. So this big problem, and not only that, but there's a lot of people doing it. Now this is the darker predictability I was talking about. I forgot that this amazing slide. So this time period thing, you have invariant, this time period thing, so that means in two years, I know where the descriptor will be. What it creates is an attack that we've been seeing and we've been blocking for the last couple of months because we have a new detection that's been rolling out. So what you're gonna do is camp at the right place when you know the descriptor is gonna come in. So let's say you wanna know, you wanna camp those become the HSD'er of a specific onion address. Let's say WikiLeaks, for instance. So you wanna know, so you take the onion address of WikiLeaks, then we do this calculation, the onion address, the time period, and then you know it takes you 96 hours to have the HSD flag. So you put in the 96-hour time period, you do some math, and you know exactly what descriptor ID is gonna be in five days, 96 hours. And then you brute force your fingerprint to camp at the right place, and you become this HSD'er number two. So which means that every time WikiLeaks service will publish this descriptor, you will receive it. Now this opens up an all new set of attacks because you have a circuit, you're able to have a circuit from the service of WikiLeaks to your relay, but it's still a circuit of three ops. So you still have anonymity, but then there's other issues. Same thing, camping. So you inject yourself. The red thing is you inject yourself. Oh wow. Okay, this is out of order. This is how many relays we block every day. All circles, the red ones are 100 and more. So since 2015 up to 2017, we're constantly monitoring the network, and we're finding a shit ton of bad relays, trying to do this thing. So let me explain to you, coming back to the directory. Imagine you just camped as an HSD'er, so you computed the descriptor ID in five days, you brute force your identity keys, so it matches the descriptor ID in five days, and then you start up your relay. You wait 96 hours and you get your HSD'er flag, and then perfect, WikiLeaks is gonna upload your descriptor to you. So imagine Alice here is WikiLeaks. Now the second thing you wanna do is, and we've seen people doing that, is run guards. So guards, remember, is the entry point of a client and a service. So you run, let's say, 10 relays, and you let them simmer for months, and then they become guard after some time period. But then you have your HSDirect3. So this is a client anonymization attack. So that means if you pull off this attack, you will know everyone that is connecting to WikiLeaks. In this case, this is how it works. We start at 137 UTC, your guard gets a connection from a client. And then two seconds later, your directory gets a request for the WikiLeaks onion. All the red ones, you control. So you have this time thing. Okay, is this a hidden service connection? I'm not sure, remember, those are circuits. Now one seconds later, this circuit gets killed, because what happens is the directory, and this is how Tor works, the directory sends you back to the descriptor, and then kills a circuit. So then, one second later, the circuit gets killed. And what happens at your guard is that two more circuits gets created in the same seconds. One going to the IP, the introduction point, and one going to your rendezvous points that you picked. Now once you introduce yourself, this is a very short-term circuit. So two seconds later, it kills the circuits. So you have this nice timing pattern going on that you can see at the guard, and remember you control the guard, and then there's a lot of traffic going through the third circuits. So to summarize, you see this timing attack that you can just follow, and then you know that this client visited WikiLeaks or requested it. So this is problematic, and one of the reasons it's problematic is because a few years ago, we switched in Tor, I'm not touching it, we switched in Tor, so usually you used to pick a guard, a different guard for every circuit, and keep it for maybe a few hours. Now it turns out some clever fellow in some research lab was able to de-anonymize everyone with that, and the reason is would be to run a guard and make you connect the service 6,000 times until you pick his guard, and then it's job done, I just de-anonymize your service. So for that reason, this rotation of guard has been cramped up to three months. So every client that you have here, you keep your guard for three months. So that means if you're lucky enough to have the guard of clients going to WikiLeaks, you're gonna see everything. Not the content, of course, just the connection we're talking about. So that is one problem we're trying to solve. I'm gonna explain how we're trying to solve it later. All right, so this is a second attack. Now let's say you wanna discover, and oftentimes this is what people want, discover the guard of the service. So you don't care that 10,000 people are going to WikiLeaks, you do care where WikiLeaks server are because you wanna take them down. So this guard discovery attack is based on two issues we have. Well, two, maybe more, but let's say just two for now. The first one is that as a client, I can make the service create circuits. And it's done is because as a client, I choose the rendezvous point. So I'm gonna tell the service, go to that rendezvous point, one goes to that rendezvous point, two, three, four, five. That means the service creates five, six, seven circuits. So this is very nice because this gives you this kind of side channel attack at the guard that you can see and you can basically know what's going on. And then the second thing is hidden services circuits are very distinctive. They have a set of cells being sent and then the circuits dies as we saw with the timing of the client denomination. But on the service side also because if you run a service website, for instance, and then when your website is a specific size, it's gonna send a specific amount of cells. So at the guard, I can count those, but not even at a guard, I can also count those at the middle node, the entire tour circuits. So it works. So this guard discovery attack we don't really know if some people are pulling enough right now, but we have our doubts because in the last, I would say, four or five months, we've seen more and more relays that are not exit being taken down by law enforcement. So we don't really understand what's going on. It's maybe some just paranoia or they have no idea what they're doing or someone figured something out. So in this case, imagine you're only need to run the middle node and middle node are rotating constantly. Remember your guard, you pick it for three months. So you're the service, you're WikiLeaks, you have a guard for three months, but then you're gonna pick middle nodes to connect to multiple rendezvous points. So this middle node is very easy, no bandwidth as long as it's running, you can get picked. So you just run that. Sorry, and then what you want to do here is discover the guard because the chance that you are the guard is very low because it rotates only three months. So this and there's like three or 4,000 of those. So you just want to discover the guard, then take down the guard and go to the ISP, get some net flows and you know everyone that connected, you know where the service is. So as the middle relay, you can control an RP, a rendezvous point in the middle. Then your client, you make the service connect constantly to this RP and at some point it's gonna pick your middle node as in the circuit. And you know the pattern of cells going through the RP because you can control the data going in and out to the service. If it's a website, you can do like three or four double you get with a specific time rate and you know how many cells and then you just count that at the middle and then boom, you know that your middle is not connecting to your rendezvous point. So that means the inbound connection, it must be the guard. In this case, because there are two middle, so which one are you? But you know because you control the RP and thus if there's no inbound connection, if there's no outbound connection to your RP, you know you have to guard. This is a very efficient attack. Very low resource, you just need few relays and you just wait and at some point you just pick it up. If you remember 2015, maybe some of you remember because I'm pretty sure a lot of people here went to Black Hat. There was this controversy about those two researchers going to Black Hat and having this amazing tour talk. Did someone remember is that? No man. Two years ago and it was pulled off completely two weeks before Black Hat. Nobody knew, nobody know what happened, whatever. What actually happens and we made a blog post about it is that those were two researchers from CMU, the Carnegie Mellon and they for six months they pull off this kind of attack in the network but with some more nasty stuff which was this, which was side channel attack inside tour which I'm not going to get into because it's much more complicated but still they put it off. Now there's a downside to that because they didn't target one specific onion address. They targeted every onion address on the network and when you have governments like NSA or whatever that records encrypted traffic, well then this six months attack you can just replay the entire thing if you got the packets passively and then de-anonymize a lot of people. So following that we of course fixed the issue and created a research board which was basically if you're doing research and tour contact us and don't do it on the real network because it put people at risk, literally. And this kind of attacks we think that it's getting pulled off more and more and more. Thus this thing is very important. Next generation onion services. For people that are very curious we have this tour specification git repository and it's proposal 224. It's a huge proposal and it's basically to fix, try to fix everything. Now first of all, better cryptography. That is for sure. Tor right now is using massively ED25.5.1.9 in Curve but we also are using Keekac which is the shot three more and more. So we're dumping this entire RSA thing. It's really nice because Elliptic Curve basically fits on 32 bytes which RSA keys are humongous. Now the new addresses. That's a big thing that's a problem we're gonna have and I'm not even kidding here. 16 characters we're gonna go to 54 which is in a nutshell your ED25.5.1.9 public key with some two bytes of checksum at the end. So typing this gonna be a problem. We do have UX and UI people in Tor that are trying to come up with ways like pet names and registration and just throwing ideas out there so we can make Tor browser usable with those kind of address. But it turns out someone made some kind of research with Focus Group. Nobody actually types on an address. Nobody remembers them. So maybe it won't be useful to have a nice UI. I don't know but this is the reality of things. Now going back to the director predictability problem how do we fix that, right? We need something that varies in the descriptor ID that both the service and Alice can compute but it's still something that they cannot fetch because if they fetch it it becomes an invariant so what is it? So we created and it took us a year of last year to create a shared randomness. So behold or eight direct three authorities in Tor I didn't talk about that but how do you know where to connect? How do you know where the relays are? It's done through eight trusted entities which we call them direct three authorities. You have all their names or it's the real names and they're across the world. I think it's 50% in the US and 50% in Europe right now and it ran by trusted people we know. We met in person and so on and so forth. And so every hour they create what we call a consensus. The consensus is a set of all the relays. This is how you know where to go. This is how you know as a client when you start you contact one of those and then you get the consensus and then you know how to do your circuits. So every 24 hours since six months ago all those direct three authorities create a shared randomness, a shared random value, sorry. What it means is that we use a very simple system of commit and reveal. So for the first 12 hours they're gonna take a share random value, ash it and publish it in their vote because they all vote in a consensus. That's another topic. So they publish it. So all eight director, seven other other director authorities do the same and then they get all those values but they are ash. And then after 12 hours the next, the last 12 hours they do what we call reveal. So they reveal the value that corresponds to the ash. Now that creates a thing where they all have eight ashes. They sort them and then ash the entire thing and create a shared random value. And in the end all eight come down with the same value. I mean I can go on for hours on this because it took us a year to pull it off but it's something is being done. And because of that every 24 hour consensus has a random value. So it's kind of the NIST beacon of random just without back doors. So it's kind of really nice and we know that other applications are actually using it that are not linked at all. So what it creates then you have a, you cannot camp on the HSDR because every 24 hours of this new value and you get the HSDR flag after 96 hours. So you cannot predict where the descriptor is gonna be. So we just neutralize the camping attack. Now I'm gonna switch to guard. We've seen a bunch of problem with guards. This is the current design. On in services I'm gonna connect to a guard and a middle, another middle and a random report. And there's a reason why you do two middle here because remember one tour circuit is three ops but this thing is four ops. And the reason is because in anonymity research you never want to extend to a relay that you didn't pick. So the rendezvous point, the service didn't pick it. So because of that it adds a third up. If you have three ops you have anonymity. So one, two, three to the rendezvous point. Now we've seen this attack with the middle being bad. So how do we try to fix this? Now this gets a bit more complicated. We call this those vanguard proposal and remember the first guard is three months. Now three months is a whole lot of time for law enforcement or whoever to find your guard and then go to the ISP or the hosting provider and make them turn up the net flow records or whatnot. So what we went through is saying, okay we're gonna have a set of different guards. Those are called the vanguards. And then if you look at the bottom they, so it's all the no intersection between those sets and they rotate a different time. So the three months, 11 days and 12 hours. And the reason is of this, it literally, we went through a lot of politics and our law enforcement works and so on in different countries and we do think that around 11 days it's kind of tough for law enforcement to actually find it and then I get a subpoena and go get it and then go back to the other guard and then subpoena it again and 12 hours as well. So we came up with this scheme that we think would be better. Now the other thing with that scheme is that to put yourself in one of the guards set for the didn't service you're looking for it's gonna be much more difficult. Of course you can become the primary guard and but if you do as WikiLeaks service I'm fucked anyway. So this is a vanguard proposal. This thing we're still working on it right now. It's kind of very complicated. There's a lot of anatomy team issues and it needs a lot of research. But we're getting there, we're getting there. So I've talked, there's one thing I forgot to mention here. So remember descriptors have the onion address in plain text so that means we have this our vesting situation, our vesting onion address situation. So how do we fix that? It's very simple. It's make the descriptor encrypted so the didn't service doesn't know what's the content. And we created that with this very nice blinded key scheme which I do not understand but there's a lot of research paper being done. It's that have been done and we implemented that. We have really good photographers that did that. And the client and the service creates a key based on the time and derive, I'm sorry, from the onion address key which we call a blinded key. And no matter how many blinded key you see you cannot go back to the identity key. But the blinded key, the difference is the blinded key can be associated with the onion address, so the identity key if you know it. This means if client and service are the only one who can decrypt the descriptor which means the directory doesn't see the onion address. So we fix that way. So you won't be able to harvest on your address. You won't be able to camp in the ashring as an HSDer. You won't be able to pull off this middle attack as a guard relays, we have better cryptography. And this new thing also which is called single onion services that has nothing to do with any attacks but it's really nice. Oftentimes services don't need anonymity. And what I mean by that is if you run Facebook servers we all know where the Facebook servers are and they don't care, they tell the world where they are. So you can remove this entire anonymity three up circuits from the service to the rendezvous point. So this is what we did with single onion service. You can set up your service as a single onion and you lose anonymity on the service side which makes this thing way faster because now it's only three ups and then the service. For instance, Facebook 2005, I think, they fire it up in on your address. So you can reach Facebook nowadays through their reading service and they have millions of people connecting to that. And we're the forefront of beta testing this feature and right now they are running single onion service. So you'd only do four ups to Facebook instead of six. I'm almost done. Progress, where we are. So shared random is an 029 stable. Just a reference point, two weeks ago I think we released stable of 030. So 029, 030. So shared random is 029 and this nice line shared random current value is what it looks like in the consensus. So if you fetch the consensus you, this is how the shared random value looks like and every 24 hours it changes. The directory system is all coded, it's all integrated, it's been released in 030. Service implementation was the biggest piece of effort. This is what you're seeing right now is a three year engineering effort and we're coming to an end by the end of the year. The service implementation thing is a humongous effort. It took us a lot of time but we're there. Right now we're stress testing this entire thing. It's gonna be an 032 which will be stable by December. The reason it's not an 031 is because on Monday it was feature freeze and I was here. So couldn't release that thing, 031. The final one is the client implementation and once the client permission is done we have all the pieces and we hope it works. So we're aiming for December 15th. This new random service generation will live in parallel with the current system. So the current system and the next generation for years they're gonna be in parallel so it's gonna work. And the reason is that we went through many discussion with the community and killing the legacy system will be a disaster, everyone will freak out. So for many years there's gonna be this transition path. Thing I'm pretty done. Use Tor and this is about our new services.