[00:00.000 --> 00:00.880]  Good evening, everyone.
[00:02.000 --> 00:04.100]  It is Saturday, 1900, Area B.
[00:05.260 --> 00:09.020]  We're about to hear from Joe Salvatore Testa.
[00:19.240 --> 00:29.600]  I am a member of Hacktivismo, which is a human rights and technology group.
[00:29.600 --> 00:36.440]  Some of you might have seen me before today at 1pm when we released a big major piece of software called ScatterChat.
[00:36.620 --> 00:38.600]  I see some familiar faces.
[00:40.980 --> 00:44.460]  ScatterChat is a major project that I've been working on for a few years.
[00:44.860 --> 00:48.320]  And this presentation is a direct result of that.
[00:49.520 --> 00:51.200]  Constructing cryptographic protocols.
[00:54.590 --> 00:59.790]  In this talk, I'm going to show a very basic cryptographic protocol.
[00:59.830 --> 01:05.210]  And I'm going to iteratively build upon it through several rounds.
[01:05.210 --> 01:11.250]  I'm going to show at which round, what's wrong, and how to fix it.
[01:11.310 --> 01:18.090]  Until you build up to a final protocol which fulfills all these requirements which I'm going to show.
[01:21.700 --> 01:26.840]  For this presentation, you're going to need knowledge on basics of cryptography.
[01:27.580 --> 01:30.740]  Like what asymmetric and symmetric cryptography is.
[01:31.280 --> 01:36.380]  The general idea behind H-max, digital signatures, etc.
[01:36.840 --> 01:38.600]  You don't need a math background.
[01:39.080 --> 01:43.060]  But it would be good if you know, if you're familiar with mathematical notation.
[01:47.270 --> 01:54.690]  Alright, well, the protocol that I designed in the ScatterChat program is a one-to-one communications protocol.
[01:55.830 --> 01:58.950]  That means one person talking to exactly one other person.
[01:59.190 --> 02:04.270]  Does not mean the other option would be one-to-many or many-to-many.
[02:04.790 --> 02:08.650]  Like, for example, chat rooms would fit into that.
[02:09.050 --> 02:10.590]  Instant messages would be one-to-one.
[02:12.790 --> 02:20.250]  So this protocol that I designed has several advanced cryptographic features which I'm going to talk about and show and explain.
[02:21.510 --> 02:24.530]  And like I said, start with a basic protocol and build it up.
[02:26.710 --> 02:29.270]  But first, before we go to that, the requirements.
[02:29.770 --> 02:33.730]  Before you start designing anything, you have to understand where you're trying to go.
[02:34.030 --> 02:35.410]  What goals you're trying to meet.
[02:35.950 --> 02:38.790]  So these are the requirements for the protocol that I was designing.
[02:38.790 --> 02:43.630]  For one, it has to be secure against well-funded totalitarian governments.
[02:44.210 --> 02:53.970]  Those are the people that are looking to bust political dissidents, human rights activists operating in oppressive situations.
[02:55.470 --> 02:58.070]  So it has to be fairly strong.
[02:59.670 --> 03:03.190]  Two is that the passive peer cannot be probed.
[03:03.190 --> 03:09.310]  For the passive peer, I'm talking about the one peer that does not initiate the conversation.
[03:09.510 --> 03:10.410]  The one that's passive.
[03:10.790 --> 03:15.870]  The reason for that is that in some countries, cryptography is illegal.
[03:16.110 --> 03:17.290]  Just plain illegal.
[03:17.450 --> 03:18.510]  You use it, you go to jail.
[03:18.730 --> 03:21.490]  They immediately assume that you're doing something bad.
[03:22.710 --> 03:29.810]  So it would not be good if the protocol you design, you'd be able to send some kind of ping packet.
[03:30.450 --> 03:33.530]  And then your protocol automatically responds to it.
[03:34.230 --> 03:38.110]  Because that would give away the fact that you are capable of encryption.
[03:39.050 --> 03:40.350]  And then you get thrown in jail.
[03:41.310 --> 03:43.170]  So that has to be avoided.
[03:44.690 --> 03:47.050]  Next one is resistance to traffic analysis.
[03:47.450 --> 03:52.570]  I'm going to detail what traffic analysis is later on.
[03:53.730 --> 03:56.450]  Also has to be resilient against partial compromise.
[03:57.110 --> 04:12.570]  So for example, if one of the peers was arrested and had his place raided by, say, the Chinese government or the Saudi Arabian government, and that one side of the protocol was...
[04:12.570 --> 04:13.850]  Well, let me rephrase.
[04:14.030 --> 04:21.610]  If that person's key was compromised, then past conversations aren't also compromised.
[04:22.030 --> 04:26.150]  So it has to be partially resilient.
[04:26.830 --> 04:29.030]  It also has to allow file transfers.
[04:32.060 --> 04:34.780]  So some notation first, like I said.
[04:34.780 --> 04:43.420]  When I'm going to talk about asymmetric encryption and decryption at the top, I'm going to denote them like so.
[04:44.960 --> 05:01.520]  E subscript A underscore pub of M equals C says, public key encryption using A's key, A's public key of message M yields ciphertext C.
[05:03.340 --> 05:11.740]  Next to that, decryption using A's private key of the ciphertext equals M, the original message.
[05:12.500 --> 05:17.220]  And then symmetric encryption, decryption operations, I'm going to denote like that.
[05:17.760 --> 05:20.620]  Lowercase e with two arguments, K and M.
[05:20.760 --> 05:24.780]  K is going to be your shared key, M is the message, equals ciphertext.
[05:25.120 --> 05:26.400]  And likewise for D.
[05:30.870 --> 05:32.910]  Okay, so round one of the protocol.
[05:35.970 --> 05:43.950]  I'm going to stick with the tradition of using Alice and Bob as the two peers, as is the tradition in cryptographic protocols.
[05:46.550 --> 05:50.250]  The first, Alice needs to get the Bob's public key.
[05:50.650 --> 05:53.230]  We're going to start this off using public key crypto.
[05:54.550 --> 06:00.490]  So, Alice gets Bob's key somehow, either from Bob directly or from a server.
[06:01.110 --> 06:10.530]  From there, Alice calculates C1 by encrypting to Bob's public key, which she just downloaded somehow, M1.
[06:10.670 --> 06:15.350]  And then she transmits M1 across the wire over to the right to Bob.
[06:16.310 --> 06:18.870]  Bob can decrypt this because he has his private key.
[06:20.250 --> 06:25.110]  He decrypts C1, which is what he just read, to recover M1, which is the original message.
[06:25.290 --> 06:28.030]  So he can read what Alice just sent.
[06:34.440 --> 06:35.560]  Okay, there's...
[06:36.360 --> 06:40.400]  The one main problem with this, it does work for small messages.
[06:41.600 --> 06:43.600]  But for larger messages, it does not.
[06:43.600 --> 06:49.840]  The reason is because public key encryption is very, very slow.
[06:50.140 --> 06:53.620]  It's several orders of magnitude slower than symmetric encryption.
[06:53.860 --> 06:59.560]  You cannot use that in real time to encrypt large amounts of data.
[06:59.820 --> 07:04.640]  File transfers, large files cannot be encrypted with public key encryption.
[07:06.600 --> 07:08.980]  You can encrypt it with symmetric key.
[07:08.980 --> 07:14.260]  So what we're going to need, eventually, is a hybrid system, both.
[07:20.020 --> 07:20.980]  So here's round two.
[07:21.340 --> 07:22.500]  We'll build upon it.
[07:25.300 --> 07:28.680]  We have Alice first, calculating C0.
[07:30.860 --> 07:32.920]  She generates a random key K.
[07:33.160 --> 07:40.660]  Now, actually, I should mention, there's not enough room on all my slides to be very formal in all my definitions here.
[07:40.660 --> 07:45.060]  So I have to dictate, you know, what some of these figures mean.
[07:45.260 --> 07:49.560]  So she first generates a random key K, which we're going to use as a symmetric key.
[07:49.980 --> 07:53.520]  Like I said, you can use symmetric key to encrypt files.
[07:56.100 --> 07:57.580]  So we're going to have to use that.
[08:00.900 --> 08:04.920]  So we encrypt this random key K, call it C0.
[08:04.920 --> 08:13.900]  Alice also then takes that key and applies a symmetric cipher, E, to compute C1.
[08:14.160 --> 08:17.480]  And then she transmits C0 and C1 over to Bob.
[08:18.700 --> 08:25.860]  Bob recovers the key K using public key decryption on C0.
[08:25.860 --> 08:36.260]  So he recovers K, and then he uses symmetric decryption with that key K on C1 to obtain M1, the original message.
[08:37.460 --> 08:44.140]  And then if he wants to send a message back to Alice, he just computes, you know, encryption of that same key.
[08:44.260 --> 08:45.960]  He holds on to K for this session.
[08:47.740 --> 08:55.540]  The problem with this protocol, there is no integrity checking done on C1, which is the key.
[08:56.340 --> 08:58.620]  Ciphers cannot ensure integrity.
[08:59.020 --> 09:00.580]  They don't by design.
[09:02.770 --> 09:03.320]  Excuse me.
[09:04.460 --> 09:06.280]  They were not designed for that purpose.
[09:06.780 --> 09:10.140]  So the integrity of K is not ensured.
[09:11.380 --> 09:15.130]  File transfers are possible now because we are using symmetric key cryptography.
[09:16.080 --> 09:19.420]  And also notice, though, that Bob can't be probed.
[09:19.540 --> 09:22.760]  Bob doesn't necessarily have to respond in any way.
[09:24.120 --> 09:30.640]  So the passive peer can stay anonymous if he so chooses.
[09:37.890 --> 09:38.890]  So round three.
[09:39.230 --> 09:41.290]  I'm going to keep building this up, so I'm going to...
[09:41.290 --> 09:42.770]  Does that come out right?
[09:42.930 --> 09:43.850]  Yeah, you can see that.
[09:44.550 --> 09:46.630]  The green is what I'm going to be adding.
[09:47.270 --> 09:52.830]  I did it this way because these slides are going to get pretty messy from previous notes.
[09:53.650 --> 09:55.670]  So the green stuff is what I'm going to be adding.
[09:55.890 --> 09:57.410]  Red stuff is what I'm going to be taking away.
[09:59.310 --> 10:01.670]  So, there is no integrity on K.
[10:02.090 --> 10:03.410]  So we need to add some.
[10:04.430 --> 10:11.950]  Alice first calculates S0 by computing a digital signature with her private key on K.
[10:12.930 --> 10:14.950]  Of course, also, she has to generate K.
[10:16.770 --> 10:20.870]  She then encrypts K to Bob's public key to create C0.
[10:22.210 --> 10:26.610]  And then again, just as before, she encrypts M1 to create C1.
[10:28.130 --> 10:36.370]  She transmits all these three over C0, S0, which is a signature on C0, and then C1.
[10:37.810 --> 10:39.470]  Bob can recover the key K.
[10:40.530 --> 10:46.230]  He verifies with his public key, with A's public key, Alice's public key.
[10:48.050 --> 10:53.330]  He verifies the signature on K, and is guaranteed now that the integrity is valid.
[10:54.950 --> 10:56.590]  And then he can recover M1.
[10:56.890 --> 11:02.430]  Then later, if he wants to transmit his own message, he can compute the same thing that Alice did before.
[11:04.590 --> 11:08.170]  And also send along his own signature on that.
[11:15.310 --> 11:15.830]  Signature on...
[11:15.830 --> 11:16.330]  Signature on...
[11:21.140 --> 11:22.240]  Oh, I'm sorry.
[11:22.840 --> 11:23.700]  I'm sorry.
[11:24.000 --> 11:25.000]  Yeah, that's a mistake.
[11:25.380 --> 11:26.300]  There's no S1.
[11:27.400 --> 11:28.460]  Strike S1.
[11:29.100 --> 11:31.980]  I would prefer to take questions at the end, though.
[11:35.580 --> 11:37.020]  Unless there's another mistake.
[11:42.820 --> 11:43.860]  Okay, whoops.
[11:45.340 --> 11:46.120]  Round three.
[11:47.460 --> 11:52.100]  Okay, the problem with this, this protocol, round three, we're still on round three.
[11:52.580 --> 11:58.540]  The problem with this is that we're exposing a signature on K, which may leak some information.
[11:59.720 --> 12:01.540]  That's not a...
[12:02.380 --> 12:04.500]  It's not a solid vulnerability.
[12:04.700 --> 12:06.120]  It's just kind of...
[12:07.280 --> 12:14.100]  Not considered good practice, in my opinion, to expose a signature, especially if it's possible to hide that signature.
[12:14.100 --> 12:18.860]  You can have the same guarantee of integrity without exposing the signature.
[12:19.870 --> 12:22.600]  That is what I would call a proactive design.
[12:22.660 --> 12:25.140]  I'm a big proponent of proactive designs.
[12:25.830 --> 12:29.260]  And so I would maintain that S0 should be hidden.
[12:35.390 --> 12:45.710]  Okay, so to hide S0, we append it to the key K, and we hide it.
[12:47.190 --> 12:48.590]  We hide it by encrypting it.
[12:48.730 --> 12:49.270]  We encrypt it.
[12:49.730 --> 12:53.710]  That double pipe symbol denotes concatenation.
[12:55.030 --> 12:58.910]  What you do is just take a whole bunch of bytes, slap some other bytes at the end of it.
[12:59.170 --> 12:59.990]  That's concatenation.
[13:02.410 --> 13:02.890]  So...
[13:03.490 --> 13:10.330]  In this model, we're hiding the signature by concatenating it to key K, and encrypting all that.
[13:10.330 --> 13:13.630]  And now we don't need to send S0 anymore, as you can see.
[13:15.590 --> 13:19.750]  And also, notice that Bob can still easily recover this.
[13:19.970 --> 13:26.970]  He just decrypts C0, splits apart K and S0, runs a verification signature.
[13:27.290 --> 13:30.830]  From there, he can get the message, and then he can send his own...
[13:30.830 --> 13:32.450]  He can send his own messages.
[13:33.410 --> 13:33.970]  Cypher text.
[13:40.820 --> 13:41.460]  Oops.
[13:42.680 --> 13:43.160]  Okay.
[13:44.380 --> 13:46.340]  So, the signature is now protected.
[13:47.300 --> 13:51.100]  The problem with this, though, is that the messages are not signed.
[13:51.880 --> 13:55.620]  We just assured integrity on the keys, but not on the messages.
[14:00.840 --> 14:05.420]  We do this also, similarly, by signing M1.
[14:06.920 --> 14:09.100]  And, well, we were...
[14:09.100 --> 14:12.220]  I just made a point about hiding the signature, so why don't we do it again?
[14:12.220 --> 14:16.260]  We can hide it there, in C1, the signature on M.
[14:18.260 --> 14:19.920]  And we can encrypt all of that.
[14:21.220 --> 14:22.420]  So that...
[14:22.420 --> 14:26.600]  The signature on the messages also do not pass over the wire.
[14:30.090 --> 14:34.510]  And notice Bob can decrypt all of this and verify all of this.
[14:39.160 --> 14:40.660]  But the problem with this...
[14:41.580 --> 14:44.480]  This protocol is that we broke files...
[14:44.480 --> 14:45.800]  File transfers.
[14:46.480 --> 14:49.300]  Why did we break file transfers?
[14:50.460 --> 14:51.740]  Speaking of the mic, please.
[14:53.500 --> 14:57.120]  To encrypt message one with asymmetric encryption?
[14:57.700 --> 15:00.880]  Well, there is no asymmetric encryption going on.
[15:11.300 --> 15:15.060]  It might be hard to distinguish the signature from the file.
[15:16.860 --> 15:17.660]  No.
[15:20.740 --> 15:21.460]  I'll try.
[15:22.300 --> 15:27.340]  Because you can't begin decrypting the message until you get to the end of the entire file and recover the signature.
[15:29.240 --> 15:29.840]  No.
[15:30.200 --> 15:30.380]  Okay.
[15:32.620 --> 15:33.220]  Okay.
[15:33.600 --> 15:34.700]  The reason is...
[15:34.700 --> 15:36.180]  Do we have any last stabs at it?
[15:36.500 --> 15:36.640]  Okay.
[15:37.030 --> 15:40.860]  The reason is because digital signatures are also slow.
[15:41.700 --> 15:43.260]  We're using digital signatures there.
[15:44.030 --> 15:46.950]  Signatures on K and M1.
[15:46.940 --> 15:47.530]  Oh.
[15:47.840 --> 15:48.320]  M1.
[15:48.540 --> 15:49.740]  You said encryption.
[15:50.260 --> 15:50.960]  Sure, I...
[15:50.960 --> 15:51.460]  That's right.
[15:51.960 --> 15:52.800]  He was close.
[15:53.030 --> 15:54.960]  He said encryption, but it's signature.
[15:55.170 --> 15:57.440]  It's just as long as encrypting the whole thing as a message.
[15:59.080 --> 15:59.760]  I'm sorry?
[16:00.560 --> 16:03.120]  This would take just as long as encrypting the whole message.
[16:03.290 --> 16:03.580]  Yes.
[16:04.170 --> 16:04.640]  Signature...
[16:04.640 --> 16:05.170]  Signing...
[16:05.170 --> 16:05.860]  Well, it depends...
[16:05.860 --> 16:07.640]  It depends on the...
[16:07.640 --> 16:09.860]  Well, the question was signing...
[16:09.860 --> 16:12.300]  Does signing take as long as encrypting?
[16:13.140 --> 16:15.840]  It depends on the actual protocol in use.
[16:16.000 --> 16:18.260]  If you're using RSA, it's the same thing.
[16:18.840 --> 16:22.260]  Mathematically speaking, the algorithm is the same thing.
[16:22.380 --> 16:23.480]  You're just using different...
[16:23.480 --> 16:24.790]  Can't you just sign the hash?
[16:26.290 --> 16:27.530]  We're getting to this, guys.
[16:27.790 --> 16:28.040]  Come on.
[16:32.760 --> 16:33.220]  Okay.
[16:34.960 --> 16:35.560]  Next.
[16:37.740 --> 16:38.480]  All right.
[16:38.960 --> 16:41.320]  So, the problem was the digital signatures.
[16:41.540 --> 16:43.720]  So, we just replaced them with HMACs.
[16:43.940 --> 16:48.900]  HMAC function is the symmetric equivalent of digital signatures.
[16:49.180 --> 16:49.900]  It's the same thing.
[16:49.920 --> 16:51.900]  If you're interested in knowing how it's implemented.
[16:52.940 --> 16:59.540]  It is a hash function that mixes in the input with a key.
[17:00.980 --> 17:02.460]  So, that's really all it is.
[17:02.460 --> 17:04.580]  It's a secure hash algorithm.
[17:06.480 --> 17:07.520]  Common examples...
[17:07.520 --> 17:11.040]  You can use SHA-1, SHA-256, SHA-5-12.
[17:11.980 --> 17:13.580]  There's a specific way to do it.
[17:13.700 --> 17:15.440]  How to actually mix in your key.
[17:15.640 --> 17:16.460]  You can look this up.
[17:19.120 --> 17:20.540]  But actually, before that...
[17:21.860 --> 17:26.120]  Notice Alice in S0, she generates two keys.
[17:26.360 --> 17:27.480]  K1 and K2.
[17:28.220 --> 17:33.380]  The reason is that you want to use one key for encryption and one for integrity.
[17:33.780 --> 17:35.760]  You don't want to use the same key for that.
[17:37.220 --> 17:38.180]  I don't...
[17:38.180 --> 17:39.000]  Actually...
[17:39.000 --> 17:39.560]  I don't...
[17:39.560 --> 17:46.020]  I've never actually read any attacks that exist if you use the same key.
[17:46.200 --> 17:49.660]  But I believe it's just bad practice to do so.
[17:50.760 --> 17:51.720]  I mean, I can imagine...
[17:52.560 --> 17:56.500]  I mean, I kind of get that feeling that if you use the same key for both, that's a bad idea.
[18:01.340 --> 18:01.740]  Okay.
[18:01.960 --> 18:05.560]  So, and also notice on the right, Bob then just runs an HMAC check.
[18:05.800 --> 18:10.800]  In this case, like I said, it all revolves around a hash function.
[18:10.800 --> 18:19.020]  So, he just recomputes the hash and checks to see that it's what was sent.
[18:20.140 --> 18:25.800]  And that guarantees that the key and the message are both valid.
[18:27.240 --> 18:29.100]  That their integrity is assured.
[18:31.380 --> 18:37.860]  The problem with this round is that there is no perfect forward secrecy, which I'm going to define.
[18:39.020 --> 18:39.340]  Okay.
[18:42.080 --> 18:58.010]  If an adversary logs all the conversations, then obtains one peer's private key, say the Chinese government kicks down somebody's door, those conversations cannot be decrypted if perfect forward secrecy was in play.
[18:58.010 --> 18:59.770]  And I'll describe why.
[19:00.860 --> 19:03.010]  It all revolves around that equation right there.
[19:03.250 --> 19:05.290]  K equals K1 XOR K2.
[19:05.920 --> 19:16.690]  If each side, say, peer 1 and peer 2, generate a key, say, K1 and K2, then they exchange the keys.
[19:17.560 --> 19:18.730]  They trade them.
[19:18.860 --> 19:21.770]  So that both sides have K1 and K2.
[19:22.010 --> 19:25.450]  Then they can compute K with this equation.
[19:26.010 --> 19:28.360]  And notice they both come up with the same K.
[19:30.750 --> 19:32.820]  Then they throw away K1 and K2.
[19:33.080 --> 19:34.190]  They wipe it from memory.
[19:34.380 --> 19:35.380]  It's not needed anymore.
[19:35.600 --> 19:36.560]  We just derived K.
[19:37.250 --> 19:40.950]  We throw that away and we use K as an ephemeral session key.
[19:41.580 --> 19:44.580]  So we're going to use this key for one conversation only.
[19:50.530 --> 20:03.950]  So if the first peer, the private key was compromised, then K1 can be recovered, but K2 can't be.
[20:06.880 --> 20:13.000]  And if K2 can't be recovered, you just have K1, you can't compute K.
[20:13.000 --> 20:20.000]  If you can't compute K, you can't recover any of the saved messages.
[20:26.990 --> 20:29.010]  This is just the...
[20:31.390 --> 20:37.850]  So this is just the beginning part of the last protocol.
[20:39.750 --> 20:48.550]  We sign KE1, which is the first half of the encryption key.
[20:49.310 --> 20:53.790]  We sign KH1, which is the first half of the HMAC key.
[20:55.370 --> 20:56.550]  Encrypt all that.
[20:57.470 --> 20:59.630]  Encrypt the two halves and the signature.
[21:00.690 --> 21:02.710]  Transmit that ciphertext.
[21:02.710 --> 21:04.670]  Bob then does the same thing.
[21:04.810 --> 21:08.190]  That whole block, that block on the right, is just the same thing that Alice did.
[21:08.270 --> 21:09.150]  This is symmetric now.
[21:11.050 --> 21:12.990]  And so he shoots over C1.
[21:14.810 --> 21:17.550]  Then they decrypt as before.
[21:18.170 --> 21:22.730]  And they both compute that same equation before for both keys.
[21:24.230 --> 21:28.450]  So they both then have KE and KH.
[21:34.280 --> 21:37.360]  I'm just gonna pause for a second to let you guys look at it.
[21:48.950 --> 21:54.770]  Okay, so then just like before, if Alice then wants to transmit a message, she computes the HMAC.
[21:56.790 --> 22:02.310]  Then encrypts the message appended to the HMAC and sends that over.
[22:02.930 --> 22:04.050]  And likewise, Bob can do the same.
[22:06.390 --> 22:08.030]  Okay, so replay attacks.
[22:08.750 --> 22:13.070]  Replay attacks involve introducing encrypted blocks from previous conversations.
[22:13.350 --> 22:20.550]  Say you log a stream from before, pick out some blocks, and try to reintroduce them into a new stream.
[22:20.890 --> 22:28.230]  An attacker would want to do that for several reasons, to introduce errors into the stream, or to spoof messages.
[22:28.850 --> 22:32.430]  That can be pretty serious.
[22:34.090 --> 22:36.230]  Sometimes the blocks are known by the attacker.
[22:38.050 --> 22:43.390]  You can sometimes discern what they are through side-channel analysis, which I'm gonna get into.
[22:44.970 --> 22:47.030]  Or it could just be a random stat in the dark.
[22:47.530 --> 22:50.770]  Like, let's just try to get lucky and try to insert messages.
[22:53.870 --> 23:02.870]  They can be...replay attacks can be lethal against automated communication streams, so some kind of, you know, server-client program is just shooting data to each other.
[23:03.710 --> 23:04.970]  That can be pretty lethal.
[23:05.490 --> 23:07.770]  It's less urgent in real-time chat settings.
[23:08.330 --> 23:16.350]  I mean, imagine if you have a long instant messenger conversation, and all of a sudden, like, previous sections of sentences start appearing.
[23:17.490 --> 23:19.170]  Like, you know something's up.
[23:19.390 --> 23:20.670]  It's just not very normal.
[23:21.970 --> 23:24.390]  It's less urgent, but it's still a problem.
[23:28.480 --> 23:31.380]  So, how to immunize yourself against this attack.
[23:31.700 --> 23:34.440]  One way is to introduce a message counter.
[23:35.720 --> 23:44.140]  To encrypt a message, you have M, the signature, and append some kind of integer, a counter, which you keep on incrementing.
[23:46.020 --> 23:59.040]  The receiver also knows CTR, and can check, well, after I decrypt, does this message match the counter that I'm expecting?
[24:00.840 --> 24:11.980]  You do have to be careful with this method, because if you allow blocks coming in asynchronously, you need to handle that somehow.
[24:13.600 --> 24:15.880]  Otherwise, your stream is corrupt.
[24:20.200 --> 24:25.340]  Traffic analysis is studying the patterns of communications to derive extra information.
[24:25.760 --> 24:26.880]  Here's an example.
[24:27.100 --> 24:32.820]  Let's say in the 2004 election in Texas, you capture traffic from voting machines.
[24:34.000 --> 24:37.040]  The messages, you notice, contain repetitions.
[24:37.440 --> 24:40.400]  So, you tabulate these frequencies, and this is what you come up with.
[24:41.000 --> 24:44.420]  You have 80% of all the messages are encrypted.
[24:44.840 --> 24:47.940]  The encrypted messages come out to the following, that ciphertext.
[24:49.740 --> 24:53.820]  19%, and then you have 1% of that string right there.
[24:55.100 --> 25:04.100]  Now, knowing the context here, 2004, Texas, what do you think that 80% is?
[25:04.800 --> 25:08.200]  You can look at the... you can analyze this in a couple ways.
[25:08.840 --> 25:15.400]  The first thing is that 80% of something tells you a little bit of information.
[25:15.820 --> 25:19.340]  To the length of that ciphertext four letters long.
[25:20.280 --> 25:21.540]  That's some information.
[25:24.300 --> 25:29.540]  Next, that middle ciphertext is five letters long, and the last one is five letters long.
[25:29.860 --> 25:32.280]  So, you assume, okay, the top one is bush.
[25:32.720 --> 25:34.100]  The second one is carry.
[25:34.940 --> 25:37.240]  Anyone want to guess what that 1% might be?
[25:37.620 --> 25:38.040]  Nader.
[25:38.640 --> 25:39.440]  All right.
[25:39.860 --> 25:40.340]  Nader.
[25:40.620 --> 25:40.980]  Yes.
[25:42.180 --> 25:43.500]  He's my hero, by the way.
[25:46.320 --> 25:46.800]  Yes.
[25:47.120 --> 25:47.800]  So, there you go.
[25:47.840 --> 25:50.080]  Here's an example of traffic analysis.
[25:53.680 --> 25:58.960]  A point that I want to mention is that it's very dependent upon the context that's within.
[25:59.360 --> 26:08.780]  If I just give you that tabulation, those frequencies, without telling you where it's from, what time it is, etc., that doesn't mean anything.
[26:12.730 --> 26:16.460]  So, to resist against this, traffic analysis can't be thwarted.
[26:16.930 --> 26:19.870]  It's very, very difficult to thwart against traffic analysis.
[26:19.870 --> 26:24.510]  But you can introduce some resistance to it, and I'll show you how.
[26:26.610 --> 26:29.710]  First is to obfuscate the message length.
[26:29.730 --> 26:34.330]  Like I said before, or like you saw before, you can count the ciphertext length.
[26:34.510 --> 26:35.650]  That can give you some information.
[26:35.910 --> 26:37.370]  So, you can do some padding.
[26:37.770 --> 26:42.730]  You can align the ciphertext up to some block.
[26:44.170 --> 26:46.330]  What is a good alignment?
[26:47.190 --> 26:48.250]  That's undefined.
[26:49.290 --> 26:54.970]  If you make it too large, like let's say you align everything to something ridiculous, like one megabyte.
[26:55.430 --> 27:00.030]  So that means every single message you send ends up getting padded up to one megabyte.
[27:00.210 --> 27:01.410]  You're wasting a lot of space.
[27:02.170 --> 27:05.470]  You might be hiding the true length.
[27:05.670 --> 27:08.150]  Like you can hide lots of lengths within that one megabyte.
[27:08.350 --> 27:10.950]  Your message could be three bytes long.
[27:11.090 --> 27:12.010]  It could be a kilobyte.
[27:12.090 --> 27:13.110]  It could be 10k.
[27:15.670 --> 27:18.230]  But the downside is that you're wasting space.
[27:18.390 --> 27:20.510]  On average, you're wasting a half meg.
[27:23.830 --> 27:29.530]  On the other side, if you make it too small, align to say four bytes, you can't really hide too many messages within there.
[27:33.310 --> 27:38.810]  I don't really have a good way to suggest how to calculate alignments.
[27:39.910 --> 27:43.450]  It's just kind of something that you guess at, I think.
[27:48.040 --> 27:56.920]  Also, to protect against message repetition analysis, which was a problem in the previous example, you can mix in random data into the cipher input.
[27:57.840 --> 28:03.180]  As you see there, you take your message M and you slam on some random bytes.
[28:03.920 --> 28:07.160]  Your resulting C is going to be different every time.
[28:07.320 --> 28:16.260]  If you encrypt M, the same M, three times, the C is going to be different every single time because you just encrypted random data.
[28:16.620 --> 28:17.660]  You mixed some in.
[28:19.880 --> 28:25.340]  And you don't tend to want to just append random data towards the end.
[28:25.540 --> 28:28.500]  You probably want to sprinkle it in, just so you know.
[28:33.790 --> 28:39.110]  Yes, so that was the design methodology that went behind my program.
[28:39.330 --> 28:41.170]  My project called ScatterChat.
[28:41.710 --> 28:43.470]  It implements all these features.
[28:44.070 --> 28:46.830]  Just a little, a quick announcement about it.
[28:46.830 --> 28:52.730]  It's a hacktivist application that enables encryption and preserves anonymity over instant messaging networks.
[28:53.170 --> 28:55.210]  You can get it at scatterchat.com.
[28:55.330 --> 28:58.050]  I just did a really big presentation on it before at one.
[28:58.230 --> 29:00.290]  We had some CDs, but I think we're out of them now.
[29:03.310 --> 29:04.010]  Any questions?
[29:07.980 --> 29:09.140]  Could you step up to the mic?
[29:11.840 --> 29:19.360]  Yeah, when you had the XOR to do the two keys together and then produce a third key, does that really solve the same problem as, like, Diffie-Hellman key exchange?
[29:19.620 --> 29:21.000]  I mean, isn't that what that's used for?
[29:21.180 --> 29:21.840]  Yes, yeah.
[29:21.960 --> 29:23.960]  Why not have used that because it's a standard?
[29:24.320 --> 29:26.040]  I mean, that's probably more complicated.
[29:26.320 --> 29:28.440]  It's not just an XOR, but...
[29:29.280 --> 29:32.840]  I mean, it depends on what situation you want to use it in.
[29:33.680 --> 29:37.500]  Yeah, the Diffie-Hellman algorithm does provide the same.
[29:37.500 --> 29:40.920]  But is, I mean, I know that's much more complicated.
[29:40.920 --> 29:45.700]  So is there a reason you would do that instead of just XOR two things together, which obviously is much simpler?
[29:47.300 --> 29:49.420]  It's called modular translation, right?
[29:50.160 --> 29:51.960]  That's a good question.
[29:52.240 --> 29:56.040]  I am having trouble coming up with an example.
[29:56.320 --> 30:02.080]  I do know that I am switching to Diffie-Hellman myself, so I know that...
[30:02.080 --> 30:03.140]  So it's not that bad, I guess.
[30:03.200 --> 30:05.260]  No, no, you can replace it back in.
[30:05.260 --> 30:07.180]  The second version of the protocol...
[30:09.160 --> 30:12.100]  I'm actually switching to elliptic curve cryptography.
[30:12.660 --> 30:13.540]  Which is very sexy.
[30:17.900 --> 30:18.420]  Patented?
[30:18.600 --> 30:19.540]  No, it's not patented.
[30:22.480 --> 30:23.520]  It's not patented.
[30:23.620 --> 30:28.040]  There's a lot of patents in elliptic curve cryptography, but that algorithm itself is not patented.
[30:29.160 --> 30:34.280]  What do you plan on doing about the keys getting swapped to disk before they get erased?
[30:36.740 --> 30:38.420]  If the keys get swapped to memory?
[30:38.620 --> 30:39.800]  If the K1 and K2.
[30:39.940 --> 30:41.860]  The one that you're supposed to throw away and never record.
[30:42.120 --> 30:43.140]  How would it happen if it gets swapped?
[30:43.880 --> 30:45.280]  To the swap to the disk.
[30:46.360 --> 30:47.140]  If it gets...
[30:48.720 --> 30:50.500]  I mean, that's an operating system issue.
[30:51.020 --> 30:54.120]  So you're just going to have to say, if you really care, you're going to have to encrypt swap?
[30:55.580 --> 30:56.340]  That's an option.
[30:56.500 --> 30:58.880]  Or you use some kind of secure memory library.
[31:03.260 --> 31:04.060]  That's a...
[31:05.020 --> 31:13.140]  If you had to use a premade algorithm or premade current protocol such as SSL, what would your current favorite be?
[31:13.240 --> 31:15.300]  If you didn't want to go through the trouble of creating your own?
[31:15.900 --> 31:17.200]  I'm sorry, could you rephrase that?
[31:17.320 --> 31:18.280]  If you wanted to create your...
[31:18.280 --> 31:25.220]  If you wanted to use a premade cryptographic system for key negotiation and such, what would your current favorite be?
[31:31.820 --> 31:32.980]  I mean, besides my own?
[31:33.080 --> 31:33.820]  Because I mean, I made my own.
[31:34.040 --> 31:36.280]  Yeah, like if you didn't want to use...
[31:42.590 --> 31:43.750]  Well, give me some options.
[31:44.210 --> 31:48.510]  Like SSL would be one, kind of.
[31:50.630 --> 31:52.910]  Or NTLM, which is on pretty much every Windows computer.
[31:53.770 --> 31:56.930]  Yeah, I don't really know the details of those.
[31:57.530 --> 31:58.270]  I'm sorry.
[31:58.470 --> 32:00.590]  Like I can't really come up with one.
[32:07.480 --> 32:11.800]  In your algorithm towards the end, you introduced an exchange algorithm.
[32:12.240 --> 32:15.200]  And that happens before the message is sent.
[32:15.420 --> 32:17.000]  And it's a compulsory response.
[32:17.460 --> 32:20.380]  Does that break one of your...
[32:22.560 --> 32:23.880]  Your China thing?
[32:25.160 --> 32:26.200]  My China thing.
[32:27.960 --> 32:29.380]  Yeah, I didn't go into...
[32:29.900 --> 32:32.880]  I wasn't as verbose on that as I should have.
[32:32.880 --> 32:37.600]  Like through the protocols, I only had so much space on my slides.
[32:37.600 --> 32:43.000]  But the receiving peer does not necessarily need to respond.
[32:43.420 --> 32:45.420]  When the initial...
[32:45.420 --> 32:48.180]  They know who the sender is before they negotiate?
[32:48.460 --> 32:49.840]  The sender...
[32:50.320 --> 32:58.900]  When the sender sends the initial message, the receiver can check the signature on that.
[32:58.900 --> 33:02.560]  And then decide, well, if it's broken, I'm not going to respond to you.
[33:03.400 --> 33:06.720]  Or if it's not broken, let's leave it up to the user.
[33:07.670 --> 33:12.260]  Like display a key hash, say this person is trying to initiate a conversation with you.
[33:12.340 --> 33:13.080]  Do you want to accept?
[33:13.200 --> 33:13.680]  Yes or no.
[33:14.200 --> 33:18.220]  You could also then roll in PKI into this.
[33:18.920 --> 33:21.720]  So that can complicate things a little bit more.
[33:21.920 --> 33:29.560]  So you can have, you know, if it automatically authenticates through a PKI structure, then you can respond.
[33:29.800 --> 33:30.360]  It's safe to respond.
[33:30.460 --> 33:33.980]  You can have like user settings for all this, depending on how paranoid you are.
[33:34.640 --> 33:40.040]  But the bottom line is that the protocol can support this.
[33:40.040 --> 33:42.420]  And also, does it support deniability?
[33:42.620 --> 33:45.100]  And how is this related to off the record?
[33:45.340 --> 33:47.200]  Which is obviously on everyone's mind right now.
[33:48.080 --> 33:48.320]  Yes.
[33:50.840 --> 33:51.280]  OTR.
[33:52.220 --> 33:53.600]  The OTR question.
[33:55.020 --> 33:57.300]  I was hoping that nobody was going to ask this.
[33:58.480 --> 34:03.100]  Because that was like the one thing that I had on my big to-do list that I never got to.
[34:03.260 --> 34:08.960]  And I have the documentation here that said, look at this stuff, because somebody's going to ask you about this.
[34:10.040 --> 34:11.890]  And I didn't have time to look at it.
[34:12.390 --> 34:13.620]  So the only thing that...
[34:13.620 --> 34:18.500]  Give me like five minutes after this presentation, I'm going to look at my notes like I should have beforehand.
[34:18.800 --> 34:19.910]  And I'll answer this question.
[34:20.180 --> 34:21.020]  I can tell you the difference.
[34:22.640 --> 34:23.000]  Okay.
[34:23.410 --> 34:23.520]  All right.
[34:23.850 --> 34:24.260]  I'm Paul.
[34:24.410 --> 34:25.960]  I'm somewhat involved with the OTR project.
[34:26.260 --> 34:26.460]  Oh, all right.
[34:26.580 --> 34:26.760]  Great.
[34:28.060 --> 34:34.000]  The difference between what you're doing, of course, is that you're sending signatures with every message.
[34:34.480 --> 34:37.320]  So it's hard to repute the fact that you've talked to each other.
[34:37.320 --> 34:46.280]  So if the two of us have talked to each other, and I have the Chinese government in my neck, and you still keep talking to me, then the Chinese government has proved that you've actually talked to me.
[34:46.910 --> 34:48.180]  You've signed messages.
[34:49.260 --> 34:58.240]  OTR uses a Diffie element key exchange, and then leaks out part of the Mac later on, which means that people can force messages, but only in the past.
[34:59.060 --> 35:03.260]  which means that even if I'm compromised, you are not.
[35:05.500 --> 35:14.890]  Of course, the problem with OTR for you is that you're doing a Diffie-Hellman key exchange all the time, which is expensive, which works for IM, but not for file transfers.
[35:15.390 --> 35:25.020]  But it wouldn't be too hard to change the protocol to add a session key generation to it, for which you will then encrypt a symmetric encryption for a file.
[35:25.240 --> 35:25.480]  Yeah.
[35:25.560 --> 35:27.060]  So I would definitely look into OTR.
[35:27.600 --> 35:27.890]  Yeah.
[35:28.020 --> 35:32.600]  It's been done by people who studied at Berkeley, who are now professors at universities.
[35:33.040 --> 35:33.140]  Yeah.
[35:33.280 --> 35:38.760]  I know AT&T has had some people look at it and not really find any problems with it.
[35:39.140 --> 35:40.950]  Cryptography is hard to do all by yourself.
[35:41.450 --> 35:41.540]  Yeah.
[35:41.540 --> 35:46.960]  I don't recommend trusting, you know, a one-person crypto system.
[35:46.960 --> 35:50.180]  And that's not because it's you, anybody, who would stand there.
[35:50.300 --> 35:51.060]  I would say the same thing.
[35:51.240 --> 35:51.350]  Yeah.
[35:51.640 --> 35:52.320]  I understand that.
[35:52.450 --> 35:52.520]  Yeah.
[35:54.450 --> 36:00.450]  The OTR's message deniability functionality can be rolled into this quite easily because I'm using Hmax.
[36:01.930 --> 36:03.640]  It's pretty easy to roll into it.
[36:05.240 --> 36:07.560]  So that's actually, that's partially correct.
[36:07.800 --> 36:09.960]  There was a big problem that's covered with OTR.
[36:10.280 --> 36:10.870]  Yeah, version 1.
[36:10.870 --> 36:11.370]  That's now fixed.
[36:12.040 --> 36:16.540]  In only protocol version 1, there was a leakage, but in version 2...
[36:16.540 --> 36:16.680]  Right.
[36:16.760 --> 36:19.810]  I mean, it's been since fixed, but the original version of OTR had a problem.
[36:20.000 --> 36:20.140]  Yeah.
[36:21.340 --> 36:22.790]  So, I'm sorry, can you actually...
[36:22.790 --> 36:26.550]  So, did you do your signing for messages with session keys or with...
[36:27.370 --> 36:28.290]  What was the first part?
[36:28.950 --> 36:31.980]  When you sign your messages, I'm actually forgetting.
[36:32.230 --> 36:37.430]  When you do the signing of the messages, do you do it with a session key or is it the more longer-lasting key?
[36:38.380 --> 36:41.960]  Sign the session key with the long-term signing key.
[36:42.430 --> 36:42.580]  Okay.
[36:42.750 --> 36:42.910]  So, yeah.
[36:43.020 --> 36:43.310]  So, that's it.
[36:43.310 --> 36:51.410]  The question I actually had is, if you're worried about traffic analysis, why not use an approach like winnowing and chafing to do...
[36:51.410 --> 37:00.330]  Basically, to send just things that to an eavesdropper will look like actual messages, but that, you know, will get dropped on your ends because you know that they're not actually coming from the person you're talking to.
[37:02.290 --> 37:02.680]  Sure.
[37:03.870 --> 37:08.310]  No, I mean, it sounded like you made it... you made it sound like a more difficult problem than I think it is.
[37:09.700 --> 37:10.140]  Sorry.
[37:17.200 --> 37:18.260]  Any last questions?
[37:19.580 --> 37:20.900]  Just one real quick one.
[37:20.900 --> 37:31.180]  I'm not familiar with the laws in China or any other country that has encryption things in place, but would the pulling down of a public key indicate that you're using encryption?
[37:32.740 --> 37:35.580]  And, I mean, or is the law just maybe not covering that area?
[37:36.520 --> 37:43.580]  Yeah, I wish my friend was here, he'd know this answer.
[37:43.780 --> 37:49.340]  I don't know the laws there, but the technical question is, does seeing the key...
[37:49.340 --> 37:51.520]  Well, how do you hide the key?
[37:52.780 --> 37:53.400]  Steganography.
[37:54.440 --> 37:55.900]  Yeah, we're just banned random.
[37:57.480 --> 38:02.000]  Well, I may not be understanding something pretty essential.
[38:02.000 --> 38:19.660]  When you said that you prefer to send a fixed word length with data scattered through it, the fact that you have separate ones of these of exactly the same length, isn't that a kind of something to bring these messages together?
[38:20.420 --> 38:22.360]  Unless I'm misunderstanding...
[38:22.360 --> 38:28.820]  Will the eavesdropper be able to see, yes, that all the messages are the same, so they know that some padding is being done?
[38:28.820 --> 38:32.580]  I mean, that's assumed that that's public, the design of the system.
[38:39.110 --> 38:39.810]  All right.
[38:40.330 --> 38:41.150]  Thank you.
[38:50.650 --> 38:55.710]  If you integrate scatter chat with more, are you going to talk about that part of the system?