 And we are from CryptoMail.org, a truth secure email for everyone. Okay, today we're going to talk about the problem statement that address the problem with web-based secure email. Then George will talk about omissions and objectives that solve the problem with web-based email. Then he will address the algorithms and protocols that use in applications. Next, he will give you a live program demonstration and show you how this program works. Then he will talk about the current platform and server platform mechanisms. At the end of the presentations, we will talk about the future directions and where we're going. At the end, you are welcome to ask any question you might have in our Q&A sessions. And here it goes, that you continue to talk to us. George said about. Okay, thanks Peter. Okay, here are the problem statements. Why is encrypted email important? It protects your privacy and it protects your assets. Let's say Peter wants to send me an email message that tells me when the next rave is and what the next secret rave location is. Or let's say he's got a piece of financial data that he wants to convey to me and wants to keep it confidential. So Peter wants to do so by keeping it confidential, so he's going to have to use encryption. The second reason why it's important is because as we all know, cryptography is free speech. And basically we believe that you should use it. You should use it in a pervasive manner or it's going to get taken away from you. So the more deployments you have, the harder it is for it to be taken away from you. So another part of the problem is how do we get people to use encrypted email? The grandma problem. How do you get your grandma who knows nothing about keys, encryption, privacy, or anything like that to use encryption? You have to get her to use it with almost not even knowing that she's using it. Also the encryption has to be basically roaming. You should be able to walk up to any terminal, any web-based, capable client, and be able to log in and use these encryption faculties. So let's say you've got your home machine and you do things with PGP on your home machine. In theory you should be able to go to Kinko's or go to your friend's house and still send encrypted email messages with confidentiality. The software's got to just work. It just has to install itself. There's no active on the behalf of the user installation. It doesn't muck with a registry. It doesn't do any of that stuff. It shouldn't do any of that stuff. So it's got a very low footprint in terms of user implication and installation. The experience has got to be ubiquitous. When you use encrypted email, it's got to look like email, otherwise no one's going to use it. It's just got to look like standard email messaging. You've got to manage people's keys. There's no key fumbling. Grandma doesn't know about somebody's PGP key. Here, grandma, cut this, paste this, and then use this program in order to import it into your key ring. Do you think you're grandma? Well, you guys come from a different gene lineage, so maybe your grandmas are capable of this. But my grandma really can't. I can't tell her to send me that secret cookie recipe by telling her to import my public key. We want to make the implementation that we're doing basically accessible. We want open source, free source with full disclosure, and we want to use basic standards. So we're going to use standard web servers, standard databases, everything basically unencumbered. So those are the problems. What are the missions? Our mission is to promote the freedom of private communications, okay? And our technical objectives are basically just lock down the transport level and lock down end-to-end message security. Okay, algorithms and protocols. I've got some very bright luminaries here, and they're actually here, some of them. Hi, John. Let's see. There's their encryption algorithms. Okay, I'm using Message Encryption Open PGP now. Basically, it's RFC 2440. And it was written by Phil Zimmerman, John Colas, Hal Finney, and a bunch of other people at PGP Corporation. So that's the specification that we're going to be going with. And our transport layer encryption that our agent is going to be using is Blowfish. It uses Blowfish 128, which is a public domain unencumbered symmetric cypher. Works great. Now, my protocols, which are on top of the previous two protocols are SexMap, which is Secure XML Message Access Protocol, and XMap, which is XML Message Access Protocol. XMap basically describes a way for you to send, receive, get folder listings and do directories and stuff like that from a mailbox. Not much unlike IMAP, but it just uses XML. And Secure XML basically takes that and it just makes it a little more secure. It adds a security layer on top. So all of this is pretty much open. If you're interested in the intricacies and the details, you can go to cryptomail.org documentation protocol specifications. And so you can read up on everything that I'm about to talk about in terms of the protocols. Now, our current five-minute goal is basically to accommodate the scenario I was talking to you about, where you go to Kinko's and all you have is this clunky web browser with a low baseline JVM with a Java virtual machine. That's that 1.1 compliance, okay? That's how low it is. And so basically the Java faculties at the time when they released 1.1 didn't have SSL capabilities. So because of that, we had to figure out a way to get the applet kind of like parameterized securely through SSL. But yet when the applet talks to the server, it can do so with a high level of confidentiality. And so the next process I'm going to be talking about, which is kind of painful, is the SSI. It's Secure Session Initialization. Okay, what happens? Basically, you go and you're presented with this login form. So you basically get this form and you pass in your username. Then the server generates a 16-byte session encryption key. This key is going to be used in order to encrypt all the communications from the client to the server in the payload. Then the server generates a 16-byte session token. I mean, a session token is just a session token. It's a unique identifier that basically describes your session with the server. Then the server generates a 16-byte random blowfish key, which I'm going to call the cloak key. And this key is kind of special. Then the server gives a 16-byte session cloak token. So you've got this cloak token, which is just another kind of token, and you've got this cloak key. So in theory, at this point, the applet and the server know all these parameters, and they've been passed through SSL. So in theory, no one knows what they are except the client and the server. So you slam in your password. Then the applet cbc blowfish encrypts the session cloak token with the cloak key. So you've got this cloak token, and you've got the cloak key. So then it encrypts the cloak token with the cloak key. Then the applet encrypts the data payload with the session key. And then basically this is what it's going to look like. So you've got your session ID, which is your unique session identifier. Then you've got in the header, you've got your cloak key, and then all your data. Then it gets posted to the server. Okay, so that gets to the server. And then basically the server just looks up the session through the session ID. And now it cbc decrypts the cloak, okay, using the cloak key. Now the server then compares the cloak token with the one that was decrypted with the one that's in the database. And if they are the same, then we know that this in fact is the applet that originated the secure session initialization. And the reason we do that is it's kind of, it's just in a quick asset test. Because if we didn't do that and we just sent over the encrypted payload with the session key, the server would actually have to go through the painful process of eventuating the bounce of the message. So let's say someone gives you this huge encrypted blob, and then someone says, here, decrypt it. And then you go and decrypt it, but it's garbage, okay? We don't want garbage through our system. So we give this little asset test in the preamble that says, okay, here's the challenge. And basically, if it gets decrypted, then you're going to pass the challenge. So it's just like, it's a little mini me. It's a little mini payload. Okay, so that's the purpose of the cloak. Now as a minor recap, we locked down normal HTTP traffic with SSL applet parameterization. The applet is posting this through normal HTTP. It doesn't use HTTPS. Okay, so now that we have the transport and we can purport, it's relatively secure. We want to authenticate and get our PGP keys from the server, because now we're going to be moving to open PGP. Okay, so when you log in, the applet sends half of the shawl one of your passphrase. So for example, if your passphrase is big boobs are good, that's your resulting hash, and the applet is going to send half the hash of that passphrase. Now the data payload that you see on the bottom there is going to be encrypted with the session, but for your perusing pleasure, it's not encrypted, just like the other picture was. So this data payload gets to the server, okay, and then if half the hash matches, you get your public key and your encrypted private key. Now remember, I'm going to say that your private key is protected with the entirety of your passphrase. So when you log in and you attempt to get your public and private keys, you're only sending half the hash of the passphrase. So basically, if for whatever reason the half the hash of the passphrase is incorrect, then you're going to get booted, and it's not going to return any of your keys. And let's say you do authenticate and it did pass you back your encrypted private key and your public key. Basically, the applet then obtains a copy of the GNU Privacy Guard. It downloads it from the server and it checks the hash of it. And then the applet just simply just hands off the keys to GNU Privacy Guard for importation. And so what we've got working right now is we've got an applet that can do Linux x86 and Windows implementations of the GNU Privacy Guard. And basically, the reason why we can do this is because of Java. When you sign your applets and the user accepts the certs, it basically allows you to gain escalated pricks. So let's go over the process of creating a crypto mail account. Basically, you go to a new account page which you saw over here. Sorry, hold on a second. There we go. And you basically pick your username and you submit a form. Then basically the server goes through the painstaking SSI process that we went over before. It creates a session, it creates a session encryption key, it creates a session token, and then it creates a cloak, I'm sorry, it creates a cloak and a cloak key. When you submit, the client is going to send the session, the encrypted cloak, that's for SSI again. And it's going to send the entirety of the public key, the encrypted private key that's encrypted with the entirety of the passphrase and then half the hash of the passphrase. So when that reaches the server, basically it decrypts it and it stores this information for you in its database and then it just sends a little response, I kiss you. And that's from back in the day when some web war was going on when Mahir was making pages. And I don't know if you guys remember that, but that was kind of when I was developing the protocol. So it's an homage to Mahir, wherever you are, my friend, I kiss you. Okay, so let's go to the program demonstration. I'm going to first create an account, then I'm going to log in, I'll send mail, receive mail, I'll go over the key manager, I'll go over client folder manipulation, client option, I might strip. Just kidding. Okay, so what username should I do? Oops, caps lock. Def, C-O-N, DefCon. So it's going through SSI. Okay, I accept the poison. Okay, you can use existing keys if you want. Like if you have PGP keys, you can import them into the system, and you have to disclose what your passphrase is so that I can save half the hash of it. So it allows you to do that. So I'm going to do DefCon. And the email notification is kind of a Biff mechanism. You guys know what a Biff is. Like whenever you receive mail, it kind of like pages you. This allows you to get a page every time you receive an email. Okay, so I'll just create new keys. And of course, you know, B-I-G-B-O-O-B-S-R-G-O-D. B-I-G-B-O-O-B-S-R-G-O-D. Okay, GPG is chugging away. It's prioritized with 2048 Algamol. Okay, I'm ready to log in. So I'm going to log in now. Okay, B-I-G-B-O-O-B-S-R-G-O-D. Okay, I'm in. All right. What should I do next? Should I send an email? I'm going to send an email. I'm going to send an email to DefCon 12. Or maybe not. Let me send an email to myself first. DefCon. Hey, subject, not cryptid. Sorry. Don't read. Subject. Uh-oh, I have a mail. Okay, this is what the message looks like, unencrypted. So basically you have your GPG message. And then there it is. Oh, sorry, sorry. How's that? Okay, sorry. Oops, there you go. This is your GPG message and unencrypted. And then here it is decrypted. Okay, so why don't I try and send a message to DefCon 12? I can't believe I made an account of DefCon 12. Okay, sorry. All right, shock me next time. Oh, I didn't create that user. Okay, let's see, who did I create? Oh, okay, I'm in the system. Okay, so I'm going to log out. And let's see. I'll go to login as Joshua T. Excuse me. And we're going to play with the key manager there. Okay, I'm in. Off the screen, don't shock me. Okay, now let's go play with the key manager. The key manager is kind of fun. We could see basically this is my list of keys. Now, if I try to send a message to DefCon 12, well, I'm sorry, if I try to send a message to DefCon, that guy's key is going to be automatically put into my key ring. Okay, so let's go to the key manager here. Uh-oh, it's not in there. Anyway, it's a small bug. Anyway, what you can do is you can import your keys. Okay, and you can do it through any number of ways. Okay, you could import it through a paste. So if you had a public or private key that you wanted to paste in, you could. Oh, wait, there it is. Hey, sorry, it was just a display issue. There's DefCon. Okay. Or you can import through a file. So you can browse your file system and import your keys through that mechanism. So that's basically the key manager. Well, I'll create a little folder. Subtrash. Okay. Hey, why don't I move this message to Subtrash? Okay. Why don't I delete this? And that's it. That's basically a crypto mail. That's a new version. It's using OpenPGP. It's shelling out. Okay. It's downloading the new Privacy Guard. It means escalated privs. It checks the hash of the GPG to make sure it's not running anything too weird. And it then employs that as the message encryption. So let me go back to the presentation. There we go. So XMAP is basically for mail and file system services. It's just XML message access protocol. I mean, it was kind of a fun little exercise. It's not IMAP. I was not really interested in using IMAP. And there were a number of reasons why. I didn't have the time to audit the code. There was a lot of unencumbered IMAP server code out there. I just didn't have the time to kind of audit it and make sure it wasn't doing anything. I really didn't have control over, immediate control over. I needed to develop this PDQ. So I just took Jim Clark's XPAC processor and put it into the crypto mail code. And so XML is a really good way to get your protocols and your apps up and running pretty damn quickly. So I kind of like that. The client platform, all messages are encrypted in the client. Basically the applets signed to allow a local file system access and shelling out and stuff like that. And it works in any Java-enabled browser where GPG can work and run. And it's got a nice ubiquitous interface. I'm sure it could use improvement. And I'd like to hear from all of you later about those improvements that I'm supposed to be making. And on the server platform, I've got MySQL 323 Plus for all the data storage. Okay, the current XMAP driver is using MySQL as a database. It doesn't use the file system. Everything's in the database nice and indexed and so you can get to the stuff quickly and scaleably. And it uses any Unix-based web server that does our Proc CGI. So if you've got Netscape or you've got Apache, what have you, it just requires our Proc CGI. And the session encryption employs the GPG Cypher library and uses send mail as the mail transfer agent. And here's a little picture of the schema that we got going on. You can all take a look at it in your spare time. Basically this is the sessions, the user base, the sequence and the data table stuff. So where is all this going? What needs to happen in order for crypto mail to be better? Or what needs to happen in general? Well, okay, one of the problems is we need to be able to send secure mail across federated domains. So how do you do that? There's certainly a number of schemes you can employ and we're currently looking and searching for those solutions. And we're considering getting on the LDAP bandwagon and starting to share and get keys using LDAP. Maybe crypto mail should then, after doing some more of the email work, maybe we should branch out into the instant messenger space so that grandma can send you instant messages. And on the architectural front, maybe we should not be using a Java applet. Although it's kind of cool, people may be used to more HTML mail approaches. So the idea would be you just have this middle tier browser object and you have HTML as your display. And so you use JavaScript to kind of bridge the gap between the HTML and the encryption and stuff like that. And maybe we should add privacy enhancements like time release messages so no one knows that you're logged on and sending and receiving mail. So that would be kind of nice. And maybe we should add alerting and rules-based processing. Whenever you get a message from X at Calm, it should biff some other site than the one that you currently have. So I mean there's all kinds of rules-based features that we're thinking of doing in order to make the experience better. Okay, so here's where the code is right now. This is an alpha version. We have not deployed this at CryptoMail.org. We need your feedback. Before we do anything, we need some salient input. So if you guys can write this down, it's at CryptoMail.org slash alpha slash index dot html. Now especially for you guys, so the username is alpha and the password is Defcon12. So in the next coming months, we're going to be migrating everyone over to this. And what I personally would like to do is I'd like to contact anyone who wants to get this up and running right now. I will help do so personally. Okay, it's really, really easy. So if you've got control of a domain and a mail server or whatever and you want to give CryptoMail a try, all you have to do is just mail me and I will definitely help you get it up. It's really easy. If you download the code and you just read the read me, you should be able to do it yourself. But in the event that you can't or you just want to talk, I can give you more of my personal information later. In fact, I'll give you my email address. It's joshwatee at CryptoMail.org. J-O-S-H-U-A-T at CryptoMail.org. I'll be more than happy to help any of you set it up if you want. Okay, so now we're on to the question and answer portion. And I'll leave the floor open to you guys. Yes, Mr. Lucky. Okay. Hushmail employees... Hushmail does not shell out. See, what they do is they have vertically independent Java PGP code. Now, I have to give them major props because that's not a small undertaking. You know, they did it... I believe some of the guys from cryptics may have worked on that. And they're continuously developing that and they do a very, very excellent job on that. And the one thing that... The one advantage I have, you know, if I may call it a silly advantage, is that the implementation of my applet is actually maybe smaller because it doesn't have to download all that PGP Java stuff. Because when the client runs, it downloads the GNU Privacy Guard only once. And if it's not in your cache, then it goes and downloads it again. I think it'll go and download it again. But also, mine may be a little bit faster because it's running natively. But I certainly have the distinct disadvantage of not being vertically independent. And that's one of the things that was hard for me to sleep at night, knowing that I was just going to cop out and just shell out. But anyway, that's what I did. And that's one of the market differences. Also, they actually have a middle-tier browser object model. They render an HTML and they communicate with the browser middle-tier through JavaScript. And that might be a direction that crypto mail may want to go in. Yes, sir. Okay, that's a very good question. In the Cyber Cafe, I believe the VMs, I don't think Sun's implementation allows that super lockdown stuff. I mean, personally, I haven't tried it. So maybe if you could get into that really lockdown state, maybe you could give it a try. But from what I know, I think if you have the Sun version of the VM and the Sun plug-in and the applet is signed, it's going to just run with it. Now, Internet Explorer and their VM has much more fine-grained control.