>> I'm going to kick it over to pdogg 77 and the Duke Zip. >> Thank you. Good morning Defcon! [Audience noise, comments.] >> Good Morning Defcon!!!! [Applause] >> So welcome to our talk, it's on Steganography and commonly used HF radio protocols. We have tons of content for 45 minutes we've cut this talk about a million times so we are going to just jump into it. First off, I'm pdogg, Paul like when pdogg is taken on Twitter, someone beats me to it, I'm pdogg77. Uhm, as a day job, I'm a security researcher at a start up called Confer Technologies Inc. We're doing some cool things with end point security threat sharing. Well, if that's interesting to you, check us out at confer.net. But I mention that because this has nothing to do with my day job, it has to do with amateur radio. Amateur radio has been a hobby of mine since I was a little kid, thanks Dad. Uhm, I'm now an extra classed, licensed ham as well as an ARL volunteer examiner. We'll talk about that a little later. This is my second trip to Defcon, so if there's any first timers out in the audience, come on up here next time please… and I'll turn it over to Brent. >> Hey everybody, my names Brent, I go by thedukezip on Instagram and Twitter. I actually don't work in the security industry whatsoever. I work as a software and systems engineer. Specifically dealing with radio protocols and devices, but hacking all the things has been a passion of mine for way longer than that so, I love being here. I'm also an amateur radio operator since 2006 and I upgraded to my extra class last year at Defcon actually. I'm also a volunteer examiner. So, one very important warning, we're going to talk about hiding messages inside amateur radio communications. And we're going to talk about using cryptography layered on top of that.Then we're releasing a tool that does all of this for you. This is completely against the FCC regulations, as far as our interpretation goes, so we do not actually transmit any of this over the air, and we are not recommending that you do so either. Okay! So, another warning, this was a project that kind of started as a fun conversation over drinks at a Massachusetts meet up called Mass Hackers. Ahh, we are talking about cryptography. We believe we are just using cryptography libraries, that we're just calling using the correct methods. But, if you're trying to hide your stuff from 3 letter agencies, you probably want to audit the code. If you find something we did incorrectly, we'd love to hear from you, you can let us know and we'd be happy to fix it as well. So… >> So what are we really talking about? We set out to demonstrate to ourselves and hopefully to you that it's somehow possible to create a really low infrastructure, fairly long range, covert, short message protocol that could be used in many ways. Whether it was point to point, broadcast, or mesh. And for reasons we'll talk about pretty soon, we wanted to use common, off the shelf consumer radio and computer equipment and some kind of commonly used digital communications mode that was already in use. Why would you want to do that? Well, the vast majority of us are dependent on some kind of short message communication all the time in our day-to-day lives. Whether it' something like Twitter or SMS what not. But all of those communication mechanisms are really dependent on some third party to provide the infrastructure whether that's an ISP or a cell phone provider or someone actually building the platform on which we communicate and those third parties don't always have our best interests at heart right. So we could subject to censorship or spying, or in extreme cases these people want off switches on these communications, right. So Mom and ApplePie at Defcon I guess, we believe it's a fundamental human right to communicate without that form of interference. That's why we're talking a look at this stuff and one of the reasons we think you should be interested in this as well. So you could use a method like this, hopefully to communicate in these ways and we'll highlight some portions in the talk where relatively small changes to things we are doing could result in new protocols. So you could definitely take forth this research and create something that is completely different but along a similar line. If that doesn't motivate you, then most likely there are bad actors doing something like this anyway, and I think it's important to actually look at what is possible, what's some of these communication mechanisms might look like. How we could find it, etc. so we could combat really bad actors using techniques like this. >> So Paul mentioned we want to have all these communications without the use of any infrastructure whatsoever, that obviously includes the internet - which we are all very familiar with. It just so happens that amateur radio operators are experts in communicating in worldwide without any infrastructure whatsoever It is a real cool hobby and you may hear us refer to it as amateur radio and ham radio, the terms are kind of interchangeable. Uhm, you get to do really cool stuff like transmit with up to 1500 WATTS of power, which is a heck of a lot if you are not familiar with that. You get to do cool things like bounce signals off of the moon or off the ionosphere over to the other side of the earth. Or practice sending a message to a satellite and having it repeated on the other side of the globe so…. All kinds of really cool stuff you can do with amateur radio. One thing that is important to mention is, after we submitted this talk to Defcon, this group calling themselves Luizlabs released a tool called AirChat, it's similar in some ways but very different in other ways. It also uses encryption over amateur radio but they are making absolutely no intentions to hide that. They're basically just transmitting encryption, anybody listening would know that. Where as we're doing Steganography, anybody listening should think that it's some innocuous normal message that they would totally expect to hear but buried inside it would be something completely different. So, you know, good stenography, good OPSEC. This is actually a picture from the tv show Lost, of which I was a huge fan of and there was this numbers station on this island that continuously transmitted 4, 8, 15, 16, 23, 42. Uhm, but number stations are a real thing. There are stations you can tune in to on a short wave radio and there's some creepy music and some person comes on and the air and starts reading off numbers and 99.99% of the time the people in the world actually have no idea what they mean. We think that, or some people think that they may be secret instruction for spies across the world or something. But, they're not trying to hide it. They're just sending numbers and everybody knows it means something secret and you don't know what it is. We're talking about doing things like having a radio in a pelican case and you can run into the woods, throw an antenna up in a tree and start transmitting your secret message and then take it all down and run away. And if you're a receiver you can have a 30, 40 foot antenna in the rafters of your attic and nobody would even know that you were listening in. >> So how are we going to hide? We'll talk a little bit about the protocols that are used over amateur radio and HF radio for digital communications. These protocols are very much different than some of the traditional networking protocols we think of. In most cases they don't have some of the features we would typically look at to use for a covert channel. The protocols are extremely tight, they're the utilization of bandwidth and power is restricted because it's thought of as a Hallmark of good amateur radio engineering not to use anymore spectrum than need. And not to use anymore power than you need. So you look at the design of these protocols and they are really designed in that way. Then you can look at maybe doing some sort of timing or substitution or error timing between symbols. Or substituting one symbol for another, etc. and those are visible and the more you use these protocols the more you can stop seeing that stuff on the screen and you can start hear it with your ear. We also took off the table what's termed auspicious emissions, hum or adding additional tones or signals along with the transmitted signals, that is also against the rules, along with everything else we are talking about. It's extremely visible and again amateur radio operators have a tune ear for that and it's thought of as bad practice so it's murk more likely to get noticed. The candidate protocol for this really has to be in widespread use. It doesn't matter if you find an ideal protocol for a betting Steganography if you are the only person transmitting on that protocol it's still a bit fishy. And then again we're looking for protocols that needed no special hardware or closed software. You can find great packet radio protocols, etc. but usually they require some sort of proprietary interface or software, etc. We were doing something you can do with standard radios and computer equipment. So, predominantly we're talking about what in the amateur world is termed sound card digital mode, or a mode that is modulated and demodulated with only a standard sound card and more or less a pc, a standard computer system. So the output and input of the sound card are wired to the microphone and output of the transceiver and then somehow usually through like a serial interface, your keying the microphone on the transmitter. There are countless numbers of these protocols, anything from these well designed, well documented to something someone threw together in their garage. So, if you're a protocols person, there's endless stuff to play with here, go take a look. Some were the modes were developed specifically for this kind of use but older modes, such as radio teletype have been in use for a very long time and have been adopted to be transmitted and received as well. But most of the examples up here are very common protocols, they suffer from the problem we were talking about, they are very tight. There's almost no room to shove in any extra information here. The other thing to know about these protocols is they are more or less keyboard to keyboard chat. You can send freeform text, whatever you would like during your transmit cycle and then switch over and then the other person talking to you does the same thing. So it's more or less a back and forth chat. So, we need to find another type of protocol. Enter this protocol named JT65, it was developed by Joe Taylor in 2005. Originally detailed in a paper he wrote. It was designed for earth-moon-earth communications. Bouncing signals off the moon and returning then back to earth. It's a very long glossy path of course. This protocol has some error corrections built into it. It's extremely power efficient with about 25 watts of on a good day with decent conditions.Can communicate worldwide with JT65. It's kind of an in between chat keyboard to keyboard chat protocol, And some of the more packet protocols, we will talk more about the structure. It has an extremely low data rate. It's one of the tradeoffs here, all of this is a tradeoff, for privacy in the communication we are traducing a lot of bandwidth you will see. Good news it is an open source implementation, uhm, it is in 4 trained the error correction code is in C. So we did deal with the 4 trand code because we wanted to stick as close to the real implementation as possible. So what does a JT65 Communication look like? This is a screen shot of one of the more common clients that is in use. Basically, amateur radio operators use this protocol to exchange a few little bits of information that compose a communication. Amateur radio call signs, the 4 digit grid locater, in a system that is detailed in a bibliography notes as well as a signal report. How well one side is receiving the other communication.It's sort of a time dependent mode. Transmissions begin at the top of a minute and are around 47 seconds long with about 13 seconds of silence. So it requires some clock synchronization between the receiver and the transmitter. When they are used on HF frequencies, generally hams congregate around these watering hole frequencies, which are displayed on these slides. And for the radio folks in the room, it's uppers sideband am. So, you're getting about 3000 Hz of usable paths there. And multiple JT65 conversations will happen within that path. You can see on the waterfall display up there, there's one that is fairly strong. Kind of to the left, around 500 Hz. So let's talk about how this protocol actually works because we need to understand how we can hide in it. Here's one of those structured messages that I talked about. These are 2 amateur radio call signs and the grid locator. Hopefully these are not still someones real call signs. If they are, we're sorry. The protocol puts that message through a custom packing routine that understands or has look up tables for an amateur call sign, the prefix, the suffix, pieces of that grid locator etc. And you get a 72 bit message, it's shown here as 12.6 symbols and it's usually manipulated in those 12.6 bit symbols. Remember we have a one minute transmit time and we're talking about 72 bits so you can do the math. We're not talking about streaming HD video. That's the source encoding, then it goes through a very important step, it's transformed into a 63 symbol message through Reed Solomon encoder. Sorry… hum, and then the resulting symbols go through a series of shuffling operations interleaving operations as well as a grey coding to result in 63 more symbols which are the final symbols. In the original paper, Joe Taylor says that some of these steps were down to improve the error correction capability of the protocol. From here it's modulated into audio and we will talk about how that happens. You have these symbols here that are shown just as regular numbers. Those numbers are put through this formula so JT65 is an MSK multiple shift keying protocol and you can see the formula there, do the math. You put in the number you get it's home. One second.. these guys are coming up here. The actual packet, and that's our term, uhm, I don't know if it's really used out there is 120 slices. A full half of the packet is a synchronization tone. A demodulator uses to find these signals and find the relative value of each symbol value there. So that is how it's transmitted on the air. That synch tone becomes really, really perceptible to your ear and you almost start singing it to yourself. This is the alien music that we've talked about. You'll hear some of it later. You start singing it to yourself when you are working on a long project with it. How are we going to hide Reed Solomon Codes? We're going to shove in some errors, I'll cut some time off this slide…so we can do this. And, we did it in multiple ways throughout the process of the project. In the end and what we're going to talk about is we're basically going to encrypt and pack our own custom message and apply forward message correction on top of that. Basically a truncated message of the same version of the Reed Solomon code used in JT65. Reed Solomon codes are everywhere, there's prior work in Steganography code so if you want to hide information in Reed Solomon code just look at that paper. >> Pardon the interruption. For first time speakers it's hard to get accepting and these guys did it so give them a round of applause, please. [Applause]. >> Brand new tradition. >> As you were... . >> I would like to see you ‑‑ >> I'm transferring the microphone over to Brent. >> So how are we actually going to do the steganography. Say we want to hide inside the JT65. Say we want to hide DEF CON 22. Right, we're going to put it through that same stuff the JT65 uses and convert it to 12 six bit symbols and we will add an additional 8 bit symbols, the same one JT65 uses. We're not make it quite as big but we will make it big so you can tolerate errors from interference or inside the transmission. This allows us to tolerate 4 errors in the steganography portion of the message. Now we also have to pick places we're going to stick this in the message. So we allow the user to input a key that the receiver would also have to have knowledge of and we'll take the hash and generate 20 locations for that. Now there's 63 possible locations. So we'll take the bits and monitor by 63 and it gives us all those numbers but of course we will have a few left over because 256 is not divisible evenly by 63 so 252‑255 we'll just throw those out so there's not an uneven biased to the symbols zero through three. So it will all work out in the end. We promise you. >> It made sense at 4:00 a.m. >> It made sense at 4:00 a.m. Right? For this example these are the 20 locations you would get out. So we can take some innocuous message, two call signs and the grid locater. This is the 63 symbols. And the 20 locations generated and we'll start with the first by the. Location 9 we replace with 42. You go through all 20 symbols and what you end up with the original message on the top and new message on the bottom that can be recovered both into the innocuous message and if you know the key and can reorder those symbols in the correct order and no where they're located from that key you will be able to get the message as well. This will go a long distance fan you pick up interference you can still get both messages out of it. But we want to do encryption too. We like encryption. Yes? So there's 12 six bit symbols. Seventy‑two bits. Most of the encryption standards I know use 8 bits. So if you divide 72 by 8 you get 9 bits which is a co‑incidence and we love that fact and this guy does too. So what question was we created a packing function. (So what we did). You have 9 eight bits. There's no magic here. We decided to do it where you have 8 data bits and 1 bite, header. Why would you want a header in this message? We thought it would be cool if you had a long age in would take multiple transmission to get across. It would be feet if the receiver could see you received packet 100 or packet 2 of three and when you get the third you can reassemble the whole thing. So we basically use it to keep track of packet numbers for assembly. In the case of a stream safe cypher. The remaining 6 bits are used for the total number of packets, packet number or because we have a stream cypher we need to track how many bytes are actually used in the last transmission. In a block it's simpler. You have that slide for the first packet and 7 bits to track the packet number. This gives us the limitation of one message if you want to call it that. It would be limited to 1 kilobyte the of data. If you have more than that you can do multiple longer transmissions and reassemble again. It's not really a limitation. It's really what's cool on the slide at 4:00 a.m. So we went through all this and we had a problem and we'll talk about some statistical analysis we did on this data. But what we found by doing this was it was really trivial to pick up the steganography if I messages. You end up with the symbol number 32 way more than any other symbol. It was very, very obvious. If you knew what to look for. So we came up with something cool we're calling bit swapping. >> Or bit Magic introduce classroom engagement. >> You take the 8 bits and swap them with 1 bit each of the 8 data bytes, and this particular diagram may not give you a warm fuzzy feeling because it forms a pattern in the data bytes but when you convert it to the 6 bits it distributes the bits among all the bit locations. So doing statistical analysis on this in the end it comes out very much flatter distribution. It looks good to us. So the tool we are releasing we will demonstrate is kind of a multi-layered software. The bottom layer, base layer is just built off the original force trans code and c source code we've compelled to make it accessible and C source code from JT65 protocol and compiled with F2Pl and be accessible from Python.C code is just a binary we can call. On top of that we made it easier to access with a wrapper layer in Python on and for our libraries there's actually two JT65 StegaH  is where the encryption and steganography that you can call is in this library and the JT65 sound which is a python library for all the audio, N coding and G coding. You can create your own tool to do this however you wanted. The analysis package which we'll talk about JT65 analysis fan you want to mess around with the protocol and change things around and experiment and see how you can make yours different this comes with black tests so you can make sure if you're experiment doesn't break anything. Play with that if you want to. If not we did it for fun. This is where we demo the tool. We hope the AV does not blow up. You can see that, right? Okay. >> So I'll show you the help output from the tool. There's two basic functions N code and D code. There's a bunch of options here. You can inject additional nose if you want to try to hide where your message is embedded and interactive mode for listening to messages live on the air, places to embed your messages, the JT65 protocol if you look into it more there's options like a frequency, a base frequency and mode. For examples for cyphers and encryption we have super secure stuff. Okay. All the way up to real things like GPG and 1 time Pad. There's trade offs using these and you will figure out what they are but we have shown all as examples so do what you will. For the output you can print the symbols to the terminal or wave file you can broadcast over the air but we did not or for the input the same thing. So let me show you what happens when you encode a message here. It's cutting me off. Okay. Let me run it then. what you can see here is we've encoded this message. The innocuous message is two call signs plus a grid locater. Anybody listening would see just see that on their tool. Our steg message is Defcon22, we're using the queue from example pdogthedukezip and printing out the symbols to standard output and you can see what symbols will get transmitted over the air. If you kind of wanted to kind of follow along the different stuff this tool uses you can enable verbose mode where you see that source encoding stuff where you get 12 symbols and add in the error and the final message is displayed here too. But the cool stuff of course is the audio which I know you all want to hear. So here we'll do the exact same message but I will put to an wave file, and I will go ahead and play that wave file. example same message but I'll play that for you. >> Sing along. >> I love singing these things. After you've been listening for 4 months every night you will love singing it too. >> (Beeping noises). >> We affectionately refer to this as the alien music because it sounds bizarre. Especially when you're listening to the real air waves and you've got multiple messages happening at the same time at different base frequencies. Of course you have the static in the background and other noise. It sounds really creepy and we might have an example of that coming up as well. But it goes on for a minute but we want to do it as quickly as possible. So let me show you what happens if you run the actual tool that the most common tool everyone uses to use this protocol, WSJTX. So if you were to open that wave file or hear it over the air waves what you get is all you'll see is that innocuous message. There's no other indication here that there are errors in the message or secret cryptographic data. Close that out. Whoops. I went past it. If you go to decode that file with our tool, you can see both the original and the innocuous message and the steganographic message as well. >> So we wanted to play with this in different form factors. One of the things we envisioned as we worked on this project a portable feed reader and that led to this. This is raspberry pie with a display on it. It can be run on batteries and plugged into that which is pretty common short wave receiver. Basically building a receiving station for this for under $200 running on batteries. We were going to demo this here but we're in RF hell in this room and receiving those low power transmissions is not going to be possible. So videos didn't happen. >> [Off mic] >> That is connected to short wave receiver. >> I hear the aliens. >> The pie is decoding. >> This is the part where the lap top dies? No anyway since we're short on time Brent will fix the lap top and what I will do is talk about some of the analysis that we worked on. I'm hoping I get an analysis slide. So we wanted to look at this protocol and basically figure out how would you locate if someone was going to do ‑‑ if someone was doing these types of activities and generating the JT65 packet. If you've been paying attention you have some limited population of real JT65 messages in the universe. Right? It's the structured communication that goes through predictable error correction algorithm, et cetera. Then you'e shoving a bunch of errors in it. This gives you a lot of other statistics about the packet that's been received. One of which is a confidence value. That confidence value is essentially the demodulator as it then signals into the various tones and it gives you the value which is how sure it was the given signal was correctly demodulated. So our thought process was you take the numbers of errors in a packet and signals to noise ratios or confidences and do some sort of analysis and figure out whether a packet was suspect or fishy. There's great pictures of this that we don't have right now but there's been analysis tool or analysis section of our tool which will take in either a single JT65 packet or multiple and it will produce graphic analysis of this for you or it will output all these statistics in basically a comma separated value and you can import them into any tool of your choice. So you can process these in bulk. We listen to probably around 3,000 transmissions on 20 meters. Called those basically a population of natural packets. And we generated 60 of our own packets and through the could over cable which is basically a stereo audio cable demodulated that on the bench. When you look at that ideal scenario where you have a lot of packets received over the air and just a few that were generated with the stego tool and you had a clean transmission line the packets were extremely obvious and Brent will bring me to the next slide right now. Please. Thank you Brent. [Applause]. You should always co‑present and have a back up lap top. The analysis module, yes, graphics and pictures and you can see those things. So we thought finding steganography is pretty easy. Here's the pictures I was talking about on the upper left hand side. That's the population of natural packets. On the light hand side you can see the orange dots, they are the stego packets. This graph is numbers of error on the X axis and standard deviation of that confidence value on the Y axis. You will notice this is the really non-populated area of the graph that you see in the natural packets. Then awful our stego packets show up there when we did it on the lab bench because you're essentially taking the low error packets and shoving a bunch of errors into them and they more or less slide into this place that it's obvious they exist. So I closed the lap top, I was done, I had a drink and finished. Brent said it's probably not that easy, Paul. Because you're not taking into account any of the interference that would be normally received over the air. You're not taking into account weather interference, bad transmitters, et cetera, et cetera, et cetera. Transmits on top of each other is problematic in this protocol. So what would happen if you actually ‑‑ again because we can't send these packets legally ‑‑ what would happen if you actually simulated the behavior, if you took the real error values and real signal to noise values, et cetera out these packets on the left hand side of the graph when you substituted them into your Stego packets and pretending that you received those Stego packets over the air, the tool supports that too. You can take a population of real world packets and model your stego pocket against them. In that case not so much. The same measurement value it turns out that there is a lot of error that you get on these transmissions in the real world. So it's not that simple. We tried other measurement signal to noise ratio. Not quite. I'm not a statistician. You've probably already notice that already. There was already enough math here to make my brain hurt. There are some statistical methods we think could tease out a few of these packets. For example you can see we can get some out here but still not all of them. So it's actually a little harder for the amateur hobbyist nonprofessional to detect than we thought. We did observe some interesting patterns. This is the frequency of error symbol and the location of those error symbols that we had seen. In the real population of packets this is about 14,000 packets received at random time at various intervals over weeks. And you can see they're definitely not random when you look at the real world. What symbols happen as errors in the real world and what symbol error locations show up in the real world. We didn't emulate this. If you were going to use a method take into account what happens in the real world. We don't know why this is ourselves but we have theories. On the bottom you will see two pictures. Those are 200 stego packets basically the same message encrypted and encoded with the same key. And you'll see that the locations and symbols really show off as very unnatural peaks there so that's certainly an issue. What about distance? So our theoretical maximum number of errors we could decode is 10. We could theoretically have 10 errors across the packet when we were done and decode the actual JT65 and our encoded message. That's an absolute best case scenario. Turns out more likely 6 or 7 or so we could tolerate. Out of our large population of packets we looked at how far away the sender claimed to be from the receiver and the receiver was that wire antenna in my attic and they were out over a thousand miles. Maybe several thousand miles, couple thousand miles. So it's definitely possible that something like this could be a worldwide short messaging protocol either if A, conditions were perfect or you had repeating stations. Obviously there's vulnerabilities and limitations to this. We made trade off. Analysis and detection is a problem. We talked about what hobbyists can do with stock tools on a bench. If your adversary is much differently equipped than that you might have a problem. Transmitter location is also a problem. There was a talk yesterday on Fox hunting and they do fox hunting here and it's well understood problem in game especially by the 3 letter agency. We certainly think if you can observe transmitters from multiple locations you can better tease out what the error symbols that are injected are. Except for the GPG mode we're not doing anything with signing these transmissions so there's a message forgery problem. You can address that but you're trading more band width. >> So how do you get this tool? We've been working on it for many months. Much longer than we probably ever thought we would but today this morning right before we came on stage we made that public. So this is on gethub/pdogg/jt65stego. There is a version on the conference DVD as well. I would recommend pulling the hub version. We made modifications after we submitted it for the DVD but either one they're both compatible with each other and work great. So we hope we showed you how you can definitely embed hidden messages inside the protocols in digital radio. If you don't want to do what we did you can take the ideas and pick your own protocol and implement it. There's lots of different ways you can hide these things. We only just started to scratch the surface basically. Some things we can do is look into more ways to defect and make sure it's undetectable and working into other protocols as well as I mentioned. So this is actually an older version of the presentation but there's a ham examine here. On Sunday in the crypto and privacy village you can head on down there noon and take the test and if you're not familiar with the material but you want to get into it there's a cram session at 9:00 a.m. in the wireless village which is listed there. If you see the pictures with these light up badges those are the volunteers that will be helping to administer the exam and if you pass any level of the test there's 3 levels you'll be going home with a really cool medallion that's somewhat like this. They're pretty awesome some come by and check that out for sure. I hope to see you there. >> But don't do any of this. And this is actually on the test. So we've actually given you some answers. Don't do any of this. >> Does the person that organizes the exam in the room? Do you want me to mention you? Or be humble? There he is. So we want to thank everybody in the room for coming to see this. We're kind of running up on the edge of time. We especially want to thank lots of people from the Massachusetts group, MassHackers. We have questions. We want to thank everyone from Mass Hackers. They've heard portions of this talk and we bounce ideas off them as well. It does look like we have time for a few questions if there are any. Right over here. Right over here, your hand was up first. >> [Off mic] >> So the question is really around the time synchronization and especially when we talk about mobile scenarios that might have not access to a network. GPS was the option. That would be one option if you can receive time from somewhere that was reliable, you can do that synchronization. The other option I personally have thought about but we didn't implement in the tool is honestly if you listen to one of these JT65 watering hole frequencies long enough you have transmissions starting when you want to start your transmission and all I need is relative clocks. I don't need to know exactly what time it is I need to know when the beginning of a minute is. Yes people are transmitting at the beginning of a minute. It is pretty exact. It's not 100 percent exact. If you look into it because what can happen is the transmitter can transmit before the start of the minute and it can still be decoded because the symbols are missing in the transmission. But one of the thoughts I had when we were ‑‑ when I thought about that actually was you could always use receiving signals as a relative thing and you can send the signal through a signal you received based on an offset. >> [Off mic] >> Did we look at having the data in the message and using the forward error correction to change that message into what we wanted to see? I'm not sure I totally understand. >> [Off mic] >> I think there's probably various places you could actually do the steganography injection in that process and there are various levels that you can actually use the ‑‑ what we thought about for example using the real innocuous message as the key so you were actually transmitting a key and that has problems as well and the advantage would be you wouldn't have to necessarily know the key. You would just have to go through at that algorithm, there are probably multiple places where you could embed the stego. There are probably multiple other ‑‑ this protocol or others. >> I think there's time for one more. >> [Off mic] >> Okay so the question was if you remove the cryptography would it remove the FCC regulations in you can talk to a lawyer. We're not lawyers first of all. Our understanding or our personal interpretation is that you cannot hide a message inside of a transmission. So for us hiding if without the encryption would still count. Now there may be other people that have a different interpretation of that and I know some are in the room actually they actually may know more than I do because they were both hams and lawyers. So that's a good question for them. There are some exceptions to using encryption. You can talk to ‑‑ if you're sending commands to space station there's work around but we're obviously we are not doing that. Somebody mentioned two days ago if you control an RC aircraft and sending back telemetry data that is also allowed but aside from that, you know ‑‑ don't quote us on that but just don't do it. We're not saying you should do it. Okay. All right. I think we're out of time but we would be happy to answer more questions outside. We'll probably be at bar con after this. If you see us around the conference we will talk about amateur radio or pretty much anything like puppies. Thank you for coming. Thank you. [Applause].