 is that good? Cool. Let's get started. I'm Jason Peele, Network Architect, work for Network Thought Co. That's pretty much it. We're going to talk about Cypherpunk grade covert network channels and we'll start off with the scenario here. Let's say that MI6 in the UK is developing a new clandestine messaging system and they've got field agents out, you know, secret ops say in China and they want to take advantage of the power of the internet instead of every time you know, risking someone's life to sneak a suitcase out to somebody or you know, micro fish inside a cigarette to exchange messages, they want to use the internet. But they need secrecy beyond plausible deniability that this person is even interacting in this network. This attempts to provide something like that. In principle, this idea sounds impossible, you know, okay. We have to assume that we've got a very well resourced Eve who has full access to all network traffic both between these two hosts that are trying to communicate as well as behind them if they're routers or something like this and they can launch passive attacks, active attacks, whatever. But it turns out there may be ways that we can still entirely covertly exchange data between these two parties. This presentation is about an idea that's still very much a work in progress. It's a library implementation. Lots of proof of concept code has already been generated but there's still a lot of things that need to be worked out or agreed on. So I'm going to make this kind of informal. I want to have plenty of time for question and answers afterwards. So you can hit me with your hardest questions and I'll try to answer them and maybe not. And we might take it offline and we might make the implementation better. So here it goes. What Cloak and Dagger is, that's what this is called, it's called Cloak and Dagger. It's a library implementation that can be used by privacy applications such as Nutella I mean it's peer-to-peer, but in a mojo nation, PGPnet, FreeNet, Crowds, MixMaster, what have you, CryptoBox. And it's to be used as a glue such that if these applications wanted to integrate Cloak and Dagger functionality into it, the user could turn on something like Ultra Paranoid mode and all traffic between two parties using this would be entirely undetectable that these two parties were even communicating clandestinely. We want these parties to not even be identifiable as using CryptoBox or whatever. Essentially, all such privacy application traffic looks just like it mimics identically other less, you know, more sensor acceptable protocols. Just agree on a couple of terms here. Generally, the phrase cypherpunk grade generally means that the thing that it describes is extreme. It's an absolute assurance such that if you follow, you know, the rules set for the usage of this application in this case, you know, normally this is going to be a cryptographic application, then as long as you follow these rules, whatever guarantees that we make, they're guarantees. Okay. This implementation is not yet cypherpunk grade, just to, you know, belay here the extremists are going to say, you're calling this cypherpunk grade. It's not cypherpunk grade yet. We're eventually hoping that we can claim that for real. But it's getting close. Okay. So we've got an MI6 agent out in China. He's undercover, very undercover. He's already suspect. He's already being watched very, very closely. All of his network traffic is being monitored, et cetera. Okay. The first step is via traditional means, whatever that is in the spy business. We get him or her or whatever. In a suitcase, we get a cloak and dagger enabled application to him along with a shared asymmetric key. Very much ideally for this to work bandwidth efficiently, for this not to be incredibly slow, that box needs to be sitting where it's got access to a lot of local network traffic, a lot of like, you know, in a colo, as a router, something like this. Otherwise there's not going to be enough stuff for it to manipulate and hide within. We're assuming some fundamental things about the operating system that this is sitting on. It's got to be secured. For example, it needs to have anti-promisc detection, such that, you know, we're going to be sniffing traffic. I mean, not to be able to have it be detected that it's doing that. We also have to assume that it can't be compromised. Yeah. Okay. Basic assumptions. So our MI6 agent gets this box with this application on it. He brings it up in this environment that we specified. And what happens is local traffic sampling begins immediately. What we're doing is we're trying to find traffic patterns. We're looking for protocols used, who's using them, the distributions of their usage, just traffic patterns in general. We're also looking for analyzing, keeping track of payload language data. If our payloads all around us are in Chinese, we don't want to start using payloads in Russian or English or something like this. The sites that are visited, websites, things like that. If we're somewhere where certain sites would be forbidden to be visited, we don't want our application payload data to be visiting these sites. So if we're in Malaysia, we want to be visiting sites like pc.jarring.my, not something in Russian or something like that. Just basic sense stuff. So we start sampling local traffic immediately, and we also immediately generate our PK pair. Each side has generated a PK pair at this point. Once we've determined that we've sampled enough local traffic for it to be statistically significant, we've got patterns built, and we think that that's enough to begin action. We need to exchange our PK pair. For this initial exchange, the symmetric key, this can basically be a one-time pad. Well, it's not, it's a symmetric key, but we have to assume the security that's shared between the two pairs you're going to be communicating there. The symmetric key is used as input to a hash function that determines from a list of protocols that we've, protocol forms that we've determined that we think are ubiquitous. So if we think that ICMP traffic or certain forms of talent traffic are ubiquitous, that no matter what network environment we're in, those are safe. There's going to be a much more limited number of protocol forms, not just protocols, but what fields we use within those protocols, the kind of data that can be in the payloads. There's going to be a much more limited list of what those protocol forms can be. But from that list that are ubiquitous, we've got a hash function keyed to those protocols. The symmetric key is used as input to that. And what it outputs is the protocols, fields, sentinel values, and timing information that we're going to use for our initial exchange. I'll go into that more later. For this exchange, the symmetric key is also used to encrypt the public key, so that even if they were to determine what these positions were, we're still encrypting the public key. Obviously, we have to show the security of that. It's public, public. In this case, it's not really public. It's just public to our shared peer. Using the information generated from the aforementioned hash, the contact is initiated with a peering host. Public keys are exchanged. Each peer, okay, okay, hold on. The way that public keys are exchanged is we've got these protocol forms and there are certain fields that we've identified as being manipulatable. We can change things there. Okay, for example, we've done this local traffic sampling and we know that within an IP header TOS field, there's certain values that are statistically distributed certain ways. We can use those fields in the statistical distribution that we've determined and shared key, here's another function of the shared key. The shared key is broken up into blocks. Say we haven't determined what these block size will be. Say 100 characters, whatever per block. When it's input into the hash function, and this is the initial hash function here that's just used for the exchange of PK keys and then local traffic data, when it's input into the hash function, the hash function, and this is shared, realize, so both sides are doing this at the same time. The hash function outputs what protocols are going to be used next, what fields we can use with them, those protocols, what sentinel values are going to be used for each instance of using those fields, what timing information, how long we should delay, which ones we should pad, which ones we should chop, that sort of thing. And because both sides are in tune to the same information, they're generating the same thing from the same, they've got the same hash function, they've got the same symmetric key, both sides are going to be in tune to this data, so I can use that to generate traffic and they're going to be listing on that to pick it up. Okay. The next thing we have to do is we have to exchange traffic pattern data. We've exchanged keys. Okay, question. Because symmetric key is only going to be used initially to, the symmetric key isn't generally used for encryption. We use it initially just to encrypt the public keys, but thereafter the symmetric key is used just to generate the hash or as an input to the hash to generate the next protocols and templates to the next protocol forms that we're going to be using. It's possible that we could use the same thing, but in various discussions we decided that it was more secure this way. I don't know. We could talk about it offline. So we have to exchange traffic pattern data. Both sides have been doing this local traffic sampling now for X amount of time. It might be a week, it might be a month, it might be a year. We're not going to stop, we're not going to move on to the next step until we've determined that we've got enough traffic that we can go ahead and start communicating securely. We know what patterns around us look like. So now I compress all this data down to the most important bits, the traffic pattern data that my side has generated and I send it to my peer. He does the same to me using the same system that we've just discussed for exchanging the PK keys. Each side then diffs the other peer's copy of their local traffic data and my copy and we decide on lowest common denominator and then that's what we're going to use initially for that's going to be an input to a separate hash function, very similar but a separate hash function that determines at any given time what protocols we're actually going to use and what timing information. Question. We're only at this point using protocols that we think are ubiquitous. Right, so we might only be using a very small number of forms but at this point we don't have a lot of data exchanged so it's fine at this point. So anyway, we then diff the two traffic pattern sets, decide on lowest common denominator, now that's the input for a new hash function and now we're ready to begin actually exchanging messages. Okay. Okay. Sure. Arp spoof it, use Mac off, something, you're going to have to get that's going to be noticed. Yeah, that's why it's set up as a rule that you've got to be somewhere. That's generally not advisable. We want this to be as passive as possible because anything like that could then be detected. So we're making it, it's an assumption that has to be there already that we're sitting where we can see a lot of traffic without doing anything special. That might be a hard assumption but that's really the only way that this is going to work. We'll stay passive, that's the thing, we'll stay, right, we don't want to do anything active there to get more traffic, we really don't. So we're on switch environment or as a router where we've got a lot of things going past us. Okay. So here's how it works. Now that we've got this new, okay, sure, I'll do that. Okay, question. To get symmetric keys sent back to them, well, that's possible if we could exchange pk out of bound, that would be ideal. Does that answer your question? Sorry, I didn't even repeat the question. But yes, okay. Here's how we hide data within the protocols. With this other hash function that we've tuned to our lowest common denominator traffic pattern data, we bring in symmetric keys input and both sides are doing this and we determine, say, okay, the next packet that's going to go out is going to be RDP and we're going to, these are the possible fields that we can manipulate and we can possibly change and it'll still be fine, it'll be normal within our traffic distributions. And this is the timing information, this is how long we want to stay, this is how much, you know, where we want to chop this message. These are the sentinel values for each field and each iteration, again, based on the hash value, will determine a new sentinel value. So for example, again, going back to the TOS field in the IP header. On a particular iteration, we might determine that it's an 8-bit field out of the last four bits, only one can be set at any given time to one. So we might say the last four bits are 0100 and that's our sentinel value for that iteration, for that field. So we've determined these things. So I start going through the possible fields that I can manipulate and I come to the first one, I pull off a byte off my queue, the first byte that I'm trying to send, you know, sending the secret word and if I can put it in that field and there'll be a valid value within our local traffic patterns, then I'll go ahead and put it there. If I can't, I place the sentinel value there. Both sides are keyed to the same thing, so the other side can look and if there's that sentinel value there, it just skips over to the next possible field that I can use. This should be really obvious, or it should start to be becoming obvious, but this is like bandwidth intensive, I mean, for every couple of megs we send across, we're just sending a couple of bytes across that we're actually going to... So this is intended only for the algebra, this is only intended for the extreme case where you use this medium and you absolutely cannot afford to be detected, you know, you might die, you might get killed, whatever. And we're not going to send traffic across, you know, again, until we feel that it's safe to do so. We're going to match local distributions, we don't want to significantly affect local traffic pattern distributions. Another thing, we're completing full sessions here, like we don't want to just, you know, send a send and then we move on to another protocol, whatever. Every time we complete full sessions within the protocol we're emulating. And we're also fully authenticating and handshaking and checking the data that we do send across. They're going to send it back to us, verify it or send checksums or something like that. That hasn't been decided on, those are all implementation details that we'd easily figure out later. But there are full handshakes, full sessions are completed every time. And then we move to a different protocol. And so basically, we might be, if we're in an environment where there's a lot of traffic going through and we might, you know, every millisecond we're switching to a different protocol, finishing a session. That session might take a long time to finish, like, you know, we'll already moved on to a different protocol but we're still finishing the first one, things like that. And the other side is key to the exact same data so they know where to be, where to receive the next bits, they know what fields we're going to be manipulating and they can pull those bits off. But otherwise it's going to be like a normal session of that protocol type. Here's a little, a little ugly thing where it makes this implementation really tough to do. And this stuff I haven't implemented yet and it's going to take forever. It's going to make this application massive. The thing is, okay, one, we've got to speak all these protocols. But two, an active attacker could say, well, okay, you're speaking, you're speaking RDP, let me try to talk RDP to you. So you have to be able to talk RDP to you. So all of a sudden you've got to have full implementations of every protocol that you want to use. That gets really massive. Otherwise the other option I guess would be act like you've got a firewall in place, some sort of filtering, you know, apple set such that you're only doing RDP with this IP address. But what if the attacker spoofed that IP address then you've still got to talk RDP with them. So that makes it really tough. There's one other little gotcha here. The one noticeable thing is that people monitoring traffic would all of a sudden see these two hosts who either weren't communicating at all before or, you know, very little, are all of a sudden communicating on all these protocols a whole lot just between these two hosts. That's certainly an anomaly. There's not a really easy solution to that except wait a long time before you send more data to that host so it really isn't that much more, you know. Or, I mean, you could always spoof traffic that you send and then spoof it to you and you'd sniff it off the wire or you'd spoof it sending it to an address that isn't your peer but that they can sniff off the wire. But again, that could be detectable. That could be detected by a well-resourced because if they could compromise the hosts that you spoofed it to and determine that they didn't really pick that up or that they didn't initiate the connection then that could be detected. So that's not really recommended either. We're looking into doing some sort of, you know, crowds-like system to where there's actually a whole chain of remixing that's happening. So you don't always have to communicate with the same host but you communicate with other hosts and then they eventually forward the traffic back. But right now we don't have a good way to do that. If we do it, if we just did that at face value, like something like what Mixmaster might do or something like that, then somewhere these centralized remixing hosts are going to have to have the IP addresses of us and then therefore they would know that we're communicating we're part of this client as a network and we can't. We can't work under that. That's not set for among great assurances. So we have to assume that these other hosts might be compromised or rogue hosts might come up or something like that. That's pretty much it. I mean basically this is stored forward messaging. It might take forever to get messages delivered. This is nowhere near real-time. Question. No. We're not using the same symmetric key for the lifetime of the session. What happens? Thanks for bringing that up because I didn't mention that. What he asked was are we using the same symmetric key for deciding where we're going to... What protocols we're going to use forever for the entire time period? Good morning. So I'd interrupt. Some jackass is walking around with a reject hacker exploitation fight back pamphlet advocating violence and damage to the hotel. I strongly encourage you not to do that unless you really, really want to see the Metro County jail here in Las Vegas. If you do see him or her please encourage her to stop. It's not funny. It's causing problems. We've been kicked out of every other hotel on the strip. We don't want to get kicked out of this one. They kind of like us here, but stuff like this makes them not like us very much because they really don't understand what we do. So I would strongly encourage you, like I said, to report this or at least encourage them not to do this. I'm not advocating violence so please don't misunderstand me. But we would like to see this stopped. Which brings me to another point. Like I said, we'd like to stay at this hotel and we'd like to be able to come back next year. So far we've had someone steal the majority of the lights along the main row by the swimming pools. I realize we're 13-year-olds of all ages here, but I would strongly encourage you to do if you have the lights or if you have other property in the hotel like the soap dispensers from the bathrooms. And I don't know why you took those, man because you know what, if you're dumb enough to take those you better be washing your hands. So if we have a general amnesty, if you have them, no questions asked, return them to the knock. For those of you who don't know where the knock is, the knock is at the very end of the building on this side. It's labeled. You can't miss it. It's where the speaker's area is. Like I said, please bring whatever fanilia you have that belongs to the hotel that you really shouldn't have and you know who you are and I'm sure you have friends who you know who they are. So please pass the message. We are supposed to be the brightest of the bright here and I have urged to string basically rope ladders across the ceiling with some swinging tires so that you all can throw feces at each other. Because you're acting like chimps. So like I said, I realized we're 13-year-olds of all ages that however it's not excused, lame-ass pranks, excuse me, like taking the lights. Had you hacked the PBX, I'd applaud you. You stole the lights. My 4-year-old niece can steal the lights. Are there any questions? Yes sir, stand up. I cannot condone drunken disorderly behavior. Myself being an Irish Catholic, I'm usually smashed by about 5. Myself also being a Jesuit priest. That means I really get drunk by 6. Accidents happen, we understand that. The problem is we had some people teeing up and playing golf with the lights and then walking away with the lights. Vegas has some wonderful golf courses. If you really have the need to bring out your sticks and to play golf, go to the golf course. Don't use the lights. If you find the lights, if you could please turn them in. Like you say, if you see them broken or something like that, nudge, nudge, wink, wink, bring them down to the knock, tell us that they were broken and you're returning it to us. Don't set fire to the tent upstairs. That's a very bad thing. Once again, my 4-year-old niece can do that. We expect better. This is the uber-hacker track. So if you're running scripts, then you probably should be at the other room over there where the newbies are. So like I said, if anyone wants to come talk to me personally about it, that's fine. Like I said, you have general amnesty. We will not prosecute you. We will not beat you up and take your shoes. We just want to make sure the property gets returned to the hotel so we can come back so you all can come back next year. Unless you don't want to come back. Who does not want to come back? Any other questions? Anyone else have any questions? No questions. Very good. I'll turn you back to your questions. Cool. Brief interlude. There are two FBI agents. One of them looks like John Denver because that's a little bigger. And he's wearing a DEF CON 5 shirt. So I'm going to get it really easy on you guys. And we can steal the lamps. So I've got to make it easy. Just yell. Okay, back. Addressing the question of if we're going to use the same symmetric key for the entire duration of the session, for eternity between these two hosts? No. With the messages that we're sending across, like I briefly mentioned, we're chopping them up, adding padding, adding all kinds of bits of entropy, just definitely not sending them as soon as the messages arrive, things like that. Well, also to fill in the gaps and just add a little more confusion. When we're not needing to send in messages across, when we're just wanting to fill in space, we're changing more data for adding onto the symmetric key or parts of new symmetric keys. So that changeover is constant. Right here in the black. Okay, the question here is since the whole point of this is to get as many bits through without detection as possible, he says my method is very slow compared to other methods that are out there. Well, in looking at everything else that's out there, this is the only way that we feel that we can assure security and assure secrecy. And it's not a concern how slow it is. We want to make it as slow as possible to make it secure. He had a question, green shirt. Yes, the question is, and I just mentioned that a little bit earlier, but just look for, as an anomaly, the fact that all of a sudden these two hosts are communicating on a lot of protocols, a lot of stuff that they weren't communicating before. Yeah, and that's something we're working to address. I briefly mentioned that a little while ago. A white shirt. Can you give more information? Yeah, the question here is that instead of trying to emulate all the protocols that we find there that we can get a lowest common denominator over that might look like quite anomaly, how about if we identify one host or a couple hosts and then take some features that all seem in common and just use those as a host profile. That's a pretty good idea and we very much might implement something like that. The only problem with that is would have to increase the amount of traffic that we're using over those protocols that much more in order to ever get significant amounts of bits across. Other questions? The question is how about just spoofing traffic from other hosts and then have it sniffed off the wire on the other end and then it'd be dropped at the host that it actually ended up at because it didn't match something they sent. Yeah, I mentioned that actually and we can't really do that because if an attacker compromised the receiving host and determined and compared the messages that they've sent and the messages actually sent in between and the messages received at the end and they didn't match then you'd be able to determine that these other hosts were doing something in the middle. What if we do this with an array of hosts? The interesting idea there would be if we had a whole array of sending hosts and receiving hosts and the sending hosts and the receiving hosts kept state amongst themselves and then use each other that would help some, but this is detectable so we don't want to use it. Back there, Beard, he says how about using packet radio? That's certainly a possibility. We're trying to limit ourselves to the wire. Man, we've got right there. Yes. He's talking about using secondography to hide stuff inside other stuff, inside messages, inside graphical images, something like that, post the use net, post the demand list and just have other people grab it off. People work very well but there are other systems that are working on doing something like this or something that does this so this would just be something else to add to the arsenal. Straight ahead there. Yes. He's talking about this is all state oriented. What if we need... Can you say that a little louder? You could watch it anyway and keep state even with connectionless protocols. Right here, question. Noise level, floor level. Total traffic. Right. The question here is because we rely on there being a bit of ambient traffic around us have we thought of increasing the amount of ambient traffic around us, manipulating it? That's possible. We'd have to be really careful about doing that because then that could be detected as well. Sure, we could throw up a bunch of other boxes around us and have them all be real chatty. We might do that but I don't know. Lots of questions. Very good question. If the sentinel value is the same as the data we want to send across then the sentinel value stays and we move on to the next field and we use the next field which will have a different sentinel value. Every field has its own sentinel value signed so we move on to the next one and use that position. That's a good idea. He says why don't we start a bit earlier and begin to create some of the distribution that we're looking for? I don't know that necessarily would create the distribution we're looking for but just have our two hosts begin communicating a bit earlier before they're doing any sort of traffic that might be detectable. That need to be very changeable because then someone might be able to look for that. Before I take any other questions one other thing I want to add here we're fast that makes this implementation even bigger. Not only do we have to emulate all these other protocols but we have to emulate all these other languages because we don't know where this is going to be used. We have to put valid looking payload data in this packet. It's realized right now we're only sneaking stuff through in headers. Just a little bit of stuff. If we're sending an SMTV message we've got to send a piece of email and that piece of email can be analyzed. It can't be any words that are in our application. We have to assume that our attacker can get access to our application. That's a hard problem and that's like a linguistics problem. We've got to be able to determine what the local languages are and pull words and put together sentences that make sense and all that kind of stuff. Same thing for lots... No. Are we planning on doing any manipulation of the source MAC address? Generally not. We don't want it to look like it's actually spoofed because then they'd be able to check that and see that that's not actually our MAC address. If we were spoofing, yes we would and would spoof the MAC address of the IP we're spoofing as well but we don't want to do that. We wouldn't be placing this in a governmental facility and we might be using existing equipment but sure, sure. Absolutely. He's saying what if we take this machine into some place and we place it there where it's going to be noticed. This new MAC address, that sort of thing. We're not even talking about going and compromising PacBell or something and sticking your machine in there. That's outside of the realm of what we're talking about here. The question is have we considered using steganographic techniques to hide stuff within the payload itself? Maybe later on, working with this right now, we're just working with the header. Eventually we'd like to be able to generate graphical images and all kinds of stuff, generate email and using hidden, basically agreed upon words. Apple actually means the NSA and all this stuff and things that would change based on a one-time path. Eventually we could add in things like that but we're not looking at that right now. Reger. The question is if the sentiment value for each field changes on every iteration, every protocol form how does a receiving host know what sentiment value to look for? That's generated as part of the hash. It's also generating sentiment values for every field that we're manipulating. So that's agreed on and both sides too. They're both generating it from the same symmetric key. They both have access to that. Other questions? Yes. He says, should we constantly sampling the network to adapt? Yes, we're going to continue sampling at all times and we can do later exchanges of traffic data and we might not change it until it's statistically significant. If 13% of this pattern changes then we'll begin slowly, randomly to begin changing our patterns to match what it looks like around. Another question of follow-up. The question is, do we do any error checking of the data that we're transferring across? Yes, in the shared we're completing every session and also within that we'll probably end up doing something like FEC forward error correcting code, something like that in order to check out there. Oh, if this space or the amount of transfer that we're going to... No, probably we'll do summarization as we capture traffic. The question was how much disk space are we thinking of having to need in order to keep all the sampled data around? We'll do summarization just like an application like MRTG does. It summarizes everything that goes along and reduces it down and so we could easily implement something like that. Other questions? Right there. That's a good idea. Hopefully everyone heard that. There's a couple ideas presented there. The one was instead of implementing this as a library that we need to add the functionality to access from whatever, eternity servers or something like that, just implement this as a kernel mod or as part of the kernel we'd have to then do that for lots of operating systems. But such that all traffic destined for our peer host automatically goes to these... We could certainly do something like that. Okay. Right here. Can you clarify? No. The question is, is there any attempt within this architecture to take advantage of asymmetric bandwidth schemes where we've got a big pipe going in one direction hopefully towards the client destined covert op and a small pipe leading back away where we can just single bits mean a whole lot. I'm standing here and I wink and depending on the context that one quote bit of data actually means a whole lot. There's nothing currently built into the system like that but that's something very much to consider. Other questions? Right here. Yes. Very good idea. His suggestion is in the case of something like MI6 or a well-resourced government that's putting this into place wouldn't it be a very good idea to put this on a router where there is a lot of traffic? That's a very good idea. If we could guarantee something like that in place where we can actually guarantee because it's controlled by the very people in charge of the system that Eve isn't going to have access to the host behind it and we put it on a router where it's got thousands of domains coming, lots of subnets, all these things that works beautifully. Other questions? The question is, couldn't we compromise a bunch of host systems and then use them to filter out and not just be communicating to one host but communicate to lots of hosts and we could do that but that could be detectable. You could detect at the host and you'd detect who is sending stuff to it and we kind of don't want to go that route right now. But we have to assume a well-resourced attacker could determine that. His point is with listening or what are called like number stations there's already an infrastructure in place to transmit MI6 out to the agents. We would just need to implement something for the agents to talk back to MI6 via this mechanism. That's certainly a point but although I'm using as an example MI6 here that's not really what we're thinking about. We're thinking about more the persecuted political person who's hiding freedom fighters who doesn't have this sort of resources. There aren't number stations set up for them. That works in the case of NSA using this or somebody but yeah. Other questions, yellow. The question is how often are we going to be changing sentinel values? But I don't think that it quite makes sense but basically sentinel values are different, are unique for every single field position in every single protocol form that we use. Basically you're saying that they're going to be able to detect the sentinel values themselves that they are an anomaly? No, we're generating these sentinel values from what we determined to be statistically significant portions within our payload data and so it's going to look like traffic around us and in the same distribution of traffic around us. Anyway, I think that's it. Last question, we're now doing spot the FUD. If you want to talk to me, ask me more questions offline, we're doing spot the FUD.