 Okay, so I'm here from Zero Knowledge Systems, a company in Montreal, Canada, and I'm going to tell you about the system that we're building called Freedom. Freedom is a commercialization of basically my PhD research, which is a pseudonymous communication infrastructure for the internet. Can you say that, please, and go? Basically, the idea is to allow you to keep some extra bits of privacy when you go online. Right now, I'm sure, as all of you are aware, the state of security on the internet is pretty abysmal. Any time that you send email, or surf the net, or whatever, who knows how many people are watching what you do when logging everything. Not just the website operators that you're connecting to, but possibly ISPs along the way, or random people that have owned random boxes on the net. What we'd like to do is allow, give you the technology, in true cyberpunk fashion, to protect your own privacy online. Right? What we'd like to do is give you the privacy to protect, give you the software to protect your own privacy online. And the point is that you shouldn't have to trust anyone else in order to keep your privacy. Now, there's obviously only a certain amount, a certain distance you can go there, right? At some point you need to trust Intel, right? That their chips aren't doing something really evil. But under some fair assumptions, you can avoid trusting some central site that you don't have a prior arrangement with to keep your transactions private. So, I'll first give a short overview of what the Freedom Network is, and briefly how it works. And then what I'm going to do is basically throw the floor open to questions and see how that goes. That seems to have been a popular way to handle this talk in the past. And normally all the right questions come up, so we don't end up missing anything. Okay, so how many of you are familiar with other privacy enhancing technologies, as they're called like remailers and stuff like this? Okay, scattered number. So, the idea of a privacy enhancing technology is it's a technology that in some way allows you to keep better control over your private information which could include your identity or your communications or something like this, right? PGP is a classic example. It only solves the data confidentiality problems and data integrity problems. It doesn't solve, for example, the traffic analysis problem. So, let's draw a little picture of the different problems you can solve. So, at the lowest level, you have secrecy of data, okay? If below this you have of course just clear text. At the lowest level, everything you do online or through email or web or whatever is just going in the clear. And anyone with access to a machine between you and your endpoint can just read that value, read the messages and do what they like with them. They can modify them, whatever. On one level above that we have secrecy of data. And what we want to achieve there is that an eavesdropper be unable to read the contents of your messages, okay? So, the eavesdropper, Eve, knows that Alice is communicating with Bob, right? A PGP encrypted message went from Alice to Bob, but Eve doesn't know what the message says. And can't, and if you use PGP in a certain way, you can't modify the message so that Bob receives a different one. So, this is encryption. PGP, for example. This is basically a solve problem. We know how to do this, right? The fact that everyone isn't using it today just by default is a side effect of stupid politics. And we've had other sessions on this topic at this very camp, so I won't go into that. Let's look at the next level above. This is the level we're trying to address. Traffic analysis. So, a traffic analysis is being able to learn interesting information just from the fact that Alice is talking to Bob, not knowing what they're saying. So, for example, if two CEOs of two companies start sending a lot of email to each other, I know a lot of stock traders that would be very interested in that information, right? Even if they didn't know what the contents of the messages were, just the fact that there's suddenly a large amount of traffic going back and forth between two companies is interesting. And the point of a system that defeats traffic analysis is to hide that. Other kinds of systems include things that the anonymous remailers try to do so you can send email either anonymously or pseudonymously, and even your recipient doesn't know who it really came from. This is in contrast to the previous example where it's assumed that the two CEOs know each other, but we're just hiding the identity information from the eavesdroppers in the middle. In this case, the sender is hiding her own identity from even the recipient as well as all the people in the middle. So, there are a number of different versions of this. So, this is the kind of thing we're trying to do with freedom. So, with freedom, the way it will turn out is that if someone's watching the network, it's obvious that any, that some given person is running freedom, right? They're sending all these funny encrypted packets all around and things like this. The eavesdropper can't tell who they're talking to what they're saying, what websites they're visiting, what IRC channels they're on or anything like that, but they can tell that they're running freedom and so they're doing something possibly interesting. Some countries don't even like that much, right? There are certain situations where just running software such as freedom would not be advisable. So, above this, there's another level of steganography. This is beyond the scope of this talk, but with steganography, the idea is to hide the very fact that you're communicating at all. So, with traffic analysis, we'll start the bomb with secrecy of data, we're trying to hide the contents of the message. With traffic analysis, the adversary knows you're communicating, but not with whom and in steganography, the idea is to hide the fact that you're communicating at all. Obviously, the challenges go up as you go up this scale and so does the interesting work. Okay, so we're going to be in this space right here, where we're going to try to defeat traffic analysis. I'll give a brief overview of how this works. Around the internet, what we do is we deploy a number of nodes called freedom servers and they're linked together in some fashion and these links are used all the nice crypto stuff, encryption, authentication, link padding, things like that. I'll get into more detail about those links in a minute. So, what happens is a client connects to the freedom network and what the software does, the client installs the freedom software on his PC and what the software does is intercept the outgoing IP packets and instead of just sending the IP packet out to the internet to its destination host, say destination host, say some web server here, the packets will instead be routed through a number of these internal nodes in the freedom network and eventually, so it's a different color and eventually come out and go to the web server. The web server in its logs, it will just look like it's this machine that requested the page. This connection is in the clear because otherwise we'd have to modify software on every web server in the world and I don't want to do that. So, this link is in the clear so everyone knows that somebody from the freedom network just requested this particular page but you can't tell who. The basic way we achieve this is by using this link padding I mentioned earlier where what you want to do is make it impossible to tell whether and in what direction actual data is flowing. So, you can imagine someone just TCP dumping each of these segments here and just seeing well traffic goes from this one to this one and shortly thereafter from this one to this one and shortly thereafter from this one and so on and correlate the times packet arrives and things like this and the sizes of the packets and these are both problems with, for example, the existing remailer network. Certainly the type one or cipherpunk remailers are totally vulnerable to an attack like this where you can just look at the sizes of messages coming in and out of the remailers. The Mixmaster network, the type two remailers, have fixed the problem of different sizes. There's still something of a timing problem but that the network somewhat alleviates by doing random delays and shuffling and reordering of messages. So, obviously random delays is not an option here. Mixmaster delays pack messages for like hours often. So, I don't want my ping times to be on the order of hours. TCP just wouldn't like that. So, we have to do something different to protect against traffic analysis. What we do is instead of sending, we do also the fixed size messages so all packets are one of a number of fixed sizes and instead of just sending packets whenever they're needed to be sent, we send a data independent amount of traffic and what that means is that regardless of the amount of data we actually need to send, we're going to send some pattern of traffic anyway. So, if we don't actually have to send any data, we'll just be sending a lot of random packets and the idea is that an adversary can't distinguish a random packet from an encrypted packet. So, the adversary looking at this link will see just this flow of packets and he can't tell which ones are filler and which ones are meat. Now, the simplest data independent function is a constant function. So, the easiest way to think about this is just we just send a constant rate of traffic on each of these lines. Now, it turns out that's not good for performance and there are other clever things you can do but as long as it's data independent, you get the properties you want out of it and that means it can depend on other things like the time or other properties. You can say, well, this network isn't heavily used at night but so there's more free space so we'll put more padding traffic in there to accommodate the people who go home at night and use the internet then. So, that's a brief summary of how we get packets around. At any point, if there are any questions, just throw something at me. Yeah, out of voice. The answer is the internet. We would love to have it over a dedicated network but, hey, I mean, we're a start-up, right? We can't lay our own fiber. In fact, there are some other clever things you can do if you're allowed to redeploy the whole infrastructure and I'll talk about the reasons why that is. There's actually a very interesting theory behind why it's a lot easier if you do that other than the obvious things. Yeah, so just like emailers, each freedom server only knows its neighbors. So this one knows it got a connection from him and it's supposed to forward it to him but he doesn't know anything downstream including where the eventual website is or what kind of traffic it is or anything like that. The last guy, in contrast, knows what websites are being visited but doesn't know who you are. So the standard argument is you'd need to break, you'd need to compromise every remailer in the chain, sorry, every freedom node in the chain in order to compromise the security of the system. So this is actually a hard problem. This is one of the reasons you get a PhD out of this. Oh, the question is if these servers don't know where the end site is, how does it route packets through the network? The answer is it doesn't. These servers just use the internet routing to route packets to the next servers. It's the client that chooses which intermediate servers in the network to do. Now that's a non-optimal solution. It's very similar to onion routing, yes. And the problem is if you know a lot about networks, you know that if you have a big network, source routing is hard. And there's a question? So what happens when you add a node is there's a database called the Network Information Database. It's distributed, yeah, or it should be. It's not, so we would like it to be more like a routing protocol. Right now it's totally just sort, the clients learn the entire state of the network. Right, okay. I'll do that in a bit. I'll just take some more questions here. So that's the measurements that we're doing. We're just bringing up this network for real like in this last month. Right now the client software is in beta 2. We have something on the order of 40,000 beta testers signed up. So we're getting that out slowly. So what happens is the nodes report when they're losing data. They can tell when traffic isn't coming in. And they report that information to the Network Information Database. And then clients, when they're building their routes, use that congestion information to avoid congested links. So we have some load balancing going on in there. Yeah. Okay, good question. The answer is, the question was, we use a MixMaster like method to get data from the client to the server. How does the response find its way back to the client? And the answer is the same way it does in MixMaster basically. As you set up a connection, so okay, I'll do this now. So what does it look like when we're setting up a connection? We have another color. So let's say this client wants to establish a route through these four servers here. Okay. What he's going to do is, the first thing he does is picks his closest one. And this is usually the one that's physically closest to you, netwise. So preferably your ISP, if not just some other close by freedom note. What? So for in the betas, right now, we just have you manually pick what city you're in from a list. Eventually we'd like to do an automatic detection by ping times and stuff like this. But usually we can assume that the user knows what city he's in and can pick it from a list. Yeah. That's not that. Right. So that's what we want to do eventually. Just do ping times and stuff. Okay. Question Okay, well, we'll get to that after we learn how to route. After we wrote, we can reroute. Okay. So I'll get to the proofs of security later. The short answer is it's secure against all passive attacks. There are some active attacks that can do interesting things. And there's some other things you can prove that there are there's only a certain amount you can do against certain kinds of active attacks. You can't prevent them all together. For example, if you assume an adversary that's able to shut down arbitrary amounts of the internet in real time at will, you're pretty hosed. Basically, if you want to figure out who is talking to this web server, he just shuts down the entire internet except for that web server and like one other freedom node. And if the traffic keeps going, then you can backtrack to the next one and so on, right? So yeah, you send a reset packet to the BGP ports on the backbone routers. That works pretty straightforwardly. Okay, so we continue. So after choosing the closest one, he also chooses his exit funnel. And this is a user choice as to where do you want to appear to be? Because the exit node is the one that the user appears to be at to the logs and everything. Sometimes it's useful to appear to be in a certain country for legal reasons or political reasons. Right? So for example, if you're trying to download crypto software, you might want to appear to be in the US or something like that. But I wouldn't advocate that. Okay. And then in between the client can either just pick them randomly or the client can configure his software to say, I never want to go through these servers. I don't trust them. I always want to go through these servers. I trust them. The important thing is that you go through a set of servers that you don't believe will all be compromised or all collude. So if there was a server run by the US government, I wouldn't mind going through it as long as there were also one run by the Iraqi government. I could go through that as well because the odds of those two servers colluding are very small. Okay. How does the setup go on? The client basically sends a setup packet through the network, which establishes secure communications between the client and each server in the chain. So in addition to having these link level encrypted tunnels between servers, there's also going to be a set, and unfortunately I've used my blue, between the client and the first server, the client in the second server, the client in the third server, the client in the fourth server. No, it will go through this, right? So think of it like an expanding telescope, right? So you have nested secure pipes. So what happens basically is the client sends a setup packet to the first guy, and that setup packet contains some information like who the next guy is, a set of encryption keys to use to decrypt data going that way and encrypt data coming back, a timeout value and serial numbers, some other things to prevent replay attacks and stuff like that, and then an encrypted payload encrypted for this guy that he just passes on to him. This guy, once he's done that, he sets up, if you're familiar with how ATM routing works, not the bank machines but the synchronous transfer mode stuff, they have these virtual circuit identifiers, and that's basically what we do as well. So this guy sets up a virtual circuit and associates that with the incoming connection from the client and the outgoing connection to the next hop. So now this guy gets the encrypted payload for him decrypts and he finds the same thing. He finds a couple of encryption keys, the address of the next guy, and a block of data to pass to him, and so on. And then when this last guy gets it, he sees that an indication that he was the last hop and we're done. And then just an act goes back through the network and the route is set up. Then what all those encryption keys were for is that when a data packet is dropped on the wire here, before you drop it on the wire, the client will take the decryption keys that he sent to each of these nodes and encrypt the packet with those keys. So first with this key, then with this key, then with this key, then with this key. When that packet goes to here, this guy unwraps the outermost layer of encryption. That packet came on this virtual circuit, according to my table. That means I have to now send it to this guy. It means I decrypt it with this key. I send it to this guy on this virtual circuit. Then it goes to here and he does the same thing and eventually gets to here and this guy unwraps it, sees, oh, this is an actual packet and sends it over the net. So it turns out the encryption is trivial. Encryption is much, much faster than networks. This is all symmetric encryption. The route set up actually uses some public key encryption, but that's just once. You do that once every while, like half hour to an hour or something. You might want to change this. Or if one of these goes down, this was that other question. If one of these goes down, then the client will notice that fact that he stopped getting packets back and will actually right now I think it prompts the user, but it could just as easily do it itself, just set up a new route automatically and just continue. As long as then, if it's not the case that this is the machine that went down, then if you pick another route that ends up at this machine, then even your existing TCP stations will stay up. Because as far as anyone knows, as far as this guy knows, this was the source. Of course, if this machine goes down, all your TCP connections will fail because the source IP address is no longer valid. This system is what we call an IP wormhole. The idea being you set up this route through the cloud, the freedom network, and you have a specified exit point. You can just drop packets into this wormhole. They do some magic in the middle and they pop out where you want them to. In the middle, no one can see where that packet went or how it got there or which way it took. But once it pops out, it looks like it just originated from this point and no one watching can tell where it came from. For all anyone knows, this node itself could be generating the traffic. You set up the session for a long time. What happens is if this guy connects to a different server, then the packets pop out here and then just go over the normal internet. He's really setting up a connection to this guy, not directly to the end server. When he sends packets to him, they'll go through this network and then come out there. Luckily, it's soft state, so it's not as hard to deal with the scalability problems. Yeah, well, so are we. Again, this is why it's a PhD research topic. Yeah. Oh, okay. So it turns out that doesn't help as much as you think because regardless of where the packets come from, it's pretty easy to follow people going through a website. Right. So the underlying network, which I haven't really described fully yet, what I'm showing you here is the underlying network, which we call the anonymous IP infrastructure. And this would support what you just said. However, on top of this, we've built the pseudonymous IP. And the reason for that has to do with that theory, which I guess I can get to very shortly. The idea behind freedom is not to give you anonymous access to the internet. It's to give you pseudonymous access to the internet. So you can use the internet under one or more pseudonyms and the pseudonyms aren't linkable to each other or linkable to you. But whenever you're browsing under one pseudonym, it's apparent that all the transactions that are going on under the name of that pseudonym are in fact by the same person. So if you want to say that, well, I'll go to this website under a different pseudonym, that'll work great. If you keep in your mind that you want to distinguish this part of your life from this part of your life, which is always a good thing. But the point of having pseudonymity is I'll do right now. So this is the concept. This is sort of the motivation behind what we're doing. This is what we call the nimity slider. And you can think of this as a slider with a control knob that controls how much information about your identity is revealed in a transaction. On the one end you have complete anonymity. At the other end you have true name. Now just thinking about what a true name is, is a little bit of a philosophical discussion in itself. I don't necessarily mean the name the government knows you as on your birth certificate. A true name is really just any piece of identifying information that can pick you out of a crowd. So if there are a crowd of people that could have been the one to perform this transaction, if I had true name information it means I can select the right one from that crowd pretty easily. So other examples of true name or close to true name information are credit card numbers or biometrics or things like this. And one other aspect of true name system is you basically get one. If once someone discovers your true name in any respect, say they discover your name or social security number, it's pretty hard for you to get a new one. So if someone tarnishes your reputation, in the US this happens all the time with credit reporting. I have no idea what the situation is like in Germany but in the US there are basically three big companies that keep track of every monetary transaction you do basically that they can and keep these lists of how good a credit risk you are. Similar in Germany. And the problem in the US is that often they make mistakes and you get your credit record having bogus things on it. It is notoriously difficult to clean it up because you only get one. So that's what true name is. Complete anonymity is pretty straightforward. That's where you walk into a store, you pay cash, and you walk out. So they're always, and sure, yeah, okay? So in fact it's not, okay? And in fact robbing a bank is probably more this next thing which I'm going to talk about out here, a little bit up which is linkable anonymity. Bank robbers have styles, they have modus operandi, right? If a bank robber, if the same bank robber robs four or five banks, usually it's obvious that it was the same one, right? This is the distinction between complete and linkable anonymity. With complete anonymity when looking at two transactions you can't even tell if they were done by the same person or not. With linkable anonymity you don't know who the person is but you can tell it was the same one as before, okay? So examples of this, other than bank robbing, prepaid phone cards, right? GSM cards, you don't give any identifying information when you buy them, so when you make a call it is anonymous but anytime you make calls with that same card they're obviously linkable together, right? Would be what? Voting. So there, well there we hope you don't vote twice, I mean the system is designed such that that's not supposed to happen. But, right, anytime that you can tell if it's the same person a second time we call that linkable anonymity. Further up we have persistent pseudonymity. Now this is very similar to linkable anonymity, this diagram is not to scale. With persistent pseudonymity the idea is that you have, you have some name, some well identified name, it's just not your true name, right? This is a name that either was assigned to you or you have picked for yourself and it has a number of properties. One is that you can have more than one of them. So you can have a number of different pseudonyms and this is useful for the reason I mentioned earlier that if you have only one and it gets dirty you're pretty hosed. Another useful reason to have more than one pseudonym is that you don't necessarily want your life that's logged when you're looking for a job to correlate with the life that's logged when you're looking for a date, right? You do different things in your real life, you do different things online, there's no reason why you should have to correlate, be forced to correlate these things together. The one huge advantage of persistent pseudonymity is that you can assign what we call reputation capital. So if someone named TC May posts to a mailing list you're on, you've never met this guy before, you have no idea if that's his true name, right? What's written on his driver's license. But as he posts over and over again, you get to recognize him and he gains a reputation with you either as being someone who you tend to agree with or someone who you tend to disagree with to pick an example out of that. And one very important feature of persistent pseudonymity is that we try to discourage or prevent spoofing, right? We don't want anyone to be able to post as TC May because that will just confuse people even more if half the time the guy posting there knows a lot about quantum physics and the other half even knows a lot about space aliens. So persistent pseudonymity is one of the most useful places to be on this slider just for social reasons. Because you can have, you can have reputation capital but you aren't restricted to one true name. That's a very useful place to be. Now one of the important properties of this slider is that if you build a system with the slider in a certain place, it's easy to move up and it's hard to move down. Okay? So what I mean by that is that let's say you have a system that supports complete anonymity, say cash transactions, right? That's a system that can support complete anonymity. If I walk into a store and pay in cash, I can walk out of there anonymous. If the shopkeeper and I in the course of doing business want to agree that as part of the transaction I will reveal more information about my identity, that's up to us and we can just do that, right? I can tell you my name while I'm giving you cash. So it's easy to take a system that was designed down low and place the slider anywhere you want above that, okay? On the other hand, let's say you're trying to buy something online today. Pretty much the only way to do it, to first approximation, is to send your credit card number over the net, right? We'd love that to be different but that's the way it is today. Credit card numbers are basically true names, right? As I mentioned before, you have trouble changing that kind of information. It's way up on the sand anyway. So let's say you wanted to buy something anonymously online. Can you give your credit card number but just withhold the identity information? So no. So this is the fundamental property of this slider. Possibly should be more logically called a ratchet. That when you design a system, you should not force identity information to be leaked in the system because then it's hard to remove it. If you design the system down here, it's really easy to add identity if you want it. So with that in mind, let's look at the internet today. The internet has these IP addresses all over the place, the source IP address and all this and those are really close up here to true name, right? You basically, most people only have one ISP, right? Or a small number. It's really hard to get an IP address in a random spot on the planet and if someone, if you're one of a bunch of people and someone knows what IP address a certain message came from, it's usually pretty easy to figure out which one of those people it was. So the internet is up here and by the theorem that says it's going to be really hard to do any of these things on the internet. For example, anonymous electronic cache. We know the protocols, right? We have the software, mumble licensing patents mumble. But there's even yet a fundamental problem with deploying anonymous internet cache software, which is that as soon as you connect to the mint or to the shop, they're going to know your IP address, right? That's not anonymous at all. So we need some kind of anonymous communications infrastructure in order to use at all the anonymous commerce infrastructure, which we could build and there was a talk last night, I think, of Nerd Bank. So we would, in order to use any system like that, we need an anonymous communication infrastructure. So or at least something lower than what we've got now on the slider. So with this principle in mind that this is a ratchet like thing, what we did is design the system to be an anonymous IP infrastructure, something way down here. And then build on top of it, the persistent pseudonymity. One reason for this is so we can change our minds later. If we decide that anonymity is a good thing, then we can just do that. We just remove the requirement that you state your pseudonym when you make a connection. And so what I've shown you so far, the the route, the freedom nodes and the routing through it, that's all part of the anonymous IP infrastructure down here. Basically, the difference that makes it persistent into persistent pseudonymity is that when the client sets up this route through the network, this last guy, when he sees the, the route create packet that says, okay, you're the last hop, he also expects that packet to be digitally signed by some pseudonym. And if it's not, then the first approximation he just says route create failed. It turns out we do allow some kinds of connections through the network that are actually anonymous that you don't need a pseudonym for. For example, connections to the machine that generates the pseudonyms, right? Otherwise, you'd have a nasty bootstrap problem. But in general, you need to prove you are some particular pseudonym when you create a route through the network. Note it's important that that happens here and not here, right? Because this guy knows the true IP address of the client. It's important that he never learned what NIM the client is. On the other hand, this guy doesn't know who the IP address of the client, but he does know the NIM. Right, so we have to, we're basically doing NAT here, right? We're doing this massive NAT where you drop an IP packet somewhere and it appears somewhere else with a different source address. So all the protocols that have problems with NAT, such as FTP, we just have to colluge in the same way. We have to reach into the data stream. We do that here, actually. We reach into the data stream and remove identifying information from the data stream. And then that can be filled back in here when it knows what IP address to connect back to. And of course you're going to have, because this is also the system as deployed does not allow for servers to be listening on anonymous ports, you're going to just have to do the passive mode tricks as well. But it all works. Yeah. Right, but it's transparent to you, right? That's right. In fact, it's unclear you want it to be totally IP transparent for sociological reasons. For example, we don't really want someone doing a Smurf attack through the network, right? Sending arbitrary IP packets. So what we have are application level proxies both on the client side and at the exit server. The ones at the client side, their purpose is to protect the user from information leaking out in the data. So for example, removing identifying information from the FTP data stream, removing control stream rather removing some headers from HTTP requests, removing identifying information from email and stuff like that. The purpose of the application level proxies here is to protect the network from abuse. So for example, limiting the number of email messages anyone nim can send per unit time in order to avoid spamming, right? We don't want people using our network to spam everybody. So we just limit you to a certain number of email messages a day that makes it totally un-cost efficient. Yeah. Right. So obviously, there's a threshold, right? If all of them are compromised, you're obviously toast. And if none of them are compromised, you're obviously safe. So obviously, there's some threshold. And the threshold is basically, to first approximation, when all of the nodes you have chosen are compromised. Any? Whoa. Usually have one at a time. Yeah. And they last for like some hours or something. Yeah, so their congestion information. Yeah, I mentioned that earlier. There's congestion information in the network information database. Right. The user will also just be if one of them decides I just don't want to take any more connections, the user will just be informed of that when he tries to make the connection. He'll say, No, you can't use that one. Try again later or try a different one. Can the government track you down? So again, this depends on how much power you think the government has, and how much you think they're willing to spend on tracking you down. So if they have the power to do this shut down large pieces of the internet, then they probably can. But they'd have to do it in real time. So it's it's still pretty complicated. So governments are still a little bit loathe to actually pass laws, explicitly restricting personal freedoms, right? Certainly. Right. Well, that's the case in the US as well. And, and there are actually some interesting stories going on right now with with how the US law and Canadian law are interacting with cell sites along the border. But basically, the idea is we want to deploy it before the government's notice. And then once a lot of people are using it and hopefully have their lives made better from it, it'll be much harder to for governments to say, Oh, no, we want to stop that, right? Imagine if if governments all of a sudden thought chat rooms were a bad idea, right? You know how many people use chat rooms now? I mean, say it's a substantial fraction of the actual population. So if the government tried to make something as popular, something very popular, illegal, there's significant social back pressure on them. Prohibition, for example, right? It took some time, but they finally came to their senses. Right. So that's how we're going to deal with that. Just don't. Yeah. In fact, the name of the company is zero knowledge for a reason. We have, we have no desire to know the true identity of our of the NIMS, right? We in fact explicitly go through several hoops and complicated things so that we never learn what real user is behind what NIMM. Now we do know for the most part, as I mentioned earlier, we're not doing steganography. We would know, for example, that you are a freedom customer, right? You are using freedom, whether you bought it from us or you bought it at a store or whatever. By looking at the network traffic, it's clear you're using freedom. But we have no idea what NIMS you are, and what you're doing with it. So no, there's no legal, legal theory that says a service provider needs to have true name like information for his customers. Well, they don't, right? That's the thing. These nodes. So there are a few countries where the nodes are required to provide tapping interfaces, but they can't. They don't have that information. So you don't use the service in Germany. They put all service in Germany. As long as you're using services outside of Germany, that doesn't affect it. Just doesn't affect it. Okay. Okay, you think about that. And what's that? So okay, we use mechanisms known as perfect forward secrecy. In order to avoid attacks like you just tap all the traffic today recorded on a big tape. And then sometime in a year, you, you go knock down their door and discover their key and get all the traffic from the past year. So the idea behind perfect forward secrecy is that in order to decrypt the traffic, you have to know the key in real time. Right? Once the session is over, keys which were ephemeral, ephemeraly created using something like Diffie Hellman, for example, are forgotten about, right? The servers don't keep a record of those keys. Okay, so if the first server gets compromised so that the key is released, then you still only learn the next server. No, those are, those are session keys shared symmetric keys shared only between the client makes it up on the spot makes up this random key and sends it to him and sends it to him, but he sends it encrypted with their public keys, right? Right. Well, then we're all screwed, right? Yeah, so in order, in order to get the shared symmetric key shared with say, this guy, you'll have to know not only know that he's talking to this guy by compromising these two first, but also get compromised this guy and get his his the private half of his public key pair. Yeah. So I want to get to that question later. Because it's an obvious question. And yes, and it's really interesting. But I'll handle. Okay. Well, it's the same thing, right? You. So it's a service based model, right? You, you pay for pseudonyms. Basically, that's right. Yes. Yes. What? Oh, implying that the client and server are freely available. Yes, the client is free software, it will eventually be open source software. After we're done with the betas and all that. The servers, not only are they are they free, we pay you to run them, right? So server operators get a cut of of money's coming in from clients. So that's actually something that some server operators for have asked for in lieu of a cut, like a bunch of free pseudonyms. And I mean, it's totally a business decision. So obviously, does not have any technological implications. So I mean, you just work out a deal with the business manager. And so ideally, no, but that's that other question that I'll get to later. Yeah. Yeah, so that's always the case that it's true today that web servers can block any large network they want, they can block AOL, they can block freedom. Funnily enough, that you see just the other day, network, network solutions was threatening to sue, to sue the black hole list, because the black hole list blocked network solutions, because they keep sending spam to everyone who has a domain name registered. And and after trying to get them to stop, and network solutions didn't stop, they went on the black hole list. And now network solutions is threatening to sue them for it's unclear exactly what but but this is this is the thing in the US. So so everyone can sue anyone for anything, right? That's right, that that's what they said, that if you just block all traffic from us, you'll not only block the spam, you'll block the actual bills that we send out, and customers won't receive them. And then their their domain names will go away and will be all your fault. It's like, Yeah, right, stop sending spam and we'll make the problem go away. You can do that. It's yeah, it's totally up the user to configure whether he wants a random exit point chosen or one that's near the destination. Actually, you can't just automatically choose one near the destination, because the exit node is just where the packets come out and then packets from there can go anywhere on the internet. So unless you know, you're only going to be communicating with one host, and thus manually choose a close one. You can either say, I want to appear to be in Israel for some reason, for some legal reason. Or you can just say random. Yeah, from the end node to the web server. Always run traceroute. That'll just work, right? The traceroute packets will drop into the wormhole appear here. What? Of course you can. Yeah, yeah, UDP packets just work. Yeah, this is this is doing it. If we didn't force things to go through certain application level proxies, then we this would just be an IP wormhole. An arbitrary IP packet would disappear and reappear could be anything in IP. What we do is for certain protocols, we just allow it to go through if we don't need to munch it. And for certain protocols, because of the FTP problem and masquerading problems, we have to munch it through through a proxy and certain things like if we see you're sending a Christmas tree packet, we'll just go and turn it into heat. Right, so that's the thing. But as long as most of them or many of them are set up correctly, it doesn't break down. So that's why we don't have to require a strict standard. But certainly we have suggestions, right? Well, we have basically a list of recommendations that I don't know if it's on the website or not, but certainly it is. Yeah, so it's on our website. And certainly people are free to make comments on it. Yeah. Yeah, the I mean, as I said, this is my PhD thesis. So all the protocols and stuff are going to be published. We'll make an informational RFC out of it even. And after that, we want to encourage people to write clients say for different OSes. And who is someone going to ask that question? So we're startup, we don't make money. Venture Capital, right? We actually are just doing Venture Capital right now. We were privately funded for a long, long time. And we just recently did a VC round. So the private fund part was a very important piece for me about zero knowledge, because if you trust the people who fund this, you know, Microsoft says, okay, we're just going to buy this and fucking change life. Right, right. So I mean, certainly I couldn't comment on specific policies for choosing VCs, but we're obviously well aware that we want to keep control over what's going on. And we don't want some to be bought out by someone who will just kill the project. So I can't comment on it. What does it run on? Yeah, yeah. So right now, the servers run on Linux and Solaris, the client runs on Win95, 98. Come on, who's our biggest market? If we're going to, yeah. So now it turns out that servers have to have basically a client without a UI in them, because they have to all the same things the client does. So the Linux client works for some value of works in that it's basically a lot of little programs and shell scripts that don't even have a consistent interface or anything like that. But it will be nicer by the time we actually say this is the Linux client. But the Linux, the set of Linux scripts is what we use to test the system, for example, right, we can set up routes, we can send packets, you can do all the things you want, it doesn't have a pretty GUI, but we don't want that anyway. Although it's really pretty on Windows. We had some really good GUI guys come in and do it for us. Yeah. So there's a time to live, right? And there's a maximum number of hops you can, you can send a packet through. So it can't loop like that. It's centrally administered because we want, at least initially, to have some control over the topology of the freedom network. So when a server operator wants to join, basically, he contacts us, you make an arrangement with him, we say, okay, you'll come up, you're in the Netherlands, there are these other nearby ones you should be peering with, and we manually set up the peering tables. We don't anticipate that server nodes will be coming up at such a high rate that we'd want to put a person out of the loop on that. That's right, they don't have to be totally trusted. We do try to give some indication when someone runs a server of what organization is running it and things like this. For example, if we know that some company is running 20 servers around the world, you want it annotated in the network information database that these 20 servers are all run by the same company, and so you should never pick two of them to be in your chain. The software will automatically do that. The congestion information is in the distributed database, but it's signed. It goes to a central place where it's signed and then published. Compromised nodes can't forge that information, so they can prevent you from having it. I mean, denial of service attacks you can do very little about in general, but they can't give you fake information. What we want to do is distribute it so that we're not relying on any one piece of trust. There isn't a central administration point for all the nodes. There's the set of keys that sort of, there's the CA, basically. There are the CA keys, and obviously if the CA is compromised, well, that's bad. We know how to do this, but that is basically the point of failure, which is if the CA key is compromised, then for example, no more NIMS could be created. This is also an answer to a similar question. What happens if we receive an injunction? The Church of Scientology comes and says stop. So the answer is we run very little of this network. So if they come to us and say stop, basically what we'd stop doing is making new NIMS, but we have no way of stopping the existing traffic from flowing, and we want to make sure that's the case, that it would be very hard to stop traffic from flowing. So technically it would just work. That's right. It would just work in some sense of just work. Obviously they're the business interests to consider, and that is also one of the discussion points about making the servers in particular open source, because the servers are the things that check that you have a valid zero knowledge NIM. So the feeling is once we get a lot of these out there, and we have some critical mass, at that point, it turns out there are other ways you can you can make money, which should a little thought you should be able to come up with them. So at that point, it's not going to be as as important a business issue. And then we can do all sorts of other fun stuff. But we need critical mass first. Right. So as I said, against passive attacks, it's great. So against people just sniffing the network against active attacks, there are, yeah, that's not quite passive because you have to compromise two nodes. So in active attacks, where you can actively go out compromise freedom nodes, or you can inject traffic into the system or do other types of things like that. It turns out there are a lot of interesting things the attacker can do. And our job is to is to make him not any more powerful than he must be. Right. There are things you can prove about, as I said about shutting down half the internet at a time, that if your attacker has a certain amount of power, then no matter what you do, you're pretty toast. So we just want to limit the attackers power to what he has to be able to do. So there are some attacks. A lot of attacks are statistical in nature. So, for example, if some client only logs on to the internet for five minutes a month, and some particular NIM is only ever seen using the system for those same five minutes a month. Okay, you have a pretty easy statistical attack there, right? I mean, they're obvious. They're more obvious and brain dead attacks, like if some client receives mail as one NIM and responds to it as another NIM. Now our software watches for that and tries to prevent you from doing that. But you can force the issue or trick the software or even if it's not responding, but just he received some information as one NIM and leaked that information back out as another NIM accidentally, then you can tie those NIMs together, right? Or if he or if he includes his signature file at the bottom, right? But we watch for that as well. So, pilot error is not something we can really technologically prevent. We can help with checks to check the more obvious things that could go wrong. Other technological attacks, if you start flooding the network, it's the same really as the shutdown attack, where you put a couple of servers out of business and watch if the traffic keeps flowing or not, and other things like this. Yeah. Right. So this is something we just have to assume that your client is secure, right? If your client is is owned, then your toast, right? You have no hope. Because what's your trusted computing base? If, yeah. All right, so let's talk about that now. Okay, there's a maximum computer science that says all problems in computer science can be solved with an additional level of indirection. So we use this a few times in solving this particular problem. So what obvious thing doesn't work? So you'd like to be able to just go online and go to some form and enter the NIM name you'd like and your credit card number and it would send you something, right? That obviously sucks, right? That would tie the credit card number to the NIM you bought. Turns out the US even has rules saying whenever you sell something by credit card, you have to record all the information about the transaction. So we'd be forced to record what what NIM was associated with the credit card. So that's solutions right up. We don't even support it. You cannot buy a NIM directly with a credit card. What is the obvious, like in the best possible world? What would we like? Well, we'd like you to be able to walk into a computer store, plop down some money and what? Sure, sure, a vending, a vending machine in ATM, a store and do it in person with real money. Right? Right. So turns out our technology supports that because we want we would love to do something like that in the future. We're not going to do it right away. What we will have is just boxes like in real computer stores, like the software and it will contain a serial number. So this is one of the levels of indirection we're using. You don't buy NIMs. What you buy are serial numbers. Right, that's why you never tell that's why the shopkeeper is is not involved in actually creating the NIM, right? You just go you buy the box, the box contains the serial number. This is what you do with the serial number. You go home, you install the software. As I said, the software allows you to set up routes through the internet, through the freedom net rather, without having a NIM, but only to do a handful of things like create a NIM. So you do that. And what the serial number does is you enter the serial number and it sends you back a number of tokens. This is another level of indirection. Okay, these tokens are then redeemable for NIMs. Okay, the tokens themselves. The reason we had that extra level of indirection is because well, what happens if you don't buy it in a store, you buy it online, what happens is online, you can use a credit card to buy a serial number. And so we have to record the credit card to serial number relationship. So we want an extra level of indirection between that and the NIM at the end. So we give you tokens. These tokens in an optimal world will be using blind signature schemes and stuff like this so that it is mathematically impossible for us to determine to link rather, what token was given for a certain serial number with what token was redeemed for a certain NIM. So unfortunately, there are some annoying patent issues involved. So in the meantime, until we can work those out, what we're doing is just having the system audited. We're, we're promising you we won't keep that information. And it's in our worst interest to keep that, right? We don't want to know. As an example, hotmail used to get subpoena after subpoena after subpoena for what was the what was the connection information for a certain hotmail account. They eventually got so fed up with that, they just put your originating IP address in the header of the every outgoing email. So they can just say, read it yourself, don't bother us, right? If we have no information that is not available on our webpage, or through some query you can do, then there's no sense in you subpoenaing us. There's nothing we can give you that you can't just get by going to the net. Well, we would hope not. That's a digital signatures are for. No, no, we make them unable to do that. Yeah, they're fairly long like 2030 characters. Yeah. No, no, it's not one to but most the thing is most consumers are aware of the concept of a serial number on a piece of equipment and it looks like a random string to them, right? So you want to use the terminology they're already familiar with. Well, what? So no, this is why a token isn't generating a token is an interactive electronic process. That is, the client has to generate the the protocoin send it to the server which signs it producing a mesocoin comes back and you produce the token. On the other hand, if you go. So for that reason, we cannot have you just buy, like go to a physical store and buy tokens, right? Because you have to do this interactive process. So the thing you go to the store and buy has to be something before the token step. So we have to have this extra serial number thing in there, which is also useful because it means that for example, at Defcon, we handed out 1000 sort of strips of cardboard with serial numbers printed on them, right? And we could do that. And this is the whole vending machine concept, right? We can have a vending machine that just drops these pieces of cardboard, right? So it's, it's a nice useful, useful property to have. Yeah, exactly. And in fact, all outgoing email from NIMS is automatically signed. Encrypted to who if it's sent to another NIM, it is automatically encrypted, right? So if it's sent from one NIM to another NIM, the software will automatically sign and encrypt it, decrypt it on the client on right when he downloads his mail. It's really interesting how we do mail. I'll get to that. I should have time to get to that. Wait, what was the other point you were making? Signed. Oh, can it be integrated with other, other things? Yes. So what we want to be able to do is have some kind of LDAP query on the, on the NIM server so that automatically integrate with programs which do encryption, we're probably going to support OpenPGP first. Right now we're just doing some throw it yourself stuff. But we'll go to OpenPGP. All the, no one's asked, and I hope you don't actually need to ask, but all the algorithms, the crypto algorithms are using, they're like exactly what you'd expect, right? Nothing proprietary, nothing 40 bit. I mean, we're talking triple DES blowfish, DSA, El Gamal, right? Any what? The answer is, it was written in Canada. So there are export tweaks, Canada does have export laws for crypto. Basically, you're not allowed to send it to Angola, Myanmar and Yugoslavia, right? You're questioning Canada on that and not the US on its ridiculous thing. But, and it turns out, it's only covers physical shipments as well, right? Like Canada doesn't cover ephemeral, right? So that's fine. Right? Yeah. Randomly. Yeah. Well, then it wouldn't be random. Yeah, we keep a database of all the ones we've generated and cross them off as they're redeemed. Right? It's very simple. No signatures, no anything. And it's, yeah, exactly. Guessing, guessing a valid one just won't happen. For what? For the pilot. In fact, I can answer that. I can answer that the answer is not in the way you're thinking. But using technologies like maybe familiar, I've written lots of programs for the pilot, such as Topkin Wingman, the graphical web browser. So the way we did the graphical web browser for the pilot is that we don't try to like download JPEGs from the internet and process them on the pilot and just display them in tiny little resolution and colors. Instead, we use a proxy, right? You have some proxy on the real internet that is well connected and has decent amounts of computing power. And that proxy can do all the hard work for you. Your pilot just has to be an interface. The same thing can happen with freedom. You can have a proxy being your home computer that you trust. It has all your freedom keys on it or whatever. And your pilot just acts as a user interface to that, so that you can browse the web or do whatever from your pilot going through this proxy on your desktop. So that's the easiest way to do such a thing. We might not build that particular thing, because there's no reason someone else couldn't. It's encrypted. That's easy. Right? That's a point to point encrypted links, one shared secret, and that problem solved. Right? Anything else? So I think I covered everything about how to buy NIMs. What? Oh, pricing. Right. So initially what we're thinking about now is, and what we've been telling people is it'll be $50 US for a set of five tokens, so five NIMs, five NIM years, right? So these tokens give your NIM one year of lifetime. And you can spend that spend tokens either on creating a new NIM or extending the life of a NIM. So we're actually talking about that right now. We'd like to, well, certainly we'll not reallocate it right away. Right? After some time. So what we're going to try to do is not reuse them until such time as we have a good reputation capital system. The hard part, the only tricky bit is confusing people that White Knight today is not the same as White Knight three months ago, right? But if you have a good automated reputation capital system, then it's not so much the NIM name, which is basically the email address, right? NIMs aren't even really required to have an email address. If you only want to use it for web surfing, that's fine. You can have a NIM with a random name or no name or whatever. A NIM is really a public key. Right? It's the public signature key or the verification key for that NIM signatures. Right? Note that it's not the same as the encryption key for mail to that NIM. That changes often. But the signature key is long lived. If you want to talk about who a NIM is and notice that White Knight today is different from the White Knight three months ago, you see that a new public key was created for that NIM and thus reputation should not. Sure. I mean, right, well, that's just a short way to print the public key, right? Just print a hash of the public key. But yeah, definitely, we do that. Sure. So what a reputation system would be is some way of keeping track of all the NIMs you communicate with, of all the people you communicate with, right? And are you familiar with things like scoring newsreaders, right? Newsreaders that you can assign rules and stuff like this? I'm not familiar with that, but it sounds right. eBay, for example, eBay is another example you might be familiar with. I've only looked at it briefly once, but it seemed that they have some kind of rudimentary reputation system where basically anyone can just say, oh, he screwed me or no, he had great service. And that adds or subtracts points from your global reputation. Global reputations, it turns out aren't very useful because the people I agree with and the people you agree with will probably be disjoint. But it's very useful to keep vocal reputation systems, or at least some kind of shared reputation system. So I could not only say I trust Adam, but I can say I tend to agree with Adam's views of other people so that I can put some positive weighting to whatever Adam has rated some other person, right? So and this kind of automated system, this is there's been so little actual work done into such things and the obvious maths behind them turned out to not work and you have to do some complicated things to avoid very strange results. But so what you want to solve is the last move problem, basically. The last move problem is someone creates a NIM and does business with people and then does a transaction where he cheats and then kills the NIM, right? What you want in order to solve that problem, you want it to be more advantageous for the person to keep a NIM with good reputation than to cheat someone once and have to start all over again. Well, we just have to make the make it actually more advantageous for them, right? Which means that if you're about to do business with the NIM that you don't really trust, right, you can look at the reputation and say, how much would it be? Would it be more worth it for him to cheat me or to keep his NIM? If it's more worth it to keep his NIM, then you can be pretty assured that the transaction will complete successfully. So this is another one of those hard problems. It only works if you. Yeah, there will be like a name that basically can ask, okay, what kind of prediction does he have, right? Right. Exactly. And then some kind of complicated math, which isn't all worked out yet, and isn't much worked out yet at all. To figure out what the value of the reputation is. But that's off later. Later products. Yeah. So if a spammer wants to buy like a million NIMs in order to send email, that's just not cost effective, right? It'll cost them $10 million to send one piece of spam, right? One set of spam. So the system prevents people from sending too many emails, you can only send a handful, maybe like 100 or a couple hundred emails a day max, right? And for a spammer, that's ridiculous, right? They have to send like tens to hundreds of thousands of emails an hour in order for it to be effective for them. So sending spam is effectively cut off by the system. Turns out we also block incoming spam. And the way we do this, if you're an advanced user, you can set up really clever things with incoming mail, like challenge response systems, you get mail from someone you've never heard of, they have to just verify they're a real person before it'll get to you. And I know some people who have such systems set up, but they're pretty heavy Unix gurus, right, to do such a thing. Ordinary folk aren't going to be able to do this. Luckily, we get your mail before you do, right? Now it's encrypted, we can't read the mail, but we can see who it came from. And we can actually it's not encrypted when it arrives at us necessarily, they could have encrypted it with your public key, but they might not have. And then we, if you want, this is totally an option for the user, we can perform that challenge response protocol for you, and then only deliver the message when when we verified it's a real person. Yeah. Right. So there are all sorts of tweaks and configurable parameters, you can have what's called a friend's list that I know these people are okay. And so you would put the mailing list on that. And that's bound to your NIM, that's right. Yes, not to your real name. That's right. So I said earlier, I was going to show how mail work through the system. So I'll do that in a second, I'll get these questions. Okay, so right now, you can already start setting up freedom servers, the I think 2.1 release of the server is went out last week or something. The beta two of the client is is out there. If you've already signed up to be a beta tester on www zero knowledge.com. Then at some point, we're just working our way down through like the 40 some odd 1000 1000 entries on there and and it'll come. I don't think any more beta two twos will go out because beta three is imminent. So once beta three comes out, we'll be sending out some more to notifications to the beta testers. Yeah, so real soon now, as they say, I have no idea. Yeah. Oh, I'm, I'm certainly hoping by this year, like by the end of the year, we've been working on this for a while time to get it out the door. Yeah, the current one. Oh, no, no, no, it works with with the worldwide freedom net now. Yeah. And we have servers deployed in lots of places. Right. So I think on the web page, we have a list of affiliates. Yeah. So we do have an ISP affiliate program where ISPs, when they run freedom servers, not only do they get a cut of of the traffic that I said before that freedom servers get money, but also any of their customers that sign up to get NIMS, they'll get an extra cut of those. Okay, so another question. Right. They're not connected. They use some of the same tricks to solve their respective problems. But they're solving different problems. Right. So in fact, we can just look and see exactly what problems are solving. Free swan solves that problem. Freedom solves that problem. Right with free swan, it protects the confidentiality of your data, but not the correspondence, not the endpoints. Okay, I'll talk about mail bit. It's pretty neat. We have a when you do this demo live, it looks really cool. So the way mail works, I'll just talk about incoming mail to a NIM. Mail comes in to the name white knight at freedom.net. Freedom.net has an mx address that points to one of several freedom mail gateways. So the mail comes in. And it's to a NIM. And it's probably in clear text unless the person that sent it was running freedom himself and looked up the key and or whatever encrypted it manually. So this mail is probably in the clear at this point. And it's to sub NIM. The freedom mail gateway will look up the NIMS key and encrypt the mail message right away to that NIM. It also looks up this is the way it does it right now, which will change in the future. It looks up reply blocks, which you're probably familiar with if you if you're familiar with remailers and NIM servers. It looks up a number of reply blocks. Normally there are three, but you can have as many as you like. The idea behind having more than one is what a reply block does is say, send any incoming mail for me through this host and this host and this host, but it's nested encryption in the same way that the that the route setup packets are. So you'd have to compromise all of them. And but what if one of those hosts goes down later? So that's why you have like three possible routes to use. And basically the mail is just sent through all three of them. So at this point, the mail gets encrypted and distributed and eventually ends up in the user's pop box, right, is mail school, where it's where it appears basically as a mind message of type XZ application XZKS mail message or something. And it's the body is just encrypted data. Is that what this will be on on the client's ISP right wherever he normally receives mail. So if you went in and just from the client, you tell that to your pop server port 110 and just look at do a list and letter and look at the email, you'll just see this big encrypted mail message. Okay, quit that. Turn on freedom or install freedom. I guess it's already installed if you got an email. When you turn on freedom, and you go to your pop box, what happens is the freedom software and the local client notices that you're trying to make a TCP connection to port 110, right? It intercepts that and does a man in the middle sort of deal where the client ends up talking to a locally running pop server. And the pop server itself acts as a client to this one. And then what it happens is this pop client will download the encrypted email messages, decrypt them and then present them to the user. So what the user would see if he did tell that my popserver.com port 110 and did a list and letter is he would see the email message in the clear, which is a really cool demo that you just tell that and look at it and you see Oh, the raw data is encrypted. And then you quit and start freedom, tell that again, and list and the raw data is now in the clear. It's very spiffy demo. But that means this is the kind of thing we do so that we don't have to give you new client software for anything, right? You can use your ordinary Eudora or Netscape or whatever you use for mail and news and web and whatever. Because we we do the stuff at the protocol and the IP level, not as a separate client program. Yeah. No, the header does not have the name that would be that would be sucky, right? The mail message when delivered to here has the client's real user ID on it, right? So it says to ENG at CS Berkeley edu, right? Not to white night at freedom.net. And the body is just an encrypted mail message. When freedom decrypts it in there, it will be the actual headers, right? Right. So that that is one of the two big drawbacks of this system, which is why in the next generation, we're going to be going to a different style of mailbox system where where you can prevent correlation tax. The tax you mentioned are basically you want you want to verify whether some person is a certain NIM. So it turns out if you already suspect that person X is NIM Y, it's not too hard to verify that in general, right? You can cut off power to person X's house and see if Y ever logs on again and things like this. Well, what there's no such thing as mail to an anonymous user. Well, then we have pseudonyms, that's not a problem, right? So wait, I want to continue with this. So what happens is, yeah, the mail arrives in the user's popbox as as the user and only once it's downloaded into the client, does it ever get decrypted and displayed? Yeah. So that's part of what's in the reply blocks. So the reply blocks say, okay, first send it to this address and encrypt it with this key. And here's some other header information to pass to him. That other header information will tell him to send it to this address. Once he decrypts it will tell him send it to this address. Here's an encryption key and so on. And this last guy, he'll have the header send it to E and G at CS Berkeley edu. No, no, that's done at the NIM server. Right. The No, this is only an incoming mail. Right outgoing mail just appears to be an email message from white knight at freedom.net. And it has a digital signature on it. But then a reply to that mail will come into the freedom mail gateway. It will see oh, this is for white knight at freedom.net. It'll look up the key then and the reply blocks, stick it all together, do all the magic, deliver it in this way and comes out. Right, well, this is the correlation attack that what happens if you just send 54 gigabytes of email to a certain NIM, right? And just watch that guy's pop box fill up. So what about we don't have it yet. But it's just more protocols we have to plug into the thing. Oh, good question. No, obviously that's bad. No, no, no. So in fact, it would be this guy, right? It would be the send mail demon here, or whatever. But in fact, it's not send mail. It's in fact, we don't use SMTP for any of these connections at all. Not only do we not use SMTP, we also route it over the anonymous internet system, so that unlike in a normal remailer system, if this guy receives something and he wants to know who sent it. So that's sort of the other way around for outgoing email, he receives something and he wants to know who sent it. This message will have this guy's address in it, in like the receive line or something, and he can go here and fight with him to look at his mailer logs and figure out who this guy was and so on. But if these these connections are themselves over the anonymous cloud, then this guy has no idea who even sent him the message in the last hop. So you can't even work backwards. Yeah, so promise if this machine is down, say, right? So what will happen this link is SMTP, right? Because this guy is expecting it. So what will happen is this SMTP demon will send a reply to the errors to address, which is assumedly this freedom mail gateway here, right? It's certainly not this guy. No, this guy does because this link is SMTP, right? But these guys can't go backwards. Nothing, nothing, he can, he can just mark it, he can mark. No, he can't even do anything. He can retry. That's it. NIM it is. That's right. No, no. Well, then all we would know is that, again, this user is having a problem. We don't know what NIM he is. So to the original NIM, this guy isn't a NIM in general, right? Okay, if so, in the special case where one NIM is sending mail to another NIM, most of this doesn't even happen, right? Most of the processing and mixing is done on the sending client send, because we have software there, right? So it doesn't even have to go through the freedom mail gateway, it can be shuffled directly. Right. So if this guy is a NIM, yeah, we could do that, and send the errors to to that NIM. Well, no, wait, but that's undesirable. No, no, that is undesirable. Well, this guy would just get a message saying he sent mail to white knight at freedom.net. You under no circumstances want him to get a message back saying unable to deliver to ENG at CS Berkeley at you. Right. So we for a bounce. That's just so I think the problem is not even necessary to be solved because we're replacing the soul system anyway, right, in the next generation. So, well, it's the mx for freedom.net. They are, they are in fact, yeah, there's more than one of these, it just has tons of MX records. No, in fact, to first approximation, every one of these nodes is running one of these. Every node is running a freedom mail gateway. Right, because it has no secret information at all. It's it's part of the reply block. So the reply block contains looks like this basically the inside it says in G at CS Berkeley at you that is encrypted with with some node C's key. And then C comma that is encrypted with some node B's key. And B comma that is encrypted with some node A's key. And then a comma that that's the reply block. There's actually a little more information. It's part of it's this is stored in the NIM database. It's part of the NIM public key information. So in addition to no, the user picks them. The user says I want mail for this NIM to go to this address via these three hosts. I mean, in reality, just as usually pick random ones, but right. So the mail arrives at the freedom mail gateway. The free. Right. Right. Has it's just SMTP, right? Right. Right. The receipt. Right. So the user when he created his NIM a long time ago, he made this. No. So this guy see send it to a this might be a right. So he sends it there. There might not be a direct connection in the freedom net between this guy and a when he sends it to a he actually sets up a anonymous IP connection through the through the freedom cloud. No, that can't happen. Right. Obviously. Yeah. It's like loose source writing. Below it is the anonymous and right. Loose source writing. It's more like that's why you have three reply blocks or some number of them. And reply blocks are refreshed automatically often to achieve perfect forward secrecy as well. Right. So it turns out I actually talked to the IP sec guys at the auto organic symposium last weekend or two weekends ago. And thought we were discussing they were under the impression initially that you could just munch IP sec a little bit to do this. It turns out you can't. Just because of the way the IP sec headers are defined if you could just slightly tweak the definition of IP sec and move some headers around, then you could do something useful with it. The problem is the padding that you need to pad packets to a fixed size. And the padding information on an IP sec packet is just in the wrong place for that to work. So that when you what you need to do as a packet moves from one place to another, it'll get it might get shorter from the decryption, but then you have to pad it again. So it's the same size. And it's just a detail in the order that the header information comes in where the padding information is is just wrong for that to work properly. So that's I found that rather unfortunate. But that having been said, we do use a lot of the same principles as IP sec, right? Our implementation is what free swan ought to have been. It turns out, so we're using on Linux anyway, right now IP forwarding for the 2.0 kernels and the 2.2 kernels will move to IP chains. If we decide it's necessary. Turns out the free swan guys at first thought that would be a good thing to do. But then someone told them that you couldn't do that. So they just did it some totally other way, which involved a whole lot of cluges and knowing about lower level interfaces that they shouldn't have to know about and stuff like this. And that's unfortunate because doing it the right way in the in the forwarding rules works. I mean, it just works fine.