 Hi. I'm Phil Zimmerman, and I just wanted to show you what I've been doing lately. I spoke here last year about my new project, Z-Phone, which is a secure VoIP protocol. And I've got a protocol, which we've submitted to the IETF as an internet draft. There's an SDK to implement the protocol, and there is also this application called Z-Phone that uses the SDK to implement the protocol to allow you to use whatever VoIP client you'd like to use and secure it. It's kind of like a bump in the wire, only there's no wire. It's a bump in the protocol stack. So it filters the IP traffic in and out of your computer, looking for VoIP traffic, and intercepts it and intercedes to secure the call. And first thing I'd like to do is show you how it works, and then I'll talk about, you know, everything else. So we're going to do the demo up front here. So first thing I want to do is run iChat. Did you know that iChat is a VoIP client? I didn't know that until I actually tried it with this. Let's see. So we're going to call a friend of mine in New Mexico and see if we can get encrypted audio and video. It does both. I hope this works. It's negotiating the keys here. Hi, Steve. You're visible to a large audience here at DEF CON, and nobody can intercept this communication. So I guess we could talk about secret stuff. You got anything subversive you'd like to say? As the audience can readily see, Steve would never talk about anything subversive. Not really. Not really in the least bit subversive. Okay, Steve, say something. Not me. I'm not subversive. All right. Okay, just to make sure there's no man in the middle, let's see if we're using the same session key. Slingshot millionaire. Okay. I'm using the same word list. Many of you use PGP, and you know that if you want to compare PGP fingerprints, you could either compare them in hexadecimal, or you can compare them using a list of words, and that's what I'm using here, the same word list that PGP uses. Steve, do you have Slingshot millionaire displayed on your... Well, then I guess there's no man in the middle. Now that would have been exciting if there was, right? It would have been quite surprising. And in an environment like this, maybe it wouldn't be that surprising. Okay. The checkbox is still checked for verify. Yeah. Okay, so what I'm going to do now is we're going to hang up this, and I'm going to call you back on Gizmo, a different Voight client, and we're going to secure that also. Okay, so we're just going to do that, and we're going to activate the Gizmo Voight client. We could go on and on with numerous Voight clients, X-Lite, Iveem, X-Meeting, Akiga, anything you want, all kinds of Voight clients except Skype. Skype doesn't follow any Voight standards, but any kind of Voight client that uses RTP can be used with Z-Phone. So now I'm going to call Steve, and Z-Phone will secure the call, assuming that Voight works here. Okay. Hi, Steve. There you go, again. Oh, all right. I think Gizmo does do video, doesn't it? That's that the iChat has the... You know, I don't think... I'm not... I don't think video is available for Gizmo. I'm not aware of it. I just got a new version of it yesterday, so... But anyway, so, okay, so, we don't really have to check here because we made a previous call, but the short authentication string is... What do you have on your display there? Fracture recovered. Okay, that's what I got here. Okay, I guess that's it. You can go. Okay, take care. All right. So... So the really spiffy thing is that, you know, you can use any Voight client you're already using, and this thing plugs into the protocol stack. It's got a demon running. This works on Linux, Mac OS X, and Windows. It runs a demon in the IP stack, intercepts the Voight packets, and encrypts them on the fly. It negotiates the keys up front, and then has its own separate GUI to show you if the call is secure and allows you to verify there's no man in the middle. So, you know, I should have asked for one of those radio mics so I could walk around. I like to pace nervously. Is it too late to do that? Maybe somebody could bring me one. Oh, this one's pretty firmly attached here. I could take it off, but then it's a very short cord, so I'm taking it off. Okay. There's one on the table. That one? Oh, you mean with the cord? Okay. Yeah, all right. I don't know if that cord is long enough. All right, I'm just going to stand here, and I'll just have to contain my nervous energy. All right, so I guess we don't really need to... Oh, you know what I could do is let's bring up the web page or the Z-Phone project. You guys should go visit this web page and download the code and try it yourself. You can do a free download and give it a try. You know, this screen is too small for this website here. Okay. Well, all right. Maybe I should... Yeah. Okay, well, it's got a nice FAQ section to answer a lot of questions, but you don't have to go there to answer your... to ask questions. You could ask me. No. Okay, so I demoed this here last year, but it's gotten a lot more polished, and it works with everything now. We submitted it to the IETF, and eventually it will get an RFC. We're going to get an informational track RFC. Eventually, after that, I think that we'll get enough deployment to go back and ask for a standard track RFC. It does a Diffie-Helman key negotiation at the beginning of the call, and then, you know, to protect against a man in the middle attack, you want to make sure that the two parties are using the same session key because these keys are randomly generated for each session, and if you found that the two parties were not using the same session key, it's because there's a guy in the middle that I'm talking to, the other party, and there's two separate encrypted channels with the guy in the middle, and that's why we compare those the short authentication string to see if it matches. So rather than try to guess what you want me to tell you, why don't I just ask you to ask me questions? Yeah. Well, there is another, there's a related protocol to RTP called what I'm sorry, what is it called? The RT, yeah. He wants to know if the quality of service information gets encrypted too, and yes it does. The packets that come back, RTSP, isn't it? RTCP, excuse me. You ever see that film Memento? I sometimes feel like that guy, I can't remember anything. That's right, yes. So, yeah, the quality of service information is also encrypted, but not the signaling. The signaling is not involved in this at all. In fact, you can use it with any kind of signaling. It doesn't just have to be SIP, it could be H323, it could be Jabber, it could be whatever your favorite signaling protocol is, or just peer to peer SIP. It doesn't even look at the signaling, it just does it entirely in the media plane. Yeah, there's no loss of performance. Encryption doesn't take much time. In fact, Kodaks take a huge amount of time. Voice compression is 100 times slower than encryption. There's a little bit of calculation at the beginning of the call to negotiate the keys, but that's over pretty quick, and if your processor's fast enough to compress your voice, it's plenty fast to do the Diffie-Ellman calculation. Yeah. Was video also encrypted? Yes. Video, audio, you could have as many streams as you want between you and the other party. They're all encrypted with separate keys. Yes. Yes, you could do three-way calling. Every link that you do is separately encrypted. Yeah. Yeah, the SDK, we're going to open source the SDK because we want people to put it in their open source projects. Now, this application that I showed you, Z-Phone, is not only the SDK. It's also got this demon that filters IP packets. I don't really see the reason to make that open source because nobody's ever going to put that into their VoIP product. You know, it's the SDK they want, and so that's what we're going to open source. Yeah. Pardon me? Yeah. I would like you to take the SDK and put it in VoIP plants on all kinds of platforms. We've got this thing running on Symbian, on Windows Mobile, Linux, Mac OS 10, Windows XP, and we'd like it to run on anything you find to run it on. But the SDK is not a complete application. It's something that you want to put inside your VoIP application. They could be put into a PBX. By the way, we have it running right now on the asterisk PBX, which is open source, and we're going to be releasing that as soon as we can get through the bureaucratic... It is fairly bureaucratic to get things released on asterisk. By the way, we tried to put it on Akiga, but we find that the Akiga CVS code repository doesn't seem to have a version that we'll actually build. So if anybody can help us with that, I'd appreciate it. I don't know how people are building Akiga if they can't check out the code from the CVS, yes. Loud, really yell. Well, we look at the packet. We have a nice little... The question is, if we don't look at the signaling, then how do we find the RTP stream? How do we tell the RTP packets from other kinds of UDP packets? Well, until about a week ago, we used to just look at the signaling and try to figure it out from that, but we were having the Devil's Own Time doing that because all the VoIP clients break the rules. They do horrible things for Natroversal. Natroversal is the big problem in the VoIP industry, and all these VoIP clients were doing highly unorthodox things for Natroversal. I'm going to close that. What they were doing is, instead of sending it through the SIP packets, they were doing things like... I'm not sure, but somebody told me that Apple iChat, if it couldn't do Natroversal using normal methods, it would actually send a text message to the other side telling it what port it was going to use. There's no way we would ever have figured that one out. So rather than try to divine it from the signaling, we just heuristically look for the RTP, and we let a few packets go by and see if they have sequence numbers that count up, if we think it's RTP, then we jump in. Now, that's what we do in that daemon, that filter I mentioned. That's not in the SDK. If you actually put this in your VoIP client, you don't have this problem at all. You're going to talk to it through an API, then of course you're going to know what port you're going to use. You are the VoIP client, so you know everything about what you are doing, so you tell our SDK, okay, here's a packet encrypted, you know? Yeah. We haven't done anything with IPv6, but maybe we should. You know, we will. We've just been too lazy to get to that. Yeah. Oh, yes. Yes. You can make this be an external box that can look at the traffic from multiple telephones. It would work the same way as it works when it's in the same machine. You know, it's an IP filter. I mean, that's what Z-Phone does. Again, I think you're better off taking the SDK and sticking it in a VoIP client. You get cleaner results. The GUI is integrated in your VoIP client. You can... It just works better. But this is a good way to get it going with VoIP clients that don't have it. So it'll even work with hardware phones. I mean, I bought one of those really cheap Grandstream VoIP hardware phones, and you can actually make this encrypt that too outside. It'll, you know, filter through your... through your Linux laptop. Yes. That's right. Yeah. PGP phone. Okay. Well, 10 years ago, I developed a product called PGP phone, and most of you are too young to remember that, but 10 years ago, it worked fine, except for the fact that nobody had broadband at home, and also there were no VoIP protocol standards. So it was kind of too early. But now it's not too early. Now it's the right time. VoIP is taking off. So I did something very similar to PGP phone at that time in 1995. I did the same kind of thing. I did a Diffie-Homan exchange. I did hash commitment, a short authentication string. In fact, I even used the same list of words to use for the short authentication string. In fact, the list of words that we used for PGP fingerprints was originally developed for PGP phone, not for PGP. We later adapted it to PGP, and now it's being used again. The Diffie-Homan exchange is a 3,000-bit Diffie-Homan prime. I'm using AES-128 or AES-256. For 3,000-bit Diffie-Homan, it's better to use AES-128 because you'd like to have the load balance between your block cipher work factor for breaking it and your public key algorithm work factor for breaking it. And so for 3,000-bit Diffie-Homan, it matches nicely with AES-128. For AES-256, you would need to have Diffie-Homan of size, you know, Elmondo grosso Diffie-Homan keys, like 16,000-bits long, and nobody would ever want to do that. So you'd probably want to switch over to elliptic curves for that, but we don't have elliptic curves in the product yet. So we just use Diffie-Homan 3,000-bits in AES-128 as a default. But that's fine. I don't think you really need 256-bit keys. AES-128 is out of reach of everybody and is going to continue to be out of reach of everybody. Yeah. Well, how are you... How is the average person going to use this when they don't have hardware to put it on? Well, you know, for Z-Phone, you would typically use it with a soft Voigt client. You'd be running some kind of Voigt client on your laptop. If they don't have a laptop? Yeah. Well, if you're using Vonage, you can't use Z-Phone. Don't use Vonage. Now, in theory, you could use Vonage and use Z-Phone. You would have to have... You know that box they give you, the analog telephone adapter? If you could take my SDK and stick it inside that box, then it would work. I doubt that Vonage is going to put it in because Vonage is in a lot of trouble. Yeah. In principle, someone who makes an analog telephone adapter could put this inside. We hope that will happen. We are partnering with other companies that make hardware, desktop enterprise phones, for example. In fact, there is a company called Ripcord Networks that's making a little box about the size of a deck of playing cards. And it's got a little LCD display on it and two RJ45 Ethernet connectors on it. And it's a real bump in the cord. And so it would go between your Voigt phone and the cloud. And it would do just what Z-Phone does. They're working on that right now. In fact, they're going to use the same kind of IP filtering techniques that we use. In fact, they're probably going to run the same code, actually, since they license it from us. If you wanted to use that with Vonage, then you would have to have the Vonage ATA and then you would have this box from Ripcord and then you'd have the cloud, the router. Somebody back there? Yeah. No, I wanted to be using enterprises. The perfect way for it to be used in enterprises is if it's in desktop enterprise phones in the firmware. But as an interim measure, they can buy these little boxes from Ripcord Networks and work with their existing phones. The other possible approach they can take is to put it in the asterisk PBX and then all the Voigt phones in the office could connect to the asterisk PBX. And so the first 10 meters is not encrypted, but who cares? It's only 10 meters. Then it's encrypted from the PBX out to the cloud. That would work. Well, I would recommend that anybody using Voigt would separate their Voigt network from the rest of the office network, just as a matter of security. You don't want your Voigt components to be attacked by hostile software running on some PC. Now, of course, not everybody's going to follow that advice. There's going to be people out there that have a single office network that carries Voigt traffic and everything else on their network. But that's a risky thing to do because if some hostile software gets on one of your PCs, some spyware, then it can intercept all the Voigt traffic in your office before it goes out to the cloud and store it on the disk as wave files. And then somebody on the other side of the world could use a web browser to browse through it like a Tivo player. In fact, this software exists. On my website, zphoneproject.com, visit the FAQ page, and you'll find in there a link to spyware that operates exactly as I've described. And you can listen to people's phone calls. I don't know if they're real phone calls that matter. I think the people knew that they were being recorded. But that could happen. The Russian mafia could install spyware like this on one of the computers in your office and intercept all the calls in your company. Now, there's ways to stop that from happening. You could make sure that you don't use hubs, use switches, and that all your Voigt traffic is segregated from your general office network traffic. But not everybody's going to be careful about that. So it's just a better idea to do end-to-end encryption. Yeah. Yeah, yeah, yeah. Well, yeah, he should repeat it back. But don't put too much emphasis on the voice imitation attack. I call that the rich little attack because it's not as easy as it looks. The attacker has to know exactly when to say what he says, and he's not going to be able to predict what he's going to do the compare. You might do it at the start of the call. You might do it at the end. The other guy might do it. You might do it. You both might do it. In fact, you might even use the words in unpredictable ways. You might use them in a sentence, for example. Who knows? The attacker doesn't know what you're going to do. I didn't think of doing that, a readme file that tells you how to do the short authentication string compare. Yeah, I guess maybe somebody should write something like that. I'll take a fairly casual attitude toward it because I think that the attacker doesn't want to get caught. He's afraid that you'll catch him attacking. The wiretappers, by their nature, don't want you to know they're there. So they're risk averse. So I don't think they're going to try it. Yeah, well, VoIP is extremely vulnerable when compared with the public switch telephone network. I mean, that's why we have to encrypt it. We don't even have a choice. We debate about whether the PSTN should be encrypted because maybe you're worried about government wiretapping or something like that. But for the most part, wiretapping on the PSTN is, well, there's not a lot of wiretapping on the PSTN except for the government. The government's always found it easy to do that because they have a friendly relationship with the phone companies. But, you know, other people, organized crime, for example, find it difficult to wiretap the PSTN. They could get close to their target. They could get, you know, they could go to your office building with an alligator clip, and they could open the box with thousands of wires inside and try to figure out which wire goes to your phone. They could do that, and hopefully nobody will see them doing it. But it's risky. You've got to get up close, and you're probably going to get caught, or maybe not, but you certainly got to be at least in the same country. But, you know, like, someone could attack you from the other side of the world. That spyware that goes on one of the PCs close to you might be, you know, from China or the Russian mafia or, you know, something like that. So it's just so much easier to attack VoIP. We really have no choice. We must encrypt VoIP or don't migrate to VoIP. Keep all of our calls forever on the PSTN. If we do that, then we'll be fine, but it's not for government wiretapping, you know. But, you know, how many people here think that we're not going to migrate to VoIP? Everybody knows that VoIP is the manifest destiny of the phone system. So we have no choice. Now, think about what's going to happen if we don't do that. You know, one might imagine that law enforcement might object to encrypted VoIP. Well, okay, so let's look at it from the law enforcement point of view. Think about the asymmetry that has existed for so long in the relative difficulty of wiretapping between the government wiretapping and criminals wiretapping. It's so much easier for the government to wiretapp than for criminals to wiretapp. But with the migration to VoIP, that asymmetry collapses, which means that the criminals can wiretapp the government judges and prosecutors just as easily. So that means that, you know, organized crime will be able to wiretapp judges and prosecutors and listen to them talking about ongoing criminal investigations. They'll be able to learn the names of witnesses and informants, and they'll be able to listen to them calling their wives at home and talking about what time to pick up their kids at school. So I think that if we want the criminal justice system you know, without fear from organized crime, you know, doing horrible things to them, they're going to have to accept encrypted VoIP as being part of the infrastructure. Yes. Yes. Counterpath, the makers of Xlight and Ibeam are going to put it in their products. They've licensed it, and in the next product release cycle it will be in their products. If you go to that website it says customers, and you can see a list of the companies that we've partnered with to license this code to. PGP is going to put it in their VoIP products when they make VoIP products. Borderware plans to put it in their products. It's taken them a while to do it to, they're kind of moving slowly in VoIP. Asterisk is, it's going to be in all the Asterisk PBXs, so that's going to affect a lot of companies. There's a couple of other open source VoIP projects that are using it. Go to that page and see who's doing things with it. Yeah. The person at the other end has to have it, but if they don't, it just probes to find out if they have it, and if they don't, then that's fine, it just steps out of the way, no harm done, you know. It quietly probes for its peer. Yeah. You know, some people have talked about using Ipsak to run encrypt VoIP. And I think that you can possibly make that work in very limited circumstances. If you have your PBX tied to another one of your branch offices with their PBX, you control both ends, you own both ends, you might be able to get it to work. But in the general case, Ipsak is not a good choice for encrypting VoIP, because it's too low a layer. It's down at the IP layer, and there's nothing to tell you if it's there or not. You can't tell what if the other party doesn't have Ipsak. How are you going to know? How are you going to know this call is encrypted? And if you don't know the call is encrypted, why even have encryption? How are you going to know when you've got to just talk about the weather, or when you can talk about secret stuff? So it's just too low. You really need to have the encryption happening close to the user at the application layer. Now, this Z-Phone thing that I showed you, the Z-Phone application has a GUI running at the application layer to talk to the user and let them see that the call is secure. But it's got this daemon running down below at the IP layer. So it's kind of it's got this hybrid approach. But if you put it into the if you take the SDK that we have and stick it into your VoIP client, then you're going to be entirely at the application layer. Yeah. You asked me about generating the session key. What was it? Yeah, we generate the session key. All of our key material is created at the start of the call and destroyed at the end of the call. So it's completely ephemeral. There's no public key infrastructure. There's no persistent keys. But one thing that we do is we destroy, before we destroy the keys, we hash the session key material and store it in a cache. So that the next time you make a call to the same person, it does the same old Diffie-Hellman exchange you always do for every call. But it also mixes in the earlier session information, the key material that was hashed, so that if there was no man in the middle attack in the earlier call, there cannot be a man in the middle attack in this call. Which means you know that thing about comparing the short authentication string, you don't really have to compare it on every call. In fact, you might call somebody a hundred times for a whole year and just never check the short authentication string because you're lazy. But then after a year you decide that today we're going to talk about secret stuff. We've just spent a year wasting our time talking about the weather, but today we're going to talk about secret stuff. When you compare it, it matches. That means there's no man in the middle on this call. But it also retroactively demonstrates there's no man in the middle all the way back to the first call a year ago. A hundred phone calls kind of retroactively protected. It's not, they're not retroactively protected. You discover retroactively that they weren't wire tapped which makes you feel good. It's kind of like being able to floss your teeth only on the morning in this office instead of every day. The short authentication string that we compare is derived from the session key. It's actually derived from the Diffie-Helman result. What was the question? I can't hear you. How do I derive it? Well, I use an HMAC. I hash it. I do a Diffie-Helman exchange and then I hash a bunch of things together to produce a shared secret. And then I derive a bunch of secrets from that such as the session key an HMAC key for protecting certain packets that I use elsewhere in the protocol and also the short authentication string. So when I, at the end of the call I erase everything except for, oh, and also I forgot to mention some, one of the things that I save is stuff that I put in the cache but I derive that with the same kind of HMAC process that I derive everything else. So, you can't reconstruct anything by knowing the short authentication string. You can't reconstruct anything from knowing what's in the cache. If somebody steals your laptop computer and they get your cache, they're not going to be able to figure out even if they recorded yesterday's phone call, they have all the encrypted traffic and they steal your laptop today. They're not going to be able to use that to reconstruct your phone call from yesterday. Now, it also means that they could use that cache to be a man in the middle on the next call but it has this kind of self-healing property that if they miss a single call if they aren't there for the next call then they miss their chance. It heals itself and you constantly change what's in the cache with every call. You're immune to the man in the middle who stole your laptop yesterday with every call that comes after that. Yeah. The difficulty of breaking public key algorithms is different from the difficulty of breaking block ciphers. Public key algorithms are using mathematics that is not exponential in the same way that keys are for block ciphers. So, 128-bit key for a block cipher requires 2 to the 128th well, maybe 2 to the 127th on the average steps to try all the keys to do key exhaustion. But for RSA, Diffie-Hulman, or Elgamal or one of those traditional public key algorithms you have to have a much, much bigger key size because you're not just going to do key exhaustion, you're going to try to do factoring which is a much more complicated thing to do. But it also is faster than just trying all the possible keys. So, they're really in different areas of mathematics. So the key sizes are quite different. Yeah. Well, right now 128-bit block cipher keys sizes are still good. They're not going to be vulnerable to Moore's law. And Diffie-Hulman 3000 is about the same work factor as a 128-bit block cipher key. So whatever you can say about the amount of computing you have to do for that applies to the other one, even though they're very different techniques. Let's look at, let's just try to I get a lot of email from people saying why don't you just make the keys bigger? I'm unhappy with this key size, I really went bigger key size. It's like arguing about the size of your dick. No one's happy with the size that they have. It's bigger, right? So, let me assure you that 128-bit size is plenty big, okay? And let's just take a moment to just see why that size is appropriate, because some years ago somebody built a special machine to exhaust all the keys in the DES key space, 56-bit keys. And so, in fact, today we're talking because of Moore's Law. But, if you look at 56-bit keys for DES versus 128-bit keys for, you know, a lot of other block ciphers that we use today, that's a difference of 72 bits. Each one of those bits doubles the work factor. Well, Moore's Law doubles processing power every 18 months in its kind of simplistic form of Moore's Law. And so, each generation of Moore's Law is worth one bit of key for a block cipher. So, 72 generations of Moore's Law of 18 months, 72 times 18 months, that's over a century. There are no engineers anywhere in the world today who believe that Moore's Law will go on for a century. Go ask Intel engineers and they'll tell you that they're running out of steam. They're not going to be able to keep doubling processing speed every 18 months. And the problems as these gate sizes get down to the size of atoms, there's no place left to go. And the heat is too great and all that stuff. So, you know, we're running out of steam. We're not going to have another 100 years of Moore's Law. So 128-bit keys are going to be out of reach of Moore's Law for a long time. And even quantum computers, you know, you're going to have to have a lot of quantum computers. And nobody has a working quantum computer that matters. Was that hand that went up going to ask about quantum computers? Okay, go ahead. Yeah, we have that in the protocol. We have other ways of augmenting the protocol. We do have the ability to add a prearranged shared secret. And we also have the cash shared secret that we had from earlier calls. Plus, not every application is going to have a graphical user interface with two human beings to compare the short authentication strings. So we added something to make it so that you can have a digital signature in the last packet that says here's a digital signature of the short authentication string it's sent across. But then you need a public key infrastructure or you need the signature key backed by something else, like key continuity the way SSH does it. And we're going to implement that. We'll do at the very least key continuity. We don't like public key infrastructure. In the 1990s, many companies went out of business trying to build public key infrastructure. I don't think that public key infrastructure is the right approach for secure VoIP. I don't think it was the right approach for email and PGP didn't really have PKI for email. It used something well it was a sort of public key infrastructure, but it wasn't like the centrally managed one. And I think VoIP is just not the right place to be trying to make PKI work. Yeah. Well you know, the question is about export controls. Export controls have largely disappeared since 2000. That's when the US government changed the law. The only residual export controls we have for software encryption software is the few countries that we're not allowed to export to. North Korea, Iran, Syria, Sudan you know it's a handful of countries and that doesn't really affect us that much. However, when you download it from my website, you have to fill in a form that says your name and your email address and it checks your IP address and it sends you an email confirmation message that you with a URL that you click on to download it. So it does check to see if you're in one of the embargoed countries and by doing that it keeps me out of trouble. And I really would like to keep out of trouble. Been there, done that. Yes. What? Yeah, it's easy to see it that the RTP stream is encrypted because if somebody could just look at the stream and they could see, well at the very least there's authentication tags on every packet, but even if we got rid of those and just kept it exactly the same packet size, you'd be able to see that it was encrypted because if you tried to run it through a codec it wouldn't make any intelligible sounds. If it was G711 the one that doesn't compress anything, if you played that it would actually make white noise. I used to have this little demo feature that I could click a button and it would play white noise. It would play the ciphertext out through the G711 codec. The problem is that it started using other codecs and then sometimes it would crash the codec. So I don't have that on hand anymore. So yeah, they're going to know you're encrypting your phone calls, but I don't think that matters because the entire infrastructure of the entire world is going to have to encrypt VoIP. Everybody. Billions of people are going to have to encrypt their VoIP calls because VoIP is intrinsically insecure and we have to protect our nation's critical infrastructure. Otherwise we're going to be owned. Now what's the proper pronunciation of owned? Is it the 0WN3D or something like that? How do you pronounce that? We're going to be owned by the Chinese or the Russian mafia or whatever fill in the blank if we don't encrypt our VoIP. Yeah. Legislation? You know, there is legislation now called KALIA that says that phone companies have to turn over their key material to the government for wiretap, but my protocol negotiates the keys at the end users not involving the phone company at all. So the phone companies will not be in violation of KALIA if the end users are using this protocol. In fact, one could argue that it kind of is good for the phone companies. It gets them out of the way. What was the question? Oh, having legislation to enforce people to encrypt. There is a lot of legislation right now to enforce that federal agencies have to use laptop computers with full disk encryption because we keep losing laptops. Let me talk about something else about using law to prevent wiretapping. I did something very unusual in this protocol. I did something where I, probably a lot of you know that I really hate software patents, right? I don't know if you know that, but I do. I hate software patents, despise software patents. But I made, I filed, I applied for a software patent here for some of the ideas used in this protocol for good instead of evil. And here's the good that I'm talking about. You see, I put a feature in the protocol so that if somebody uses this protocol in a phone that provides the keys to a third party, you know, kind of like the clipper chip, remember the clipper chip from the 1990s, if somebody does that, they have to declare it in one of the packets. There's a disclosure flag I defined in the protocol and you have to set that disclosure flag if you're going to give the key away to somebody. And if you don't do that then you're not allowed to use my patent for free. You are allowed to use my patent. Everybody can use my patent for free unless you don't set the disclosure flag when you're giving the key to someone else. I can't stop you from giving the key to someone else. Remember I can do that in my own products. I can make sure that my products don't give up the key to someone else because I can control my own products. But remember this is a protocol that means anyone can implement it. It's a protocol, it's not a product. So someone could take the protocol and put it in their product and their product could, you know, act like a clipper chip and give the key outside out of ban to a third party. I can't stop them from doing something out of ban but what I can do is say that, look if you do that and there are plenty of legitimate reasons why companies might need to do that, like stock brokers need to record your calls because they want to prevent insider trading, they want to keep their guys honest, or maybe a nuclear weapons facility has to make sure that the guy is not calling his buddies outside who are going to attack the place or something. I don't know. But there are some reasons why companies might need to do that. And that's fine with me. I don't have a problem with that at all. But if you're going to make a phone and sell it on the market and try to get people to buy it, you've got to confess that you're disclosing the key to a third party and you've got to put that in the packet. And if you don't do that, you can't use the patent. And that's what I mean and it's free. The patent is free otherwise. And maybe I'll still let them use it but they have to pay me a lot of money. I don't know. Maybe I won't let them use it. But the point is, is they don't get a free license if they're going to do that kind of stuff. So that's what I mean by using the patent for good instead of evil. Or what? My pockets? Well, they could pay me. Yeah, lots of money. But, you know, it would be known.