 Freedom of speech. Freedom of speech. As Americans, freedom of speech is one of our most coveted and cherished rights. However, certain things are better left unsaid. Certain things are better left unsaid. This project is definitely one of those. My name is Keith and standing to my immediate left, this is Argus and again next to him, that is Dejay over there. Collectively we are known as Chung's Donut Shop and today we will be presenting on the Lunar Correspondence Protocol. We're going to ask you at this point that you reserve all questions to the end of the presentation. Time for meeting. We will have a Q&A session. If we do run out of time then you're more than welcome to approach us at any time during the time with any questions you may have. We're going to ask that you pay. Okay, I'm sorry these mics suck. We're going to ask that you pay particular attention to the methodologies behind the actual software as they're not only applicable to our own implementation by anyone of your own. This is a flexible security scheme. It's not any particular tool. It doesn't require client-server software. It's basically a collection of methodologies used to achieve anonymity and security over a public network. Can everybody hear? I'm getting a lot of blank stares. Most of you are probably wondering why we're in fact here today. Well, the security of our world as we know it is at stake. The Lunar Correspondence Protocol will help you... Hello. Can we just use that one and pass it? I think that's the best way to do it. Technical difficulties. It doesn't interfere with 2.4, right? Making sure. The security of our world as we know it is at stake. Lunar Correspondence will help to safeguard your constitutional right to freedom of speech under the mounting pressure of an ever-increasing governmental bureaucracy, poising itself to become the big brother of tomorrow. However, the nature of our project may lend itself to possible abuse by malicious users, industrial saboteurs, and perhaps even terrorists. That stated, we are still confident that the pros of our project far outweigh the cons in providing three key features. Those features are secure communication and anonymity. Abstractly, the Lunar Correspondence Protocol is a revolutionary new protocol used to anonymously transmit and receive data securely across the internet. Lunar Correspondence Protocol is based on the finite improbabilities of vast random data dispersal and exploits properties in IP to accomplish a portion of its goals. Essentially, that means we're using the internet as is. No special client server software is required for a full implementation of the Lunar Correspondence Protocol. Finally, when coupled with the latest encryption technologies and our in-house Chung's Donut Shop developed advanced permutation engine, the Lunar Correspondence Protocol achieves a level of security unsurpassed by any other protocol or privacy scheme. Okay, first off, I'm going to apologize for any technical difficulties with sound. If you can't hear me, just yell. I'll talk louder, hold the mic closer. Okay, first thing we're discussing is a tool called Loki. Okay, during the initial stages of Lunar's development, we're often asked if it was just a revamp of the Loki tool. For those of you that don't know what Loki is, Loki is a tool which claims to use ICMP to create a stealth channel to communicate through firewalls. That's really the only similarity between our implementation and Loki. We chose to use ICMP traffic. The reason for this is a lot of the same reasons they chose to use it for Loki. It easily passes through a lot of consumer firewalls. Okay, not all, but many. Secondly, it's a connectionless protocol, which aids in our anonymity. And third, and most importantly, it's blindly relayed by the vast majority of public hosts on the internet, and that's just the way that ICMP works. So start off, let me show you a typical ping transmission, or ICMP transmission. Basically, you have your packet, the data of this packet contains, say a system time, ticks, whatever. You're going to use this data in a calculation to determine the round trip it took for your data to get from one point of the internet to another. So we send it out into our network. It goes off into the internet, and it goes to our first arbitrary host. We'll call it host A. Now, the only thing that host A can do to validate where this packet came from is it trusts the source address in the header. It's a connectionless protocol. Therefore, there's no validation performed. What it does is it looks at the source address. It says, okay, this came from here, and sends it right back to, in this case, transmitter's network. To accomplish the anonymity portion of our implementation, we're actually going to deceive the internet. And the way we're doing this is we're making use of that flaw in ICMP, the lack of a validation scheme. Instead of putting our source address for it to reply to, we're going to put the target host address. So we'll show you here. Our data's at our transmitting host. It's all ready to go. It's prepared. It's been ordered. We're going to get a lot more into what we're doing to prepare this data later on, but all you need to understand now, that's ready to go. Okay? First thing we do is we send it off into our own network, and you know it's one packet staying behind. The reason for this is to show a delay, which we're going to get into later. Just take note of it now. So it's going from our network, you know, firewalls and egress filtering permitting, out into the internet, where it's routed to two separate hosts. Okay, we're choosing to use unique hosts, sending this data all over the internet to aid and avoiding the creation of a pattern. That's really what we're trying to do here. Now as far as they're concerned, these packets came from the receiver network, because that's all they have to go by is that source header. So what it does, it says, you know, good enough it sends this data intact right back to the receiver's network. Now you notice it's not going to the receiver's computer itself. This is because, number one, a lot of masqueraded routing systems will not allow it to go to a host that didn't put the request in queue. Secondly, if you've got a lot of ICMP traffic going to one host on your local network segment, you're going to know something's up. It's going to set off a flag. It's going to create a pattern that's going to be trace and notice. We want to avoid that at all costs. So what we're doing is our receiving host is actually promiscuously sniffing all ICMP traffic on the network during this particular session. It's going to be collected and parsed later, but right now it's just sniffing everything. Okay, we've got our last packet coming into the network. It goes back in. It's reordered at the other laptop, and we basically send our data across the Internet. To do this, we're utilizing two layers of spoofing. Now, obviously, there's going to be situations where you can't spoof the MAC address, you can't spoof the IP address, wherever. This is all applicable to any particular scenario. You can add or remove any component of this scheme as needed per your situation. You can't say you can just break it by filtering out MAC addresses, because you could simply remove that component, use everything else, and remain relatively anonymous. What we're doing is we're actually changing the hardware address to the card. Again, if somebody's looking on a local network and they see all this traffic going to all these different hosts on the Internet, and they're coming from different addresses, everything else, not on our network, but it's coming from the same MAC address. You're able to pinpoint what card or what boxes came from. It's also going to create a pattern. You've now flagged all these packets with your MAC address, and now you know which packets are part of this scheme. Secondly, we already touched on it, and it makes us able to basically remain anonymous on the transmitting end. Now we're going to get into inefficiency. Now why wouldn't we want to be efficient? Why wouldn't you want to transmit your data across the Internet, and the quickest, most efficient method possible? Well, we've added this relay, and that's already at a level of inefficiency and everything. It's not a quick protocol at all. It can be, but in the most implicit implementation, it's not. Secondly, when you send data from point A to point B, let's say I am in Southern California, and our goon back here is in New York, and we want to communicate back and forth. He's not looking at me. We want to communicate back and forth. Somebody who thinks that we might be talking to each other could easily pick a note along this path, predict where our data's going to go through. We're giving these people a lot of credit. We're not assuming it's just your average jackass trying to sniff our traffic. What we're going to do is, again, and we're making a lot more inefficient for this to go across, and a lot less reliable as well. But, again, we're going to get into reliability later. What we've been to prepare our data before we send it out, is we've done several things. Now, again, you could probably encrypt your data, send it out through the relay, 90% of the time you're now anonymous and relatively secure, but we're going to give these people a lot of credit. We're going to say our snooping party is a paranoid military, a government, a country, whatever that has limited resources and deciphering and collecting our data. We're going to give them a lot of credit because we want true anonymity. We don't want anonymity to the point of the knowledge of the person snooping our traffic. What we're going to do first thing is we're going to reorder the data. We're going to take our packets and our sequence, shuffle up, put it out of order. The reason for this is we're trying to avoid the creation of patterns. If you send data across the network in order, and it gets, or even if you send over the period of a year and a half with this delay, if somebody can guess when it started and when it ended, they're going to be able to at least assemble these in sequence. It's going to aid in the deciphering and reordering these packets, so we want to avoid that. Second thing we're going to do is we're going to inject false positives. Even with reordering and delaying everything else, in a scenario where all data is valid, laws of probability state it will eventually be reordered and deciphered. So we're going to inject false positives into the thing and the engine we're going to use to do this we're going to assess later. Third, that data delay that we already had before. Now in our implementation we chose to have two values. A minimum and maximum delay time. So that could be anywhere from like one millisecond to five years. So the first packet obviously goes off instantly. The next packet may come 30 seconds, the next one may go a year, the next one may go in a week. Obviously this isn't feasible for most communications but it's just an example of how it works. It's going to send anywhere in between these times. Not at a random set interval, but a truly random value. Again, all this is doing is avoiding the data delay. On top of this we're applying cryptography. Now again, with unlimited resources and a company or government that has a time and sufficient power to do this, cryptography eventually will be cracked. Doesn't mean it's going to happen anytime soon, doesn't mean it's going to happen in a year, but eventually it's going to be cracked. We want true security anonymity. So what we're doing is we're saying crypto isn't valid as a primary means of security and communication. However, it's far from trivial because when applied over the whole scheme it severely complicates the efforts to reorder and decipher the data. You have encrypted garbage coming across the network, it's going to be real difficult for you to figure out how it's coming across and how it's being deciphered. And all this we use in our implementation in a variety of ways we'll get into that later, but all these methods applied adding or subtracting any of them could be applied to any security scheme. This is how you're going to remain anonymous. Regardless of how you're implementing it. And we're moving on to security with Keith here. Okay, as Argus just so eloquently stated we're basically trying to avoid the creation of patterns and complicate all efforts to reorder and collect our data. Now we're going to do this by using a mathematical permutation function P accepting two arguments N, the total number of packets, R instead of packets composing real data. That is eliminating bogus packets. As was discussed earlier we're also injecting bogus packets across the network to figure the number of bogus packets one would just take R and subtract it from N. Now I'm not going to get into the nitty-gritty mathematical details behind this function as that's far beyond the scope of this lecture here. But what I will explain is the result of this function. See, the result of function P is or the number as a result of inputting two variables N and R is the total number of permutations required in an area to reorder our data effectively. So let's go ahead and plug in and plug in some numbers through this function. We'll start with 60 and 10. 60 packets total and 10 packets composing real data. That leaves us with 50 bogus packets being injected across the network. We end up with a number 2.735898472 times 10 raised to the 17th power. That's an extremely large number for just a relatively small set of packets. Again, we injected 60 packets over the network. That's the total number of permutations required given the worst case scenario to correctly order our data. This function as you can see here is exponentially growing. We'll go ahead and up the ante just a little bit and we'll inject 100 packets total across the network. 80 packets consisting of real data that leaves us with 20 bogus packets. Well my trusty TI-83 can't even comprehend the total number of possible permutations in real data. 100 packets, just to put this in perspective, 100 packets could be easily sent in maybe a paragraph, maybe four or five sentences. Again, very easy to do. For simplistic form here, we've gone ahead for the visual learners and represented this. Basically what we've done here, just to show how insanely difficult this is to do, we're going to assume a relatively bare network. That is, a pristine network basically blank and devoid of any traffic. We're going to go ahead and inject packets across the network, eliminating all the bogus packets. We're just going to send the real data here. We'll send one packet, one character, the letter L. That leaves us with one possible permutation. Again, just the letter L. Two packets, two characters, the letters L and U. That leaves us with two permutations, L, U or U and L. Three packets, three characters, L, U and N. Six total permutations possible between those three characters. Four packets, four characters, four letters, L, U, N and A. And now you're looking at 24 different permutations. Again, it's exponentially increasing. Okay, so if prying eyes are unable to correctly order our data here, you're probably wondering how the receiver is able to do this. Well, the receiver and the transmitter both have random number generators seated by the same value, basically meaning that they're able to generate the same random numbers in succession one after another on either side. Now, how the seed is transmitted between the two is solely up to the communicating parties. Very elaborate schemes such as perhaps writing that seed down on an index card, passing it physically where the other party then memorizes it, burns it, ingests it. It's all up to you. Or even more overt methods such as, you know, PGP, like private public key passing, or even, you know, like any other handshaking. But those are all susceptible to man-in-the-middle style attacks. And what we're going to do is we'll line all of our data here up at the receiving order. We've got our start sequence, our stop sequence, and then three packets, CD and S. We're going to push them across the network. We've got CDS and two bogus packets along with the start and stop sequence. We're doing this at random intervals, random times, and completely out of order across the network. What the receiver's going to do now is sit back, receive all the data as it comes in, and wait for two packets. The receiver's going to look for the start sequence and the stop sequence. Once the start and stop sequence have been received, it's then possible for the receiver to take all the data in between those, figure out where it needs to go, and start applying it where necessary to fill in the entire data as a whole, and then flush it out to a disk, write it to a file, email it. It's really up to the user implementation. But again, three... The seed is used basically for three primary purposes. That is to generate the start sequence, to generate the stop sequence, and then to apply that random number as a sequence number for any of these packets that are traversing the network here. Okay, so moving on. Data filters are basically filter plugins that can range from anything, encryption ciphers to any sort of data encoding such as, you know, Base64, MIME encoding, or perhaps just a relatively simple ASCII translation. Data filters are not necessary. We've gone ahead and implemented them in our version of the protocol, just as a matter of upping the ante here, upping the security. Data filters are actually applied over the entire datum before it's chunked into packets. So if you've got three packets CD and S, what we're going to do is package them together, and then we're going to filter them wholly. Now, the only exception to this is the start and stop sequence. For simplicity purposes so that the receiver is more able to recognize these packets as they come in, we're going to go ahead and filter the start and stop sequence separately. They're actually filtered on their own merit. And that just makes it easier on our part to notice them as they are coming in on the receiving side. And finally, the Lunar Correspondence Protocol is multi-tiered security. That is to say, even if the Lunar Correspondence Protocol is cracked, flawed, or some way rendered useless, your data is still protected by the lowest grade of encryption used in your data filter cipher here. So let's say we wanted to use, like, RSA 496 bit keys as our data filter, and then you're going to send this data over the network using our protocol. We're going to release that security, folks. That means if our project is completely irrelevant here, your data is still encoded, you're still relatively secure. Data filters can be used to incorporate any kind of encryption filter. It could be RSA, blowfish, two-fish, one-fish, developed fish. It's really up to you. So summarize what we're doing here as far as the anonymity and efficiency is concerned. We're basically taking data. We're trying to use the entire internet to spread out as wide as possible and have it collected back at a particular source. We're having to go to a pool as opposed to a specific source. Again, because we want both parties sending and receiving to remain anonymous. Again, you don't need special client-server software. Ours is actually a packet parsing and creation engine. And again, you're using it these methods that a lot of other things use as what might be familiar with, the spoofing, the relaying, and then the host-level transmission using the permutation engine and some of the other stuff we've incorporated as well as the filters. And then finally, we discussed achieving security via the Lunar Correspondence Protocol, the mathematical permutation function, packet-level transmission, which actually happens over OSI, OSI Layer 5, I'm sorry, for those of you familiar with the OSI model. And then we finished up with covering data filters, encryption filters, and encoding filters. Okay, well, you guys are probably wondering how this sounds complicated, stuff like that, or whatever, or where's the proof? We have working software that proves this, and sometimes shortly after the conference we're going to post it on SourceForge once they get their act together, and you guys will be able to download it from there and see how it works. Just another note, our software is completely open-source. It is released under the GNU Public License. Richard Stallman is our hero. Okay, so where are we actually going to use such a complicated scheme in our own communication? We'll start off with a really extreme example and a purposely patriotic example. Let's say we have a CIA or American operative in China or Afghanistan or wherever, and he needs to get mission-critical sensitive data through a network, through a hostile, paranoid military network, either U.S. or some arbitrary host where it can be used to prevent something from happening or, you know, complete a mission. Well, obviously he's going to incorporate the most extreme values and extreme implementations of these methods here to avoid all costs, like life and death situation, not just for himself, but possibly millions of other people. Of course he's going to encrypt this data, he's going to reorder it, he's going to permute it with the false data, or at any random delay that is going to be feasible to the particular scenario. So obviously if it has to get across in a week, something's going to happen a week from now, and he needs to warn us about it, he can't set the delay to happen over a period of years. There's not many situations where you could, but that's going to be the most anonymous, most likely to go unnoticed. So what we're going to do is, again, he's going to play all the messages here, put it on a delay that's pertinent to the timeframe here. Now, a more dated example, something that some of you might want to use or average person, a scenario where you need, you have a problem with, say, an employer, something else you need to go over there. You need to communicate anonymously to complain while they're monitoring your network. There's a lot of other applications, like Anonymous Dropbox, Relays to specific servers that are collection data forms. There's a lot that we're going to get into a little bit later on and also on the data that's going to be posted on the storage forage site. However, you can make this as secure or, again, as overt and insecure as you need it to be. You can add or remove any one of these components to complete your transmission. Our software can implement everything, but you can do it, again, at your own pace. There's not any way to sit down in a terminal and be anonymous if you don't know what you're doing. You can't, you know, if you're anonymous and stupid, don't go together. You have to understand how the network works. There's no tool that makes up for lack of knowledge or poor implementation. So using our software intelligently or devising a plan of your own intelligently implemented with 30 Sprint in here, you will remain anonymous on the network. And now for some more creative implementations that we've come up with. All right. So basically, I'd just like to let you know we at Chung's Donut Shop believe privacy. And I don't know about you, but I don't like when I'm trying to talk to my friend about something important and then somebody's eavesdropping or something that you don't want somebody to know. This applies to everybody. So we believe that you should be able to stay anonymous and have freedom of speech. So this protocol implements that and keeps it going. Here's an example of how you could use our protocol. Basically, let's say, for instance, you want to go to an area coffee shop, one that may provide wireless internet, either paid or free. You would be able to implement our software on that network without having to have an IP address. This basically what you can do is when you're on the network, you can passively sniff the packets. As long as you're on the network, that's all you need to know. So if you're on the network, you have our software, your communication is possible, no IP address, your identity is hopefully kept a secret, and if that fails, you always have the cryptography on top of that, whatever level of encryption you have. So just to let you know, I'm going to pass it over to Keith for another aspect of that. Okay, finally and we're almost in somewhat way shape or form ashamed of this, but due to the vast random data dispersal nature of our project, Lunar correspondence protocol can be used to distribute a nasty nasty denial of service attack. So for packet kiddies out there like you, you and packet princesses such as you, please do not affiliate our software with any sort of these attacks. It was not the original device meaning or basically what we intended to use this project for. So again, we'd just like to emphasize that it is possible to launch a massively distributed DGOS attack, however don't do it. Please. If you don't like the internet, please don't break it. Alright, there's some other talks going on today and the rest of the con basically today you got government IP tapping happening with J Baloo. I'm probably going to check that out. Should be pretty good. It has to do somewhat with this concept tomorrow. On Saturday we have Air Snarf with Beedle and Bruce Potter and then on Sunday we have Jeffrey Pruson presenting technical security. So these are all things that have to do with your right to have be anonymous and privacy and how you can do things. So recommend that you check those out. Also we're going to add the Air Jack projects. For any of you who want to check it out, Air Jack's actually been used in some of our testing and it makes a lot of very interesting things possible. It's a really great subject and you guys should check it out by abandon. Finally we'd like to make some acknowledgements here. We'd like to acknowledge the infamous Mr. Tank for the mathematical genius guidance. Unfortunately he was unable to join us today so he's not sitting in an audience per se but he is vicariously watching us somehow through a closed circuit television somewhere. Second we'd like to acknowledge Douglas Adams and the meaning of life 42. Please rest in peace. We use some of his concepts strikingly believe it or not like the finite improbabilities yada yada yada. And then most importantly thank you all for the support. Thank you very much for showing up today. We really appreciate it. Now we've come to the Q&A portion. So what's the matter here? For those of you who couldn't hear gentlemen here we're asking how the software deals with ICMP packets being lost or lost packets going across the network. And it's much extreme implementation it doesn't. However there's a filter and there's a set of rules that you can apply to any one of these. One of them being a pseudo ACP that has sins and acts. And this is encapsulated within the encrypted data. This is part of the payload of the packet that's already been anonymously sent via Luna. However if you're doing sins and acts it exponentially increases the amount of traffic going across the network and across the relays and you're going to have the same packets going across back and forth several times. And they may be flagged as suspicious traffic. That's why we chose not to address it here and in software but you can do it with the data filters. Luna by itself does not deal with the issue of dropped lost or somehow wrapped packet. We do not have like a DCP style protocol wrapped around it. So in essence we basically call it like finite improbabilities there's really no way for me to know that you did receive all the data. I mean that is the downfall of the basic Luna correspondence protocol in its own. There's really is no way. I mean you may never receive the data for all I know. It's true. That's very true. One lost packet could very well invalidate all the packets. There's no way for us to know if you did receive the packets therefore there's no way of me retransmitting them and therefore the receiver will just be listening and waiting for this packet to arrive. And again that's under the most extreme anonymous secure implementation of what you'd want to do. You can again when we've tested it works the sin acts scenario with tunneling basically a pseudo ICP within the Luna packet. And thereby guarantee that it came from one source to the other. For anybody that has any questions please come up here and just ask on the mic so that everybody can hear. I'd probably expedite things. You guys can just all come whoever has questions and come and ask and we'll answer. With some of the features of IPv6 is this going to be able to work over that? I mean the security IPv6 the encryption the you know it limits on doing the spoofing technique you can do in IPv4. As far to address that question right there we haven't been able to really test it over IPv6 distributed over the entire internet because it's not really implemented yet. It hasn't been tested. It hasn't been tested yet. But basically software can be modified and ICMP again to address this ICMP is not the most critical component of this it's just a relay. It's anonymizing your host. One of the things that was brought up was on a local network streaming from box to box like a local network segment to hide the data in like a UDP packet for masks as syncing your time servers. Or even somebody mentioned hiding in shout cast a lot of different implementations. If you have an organization like the NSA or echelon somebody who has access to maybe all of the routers on the internet or most of the routers on the internet if they were to implement something where I mean there's been things suggested where they would start logging every packet which is ridiculous because they'd need a hard drive the size of a football field. But if they started implementing something like logging the CRC or check some of every packet it seems like it would be possible to back trace simply by even if the packets are encrypted and out of order. If you know that this meant that a bunch of anomalous packets went and that they all had the following check sums you could just match up the check sums across the network until you narrow down to the originating subnet and that would at least tell you perhaps what subnet it originally came from not necessarily who sent it but it seems like you could narrow down the origin that way if you had that much information. That's a very good question. It's one that we've actually been asked several times before for people to discuss this with. The main goal of creating anonymous communication is not that we don't want to have something that's a standard Luna packet or something to be flagged as a Luna packet. That's kind of where the permutation routine enters. Let me cut in. I think what he was saying was all the packets going through on through one subnet but the thing about Luna correspondence protocol is that when you send the packets you're using multiple relay hosts which are multiple subnets so even if you did have the NSA and everybody logging everything it would be hard because your packets could be spread across a period of 100 subnets. So even if you were logging everything you have to go to those 100 subnets log everything on the 100 subnets and then try to order the packets in the right order then after you get all the packets in the correct order then you have to decrypt them. So basically I think that's what he was talking about. So to answer his question it's almost impossible. Also if it's anomalous packet you're looking for again a lot of ICMP traffic is anomalous by nature. Arbitrary applications create arbitrary data within the ICMP packets to calculate what's going on in the network. We have yet, we offer you to download to see if you can filter out your Luna packets. We haven't been able to. And again this is through good practices of doing it you're not keeping the same seed the same values on the session by session basis if you're doing your screwing yourself. Just as if you're using the same relays and a lot of same stuff you want to keep it moving. To address the next question. So you said that the packets go out in kind of a random order but there's also the start and end sequence that the listening host looks for. So do those have to be received in order like the start sequence? No in fact the start and stop sequence can be sent anywhere within the order because the receiving host left just receiving all traffic as it comes in he's looking for these two packets when they do arrive be it the first two the last two anywhere in the sequence when he does have them it's then possible for him to set them up see where they exist in the sequence of random numbers and then figure out where packets need to be injected in between. So the receiver is unable to order them until he has received both of them but they can be sent anywhere within the stream. But he might have to keep listening that's correct if there was a delay or they were sent last. Thank you. This protocol is on the other end when you receive it's very passive that's why you can use UDP packets on a local network without even having to use any relay hosts. Alright two questions. The first you said that even if the protocol is flawed that the encryption done through one of the data filters over the data will still be the absolute minimum security. How do you deal with key distribution? How do you deal with key distribution? The key distribution basically is transmitted in the same way that the seed initially was it's up to the two parties. You see our protocol is basically interested in keeping we call them like host key files. But if you have to do key negotiation before you can send data how do you do the anonymous data transfer? Well that's what I'm saying. Beforehand it would be a matter of you and I physically meeting and we'd write down our keys or we'd transmit them and then we both have them. So that when we separate or when you're in Europe and I'm over in Asia somewhere we then have them and we are able to communicate. You see it's truly up to the two communicating parties. It could very well be that maybe we have some sort of a challenge response protocol to send the keys but those are all susceptible to man in the middle style attacks and it's not very secure. Well any key exchange protocol is part of our protocol. It's implemented on however you wish to do so. Actually encryption as a whole is part of a data filter set that we chose to implement in the software and it's a really good idea. Again you don't need PGP for a pop3 to work correctly but it's a really good thing to have in your client. Now obviously if you've got to do session per session keys it's not feasible to call you up on the phone say here's my key hang up and then start transmitting over the network. But if you're trying honestly to somebody, how do you do any form of key negotiation beforehand? Again this is going to be up to the individual host. No, I think you're trying to ask if I don't know you and we both have the software how do we communicate? Well we don't. I would have to know you first and we would have to establish beforehand the keys, the seeds and whatever else is necessary to decrypt the data. It would all have to be established at some point. Yeah that's what I was going to say. It doesn't have any negotiation like SSH or anything like that. It's not like a chat client in the sense that I can search rather than users. It's a great question. Same to ICMP to people who aren't expecting it is more of a denial service attack than communication. So you kind of want to know what's going on between the two parties. Now you said that you have problems if there's egress filters. Have you considered any kind of implementation of a client and server, a server on the internet where you would in essence be able to overcome that because you know the servers connected somewhere where they're not egress filters. Basically if you're in a situation where you cannot spoof your IP address to get across your network, leave in your MAC address that's kind of how the it's probably going to run out of time before we can really discuss in depth how the HTTP relay works and for internet access. Basically you don't have to have anything besides these parsing engines on either end and know what this initial value is to use Luna in its base form. But you can implement whatever you want over it. We have a situation where you can actually have a second host, maybe your home computer you want free wireless at some coffee shop that's all over the country and you basically can send this data out to the listening party at your own network. They can go and execute commands on your behalf, relay this data back to you. Really in situations where you can't spoof you could have another host do it, but again that host is just implementing Luna and you might as well just telnet into it or shell into it and reach in and run Luna from that local server. There is a non spoofing option for our protocol software implementation. Hi. So given a shared key and a common set of random number generators, two parties can communicate scrambling the data and the data stream in a deterministic manner. So why is this any more secure than using the same random number generators and the same shared key to just generate a one time pad? A one time? A one time pad. Use your random number generator generate a long stream of random numbers and XOR that with your data stream. Why is Luna any more secure than a one time pad? Well we don't have to do that. In effect we are doing that but we're generating them off the initial seed and then matching up later. It seems like you're doing a lot of extra work for not much extra security. I mean the rent. The protocol certainly that's great. But the actual scrambling of the data doesn't seem to be any more doesn't give you any more effect than a one time pad. What we can answer this is how you actually implement the reordering. Basically we're telling you how our software does it but you can actually reorder it just that same way as long as the data is not coming in order as long as you're applying the methods behind it the logic behind how you're doing it you can implement it however you want you can implement it with a one way pad. You're correct. I mean basically I totally see what you're saying the thing about Luna is that it's very passive so you can be on a subnet, send from one subnet to another. That's the thing about Luna it's not just the idea of reordering the packets because that would be the same as like cryptography right? So the thing about it is you're on two different subnets you're able to communicate to each other and then you have the different relay hosts you can bounce from. So that just adds on top of that but even if that's done then you still have the cryptography. So just briefly, rather than store all of the random numbers in other words like generate a pad as you called it of random numbers we're just storing the seed and then generating the random numbers later. It can happen either way but we're storing less initially to generate more later if that makes sense rather than store everything now and then at least with the seed we can now say instead of giving me this set of 10 random numbers let's you know evaluate this function 20 times so they can always change and we could do like a roundabout thing or we could just for simplicity's sake never reuse the same random number and just keep going down the stream but keep a placeholder and know where we are every time by storing one piece. Can you go into a little more detail about how exactly you do the reordering of packets? Are they somehow marked in some way or are you just depending on the order in which they're received so that if they were scrambled somehow in time when you receive them the packets are reordered based on the sequence number. The sequence number is set to the random generated number coming out of the random function basically. So we have basically we have a seed we stick the seed in through the random number generator and on both parties both parties are then generating the same random numbers in succession one after another. These numbers that are being generated are affixed as the sequence ID in all of the packets. The sequence ID I'm sorry. It's part of the IP header in the packets so we're setting the sequence ID as that field in the IP header so when the packets come in on the other end he's able to then match it with the same random numbers that he's generated. The IP ID? The sequence numbers are part of TCP so I'm wondering is it the IP ID? We're writing straight IP straight to the link layer this is the sequence number in the IP datagram. The IP header field. The IP ID. That's it. Your protocol seems like it would make a lot more sense if you were implementing a many to many sort of thing where you have many source hosts the data is physically broken up across all of them and you have many receiving hosts because other than that you still have a single endpoint on the other end. We are doing the multiple sending by basically spoofing various networks however in a sense we're doing the multiple receiving because we're spoofing various targets as well so if we can say that they're receiving and reliably sniff on an entire class B network then what we can do at the sending end the transmitter is we can spoof all of that and it is quite possible that if you had two machines set up they can both sniff that same class B network and they both were aware of your user credentials the seed and everything else that both parties could sniff that traffic so it could very well be a many to many relationship. Does that make sense? Yeah, yeah. And in the base implementation we basically want to avoid a scenario where you had to have client service software or have one you know an extra machine out there to do your dirty work for you. You're using the internet as is to do your workload. You want people to you know be able to communicate individually without the need of a third party or third box that they may have a shell account on whatever you want to avoid creating that pattern you want to avoid that third host because again if you're constantly going everything through this third host you're creating another pattern another point for what you can be traced. Now again you can apply these to anything. Any means of communication doesn't have to be ICMP you know it could be UDP you know somebody even talked about embedding it like a shout cast server a lot of different ways to do it is you want to avoid the creation of patterns and you want to look logically at every step along the way. If you've created you've got this server that's an intermediary a bunch of different servers across internet that you log into shell into whatever you're creating another point for them to find where you were from you know it's another box that has your information on it and you don't want that. So I think we've got time for one more question we got the five minute signal so anybody else Any further questions? Here we go. Okay so you're bouncing the ICMP packets across something on the internet does that have to be something you set up or can it be anyone? Basically we're relaying it through an ICMP echo message we can relay through anyone anyone relaying ICMP echo traffic whether it's google.com, msn.com, yahoo.com and the slew of other we can all relay over them there is no you know hacking or owning of machines out there on the network to establish relay host whether it be your personal windows machine at home you know your cocks relay at home or your business line we can relay over it Okay so that brings us to the end of everything thank you guys very much once again Yeah check out SourceForge Again SourceForge right now some of you may know SourceForge is currently upgrading some servers and some hardware and doing a couple things that aren't allowing us to upload the software at this time and again a lot of this we all work and it's a spare time kind of project so it's going to be released in a timely manner but again it's not going to be a constant project we're going to be updating it as we can He's just asked if it's Windows or Linux based Right now it's Unix based however there is a plan to export it out to DLL to be able to be used by the Windows layer but right now we just want to make sure we had everything done and working in the Unix implementation because that's what we all run and we want to use it ourselves So yeah thank you guys very much and enjoy the next