And so far four 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 background. Without further ado I'd like to introduce Thor. [ laughter ] I'm just kidding. This is Ladar Levison and Stephen Watt who are going to talk about Dark Mail. Give it up. [ Applause ] [Applause] >> I know everybody gets upset when it's time to get down to work they just want to keep watching the video. We're here the talk about Dark Mail. Unfortunately we're not calling it Dark Mail any more. Like all the really catchy names they all tend to change, lengthen when you go through that standards and formalization process. And I think the entire point to lengthen it just so you can turn it back in to a shortened acronym. There's a pay phone joke in there I'm just not 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 black board and take a picture. Did everyone get that? Already, get your pencils ready I'll do it one more time. Oops. How did that get there? Those private keys are supposed to be private. What is DIME? Quite a lot of different moving pieces, it's two protocols, two formats and management and configuration record and DNS system. We've got the Dark Mail, transfer protocol, which is on unauthenticated protocol that provides inner domain message transfer and key look ups, we've got the Dark Mail access protocol. Which is authenticated, handled persistent access to messages. Synchronization of Caches and key information. And a submission protocol. It's worth noting even know 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 a signing and encryption key along with collection of attributes and a signature very much like what we're familiar with when it comes to PGP public key. Or X509 certificate. Of course, it's neither of those. Don't call them either of those call them a Signet. Like a Signet ring. We've got the dark message format which is mine‑like as we'll get to later. It breaks up the mine structure in to independent chunks that are encrypted with different symmetric keys. And the goal of designing that was to basically create a format that would translate lost-lessly between mine and the format. The only information that is lost is actually the original mine 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. There was supposed to be audio file that plays. An easy button that would turn it all in to working software. But in lieu that have I have Stephen. 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 didn't find it. Like to point out even they we use 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 look‑up 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 orders of magnitude each. But I think it's important because with the type of metadata collection that's going on today we have guilty 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 in to, which is the idea that as a service provider I'm beholding 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 piece of paper that says you have to betray the people that are funding your business. It's creating a crisis of confidence. But 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 Auto‑magical. And making security and cryptography happen automatically while remaining secure and doing it for e‑mail while preserving all of the functionality that e‑mail provides is actually a very technical difficult challenge. I touch briefly on what the goals were but I think it's worth reiterating them here. PGP and S-mine give us author validation and message confidentiality but don't do a very good job at any of the other goals. Dark Mail 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 access e‑mail today. And that to do it and build it in a way that can handle Internet scale. Last time I checked there were about three billion e‑mail users on this planet. That's the reason I got in to 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 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 back 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 four days that I had to find one. But then as I thought about it more I started wondering, well how do 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. 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 Lavabit. If you read that sentence again with the word "Lavabit" it actually makes sense. On the next page, though, we see why I put this slide together. They were coming in and not only do 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 Bios or starting with the source code. I think I already know the answer to that question. I actually had to go to court to get B, C 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 your friends and family without any kind of fear of government surveillance. [Applause] I'm upset because I thought we one this war back in the '90s when we earned the right to have secure cryptographic algorythms to encrypt our communications. I'm upset that I need to take our e‑mail which is traveled around the Internet unprotected for the last 40 years and stick it in an M182 just to feel safe. I'm upset because you shouldn't need an Abrams tank for your e‑mail 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 and $10 billion annual budget. Did I the math, their budge set a little bit bigger than mine. This is who you should worry about. These guys, too. They have guns. Probably mention these folks, too. And of course if one kid on the playground has a toy, everybody else wants it. So you start to understand we don't just need DIME, we need it yesterday. I keep telling Stephen 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 in to 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 have rotated their keys that the new key information will sign by the previous. 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 is 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 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 upon DLS which has the OCSP protocol built in to the latest versions. Which check for the revocation of a certificate and they do it over 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 alluded 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 in to the authentication scheme that will make brute forcing more difficult. But ultimately it still comes down to you. And like the God father 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 Devian for that example. The algorithms themselves, the thing about cryptography 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 in to all of the hype we've only got so many years before the bad guys develop quantum computers can break the crypto anyways the way I look at it we 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. Seems like all the people who know a lot about security like to get in to Dev‑ops and system administration and very few follow my path and Stephen'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 in to 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 on the web mail system with client written java script. Yeah, we can do the crypto on your device but if we're loading the code to the client off of an untrusted server kind of open yourself up to attack. Just ask hush mail. And then we have the problem that 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, I thought I'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 Soapbox and get back to talking about DIME. I've decided that I don't just want to create a specification 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. 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 is going to be able to follow this as much as possible. What you're go fog see right now is called volcano and that's the client we've been working on a Thunderbird for it. As Ladar mentioned one of the important things about this, 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. 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 Cigna information for Dark Mail recipients that only shows off if you're sending e‑mail to a Dark Mail protected domain. The second case here we're going to send an e‑mail to a domain that's not encrypted by Dark Mail. This is an e‑mail I got from actually Keith Alexander uses this one to send e‑mails to one of his buddies at Google. I don't know if you can read that. As you see there the address cannot be found when you attempt to send it you get this warning dialogue saying that, at least one of the recipients is not protected by Dark Mail. 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 e‑mail address then we're going to use that same G‑mail address and as you can see there once again you get the little warning icon, the address Cigna cannot be found 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 administrators of these domains in to protecting themselves properly. The last little bit of information here we're going to go in to DEF CON presentation folder here and click on an e‑mail 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 to trust transmitting across a network in this sort of environment seemed a little bit suicidal. I'm in to self deprecation don't want to humiliate myself in public by everything somebody hijack my session. I'm going to turn it back to Ladar for a second. [Applause] >> What Stephen illustrated quite perfectly that somebody doesn't need any specialized knowledge in order to use DIME. All they need to know how to do is type in an e‑mail 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. Let's start by looking at the most important piece, the cornerstone, so to speak. And that's the DIME management record and the DNS system. For those of you who are eminently familiar with how e‑mail works, you'll recognize concepts that are already out there with sender I.D. mark, DCAM and sender policy framework. 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. It's out of DNS‑SEC this information is less reliable. What that long string of characters is, is actually the public signing key for the SIGNET. When you get the SIGNET from the DMTP server for the organization it's actually encrypted 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 corner stone of our trust. That you need a primary source and a second preauthenticated 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 be found by looking at the MX record. And we're assuming that the TLS certificate that we'll run in to when we access 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, the attributes. In this case we actually specify an at server so that you can put your DMTP host on a different server than you're SMTP host. And perhaps you don't like using 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 simplified. You know. [inaudible] 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 in trying to build in the necessary flexibility that the more complicated and larger environments can actually adapt during deployment. What is a Signet? Looks like bit like this. It's a relatively simple format. It has 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, name, maybe website address, 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 parameters is three bytes, we've got an effective technical limit here of 16 megabytes for a Signet. Please don't make your SIG‑NET 16 megabytes. In reality they should be far smaller. It's just trying to determine what to cap at is 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'll 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 recommended making kilobyte one thousand 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 listen to the very same bodies that gave us WEP and dual ECDRBG. How did 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 fit was a simple number that ended in zero? [ laughter ] Kind of reminds me of what happens when you got one team working with the metrics system and another one working with the imperial system. Just ask NASA how many satellites that little screw up has cost them. But this is your most basic SIG‑NET. The four required properties and the section that I like to refer to as the security portion. 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 SIG‑NET 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 SIG‑NET 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 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 are only signed by the organization which means that the SIG‑NET 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 SIG‑NET. Thought it would be worth it to throw in couple of what I'm calling undefined attributes. Mr. Greenwald likes bitcoin and wants to know his address. And because he's somewhat political he thought he'd add a motto to his SIG‑NET. The idea is we're creating a framework for you guys to build upon. The most important piece of DIME is actually this SIG‑NET process. Because if you can translate a e-mail address in to a public key what you can do with that is almost infinite. Imagine a ZRTP phone call where you don't need to do short authentication string to know there's no man in the middle attack but you can actually have the handshake signed by the signing key that you then verify through this DIME look‑up 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 in play. There are at models I don't have time to get in to but if you recall the cardinal rule is, you need a primary source and then a second preauthenticated source for verification and validation. DNS‑Sec is preauthenticated. The TLV root keys shift with your resolver. 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 at Internet and stick you on it. Thought it would be worth talking about who controls these keys. Because at a certain point you realize that even with DNS‑SEC 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. DNS‑SEC makes it that much better. We have mechanisms that I'm not going to be able to get in to 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 is coming out of the DNS system. My motto. I figure if I need someone to trust it will be a dog. Like to introduce Princess, the project mascot. >> The second part of the demo here, I guess my big person's mic is malfunctioning just a little disclaimer I was mentioning before this seems like the video is unpausable luckily Ladar slowed it down to 70% last night but I want to try to keep pace, I will pause a little bit longer in between the different components here. What I'm going to show you right now is the 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 SMPT and Dark Mail sections or at least the beginning of them. Not working. This is the output of magma being run there you can see the dependencies scroll by. We're telenetting the host Port 25, you can see the banner there, ESTP and DMTP1 issued a mode command showing that both of them are currently available. Now with traditional E‑hello command and we're going to issue a traditional mail‑from command. And you see that receive the success, that way we issue the mode command it says ESMTP now try to issue Dark Mail, the SIG-NEt command, and we're going to see the SIG‑NET is disabled. And that is because we fell in to ESMTP mode with the mail‑from command from RFC822 sal email. We're connecting again, we tried issuing the Dark Mail SIG‑NET command we that requires start TLS first. Now you don't have to worry it's going to scroll by the python code. Long story short we use this to start TLS so this shows the command being executed and reply we're doing start TLS, we got the certificate, we execute a mode command and now we're DMTP V-1 now we try an E‑ hello. We issue a SIG‑NET command we get the successful response, now we try issuing that old school mail‑from with the RFC822 style e-mail address, we get error, now dark style mail from the specifies a fingerprint only domain and it's successful. We're going to tweak something here in the config file we're going to search for the dual mode parameter we're going to set it to false so that is going to basically cause it to revert from dual mode into Dark Mail mode only. And now we're going to kill the magma Damon and start it over. Go back to our session here. Telenetting back in. And now if we try to do that same innocuous E‑hello command it tells us that it requires start TLS first. As opposed to saying, okay, then allowing the mail from command to determine which of the servers it's going to fall in to. All right. This next bit here is going to illustrate the cypher sweet that magma uses. So we're going to see here the dedicated SSL port for DMTP is 31301 we're going to launch server again, go to run SSL scan against it. You see whole bunch of crap scroll by in server log because the scans, now we're going to scroll up going to see all these failed cybernegotiation attempts. A lot of them. We're going to get the end of them there's going to be only one of them accepted. You see the EC depihelman exchange RSAES256 shot 384, which is the mandatory cypher sweet that we've opted for for Dark Mail for DMTP and Dmap insuring both perfect for secrecy and mandating that the connection we established was over TLS version 1.2. Back to Ladar for a second. [ Applause ] >> We're not able to achieve perfect forward secrecy or messaging because it's contrary to what people want which is persistent access for a long period of time to all of your historical messages. But by requiring TLS1.2 and cyphersweet to provide for PFS we get it at the wire level. I don't know if anybody can read this. But this is how we break up sample message. We've got the ‑‑ I just realized that this diagram is wrong. The tracing, the first box with the the top is actually only data that is actually unencrypted. And can actually be stripped off with each successive hop. 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 to you pay the most attention to. The origin and destination boxes. They're the envelope. They contain the information that 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 data protection at the organizational level. Like I said, you can 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 in to 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 then of course each individual attachment so that they can also be downloaded and verified independently. I don't have time to get in to 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 telenet and pine. And protect the metadata we use some what of a pseudo‑onion. There's 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 extensions to it that will allow you to upgrade your communications with specific recipients, that may even allow you to you send a message directly peer to peer through something like a core 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 year's before anybody knows about it. Do we have time for this? >> This is the only slide I designed in the presentation. Somebody posted it to my Facebook wall the other day, I was pretty impulsive, this needs to go in my talk immediately. So we're pretty low on time I'm going to cut this short just going to give you sort of vague idea of what magma the client and server suite will look like. So first thing to know is that Ladar 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 multi-intuitive process for anybody out there that is irritated with large installers and packages and tons of dependencies you might be thrilled to now there basically three files ‑‑ there's executable, there's a one massive library that all dependency libraries get linked in together you have config file. Technically at the very base that's all you need to run magma 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, pop 3 now DMTP and DMAP and integrated web server no matter which part of this infrastructure you choose to deploy that is all you need including free web mail clients. We have our thin client in java script and our thick client, which I demonstrated to you earlier which is a Thunderbird fork, the thick client is one that works directing our immediate attention to and our resources to it's not only our top priority as developers but also what we recommend that people use for security purposes. The java script client is really just something for laziness or convenience. As far as how the java script client works, the web server that we have integrated it actually interfaces directly with the message store so unlike Squirrel mail where you have the dependency on the scripting platform that in and of itself might have 0-Day vulnerabilities in it, you don't have to go through that intermediary step, everything is merged together in to one coherent whole. 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 decided shipping executable code with the virus signatures, I had to disable that feature, developers didn't agree with me. We're almost out of time. So I thought I'd just give out some attributes ‑‑ whatever. To the people who created 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 in to a macro concept. And ensuring that we get the nomenclature right. I'd love to hang out answer questions but they are about to kick me off stage I see we have couple of people up there do I have time to take couple of questions? Okay. We'll try and go through them quickly. >> Is there any provision for tunneling existing SMTP mail through the system? >> It operates at a domain level, either domain support stark mail or it doesn't and if it doesn't support Dark Mail and you have dual protocol mode enabled, it's non‑dark domain can still connect to your SMTP server and send a message. When it arrives the volcano client 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 ‑‑ [Applause] >> The way I look at it is I just did what I expect anybody else in this room to do in the same situation. >> It was pretty gut wrenching to watch what happened to the company I just wanted to thank you and your team continuing to offer products and services to the customers. >> I think it's funny you said that we're not offering any products or services right now. >> You're continuing to expand. >> We raised couple hundred thousand dollars which is what we're using to fund the development of the Dark Mail project and 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 we have to write, we've only been working on the Dark Mail pieces for about four weeks. So if anybody is interested in moving to Dallas and earning a subsistence wage while working on a persisiance code to change the world, come talk to us. >> Hi, I have relatively uninformed question about spam, Dark Mail, PGP, that kind of thing. Once everyone is using encryption spam is expensive to send. But while we're getting there all these key servers have e‑mails with real names, see if an e‑mail is active and find out their name that kind of thing. >> There's two parts to that question. The first thing you need to understand is that when everything is 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 that have 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. Really just about every piece of functionality that we think can't happen in a Dark Mail 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 key words if you just have to do them in java script in your client after they have been decrypted. >> I think you misunderstood the question. >> I've got just general kudos and questions. I really appreciate when you are forced to turn over your key and you literally took pen to paper and handing that over I think was powerful expression. >> We're calling it information. Information and paper should have been fine. Right? >> Incredibly reasonable. >> And it was to buy me time I figured while they were busy transcribing it in to the computer I could be busy shutting down my systems, making sure they didn't show up and confiscate everything. Everybody forgets I actually thought I was going to get arrested they were going to confiscate all of my servers. I think ‑‑ >> Go ahead. >> Question around sort of the connection between keys and the different user SIG‑NETs had like ‑‑ TLV value custody that you could use to sign like a future SIGNET but with people that don't communicate frequently, a client that's not frequent looking up the user's SIGNET >> You can actually connect ‑‑ I'm cutting you off because we're out of time. You can actually connect to the DMTP server and you wouldn't be able to pull the full SIG‑NET with all of the additional attributes but be able to pull history of a security that have portion see the chain of those security portions of SIG‑NET over time and link it between the one that you had in the cache the one that you discovered. The way to think about it is to think about same way about DNS. You have a domain name that you need to translate in to an I.P. address and you have resolver that goes out and does that process for you. Well in the Dark Mail world we're going to have a SIG‑NET resolver that will go out do that resolution for you and translate that address in to a SIG‑NET. And it will apply those chain of custody checks for you and tell you ‑‑ tell the client if it needs to show warning to the user. >> Thank you. >> I'll be around for the next couple of days for those who didn't get chance to ask me questions. Just flag me down and talk to me. [ Applause ] "This text is being provided in a rough draft format.  Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings."