 And so for our last talk of the day, I think this is going to be a big one. These guys have a lot of information to share with you guys with some really interesting stories and some interesting background. So without further ado, I'd like to introduce Thor. I'm just kidding. This is later Levinson and Stephen Watt who are going to talk about Dark Mail. Thank you. Let's give it up. I know everybody gets upset when it's time to get down to work. They just want to keep watching the video. But we're here to talk about Dark Mail. Unfortunately, we're not calling it Dark Mail anymore. Like all really catchy names, domain keys, pretty good privacy, they all tend to change, lengthen when you go through that standards and formalization process. And I think the entire point is to lengthen it just so you can turn it back into a shortened acronym. There's a pay phone joke in there. I'm sure it's funny so I'm not going to tell it. But you can make up your own later. I figured the easiest way to explain what Dime was was to draw it all up on a blackboard and take a picture. Did everyone get that? All right, get your pencils ready. I'll do it one more time. Oops. How'd that get there? I thought those private keys were supposed to be private. What is Dime? Quite a lot of different moving pieces. It's two protocols, two formats, and a management and configuration record in the DNS system. We've got the Dark Mail transfer protocol, which is an unauthenticated protocol that provides inter-domain message transfer and key lookups. We've got the Dark Mail access protocol, which is authenticated, handles persistent access to messages, synchronization of caches and key information, and a submission protocol. It's worth noting that even though DMAP and DMTP are pictured together on that slide, I'm only trying to indicate that both are on a server. They don't necessarily have to be on the same server, just like mail is today. The formats. We have a SIGNET, which is assigning an encryption key along with a collection of attributes and a signature. Very much like what we're familiar with when it comes to PGP public key or an X509 certificate. Of course, it's neither of those, so don't call them either of those, call them a SIGNET. Like a SIGNET ring. We've got the Dark Message format, which is MIME-like, as we'll get to later. It breaks up the MIME structure into independent chunks that are encrypted with different symmetric keys. And the goal of designing that was to basically create a format that would translate losslessly between MIME and the Dark Message format. The only information that's lost is actually the original MIME boundary. And since that happens to be something that is easily fingerprinted, losing that information might actually be a good thing. So we've got this complex ecosystem that we're trying to build here. It's all up here. All I need now is an easy button. Whoops. There's supposed to be an audio file that plays. An easy button that would turn it all into working software. But in lieu of that, I have Steven. I tried the Apple key. That didn't work. Tried the Windows key. That didn't work either. And then I went looking for the Linux key and I just couldn't find it. I'd like to point out even though we used the word dark quite a bit, we never follow it with the word tangent. I think it's important to spend a few minutes talking about why something like Dime is so important and why it has to be as complex as it is. The original idea was actually far simpler. It was centered around managing the key generation and lookup process for PGP. And because of everything that has come out in the last year, we've really had to expand what we're trying to accomplish to include both minimizing the leakage of metadata and create a system that was resistant to manipulation by advanced persistent threats. And unfortunately, each one of those additional goals only compounded the complexity of the ecosystem by a few more orders of magnitude each. But I think it's important because with the type of metadata collection that's going on today, we have guilt by association. Imagine being placed on a no fly list because you happen to sit next to a criminal at a convention like this. Or the problem of mass surveillance. Record everything and let the NSA sort it out. And then of course, there's the problem that I came into which is the idea that as a service provider, I'm beholden to my customers. Those are the people who I serve. Without them, the business does not exist. And here's this entity that comes along with a bunch of guns and a piece of paper and says you have to portray the people that are funding your business. It's creating a crisis of confidence. Thought I'd use a couple of excerpts from my own case. This is a court transcript. And as you can see from the judge's very own words that today, the court feels that they are entitled to access everyone's information. And the only way we can stop that is through the introduction of end-to-end encryption. But in order for everyone to start using end-to-end encryption, we need to make it easier. We need to make it automagical. And making security and cryptography happen automagically while remaining secure and doing it for email. While preserving all of the functionality that email provides is actually a very technically difficult challenge. I touched briefly on what the goals were, but I think it's worth reiterating them here. PGP and SMIME give us author validation message confidentiality, but they don't do a very good job at any of the other goals. Darkmail was really started to achieve these additional bullet points. And it meant building a system that was both secure, automatic, and could be accessed from different types of clients on different platforms with different types of constraints in the very same way that we accessed email today. And to do it and build it in a way that can handle internet scale. Last time I checked, there were about three billion email users on this planet. It's the reason I got into the business. I knew I'd never have a shortage of potential customers. But doing that while also minimizing the leakage of metadata is incredibly difficult. Might be why we borrowed the onion concept from Tor. Now we're not Tor, but we do come a lot closer to limiting the amount of information that a service provider has available to turn over. And the goal is really to get the leakage down to what an attacker could discover through extensive traffic analysis of the entire internet. Not that anybody actually does that. But the idea is if they can see every DNS query you make and they can see every encrypted packet and where it flows to, they can discern certain things. They may not be able to discern who you're talking to, but they may be able to discern that you sent a message to your provider and that provider handed it off to this other provider. And the thing is we need to make it bulletproof. I thought I'd use this other example from my own case to illustrate why the protection of metadata is so important. Here I am in court saying that I would like to tell people that the FBI is asking for my SSL private key. And in response to that request, the prosecutor stands up and says, well, we know he's been talking to the EFF and to other attorneys who have been associated with WikiLeaks cases in the past. Now, I was a little taken aback by that because, one, how did they know that? I didn't know that. I'd spoken to maybe a dozen attorneys trying to find somebody who could represent me in the four days that I had to find one. But then as I thought about it more, I started wondering, well, how did they even know that in the first place? What happened to attorney-client privilege? How bad has it really gotten? And it's become clear that if they can find the tiniest of openings, they will go in and take everything. The theoretical is now reality. The impractical has already been deployed. Now, can anyone spot the typo in this sentence? It's actually my second favorite excerpt. In the court's haste, they forgot to substitute the word Google for the word lava bit. If you read that sentence again with the word lava bit, it actually makes sense. On the next page, though, we see why I put this slide together. They were coming in and not only demanding the encryption keys, but the source code that was used to protect the system. Think about that. Think about what we've been talking about the last couple of days with firmware exploits and hardware exploits. And then ask yourself, do you really think they're finding those exploits based on binary dumps of a bios, or do you think they're starting with the source code? I think I already know the answer to that question. I actually had to go to court to get BC and D unredacted because I wanted to be able to tell people that just communicating with somebody now makes you a co-conspirator. It's enough of a justification for the court to issue a warrant for your communications. They call it hopping. Like such a friendly term associated with bunny rabbits in a field would make it any better. So if I sound a little bit upset, it's because I am. I'm not upset that I got railroaded and I had to shut down my business. I'm upset because we need a mill spec cryptographic mail system for the entire planet just to be able to talk to our friends and family without any kind of fear of government surveillance. I'm upset because I thought we won this war back in the 90s when we earned the right to have secure cryptographic algorithms to encrypt our communications. I'm upset that I need to take our email which is traveled around the internet unprotected for the last 40 years and stick it in an M1A2 just to feel safe. I'm upset because you shouldn't need an Abrams tank for your email just to keep anybody from reading it. And I'm upset because the design for dime needs to be resistant to manipulation by a three letter agency with 40,000 people on a $10 billion annual budget. I did the math. Their budget is a little bit bigger than mine. This is who you should worry about. These guys too, they have guns. You should probably mention these folks too. And of course if one kid on the playground has a toy, every other kid wants it. So you start to understand. We don't just need dime. We need it yesterday. I keep telling Steven that but it doesn't make him go any faster. So I've talked about what it's going to do and before I get into how it does it, I'm going to talk a little bit about the weak spots. The first one is the DNS system. Yes, DNS sec helps. But in the real world it's only been deployed on less than 1% of all the domain names out there. And the simple fact is if somebody can hijack your domain, your DNS entries, they can point your domain at whatever server they want. Now we've built in a concept called the chain of custody check which can be used to ensure when you're communicating with somebody over a period of time and they've rotated their keys, that the new key information was signed by the previous key. So if the domain does get repointed at a new server, all the people who communicated with people on that domain in the past would get chain of custody warnings. But everybody else, everybody who was hitting it for the first time wouldn't know any better. The other problem with DNS is that it's very leaky. We still don't have an accepted standard for encrypting our DNS queries which means if somebody is sitting on your upstream link, they can see every DNS query that you do. I think that's interesting because we also rely quite heavily on TLS which has the OCSP protocol built into the latest versions which check for the revocation of a certificate and they do it over an unencrypted channel. So somebody can actually sit on the link for the OCSP server for a certificate authority and actually see where particular people are coming from when they access that domain because that very same IP is going to fire off a request to that OCSP server. If the FBI had been a little bit smarter, they may have been able to discover the IP address information that eluded them by doing that very same attack without actually taking my private key. If your password is password, nothing I do will save you. Now we've designed mechanisms into the authentication scheme that will make brute forcing more difficult. But ultimately it still comes down to you. And like the Godfather told me, humans are a very poor source of entropy. Our devices, as we're learning, have a very horrid track record when it comes to security, particularly consumer devices. They stand very little chance of defending you against a sophisticated and determined attacker, particularly one with physical access. You also have problems with things like poor implementations. Even if you have good online hygiene and you're using open BSD, if the entropy provider for your random number generator gets commented out, your crypto won't be secure. We can thank Debian for that example. The algorithms themselves. The thing about cryptography is that you can never prove something is secure. You can only prove it's insecure. So just because we don't know of a vulnerability doesn't mean somebody else does. And then of course if you buy into all of the hype, we've only got so many years before the bad guys develop quantum computers and can break the crypto anyways. The way I look at it is we've got at least 20 years for that to happen. We still depend on programmers. And the number of programmers who understand how to make complex systems work and make them work securely is still very, very, very small. It seems like all the people who know a lot about security like to get into dev ops and system administration and very few of them kind of follow my path and Steven's path and end up as programmers. We need more people who understand how systems work, understand how they're attacked and can build defenses directly into the architecture and design of the system. I think it's funny that all of a sudden keeping your attack surface small has become all the rage. Been doing that for like 12 years. We have the problem that everybody likes using a web browser and a web mail system with a client written in JavaScript. Yeah, we can do the crypto on your device but if we're loading the code for the client off of an untrusted server, you kind of open yourself up to attack. Just ask Cushmail. And then we have the problem that, you know, Bull Run had a $250 million budget annually. Do you think they're just going to return that money to the taxpayers? They're going to keep coming after us. So I thought it'd be fair to issue a little warning. I think what we need to be afraid of is that if everybody started using something like Dime and ZRTP to communicate, it wouldn't be too long before we started seeing vulnerabilities embedded directly in the silicon. As kids, we like to play a little game called Where's Waldo? Our kids might actually get to play Where's the Clipper Chip. Make something like this look a little more useful. All right, time to climb back down off my soap box and get back to talking about Dime. I've decided that I don't just want to create a specification and hope the world listens to me. I think the best way to prove that Dime is secure, prove that Dime functions is to build it. So I'd like to introduce Magma and Volcano. Magma is the server implementation and Volcano is the client. All right, we're going to do a quick little visual demonstration here. Hopefully everybody's going to be able to follow this as much as possible. So what you're going to see right now is called Volcano. And that's the thick client we've been working on, which is essentially a Thunderbird fork. So as Ladar mentioned, one of the important things about this is to make sure that this is all usable in a, with a friendly experience for everybody. It's familiar to them. So just to give you a little taste of this here, start this off here. See our little custom branding here. And we're going to start off by composing a new message. So in the first example case here, I'm going to be sending a message and the first recipient here is going to be Ladar. Okay, this isn't pausing like it was supposed to, so I'm going to start talking a little bit faster. As you see there to the right, the sign it information for dark mail recipients, that only shows up if you're sending email to a dark mail protected domain. The second case here, we're going to send an email to a domain that's not encrypted by dark mail. This is an email I got from, actually Keith Alexander uses this one to send emails to one of his buddies at Google. I don't know if you can read that. So as you see there, the address sign it cannot be found and when you attempt to send it, you get this warning dialogue saying that, you know, at least one of the recipients is not protected by dark mail. And then finally we're going to try to do a mixed recipient message where we have one user that's protected by dark mail as we saw before, Ladar's email address. And then we're going to use that same Gmail address. And as you can see there, once again, you get the little warning icon. The address sign it cannot be found and if I attempt to fill in the body of the message and the subject and send it, we're going to see another warning message popped up. So it's our hope that we can badger the users and the administrators of these domains into protecting themselves properly. The last little bit of information here, we're going to go into a little DEF CON presentation folder here and click on an email that has been received from a dark mail sender. So again, you see there's a completely different graphic representation of how that looks. Sorry, I wasn't able to do a live demo here today, but I wasn't quite adventurous enough to trust transmitting across a network in this sort of environment. Seemed a little bit suicidal. So I'm into self deprecation, but don't want to humiliate myself in public by having somebody hijack my session here. So I'm going to turn it back to Ladar for a second. So what's even illustrated quite perfectly is that somebody doesn't need any specialized knowledge in order to use time. All they need to know how to do is type in an email address and their client does everything else. We still have the one burden of education, which is don't send out that classified document if you get the warning that says you're sending it out insecurely, but I seem to remember an old adage about taking horses to water and throwing them in. How does it work? Well, let's start by looking at the most important piece, the cornerstone, so to speak. And that's the dime management record in the DNS system. For those of you who are eminently familiar with how email works, you'll recognize concepts that are already out there with sender ID, DMARC, DKIM, and the sender policy framework. It's the idea that you can stick some information in the DNS system and it's really easy to find. Again, DNS system is a weak point. Without DNS sec, this information is less reliable. But what that long string of characters is is actually the public signing key for the SIGNET. So when you get the SIGNET from the DMTP server for the organization, it's actually encrypted with this, with the private version of this key. So you need this information in order to access the encryption key. It forces the two step process that is at the cornerstone of our trust model. That you need a primary source and a second pre-authenticated source for validation verification. Now what I'm showing you here is the most simplistic version of a dime record. All of the other attributes are assumed. We're assuming that the DMTP server can actually be found by looking at the MX record. And we're assuming that the TLS cert that we're going to run into when we access it is actually signed by one of the recognized CAs. But if we didn't want to do that, we could set up a much more complicated DX record. Highlight some of the properties here or the attributes. In this case, we actually specify an alternate server so that you can put your DMTP host on a different server than your SMTP host. And perhaps you don't like using a CA. You'd much rather prefer storing a hash of your TLS certificate in the DNS system so that you can use a self-sign cert. It's Dane simplified. No? Yeah, so I said that in the first slide. If there is no explicit DX specified, the assumption is that your MX is your DX. So if you connect to the SMTP host, it's also your DMTP host. I'm starting with the most simplified use case and trying to build in the necessary flexibility that the more complicated and larger environments can actually adapt it during deployment. What is a signet? Looks a little bit like this. It's a relatively simple format. You've got a four-byte header that tells you the version. Three of those bytes determine the length. You have defined attributes. Still trying to come up with exactly what that list of defined attributes is going to be. We know a few of them. Your signing key, your encryption key, your user signature, your org signature, your photo, your name, maybe your website address, your telephone number, your address. But we're not going to be able to think of everything. So we leave open the possibility of creating undefined attributes where you actually provide the name of the attribute and the value. Now, because the overall length parameter is three bytes, we've got an effective technical limit here of 16 megabytes for a signet. Please don't make your signet 16 megabytes. In reality, they should be far smaller. It's just trying to determine what to cap it at is kind of a much more difficult proposition. I think the only field that we're going to allow to be longer than 64K and many of them we will probably actually end up defining as a one byte length would be a photo. But the idea is it must be under 16 megabytes. And I mean a real 16 megabytes. Not what Google thinks is 16 megabytes. It seems that the IEEE and NIST recommended making a kilobyte 1,000 bytes. It's like they got paid off by the hard drive manufacturers. And I couldn't believe Google actually listened. I think all those PhDs would be smarter. They actually listened to the very same bodies that gave us WEP and dual E-C-D-R-B-G. How'd that work out? I mean if we're going to start changing stuff, why don't we change around the gravitational constant for Earth? Wouldn't it be a lot easier if it was a simple number that ended in zero? Kind of reminds me of what happens when you've got one team working with the metric system and another one working with the imperial system. Just ask NASA how many satellites that little screw up is custom. But this is your most basic sygnet. The four required properties and the section that I like to refer to as the security portion. It's the portion that is signed by both the user and the organization and contains the encryption information. Now if this were a rotated key there would be an additional signature here that was created by the previous key. That is so once you have a sygnet in your cache if your client does a look up and discovers that the key has been rotated it can trace the chain of trust back to the sygnet that it actually had in its cache. And if there's a break if this parameter is missing or invalid you know that something may have happened. Maybe something innocent or innocuous like a password reset or something nefarious like a man in the middle attack. But at least you get warned. Of course I added a couple of defined attributes. It's worth noting that they are outside of the user signature which means they're only signed by the organization which means that the sygnet signing request can actually be taken by the server and these attributes can be appended based on a profile or configuration. We're still considering whether or not we want to give users the ability to submit attributes with every request. But it's the idea that the organization can still have some control over the non-security portions of the sygnet. I thought it would be worth it to throw in a couple of what I'm calling undefined attributes. Mr. Greenwald happens to like bitcoin and wants people to know his address. And because he's somewhat political he thought he'd add a motto to his sygnet. The idea is we're creating a framework for you guys to build upon. The most important piece of dime is actually this sygnet process because if you can translate a e-mail address into a public key, what you can do with that is almost infinite. Imagine a ZRTP phone call where you don't need to do a short authentication string comparison to know there's no man in the middle attack, but you can actually have the Diffie-Helman handshake signed by the signing key that you then verify through this dime lookup process. Trust. It's earned, not given. But I thought it was important to illustrate how it works. Now this is the most simplistic trust model. And it only applies if DNSSEC is actually in play. There are alternate models I don't have time to get into. But if you recall, the cardinal rule is you need a primary source and then a second preauthenticated source for verification and validation. DNSSEC is preauthenticated. The root keys, TLD root keys ship with your resolver. It's preauthenticated. And what it means is that if an attacker wants to give you spoofed or false information, fake data, they actually need to compromise one of the keys in this chain in order to do it. They can't just make up an entire alternate internet and stick you on it. I thought it would be worth talking about who controls these keys. Because at a certain point you realize that even with DNSSEC you have to trust your registrar to publish the correct DS record. And then you have to trust the top level domain to protect its root signing key. Otherwise the entire system of trust breaks down. Like I said, DNS is still somewhat of a weak point. DNSSEC makes it that much better. We actually have mechanisms that I'm not going to be able to get into today that were built specifically because of this problem. Things that particularly security sensitive domains can actually implement optionally that clients can then check for additional verification of information that's coming out of the DNS system. That's my model. I figure if I need someone to trust, it'll be a dog. I'd like to introduce Princess, the project mascot. All right, the second part of the demo here. I guess my big person's mic is malfunctioning. Just a little disclaimer here. I was mentioning before, it seems like the video is unposable. And luckily Ladar slowed it down to 70% last night. But I'm going to try to keep pace. I planned to sort of pause a little bit longer in between the different components here. So what I'm going to show you right now is a differentiation between modes for DMTP and SMTP from a client perspective. And you're about to see the magma server being run and some simulated SMTP and dark male sessions, or at least the beginning of them. No, not working for him either. All right. This is the output of magma being run there. You can see the millions of dependencies scroll by. We're telenetting the local host port 25. As you see the banner there, ESMTP and DMTP v1. We've issued a mode command showing that both of them are currently available. Now a traditional e-hello command. And we're going to issue a traditional mail from command. And you see that received a success. And now when we issue the mode command again, it just says ESMTP. Now we're going to try to issue a dark male command, the signet command. And we're going to see that signet is disabled. And that's because we fell into ESMTP mode with the mail from command specified in RFC 822 style e-mail. We're connecting again. We tried issuing the dark male signet command and we see that that command requires start TLS first. So now you don't have to worry about this. It's going to scroll by a bit of Python code. Long story short, we use this to start TLS. So this shows the command being executed in the reply. So we're doing start TLS. We got the certificate. We executed mode command. And now we're in DMT PV1. Now we tried an e-hello. We issue a signet command and we get the successful response. Now we try issuing that old school mail from with the RFC 822 style e-mail address. And we get an error. Now we try a dark male style mail from that specifies a fingerprint and only a domain and is successful. We're going to tweak something here in the config file. We're going to search for the dual mode parameter which is, we're going to set it to false. So that's going to basically cause it to revert from dual mode into dark male mode only. And now we're going to kill the magma daemon and start it over. Go back to our session here. Telnetting back in. And now, if we try to do that same innocuous e-hello command, it tells us that it requires to start TLS first as opposed to saying okay and then allowing the mail from command to determine which of the servers it's going to fall into. All right. This next bit here is going to illustrate the cipher suite that magma uses. So we're going to see here the dedicated SSL port for DMTP is 31301. We're going to launch the server again. We're going to run SSL scan against it. You can see a whole bunch of crap scroll by in the server log because of the scans. Now we're going to scroll up. You're going to see all these failed cipher negotiation attempts. A lot of them. And then we're going to hit the end of them and there's going to be only one of them accepted. All right. You see the EC diffie helmet exchange RSA AES 256 SHA 384 which is the mandatory cipher suite that we've opted for. Four dark mail for DMTP and DMAP ensuring both perfect forward secrecy and mandating that the connection be established over TLS version 1.2. Give it back to the dark for a second. So we're not able to achieve perfect forward secrecy for our messages because it's contrary to what people want which is persistent access over a long period of time to all of your historical messages. But by requiring TLS 1.2 and a cipher suite that provides for PFS we get it at the wire level at least. I don't know if anybody can read this, but this is how we break up a sample message. We've got the, and I just realized this diagram is wrong. The tracing, the first box at the top is actually the only data that's actually unencrypted and can actually be stripped off at each successive hop. You don't have to, in theory a DMTP spec conforming server wouldn't put any sensitive information in that area. But if you happen to be a little more on the paranoid side you just strip it off when it arrives. The next two boxes are the ones I want you to pay the most attention to. They're the origin and destination boxes. They're the envelope. They contain the information that has historically and traditionally been part of the SMTP conversation. And what you'll see based on the letters that indicate who can access that information, you'll see that we have somewhat of a pseudo-onion. The origin can see who sent the message and the destination domain, but it can't see the destination mailbox. The destination server can see what the origin domain was and who the recipient is but can't see who the actual sender is. So we achieve a level of metadata protection at the organizational level. Like I said, you could discover that information if you had enough resources and were doing traffic analysis because you could just follow the flow of packets. Now we also break up the traditional headers into two separate blocks that are separately encrypted so that a resource constrained client can download the most commonly used headers without downloading the rest. We separate out the display portion of the message and then of course each individual attachment so that they can also be downloaded and verified independently. I don't have time to get into all of the details but suffice it to say, it's kind of a new concept. And it's what we need in order to have an encrypted e-mail message that will function under the very same conditions that we use e-mail today. In web browsers, on phones, on desktop clients, even occasionally via telnet and pine and that to protect the metadata, we use somewhat of a pseudo onion. This only illustrates what I was just saying. Who can see what? It's not perfect, but it's a big step in the right direction. And the hope is that once we get this system working, we can start building in extensions to it that will allow you to upgrade your communications with specific recipients that may even allow you to send a message directly peer to peer through something like a Tor circuit if you happen to need that kind of security. It's about understanding what your threat model is. There's a lot I haven't been able to talk about today, like the client modes or any of the access protocol stuff or the different deployment scenarios. Typically it takes me about three days to brief somebody, but I hope you start to understand how the system works because I need your feedback. If I'm going to be doing something wrong, I'd rather you guys find it and tell me than somebody else find it and exploit it for years before anybody knows about it. I don't know. Do we have time for this? This is the only slide I designed the presentation. Somebody posted it to my Facebook wall the other day. I'm pretty impulsive, so I'm like, this needs to go into my talk immediately. All right, so we're pretty low on time here. I'm going to cut this short. I'm just going to give you a sort of vague idea of what magma the client and server suite is going to look like. So the first thing to know is that Ladard actually worked on the server for over ten years. He pretty much wrote everything from scratch in C and this was a code that was deployed live on LavaBit.com. Everything, as I said, written in C, it's one massively multithreaded process and for anybody out there that's irritated with large installers and packages and tons of dependencies, you might be thrilled to know that there's basically three files. There's an executable, there's one massive library that all the dependency libraries get linked in together and you have a config file. And technically at the very base, that's all you need to run magma. So all running in one process space, you have all these different servers that might typically be different executables or different packages. So you have IMAP, SMTP, POP3, of course now there's DMTP and DMAP and there's also even an integrated web server. So no matter which part of this infrastructure you choose to deploy, that's all you need including for your web mail clients. And on the client side we have our thin client which is written in JavaScript and we have our thick client which I demonstrated to you earlier which is a Thunderbird fork. The thick client is definitely the one that we're directing our immediate attention to and our resources to. So it's not only our top priority as developers but it's also what we recommend that people use for security purposes. The JavaScript client is really just something for laziness or convenience. As far as how the JavaScript client works, the web server that we have integrated, it actually interfaces directly with the message store so unlike something like Squirrel Mail where you have dependency on a scripting platform that in and of itself might have zero day vulnerabilities in it, you know, you don't have to go through that intermediary step. So everything's merged together into one coherent whole. So I'm going to turn it back to Ladar for the conclusion. For the record I was always worried about running Clam AV in the same process particularly when they integrated the LLVM compiler and decided shipping executable code with their virus signatures. That's why I disabled that feature. But the developers didn't agree with me. We're almost out of time so I thought I'd just give out some attribute, whatever. To the people who created a couple of the photos. Particularly I'd like to call out Dave Crocker. He was one of those people that invented the internet although the way he tells the story he couldn't have done it without his brother Steve making coffee in the other room. He's been incredibly helpful translating my micro ideas into a macro concept and ensuring that we get the nomenclature right. I'd love to hang out and answer questions but unfortunately they're about to kick me off stage. So I see we have a couple of people up there. Do I have time to take a couple of questions? Okay. We'll try and go through them quick. Is there any provision for tunneling existing SMTPs mailed through the system? So it operates at a domain level. Either a domain supports darkmail or it doesn't. And if it doesn't support darkmail and you have dual protocol mode enabled, a non-dark domain can still connect to your SMTP server and send a message. And when it arrives, the volcano client would just indicate that it arrived insecurely. I don't actually have any questions but I wanted to express my gratitude to you and your team. It was pretty... The way I look at it is I just did what I'd expect anybody else in this room to do in the same situation. It was pretty gut-wrenching to watch what happened to the company and I just want to thank you and your team for continuing to offer products and services to your customers. I think it's funny you said that because we're actually not offering any products or services right now. You're continuing to expand upon... We raised a couple hundred thousand dollars which is what we're using to fund the development of the darkmail project and the reference implementation. But we need programmers because we basically decided to take a year off from seeking out personal gain and earning a living to build this and make this happen. And we need more people to help us because there's a lot of code yet to write. We've only been working on the darkmail pieces for about four weeks. So if anybody's interested in moving to Dallas and earning a subsistence wage while working on a piece of code to change the world, come talk to us. Hi. I have a relatively uninformed question about spam, darkmail, PGP, that kind of thing. Once everyone's using encryption, spam is expensive to send. But while we're getting there, all these key servers have emails with real names. They can go look up, see if an email is active and find out their name and that kind of thing. So there's two parts to that question. The first thing you need to understand is that when everything's encrypted, reputation actually becomes a much more viable tool for blocking abuse because you know the messages actually came from that domain. The second half of that equation is understanding that just because that kind of abuse prevention can't happen on the server doesn't mean it can't still happen in the client. And really just about every piece of functionality that we think can't happen in a darkmail world is because we're thinking of it as something that has to happen on the server when in reality it could just be moved out to the client. Google could still scan your messages for keywords. It just have to do them in JavaScript in your client after they had been decrypted. I think you've missed one question, but that's just fine. I've got just a general kudos and a question. And kudos is I really appreciate when you were forced to turn over your key and you literally took PEM to paper and handing that over I thought it was a pretty artful expression. They were calling it information. If it was just information then the paper should have been fined, right? It's incredibly reasonable, right? And it was to get by me time I figured why they were busy transcribing it all into the computer. I could be busy you know shutting down my systems, making sure they didn't show up and confiscate everything because everybody forgets. I actually thought that I was going to get arrested and they were going to confiscate all of my servers. So the second part I just had was a question around sort of the connection between keys and the different user signets. Should you have like a TLV value custody that you could use to sign like a future signet? But with people that don't communicate frequently and maybe a client that's not frequently looking up a user signet. So you can actually connect, I'm cutting you off because we're out of time, but you can actually connect to the DMTP server and you wouldn't be able to pull the full signet with all of the additional attributes, but you'd be able to pull a history of that security portion and see the chain of those security portions of those signets over time and link it between the one that you had in your cache and the one that you discovered. The way to think about it is really to think about it the same way we think about DNS. You have a domain name that you need to translate into an IP address and you have a resolver that goes out and does that process for you. Well, in the dark male world we're going to have a signet resolver that will go out and do that resolution for you and translate that address into a signet and it will apply those chain of custody checks for you until you tell the client if it needs to show a warning to the user. It makes perfect sense, thank you. I'll be around for the next couple of days for those who didn't get a chance to ask me questions, just flag me down and talk to me.