[00:00.940 --> 00:04.180]  Suboptimal, but it's the best we could do without delaying even further.
[00:04.540 --> 00:05.220]  So take it away.
[00:05.620 --> 00:06.700]  Thank you so much.
[00:07.000 --> 00:12.240]  I really appreciate HOPE and inviting us to talk with you.
[00:12.320 --> 00:18.180]  And again, I apologize for the primitive display option that we're left with.
[00:18.340 --> 00:21.220]  But if you can just deal with that.
[00:21.960 --> 00:22.680]  Let's begin.
[00:24.300 --> 00:27.040]  Okay, this is my partner in crime, Peter Leung.
[00:27.040 --> 00:32.320]  He runs the cryptomail.org organizational aspect of it.
[00:32.560 --> 00:34.780]  I'm more or less the technical lead.
[00:36.280 --> 00:38.500]  Okay, it's Saturday morning, 9 a.m.
[00:38.540 --> 00:41.020]  And look at all the technical difficulties we have.
[00:41.260 --> 00:42.140]  Did you guys sleep?
[00:42.540 --> 00:43.140]  I didn't.
[00:43.740 --> 00:44.980]  Thanks for being here.
[00:45.220 --> 00:50.140]  Okay, because it takes an extended effort to get up this early.
[00:51.420 --> 00:51.960]  Okay.
[00:54.900 --> 01:00.020]  Okay, we're going to talk about some of the problems that CryptoMail tries to solve.
[01:00.600 --> 01:03.460]  Some of our missions and objectives.
[01:05.360 --> 01:10.980]  We can't go through a program demonstration, unfortunately, because things are just simply AFU.
[01:12.380 --> 01:16.940]  We can go through some of the algorithms and protocols that we use.
[01:17.840 --> 01:22.960]  And we can go over some of the client and server platforms we are using.
[01:23.180 --> 01:27.100]  And we can go and talk about the future directions.
[01:27.240 --> 01:29.840]  And we can go into question and answer after that.
[01:31.300 --> 01:32.320]  Okay, thinking.
[01:33.280 --> 01:37.260]  Okay, why is encrypted email important?
[01:38.180 --> 01:41.820]  Well, it protects your privacy and your assets.
[01:43.040 --> 01:44.300]  It's pretty cool.
[01:45.000 --> 01:51.220]  I think it's kind of neat to be able to send and receive confidential information.
[01:53.120 --> 01:54.320]  It's free speech.
[01:54.500 --> 02:01.040]  You have every right to do so, to use encryption in your communications with other people.
[02:02.000 --> 02:04.720]  And so you should be able to speak your mind.
[02:06.960 --> 02:22.920]  And what we should do is we should try and make it as pervasive as possible and as out there as possible, so that it becomes so entrenched that no one or nothing can take it away from us.
[02:25.220 --> 02:30.020]  Okay, so how do we get people to use encrypted email?
[02:31.700 --> 02:33.680]  I call this the grandma problem.
[02:33.680 --> 02:37.700]  How do you get your grandma to communicate with you securely?
[02:39.380 --> 02:40.360]  It's kind of hard.
[02:40.540 --> 02:51.900]  You know, the programs that are out there, you know, they require, you know, a high level of geekdom in order to get them up and running securely, too.
[02:53.440 --> 02:59.640]  So that's one of the main problems that CryptoMail tries to address, is just how do we make it easy?
[03:01.280 --> 03:04.980]  Also, you want your... the solution to be migratory.
[03:05.320 --> 03:13.700]  You don't want to be... you don't want to have to carry your keys on a USB dongle.
[03:13.900 --> 03:16.080]  You want to... or a floppy.
[03:16.080 --> 03:25.180]  You want to just be able to go anywhere, sit down at a... at a terminal, and just log in and use your public and private keys.
[03:26.740 --> 03:30.460]  We want a zero install client.
[03:31.260 --> 03:36.020]  That means that no special software has to be installed.
[03:36.500 --> 03:38.560]  No non-standard software, rather.
[03:38.860 --> 03:43.100]  So you go to Kinko's and, you know, they have the registry on lockdown.
[03:43.100 --> 03:48.120]  They do all these kind of things in order to prevent you from nefariously installing software.
[03:48.220 --> 03:48.980]  Which is a good thing.
[03:50.100 --> 03:56.740]  But, with a web browser, you should be able to log in and use encrypted email.
[03:58.280 --> 04:00.840]  We want the platform to be open.
[04:02.120 --> 04:03.800]  We want it to be open source.
[04:04.240 --> 04:09.220]  We don't... we want to be... you know, have a ubiquitous user experience.
[04:09.220 --> 04:11.600]  When you use the program, it should look like mail.
[04:11.760 --> 04:13.280]  It shouldn't look like an XML editor.
[04:14.900 --> 04:17.160]  We want the transparency.
[04:18.120 --> 04:19.900]  Open source gives you that.
[04:20.100 --> 04:27.580]  When you disclose the source at the client and the server, it becomes no question as to what the program is doing.
[04:29.520 --> 04:30.080]  Okay.
[04:31.840 --> 04:35.980]  What... here... this is tying into some of the problems that we're trying to solve.
[04:36.360 --> 04:37.620]  What's the threat model?
[04:38.080 --> 04:38.500]  Okay.
[04:38.800 --> 04:41.060]  We're always going to assume Eve is around.
[04:41.220 --> 04:42.900]  She's always listening to our traffic.
[04:43.220 --> 04:43.480]  Okay.
[04:43.520 --> 04:44.400]  That's just a given.
[04:45.200 --> 04:48.940]  And we're also going to assume that Mallory is kind of there.
[04:50.020 --> 04:53.480]  Mallory has your system or can get your system.
[04:55.640 --> 05:00.600]  So... the threat model says... or tries to address...
[05:01.340 --> 05:06.840]  Can we build a system such that the user's private keys and messages are not immediately compromised?
[05:08.280 --> 05:10.840]  With a zero install client.
[05:12.460 --> 05:19.000]  And can the transport be locked down such that Eve only hears basically line noise or encryption?
[05:21.760 --> 05:22.280]  Okay.
[05:22.560 --> 05:26.640]  So, again, our mission is to promote the private communications.
[05:27.040 --> 05:31.140]  And, again, the technical objective is to answer the threat model questions.
[05:31.600 --> 05:36.660]  So, we want security at the transport layer and end-to-end message encryption.
[05:37.240 --> 05:43.760]  And we don't want to disclose any private key information to any agent other than the user themself.
[05:45.100 --> 05:45.620]  Okay.
[05:45.780 --> 05:47.240]  So, the demonstration is kind of borked.
[05:49.720 --> 05:57.360]  But, if you guys want, you can go to www.cryptomail.org to have a full demonstration of this functionality.
[05:59.060 --> 05:59.580]  Okay.
[06:00.820 --> 06:02.000]  What are we doing here?
[06:02.140 --> 06:07.260]  What is the technology and encryption platform that we're using?
[06:07.260 --> 06:10.200]  We're using Elgamal 1024.
[06:12.560 --> 06:15.640]  And, I have a note here that says RSA is good.
[06:15.820 --> 06:21.460]  But, at the time when I was writing this in 99, early 2000, RSA was still encumbered.
[06:21.940 --> 06:23.360]  So, I couldn't use it.
[06:24.000 --> 06:31.140]  Although, technically, I could have started using it and then all of a sudden the patent expires and then everything would be hunky-dory.
[06:32.960 --> 06:37.900]  But, things as they were, I released it as is with Elgamal.
[06:39.120 --> 06:43.100]  GPG uses Elgamal as well as a default ASIN.
[06:44.740 --> 06:46.420]  The symmetric cipher.
[06:46.760 --> 06:48.900]  For symmetric ciphers, we use Blowfish.
[06:49.040 --> 06:52.000]  It's a great unencumbered public domain cipher.
[06:52.220 --> 06:54.080]  Really strong, 128-bit.
[06:54.320 --> 06:55.240]  It's good stuff.
[06:55.240 --> 06:56.980]  The protocols.
[06:57.660 --> 07:04.400]  We have Secure XML Message Access Protocol, SexMap, and XMap.
[07:05.200 --> 07:10.600]  XMap is something like IMAP, but in XML.
[07:11.460 --> 07:12.020]  I didn't...
[07:12.020 --> 07:19.180]  When I was writing this, I didn't want to incorporate IMAP because I thought it was a pain.
[07:20.660 --> 07:21.380]  Okay.
[07:21.740 --> 07:26.760]  So, the protocols can all be found on our website at cryptomail.org.
[07:26.820 --> 07:30.280]  And you can go through the documentation and look through the protocol specifications.
[07:31.400 --> 07:46.860]  But, what this talk is going to be mostly about is trying to show how we lock down the user's private keys and secure the session.
[07:46.860 --> 07:58.640]  So, how we can prevent Mallory from gaining any salient information about your private keys and how we lock down the transport session.
[07:58.900 --> 08:03.580]  Now, CryptoMail, as it stands, is a Java applet.
[08:03.960 --> 08:04.480]  Okay.
[08:05.000 --> 08:14.320]  And, at the time, there was no SSL capabilities embedded in the VMs.
[08:14.320 --> 08:22.980]  So, you couldn't do HTTPS without incorporating your own vertically independent libraries.
[08:23.740 --> 08:25.560]  And so, that could get kind of big.
[08:25.820 --> 08:32.380]  It can get kind of floppy because I'm not going to sit there and write, you know, my own SSL layer.
[08:32.540 --> 08:35.000]  I'm going to use someone else's because that's pretty good practice.
[08:35.000 --> 08:45.660]  But, at the time, I was thinking of a way to try and avoid having to use SSL entirely.
[08:46.020 --> 08:56.280]  So, the next couple of minutes will be focused on how we use normal HTTP with an applet that is served via HTTPS.
[08:56.280 --> 08:57.900]  So, that's how we're going to lock down the session.
[08:58.600 --> 08:59.140]  So, okay.
[09:01.660 --> 09:05.800]  When you first start out in CryptoMail, you're presented with a login form.
[09:06.280 --> 09:08.760]  And you just type in your username.
[09:09.620 --> 09:12.140]  And that gets submitted through HTTPS.
[09:12.480 --> 09:21.240]  So, assume that you submit that securely and you post it via HTTPS.
[09:22.580 --> 09:23.220]  On the... let's receive a free system address.
[09:23.220 --> 09:26.020]  Then, the server generates a 16-byte session key.
[09:26.200 --> 09:27.120]  That's just your session.
[09:30.440 --> 09:31.240]  I'm sorry.
[09:31.400 --> 09:34.360]  It generates a 16-byte session encryption key.
[09:34.580 --> 09:34.940]  Okay.
[09:35.160 --> 09:38.600]  This is used to encrypt the session between the client and the server.
[09:38.920 --> 09:42.640]  Then, the server generates a 16-byte session token.
[09:43.420 --> 09:44.060]  Okay.
[09:44.200 --> 09:46.860]  This is the session client-server identifier.
[09:46.860 --> 09:52.640]  Then the server generates a 16-byte session cloak token.
[09:54.060 --> 09:57.700]  This is going to be a little challenge.
[09:59.000 --> 10:11.540]  And the server generates a 16-byte random Blowfish cloak key that's used to encrypt the challenge and put in HTTP headers.
[10:13.140 --> 10:18.680]  Okay, so the server passes the client, passes the applet, all those things.
[10:18.860 --> 10:23.780]  It passes the session token, which represents the applet's session with the server.
[10:23.940 --> 10:34.620]  It passes the encryption key, how the client and server are going to encrypt the traffic with 128 Blowfish.
[10:34.620 --> 10:46.480]  It passes the cloak token, which is basically this token challenge, and a session cloak encryption key.
[10:48.420 --> 11:03.260]  Now, the applet reads up the parameters, and in theory, because the form was submitted securely, in theory, the only one who knows about this parameterization is the client and the server.
[11:05.830 --> 11:18.050]  Okay, so whenever the applet wants to communicate with the server, okay, the applet Blowfish encrypts the session cloak token with the cloak token key.
[11:19.170 --> 11:23.350]  This effectively authenticates the client at the HTTP layer.
[11:23.930 --> 11:32.530]  So, it's a quick ACID test to verify that only the single client and the server are talking.
[11:36.250 --> 11:40.790]  So, the applet constructs all this information and sticks it in the header.
[11:41.050 --> 11:48.370]  It encrypts the Blowfish encrypted session token, and the server looks up the token, and if it can't find it, it's an error.
[11:52.180 --> 11:57.900]  And the server compares the cloak tokens, and if they're not the same, then abort.
[11:58.580 --> 11:58.840]  Okay.
[12:00.640 --> 12:03.660]  So, again, why do all this?
[12:03.820 --> 12:04.520]  Why tunnel?
[12:04.780 --> 12:10.120]  Why effectively try and do HTTPS over HTTP?
[12:10.600 --> 12:20.480]  Again, it's because there weren't any SSL faculties at the time to communicate within the Java VM and the server.
[12:20.480 --> 12:35.500]  Also, if there are libraries, you have to make the server and client use authenticated certificates.
[12:36.180 --> 12:39.340]  So, I didn't have any money at the time.
[12:41.180 --> 12:41.900]  Okay.
[12:42.760 --> 12:46.840]  Are there any questions about the SSI, secure session initialization?
[12:47.140 --> 12:47.760]  Yes, sir.
[12:51.480 --> 12:52.400]  Okay.
[12:52.640 --> 12:56.940]  Well, the applet is parameterized through SSL.
[13:02.970 --> 13:03.430]  Yes.
[13:04.110 --> 13:04.570]  There's...
[13:04.850 --> 13:06.050]  Well, okay.
[13:09.670 --> 13:18.570]  My assumption was is that no one could do that because the...
[13:21.470 --> 13:21.910]  Whatchamacallit?
[13:22.090 --> 13:24.830]  Because if the...
[13:25.770 --> 13:26.450]  I don't know.
[13:26.590 --> 13:31.990]  I guess if there's a manual on SSL through HTTPS, then, you know, it is what it is, right?
[13:31.990 --> 13:32.990]  I mean, if you could...
[13:33.830 --> 13:34.870]  I mean, if you could...
[13:34.870 --> 13:39.930]  Just with any SSL communications, if someone gets in the middle, then someone gets in the middle.
[13:42.350 --> 13:42.790]  Right?
[13:45.910 --> 13:46.950]  Um...
[13:46.950 --> 13:47.630]  Yeah.
[13:47.930 --> 13:47.970]  On...
[13:48.810 --> 13:49.330]  On SSL.
[13:49.550 --> 13:50.590]  Yeah.
[13:54.190 --> 13:54.310]  Mm-hmm.
[14:00.320 --> 14:01.360]  Yeah.
[14:03.620 --> 14:05.420]  Assume that the client...
[14:05.660 --> 14:15.900]  After the client posts through HTTPS, the form, and the server passes back the applet and the parameterization, that that information is confidential.
[14:16.380 --> 14:16.740]  Okay?
[14:16.800 --> 14:17.680]  We'll have to assume that.
[14:17.940 --> 14:18.740]  Everyone does.
[14:19.600 --> 14:20.160]  Uh...
[14:20.160 --> 14:22.140]  You know, we were probably wrong.
[14:22.140 --> 14:25.340]  Someone out there knows how to do it.
[14:25.840 --> 14:26.400]  Probably.
[14:29.480 --> 14:30.220]  Yes.
[14:39.190 --> 14:40.470]  Any other questions?
[14:40.970 --> 14:41.590]  Regarding SSI?
[14:41.690 --> 14:41.950]  Yes, sir.
[14:44.410 --> 14:45.150]  Okay.
[14:45.630 --> 14:46.610]  They last...
[14:46.610 --> 14:48.500]  Right now, they last, uh...
[14:48.850 --> 14:49.350]  30 minutes.
[14:50.310 --> 14:50.550]  Yes.
[15:02.000 --> 15:02.740]  Okay.
[15:02.740 --> 15:03.220]  If...
[15:04.240 --> 15:04.800]  Uh...
[15:04.800 --> 15:06.700]  If she closes the...
[15:06.700 --> 15:10.060]  You're saying, if she closes the navigator window?
[15:18.160 --> 15:18.720]  Okay.
[15:18.860 --> 15:21.000]  If she closes the window, it'll send the app...
[15:21.000 --> 15:22.860]  The applet will be sent a message.
[15:24.480 --> 15:25.040]  Uh...
[15:25.040 --> 15:27.580]  I think it's basically an on destroy meme.
[15:27.860 --> 15:28.280]  Okay?
[15:28.720 --> 15:32.620]  And on destroy, it automagically logs you out.
[15:32.620 --> 15:41.000]  Whether that's conformant Java VM behavior across all platforms is as good as yes as anyone's.
[15:41.520 --> 15:46.880]  But we'll have to assume that all relatively new VMs are compliant.
[15:47.480 --> 15:47.860]  Yes.
[15:48.200 --> 15:48.660]  Yes, sir.
[15:49.580 --> 15:50.280]  Yes.
[15:50.440 --> 15:50.720]  Yes, sir.
[15:58.120 --> 15:59.060]  Excuse me?
[15:59.780 --> 16:00.580]  Oh, okay.
[16:00.700 --> 16:01.940]  It's in the Java VM.
[16:01.940 --> 16:14.260]  So when the Java VM goes poof, basically if the Java VM cleans up its memory, then everything should be fine.
[16:15.060 --> 16:25.320]  I'm sorry, I will have to defer responsibility for the behavior of VMs.
[16:25.320 --> 16:29.060]  You know, it's one of the toughest things.
[16:31.800 --> 16:38.480]  It's really hard because all the software is laid on top of each other.
[16:38.500 --> 16:45.840]  So if the VM doesn't clean up after you close it and you can go in there and take a peek at it, that's a distinct possibility.
[16:45.840 --> 16:47.220]  But yet that's the reality.
[16:47.440 --> 16:50.840]  We live with other systems.
[16:54.190 --> 16:55.630]  While in memory... No.
[16:57.270 --> 16:59.010]  It's all in the VM.
[17:03.540 --> 17:04.140]  Yes.
[17:04.140 --> 17:05.820]  That is a possibility.
[17:06.080 --> 17:07.640]  But I do not make that effort.
[17:07.640 --> 17:18.140]  We're going to assume that the client machine that grandma is using is exactly not loaded with Spire.
[17:18.320 --> 17:20.720]  It's a really big assumption these days, okay?
[17:21.600 --> 17:34.920]  And it's not a huge reality, but, you know, we're just going to assume that there's nothing terribly malicious against crypto mail.
[17:34.920 --> 17:36.180]  But it's entirely possible.
[17:37.120 --> 17:37.620]  Okay.
[17:37.840 --> 17:39.680]  So let's talk about the threat model.
[17:39.780 --> 17:40.940]  Let's get back to the threat model.
[17:41.100 --> 17:42.060]  You know, the SSI...
[17:42.060 --> 17:42.220]  Okay.
[17:42.440 --> 17:43.260]  So we've got...
[17:43.260 --> 17:45.920]  You know, we've totaled HTTPS.
[17:46.060 --> 17:57.260]  We did all this work just to freaking, you know, get away from paying certs and incorporating this huge 256K vertically independent SSL library.
[17:57.260 --> 18:01.320]  That's going to be really slow because it's written in Java.
[18:02.800 --> 18:03.280]  Okay.
[18:03.760 --> 18:07.720]  Generally, you know, you know, software, crypto with Java.
[18:08.140 --> 18:10.480]  I mean, that's like two strikes against you already.
[18:10.780 --> 18:11.020]  Okay.
[18:11.640 --> 18:13.660]  It's bad enough, you know, just doing software, crypto.
[18:13.860 --> 18:15.180]  You're going to really burn some cycles.
[18:15.760 --> 18:16.240]  Okay.
[18:18.260 --> 18:18.740]  Okay.
[18:18.880 --> 18:19.640]  The threat model.
[18:21.940 --> 18:23.940]  Basically, let's talk about Mallory.
[18:24.180 --> 18:24.320]  Okay.
[18:24.440 --> 18:32.280]  At the end of this, we should show that Mallory, while he may pinch me, okay, is going to have a little bit of a hard time.
[18:32.460 --> 18:38.300]  You know, with today's hardware, the current implementation in terms of size, I'll be a little bit direct with you.
[18:38.400 --> 18:50.720]  The current implementation in terms of key size is on a particular user focus is not terribly strong, but neither are passphrases in general.
[18:50.720 --> 18:58.260]  So, if you do, if you read the passphrase back, it says basically passphrases are, you know, they're basically useless.
[18:58.680 --> 19:08.280]  Because the domain, the search domain is for, you know, basically today's hardware is pretty small.
[19:08.560 --> 19:17.880]  In any event, we're going to try and go over the threat model and show you that Mallory might have a little bit of a difficult time.
[19:18.800 --> 19:20.260]  So, creating an account.
[19:20.520 --> 19:25.200]  Basically, the applet creates a public and private key pair.
[19:25.980 --> 19:28.580]  And the user chooses a passphrase.
[19:29.060 --> 19:33.300]  And the applet CBCblowfish encrypts the private key with the passphrase.
[19:33.400 --> 19:39.700]  So, you have the entirety of your passphrase encrypted with the...
[19:40.480 --> 19:43.920]  You have the private key encrypted with the entirety of the passphrase.
[19:45.120 --> 19:50.000]  Then the applet saves half the hash of the passphrase.
[19:51.080 --> 19:56.220]  So you've got your encrypted private key, and you've got half the hash of the passphrase.
[19:58.600 --> 20:12.880]  Now, the applet basically constructs a little Mac at the end of the encrypted private key blob, just to make sure, you know, for later use, to authenticate that the private key information hasn't changed.
[20:13.100 --> 20:21.120]  So we've got half the hash of the passphrase, the encrypted private key encrypted with the entirety of the passphrase, and we've got the little Mac.
[20:22.940 --> 20:42.380]  Now, the applet sends the message, new account, with the public key, the encrypted private key, that's encrypted with the entirety of the passphrase, half the hash of the passphrase, and the encrypted hash of the passphrase.
[20:43.920 --> 20:49.680]  So basically, it goes through SSI before it sends that, and it just sends the new account.
[20:49.680 --> 20:53.940]  And then, does anyone remember the web lore from Maher?
[20:54.500 --> 20:57.600]  That, what was it, a Turkish guy or something, I don't know.
[20:57.820 --> 21:04.020]  He was like, he wrote this cheesy GeoCities webpage, and it said, I kiss you.
[21:04.480 --> 21:05.500]  You don't remember that?
[21:05.900 --> 21:07.580]  Welcome to my site, I kiss you.
[21:07.840 --> 21:08.040]  Okay.
[21:08.340 --> 21:13.640]  Well, this was around that time, and I was making the protocol, so this is an ode to him.
[21:13.640 --> 21:16.860]  It made wired and all this other stuff.
[21:17.300 --> 21:17.460]  Okay.
[21:19.860 --> 21:21.920]  So, what do we have on the server?
[21:22.280 --> 21:27.020]  We've got the encrypted private key, encrypted with the entirety of the passphrase.
[21:27.240 --> 21:28.360]  We've got the public key.
[21:28.540 --> 21:32.060]  Okay, everyone can have each other's public keys without any problem, right?
[21:32.880 --> 21:33.840]  I'll assume that.
[21:35.180 --> 21:39.960]  And we've got the Mac of the private key.
[21:40.220 --> 21:42.300]  Now, what happens when you try to log in?
[21:43.980 --> 21:44.500]  Okay.
[21:44.700 --> 21:48.480]  So, the client wants its private key information, right?
[21:48.580 --> 21:51.940]  It wants to send and receive end-to-end encrypted messages.
[21:53.320 --> 21:58.280]  So, basically what happens is the applet requests a passphrase.
[21:59.220 --> 22:03.440]  Then the applet SHA-1s and saves half of those bits.
[22:04.280 --> 22:04.940]  Okay.
[22:05.660 --> 22:09.160]  And then it logs in with half the hash of the passphrase.
[22:12.440 --> 22:21.200]  So, basically, you know, we set up all the HTTP headers for SSI, secure session initialization.
[22:21.200 --> 22:24.360]  And the applet sends the payload.
[22:24.960 --> 22:29.360]  Then the server compares half the hash of the passphrase.
[22:31.710 --> 22:43.060]  And if it's successful, it sends the encrypted private key and the encrypted hash of the private key.
[22:43.890 --> 22:49.420]  So, half the hash of the passphrase is stored encrypted again.
[22:50.220 --> 22:51.620]  Basically, as a password.
[22:54.740 --> 22:55.100]  Okay.
[22:56.980 --> 23:03.460]  So, then the applet basically decrypts the private key and then it authenticates the Mac.
[23:07.540 --> 23:11.820]  And if the decrypted hash doesn't match up, then it splits fill.
[23:13.180 --> 23:15.920]  So, at this point, what does the server know?
[23:18.540 --> 23:22.100]  The server knows at most half the hash of your passphrase.
[23:23.620 --> 23:24.260]  Okay.
[23:24.740 --> 23:30.960]  So, the server maintains a high level of security of the user's identity without compromising the private key.
[23:32.460 --> 23:32.980]  Okay.
[23:33.180 --> 23:34.560]  So, going back to the threat model.
[23:35.260 --> 23:38.960]  Mallory, who may control the server, only knows half the hash of the passphrase.
[23:39.180 --> 23:40.240]  Not its entirety.
[23:43.120 --> 23:43.640]  Okay.
[23:44.710 --> 23:46.220]  Any questions about that?
[23:46.880 --> 23:47.540]  Yes, sir.
[23:52.080 --> 23:52.600]  It's...
[23:52.600 --> 23:53.760]  I think it's the first half.
[23:54.760 --> 23:55.280]  Yes.
[23:55.580 --> 23:55.900]  Yes.
[23:56.080 --> 23:56.540]  Absolutely.
[23:56.540 --> 23:57.820]  See, that was a...
[23:57.820 --> 23:59.100]  That would be a concern.
[23:59.260 --> 24:16.360]  If it took a random number of bytes the first time or, you know, or the second time, then someone listening passively could determine the entirety, you know, could get the whole hash of it.
[24:16.560 --> 24:18.600]  And so, that's certainly not good.
[24:19.280 --> 24:24.440]  You don't want to disclose any more information than you have to.
[24:30.160 --> 24:30.760]  No.
[24:31.100 --> 24:31.200]  No.
[24:31.200 --> 24:31.780]  The server...
[24:31.780 --> 24:35.660]  All encryption and decryption is done on a signed Java applet.
[24:36.260 --> 24:36.800]  Okay.
[24:37.520 --> 24:38.920]  Well, let's talk about...
[24:38.920 --> 24:39.820]  Let's talk about this.
[24:40.580 --> 24:42.340]  Mallory has gotten your machine.
[24:43.140 --> 24:43.640]  Okay.
[24:44.240 --> 24:45.440]  What does he know?
[24:45.640 --> 24:48.140]  He's borked your server and he has got...
[24:48.140 --> 24:50.660]  He's got half the hash of your passphrase.
[24:50.820 --> 24:51.800]  And that's it.
[24:51.980 --> 24:52.880]  What can he do?
[24:53.460 --> 24:56.000]  Can he change the signed applet?
[24:57.320 --> 24:59.820]  Can he change the behavior of the signed applet?
[25:06.040 --> 25:08.180]  It's basically the SSL problem, right?
[25:08.320 --> 25:09.560]  I mean, you've got this encrypted.
[25:10.580 --> 25:16.220]  You've got this applet that's signed by a trusted root authority.
[25:16.340 --> 25:17.580]  Which crypto mail is not.
[25:18.120 --> 25:18.340]  Okay.
[25:18.660 --> 25:20.020]  But let's just assume...
[25:20.020 --> 25:23.300]  Let's assume that, you know, these are not poison certs.
[25:23.300 --> 25:23.580]  Okay.
[25:24.420 --> 25:26.080]  And that these are good certs.
[25:26.320 --> 25:26.580]  Okay.
[25:26.820 --> 25:29.240]  And I bought my VeriSign certificate.
[25:29.560 --> 25:32.420]  And they verified me through Dun & Bradstreet.
[25:32.580 --> 25:33.720]  And I signed it.
[25:34.180 --> 25:34.420]  Okay.
[25:34.800 --> 25:36.860]  Could someone change my...
[25:38.420 --> 25:46.080]  Could someone replace my binary and still have it come up with the correct information?
[25:46.080 --> 25:48.340]  And I don't think so.
[25:48.540 --> 25:54.220]  Because I keep the private key for encrypting or signing the applet offline.
[25:54.940 --> 25:56.440]  Those keys aren't even there.
[25:58.840 --> 26:04.080]  So, Mallory is going to have a really, really hard time changing the behavior of my applet.
[26:04.280 --> 26:07.160]  But he can certainly get the session.
[26:07.540 --> 26:07.660]  Okay.
[26:07.960 --> 26:08.480]  Game's up.
[26:08.960 --> 26:10.300]  He's got my session.
[26:10.300 --> 26:19.400]  But if you're sending encrypted email, in theory, the bits of the end-to-end encrypted messages should be fine.
[26:19.520 --> 26:21.600]  He can know what folder you're browsing.
[26:22.120 --> 26:24.700]  He could see all your Xmap traffic.
[26:24.920 --> 26:49.320]  But if the contents of the message are encrypted through end-to-end message encryption, provided the applet is not poisoned, and I purport that it probably won't be because it's supposed to be signed, and so he can't change it, that the message contents going end-to-end are going to be relatively locked down.
[26:50.100 --> 26:50.780]  Yes, sir?
[26:51.480 --> 26:51.920]  Okay.
[26:56.950 --> 26:58.490]  It's a long story.
[26:58.730 --> 26:59.470]  It really is.
[26:59.530 --> 27:00.190]  It's a long story.
[27:00.350 --> 27:02.930]  You can go to www.cryptomail.org.
[27:06.710 --> 27:09.810]  Unfortunately, we're viewing it under this thing.
[27:09.970 --> 27:14.170]  There's no network, and it's absolutely indefensible.
[27:14.830 --> 27:16.610]  I'm perfectly sorry for that.
[27:16.830 --> 27:21.570]  But if you go to www.cryptomail.org, you can see the applet running.
[27:21.790 --> 27:27.250]  If you're not scared of my poison certs, because I haven't paid.
[27:27.250 --> 27:30.130]  So I deeply apologize for that.
[27:31.370 --> 27:31.870]  Okay.
[27:32.510 --> 27:33.210]  Yes, sir?
[27:33.290 --> 27:33.630]  In the back.
[27:44.720 --> 27:47.440]  That is an attack.
[27:47.680 --> 27:48.000]  Yes.
[27:48.580 --> 27:48.900]  Yes.
[27:49.580 --> 27:52.780]  If you want to send it...
[27:52.780 --> 27:59.560]  CryptoMail basically provides for escalated privileges, so you can send attachments.
[27:59.560 --> 28:03.700]  So grandma wants to send her recipe, and it's in this text file.
[28:03.880 --> 28:09.360]  She can do so, but the applet needs escalated privileges.
[28:09.360 --> 28:20.360]  In the event that Mallory replaces that with unnecessarily signed code, then yes, we have been poisoned.
[28:20.660 --> 28:21.260]  Indeed.
[28:25.920 --> 28:26.440]  Okay.
[28:29.400 --> 28:30.000]  So Xmap.
[28:30.260 --> 28:32.280]  XML message access protocol.
[28:32.660 --> 28:36.900]  You know, it's just my silly substitute for IMAP.
[28:38.480 --> 28:39.660]  It's nice XML.
[28:39.900 --> 28:43.400]  You know, James Clark written a great XML parser, XPAT.
[28:43.660 --> 28:44.740]  It is so...
[28:44.740 --> 28:46.840]  It's like butter to develop with it.
[28:47.080 --> 28:47.320]  Okay?
[28:47.940 --> 28:52.520]  If you want to do any kind of protocol development with XML, XPAT's the way to go.
[28:53.620 --> 28:55.240]  So you guys can take a look at that.
[28:56.160 --> 28:58.820]  So basically, we're going to talk about the client platform.
[28:59.080 --> 29:00.640]  It's, you know, it's a Java applet.
[29:00.780 --> 29:01.980]  It uses HTTP POST.
[29:03.560 --> 29:06.600]  The current implementation works in Mac OS 9.
[29:08.700 --> 29:10.820]  It's got a nice ubiquitous interface.
[29:12.360 --> 29:16.800]  For the backend, we use MySQL 323.
[29:18.220 --> 29:25.920]  What's of note here is that basically there's no system user names.
[29:26.140 --> 29:27.680]  There's no system users.
[29:28.220 --> 29:31.540]  They're not in an /etc/passwd or anything like that.
[29:31.920 --> 29:34.060]  Everything is inside the database.
[29:34.240 --> 29:41.360]  So the file system and everything else and the user base is all inside the MySQL tables.
[29:42.440 --> 29:46.920]  It uses any Unix-based web server that does out-of-proc CGI.
[29:50.100 --> 29:54.920]  The session encryption engine employs the GPG cipher portion.
[29:55.120 --> 29:57.200]  And it uses SendMail as the MTA.
[29:58.340 --> 29:58.880]  Okay?
[29:59.040 --> 30:00.540]  And here's a little picture of the schema.
[30:03.540 --> 30:04.260]  And we're waiting.
[30:04.260 --> 30:05.380]  Okay.
[30:05.740 --> 30:06.840]  Where are we going?
[30:08.940 --> 30:12.000]  Should we use OpenPGP as the base?
[30:13.400 --> 30:14.280]  I don't know.
[30:14.760 --> 30:15.900]  Sounds like a good idea.
[30:16.300 --> 30:19.980]  I think we can get a lot more people to use it if we did that.
[30:22.040 --> 30:27.880]  Should we make or use an instant messaging client along with this?
[30:27.880 --> 30:36.060]  So when you log into the CryptoMail server, use your public and private key to encrypt instant messages to each other through this mechanism.
[30:36.240 --> 30:41.240]  So grandma can communicate with you live as opposed to emails.
[30:42.620 --> 30:44.240]  How can we link servers?
[30:45.040 --> 30:48.360]  And how do we trust public keys?
[30:48.540 --> 30:52.860]  These are outstanding questions that CryptoMail has yet to address.
[30:55.600 --> 31:13.860]  So, what I'd like you to do in the face of my belly flop with the autonomous demonstration, I'd like you to visit CryptoMail.org and just take a look at A, the code, and B, the code running.
[31:14.980 --> 31:19.180]  I can go over it with anyone who wants to.
[31:19.180 --> 31:25.520]  And basically, we need help.
[31:25.880 --> 31:36.700]  We need developers and HTML UI people who are interested in implementing pervasive cryptography.
[31:37.720 --> 31:39.400]  And we're going to go to questions.
[31:42.100 --> 31:42.720]  Yes, sir.
[31:45.060 --> 31:46.020]  Yes.
[31:55.520 --> 31:57.420]  Well, I don't know, really.
[31:59.000 --> 32:08.340]  Yeah, I mean, you know, the reason why I chose ElGamal was simply because it was unencumbered.
[32:09.100 --> 32:09.740]  Okay.
[32:10.560 --> 32:19.160]  Yeah, at the time I was writing it, basically, RSA had a patent on it at the exact time I was writing it.
[32:19.260 --> 32:22.620]  Now, had I waited three months before deployment?
[32:23.280 --> 32:23.300]  Sure.
[32:23.820 --> 32:28.580]  I could have used RSA without any kind of encumberment whatsoever because the patent expired.
[32:29.760 --> 32:38.600]  But if we look at what other people are doing, GPG uses ElGamal as a default, so I would say, you know, it's pretty good.
[32:39.200 --> 32:40.000]  It's good stuff.
[32:41.420 --> 32:42.220]  Yes, sir.
[32:51.210 --> 32:51.850]  Okay.
[32:54.810 --> 33:03.810]  That was one of the areas of exploration that CryptoMail has yet to, you know, go through.
[33:03.810 --> 33:20.930]  But, in theory, if CryptoMail used PGP as the mechanism for message encryption and end-to-end encryption, then I guess we could use PGP keys.
[33:22.970 --> 33:24.030]  Yes?
[33:33.060 --> 33:33.840]  Uh-huh.
[33:42.580 --> 33:49.100]  Well, okay, I don't know necessarily the exact program you're talking about.
[33:49.100 --> 33:56.200]  Well, I guess I'm assuming Blowfish is an encryption tool.
[33:56.600 --> 33:56.980]  Okay.
[33:57.400 --> 33:57.940]  So, yes.
[33:58.400 --> 34:04.860]  You would have to assume either the encryption tools were congruent or the protocols that they speak are congruent.
[34:05.420 --> 34:09.340]  If they're not, you're certainly going to have problems.
[34:09.520 --> 34:10.980]  Now, PGP is a specification.
[34:10.980 --> 34:20.940]  So, if you encrypt things to the same specification, in theory, one should be able to communicate with each other.
[34:21.600 --> 34:23.940]  But PGP is generally very good at it.
[34:24.120 --> 34:29.120]  If you use PGP, another PGP program will probably be able to encrypt and decrypt.
[34:36.990 --> 34:40.350]  Yeah, you can get PGP from a number of sources.
[34:40.810 --> 34:47.250]  If you're using a UNIX, or a UNIS rather, GPG works extremely well.
[34:47.250 --> 34:53.110]  And that's at GNU Privacy Guard, GNUPG.org.
[34:53.710 --> 34:55.370]  G-N-U-P-G.org.
[34:55.550 --> 34:55.890]  Yes, sir.
[35:00.740 --> 35:01.220]  Yes.
[35:06.040 --> 35:07.820]  You know, I really haven't tried it.
[35:08.920 --> 35:10.640]  Maybe I can get some data points.
[35:11.000 --> 35:12.380]  I would like to try it.
[35:13.360 --> 35:16.280]  That's a very interesting question.
[35:16.280 --> 35:22.100]  But yeah, adding anonymity to the picture is certainly something of value.
[35:23.220 --> 35:23.360]  Yes.
[35:25.660 --> 35:26.500]  Yes, sir.
[35:30.140 --> 35:31.420]  Key revocations.
[35:33.280 --> 35:34.500]  Basically, I don't.
[35:34.660 --> 35:40.540]  Right now, CryptoMail.org does not, in its current format, does not support that.
[35:41.240 --> 35:42.020]  Yes, sir.
[35:42.880 --> 35:43.520]  Yes.
[35:55.730 --> 36:00.570]  Okay, the message, it works almost like PGP.
[36:01.330 --> 36:02.730]  But it's not.
[36:02.990 --> 36:03.510]  Okay?
[36:03.810 --> 36:08.010]  The message is encrypted with the symmetric cipher.
[36:09.140 --> 36:14.590]  But the symmetric cipher key is encrypted with Elgamal.
[36:15.290 --> 36:17.250]  So it works kind of like PGP.
[36:17.250 --> 36:24.470]  I mean, it would be very foolish of me to encrypt the whole message with asymmetric cipher.
[36:25.090 --> 36:27.390]  So we use the symmetric cipher for the message contents.
[36:27.670 --> 36:28.490]  Message key.
[36:28.810 --> 36:30.530]  We use asymmetric encryption.
[36:41.820 --> 36:43.380]  I have thought about it.
[36:43.540 --> 36:43.940]  Yes.
[36:44.680 --> 36:49.440]  And it just so happens that most of the VMs actually do support compression.
[36:52.920 --> 36:53.520]  Yes.
[36:54.960 --> 36:55.560]  Yeah.
[36:56.280 --> 36:56.440]  Yeah.
[36:56.440 --> 37:08.520]  But in working towards my goal towards a more standard message format, I think that that might be taken care of in some other way.
[37:08.740 --> 37:08.820]  Yeah.
[37:10.000 --> 37:12.620]  I mean, if I were to go to open PGP, then yeah.
[37:12.840 --> 37:20.280]  I think that's part of what the PGP guys do, is they usually compress first.
[37:20.500 --> 37:21.760]  Depending upon message size.
[37:21.900 --> 37:23.100]  I mean, it depends on your implementation.
[37:23.420 --> 37:25.920]  I've seen some that don't compress.
[37:26.240 --> 37:30.340]  But I've seen some that compress based on the size of the message.
[37:32.660 --> 37:33.560]  Any other questions?
[37:35.580 --> 37:35.940]  Okay.
[37:36.280 --> 37:37.540]  Thank you so much for your time.
[37:37.720 --> 37:41.560]  I'm sorry that I didn't get to give you a demo and it was kind of floppy.
[37:41.980 --> 37:43.640]  So thank you very much for your time.
[37:43.700 --> 37:44.540]  I really appreciate it.