WEBVTT 00:00.000 --> 00:12.400 I have your speaker was going to talk about building privacy infrastructure and the day 00:12.400 --> 00:16.880 we are living in, especially the year 2021-25, privacy is becoming a big issue, you have 00:16.880 --> 00:23.840 seen it around for them, even Mozilla is handing out cookies here, we're all into privacy 00:23.840 --> 00:29.440 violations, tracking and the political world is not getting much better, so I have 00:29.440 --> 00:36.080 Ava here was going to tell you how to build privacy infrastructure using the amazing language 00:36.080 --> 00:38.840 called Go, applause. 00:38.840 --> 00:44.840 Hello, can you hear me? 00:44.840 --> 00:51.880 It's a good, okay, awesome, I'm ever infilled, I'm a mathematician and I used to be an academic 00:51.880 --> 00:59.360 mathematician, but now I'm building privacy software, which is a lot more fun and important. 00:59.360 --> 01:07.400 So let's talk about it, so this is more or less what I'm going to go over, so for some 01:07.400 --> 01:16.600 motivation, the context of today's surveillance world, which is incredibly pervasive and requires 01:16.600 --> 01:24.760 thinking about a lot of different factors, and then hope, because it is not completely hopeless. 01:24.760 --> 01:28.800 So I'm going to tell you about how we're trying to address it, and then I'm going to tell 01:28.800 --> 01:34.960 you that we need some help and there are some tasks that we could actually compensate 01:34.960 --> 01:43.840 contributors for that are funded, so I'm just going to quickly go over those, and hopefully 01:43.840 --> 01:49.760 you can talk to me about that, and you could also look at this project as a codebase that 01:49.760 --> 01:56.080 has some tools that you could potentially use, these are currently mostly cryptotools and 01:56.080 --> 02:01.080 networking tools, but we're also going to be building some audio signal processing stuff that's 02:01.080 --> 02:07.440 going to be very cool, so we're going to dive into that a little bit too. 02:07.440 --> 02:13.480 The slides I was trying to make comprehensive don't worry about reading everything on them 02:13.480 --> 02:18.320 if they are too dense, it's because we're going to have a video I'm just making the 02:18.320 --> 02:22.680 slides thinking about people who are going to be watching the video and can pause it to 02:22.680 --> 02:23.680 be the slide. 02:23.680 --> 02:26.680 All right, so let's do it. 02:26.680 --> 02:30.520 Okay, so first of all, surveillance. 02:30.520 --> 02:39.400 We live in the world of incredibly powerful surveillance, it's everywhere, the adversaries are 02:39.400 --> 02:48.560 incredibly powerful, and because without privacy, we have a much smaller chance of addressing 02:48.560 --> 02:55.200 the world's problems which are immense and getting worse by the day, so let's talk about 02:55.200 --> 03:01.200 what our adversaries can actually do and what we're going to have to build for, so we have 03:01.200 --> 03:07.760 adversaries that are global, so they see a significant part of the connections on the internet. 03:07.760 --> 03:14.240 This is mostly a concern for statistical analysis, although for statistical analysis, it's 03:14.240 --> 03:19.640 actually enough if your adversary can just see two ends of a connection, it doesn't actually 03:19.640 --> 03:30.520 have to be a global adversary, which means this is a problem for a much wider range of situations. 03:30.520 --> 03:35.600 We are also thinking about people who can take over parts of the network, so if you're 03:35.680 --> 03:42.960 using relays the way torque project does, for example, you want to have a lot of them, in 03:42.960 --> 03:49.560 case the adversary takes some over, we're also thinking about people who can take over your 03:49.560 --> 03:56.760 friends' devices, so we're trying to give you some deniability if someone takes over 03:56.760 --> 04:00.320 your contact. 04:00.320 --> 04:06.200 Also, we're talking about adversaries who have a lot of computational power and can 04:06.200 --> 04:12.400 do frontier cryptanalysis and might at some point soon have quantum computers, so we really 04:12.400 --> 04:20.840 want to have solid top-notch cryptography that can do as best as possible in those situations. 04:20.840 --> 04:28.280 And surveillance actors today have incredible amount of context about all of us, right? 04:28.280 --> 04:35.280 Because there's all kinds of information about every physical person that's out there. 04:35.280 --> 04:40.480 And it's pretty clear what kind of adversaries I'm talking about here, right? 04:40.480 --> 04:46.200 The canonical example is the NSA, but it could be a bunch of other actors, it could be Google, 04:46.200 --> 04:51.120 it could be Apple, it could be some other intelligent service from some other country, 04:51.120 --> 04:58.240 it could be another powerful organization's organization, and the, okay, so we're 04:58.320 --> 05:03.440 so for an adversary that's global active sophisticated and has context, I guess I am still 05:03.440 --> 05:11.040 worth shopping the algorithm, because maybe it shouldn't be gashed, but at least that's memorable. 05:11.040 --> 05:18.480 So, it's, all right, so let's go. 05:18.480 --> 05:25.160 So here's an example, all right, so this is beyond the threat model of leading anonymity systems. 05:25.160 --> 05:31.960 Like this is actually kind of an understatement because there is no system today that can deal 05:31.960 --> 05:35.560 with all of that. 05:35.560 --> 05:39.560 There's, there's always, you know, this is just too powerful. 05:39.560 --> 05:47.000 So here's an example, Tor is awesome, it does a lot of things incredibly well, but it cannot 05:47.000 --> 05:51.360 protect you if someone sees two ends of a connection, right? 05:51.360 --> 05:57.040 So if it sees you and it sees the server you're connecting to inside and outside the network, 05:57.040 --> 06:01.920 it can see the properties of the connection that make it easy to correlate, or it can 06:01.920 --> 06:07.040 see disruptions in the network on one side and the other, it's just not going to protect 06:07.040 --> 06:14.320 you from that, but it does other things very, very well, so, you know, they're awesome. 06:14.320 --> 06:20.400 Obviously VPNs do even less, because you only need to watch the VPN and the incoming 06:20.400 --> 06:26.400 and outgoing connections to see the same kind of properties. 06:26.400 --> 06:31.440 So we need something a lot more powerful than all of these things. 06:31.440 --> 06:37.080 All right, so what do we actually need to do? 06:37.080 --> 06:41.320 We need to show nothing, okay? 06:41.320 --> 06:45.840 We're actually pretty good at protecting content of a connection, because we need to encrypt 06:45.840 --> 06:49.880 the content, the problem is metadata. 06:49.880 --> 06:54.920 The problem with metadata is, you know, stuff like who's talking to whom, when, how big 06:54.920 --> 06:56.880 the packet is. 06:56.880 --> 07:02.120 The problem with that is even the slightest amount of information will eventually become 07:02.120 --> 07:03.840 deadly. 07:03.840 --> 07:09.880 So for, you know, if you, if you have two people talking to each other and say they're 07:09.880 --> 07:14.440 going to be online at the same time with, I don't know, probability 50 percent, if they're 07:14.440 --> 07:19.080 not friends and 51 percent if they are friends, then if you watch them for long enough, 07:19.120 --> 07:24.120 you can always tell the difference between the 50 percent and the 51 percent, right? 07:24.120 --> 07:30.120 So this is, so you have to give up nothing. 07:30.120 --> 07:34.880 And there are some things that just not addressable, because your users are human, and 07:34.880 --> 07:38.320 they will never have a perfect behavior, right? 07:38.320 --> 07:46.240 But there are things what you can do is you can make sure that a user that is aware and 07:46.240 --> 07:51.000 does everything right can protect themselves. 07:51.000 --> 07:55.000 All right. 07:55.000 --> 07:59.320 So here's the, here's the hope, here's how we're trying to do it. 07:59.320 --> 08:01.120 So first of all, your connection. 08:01.120 --> 08:05.080 So the whole system is a mix network. 08:05.080 --> 08:09.360 So if you're, if you're aware of how tour works, it's a little like that, also bouncing 08:09.360 --> 08:15.920 things around and trying to make sure things get mixed with each other. 08:16.840 --> 08:20.960 Except every connection looks the same. 08:20.960 --> 08:22.760 The backups are the same size. 08:22.760 --> 08:29.640 They're being sent and received, no matter if you actually need to send or receive something. 08:29.640 --> 08:35.600 And they're also staying in each relay for a while to make sure that when they, 08:35.600 --> 08:40.000 that you can't correlate the incoming and outgoing times. 08:40.000 --> 08:44.000 And these, there's a probabilistic amount of time that they're staying in the 08:44.000 --> 08:46.160 relay for. 08:46.160 --> 08:53.520 So the way also we're doing this is we're trying to make every interaction with a server, 08:53.520 --> 08:57.280 which is on the other side of the network, the, the node you're connecting to doesn't 08:57.280 --> 09:00.520 know anything about you except that you're connected. 09:00.520 --> 09:04.120 And every interaction is bounce. 09:04.120 --> 09:09.360 So it doesn't, it's impossible to tell if you're sending or receiving. 09:14.400 --> 09:19.520 We're also trying to make sure your contacts don't know anything about you other than 09:19.520 --> 09:23.440 what you tell them that you know that you're telling them. 09:23.440 --> 09:29.920 And also because we don't want the disturbance in the network to be visible on the 09:29.920 --> 09:33.680 other side, we don't want any forced interactivity. 09:33.680 --> 09:41.040 So for example, it will be impossible to do better than tour and have functionality of 09:41.120 --> 09:44.560 browsing the internet comfortably as just impossible. 09:44.560 --> 09:47.280 Not going to happen. 09:47.280 --> 09:50.800 All right. 09:50.800 --> 09:55.520 So you can find out more in a paper that we just released. 09:55.520 --> 09:58.480 There's very cool stuff. 09:58.480 --> 10:03.440 There's new crypto protocols for messaging that we're very proud of. 10:03.440 --> 10:07.760 There's mathematical analysis of everything I just told you. 10:07.760 --> 10:12.720 And also we might be renaming the project to echo mix because we're getting feedback that 10:12.720 --> 10:15.200 cuts and posts us to complicate it and to German. 10:18.160 --> 10:19.920 That might happen in the future. 10:21.200 --> 10:21.600 All right. 10:21.600 --> 10:24.400 So let's, let's go to some more practical stuff. 10:25.200 --> 10:27.280 So we have some funded tasks. 10:28.560 --> 10:32.720 Thanks to director Grants from Anonet and Bohalen Stiftung, 10:33.680 --> 10:35.840 which you could potentially help us with. 10:35.840 --> 10:36.800 This is all in go. 10:39.040 --> 10:44.160 And these are things that we could in the short future compensate you for. 10:45.040 --> 10:50.640 So we are implementing cryptographic protocols of various kinds. 10:50.640 --> 10:55.120 We're trying to take the code base, which at this point is quite robust. 10:55.120 --> 11:01.200 And we're trying to make it more usable for other projects to take other tools. 11:02.880 --> 11:04.800 And plug them into places. 11:05.760 --> 11:10.480 And also we actually have a messenger that works, but it's not very good. 11:11.520 --> 11:12.880 So we're trying to make it good. 11:12.880 --> 11:16.080 We're adding audio functionality. 11:17.200 --> 11:22.960 We're doing a bunch of big behind the scenes, things, adding attachments, 11:22.960 --> 11:23.840 this kind of thing. 11:23.840 --> 11:26.240 And we have that kind of stuff funded. 11:26.800 --> 11:31.840 And in the long term, we would also, we will be seeking funding, 11:31.840 --> 11:34.000 which we have some hope for. 11:34.000 --> 11:35.200 It's probably going to happen. 11:36.240 --> 11:38.640 To first of all, audit the code. 11:40.000 --> 11:43.360 Because, okay, so I work with the kind of hackers that broke 11:43.360 --> 11:46.000 every other system, and they're watching each other very closely. 11:46.000 --> 11:49.440 But we don't formally have external audits yet. 11:51.040 --> 11:56.320 Then we also want to make it even easier to use the software. 11:56.320 --> 12:01.520 We want to be able to make it very easy to set up your own form 12:01.680 --> 12:05.200 of the network for like an organization, if you need to do it. 12:05.200 --> 12:07.360 It's technically already possible. 12:07.360 --> 12:09.120 It's just incredibly complicated. 12:10.880 --> 12:13.040 And there's a lot of work to be done to make it easier. 12:15.040 --> 12:19.920 Then we would like it to make it easier to connect to a mixed network 12:19.920 --> 12:25.120 instance that we're running with your applications, which we're actually, 12:25.120 --> 12:28.320 you know, it's currently in Go, we're also making interfaces for other, 12:28.960 --> 12:32.640 for other languages as well. 12:34.480 --> 12:38.240 We want to make the messenger a lot more usable. 12:39.360 --> 12:50.320 And then we have a pretty dynamic research program that is my part, actually. 12:51.840 --> 12:53.200 That's full of fun stuff. 12:53.280 --> 12:58.240 All right, so let's talk about some of the code. 12:58.240 --> 13:01.600 So if you go to our repository, which is, um, 13:01.600 --> 13:05.520 get help slash cats and posts, there's, um, one of the 13:05.520 --> 13:10.560 repose subrepose there is the HPQC hybrid post quantum cryptography library. 13:11.440 --> 13:15.440 And if we're talking about, you know, if we're thinking about 13:15.440 --> 13:17.760 adversaries that might soon have quantum computers, 13:18.960 --> 13:21.600 the cryptography that's resistant to that 13:21.680 --> 13:24.480 is not the same cryptography that we've been using for decades. 13:25.360 --> 13:30.720 Although the cryptography that we've been using for decades has a lot of advantages, 13:31.760 --> 13:34.800 which is a lot of people try to break it and no one managed to do it. 13:35.520 --> 13:42.320 So what you actually would like ideally is to use hybrid encryption, 13:42.320 --> 13:44.320 so you're doing basically both, right? 13:44.320 --> 13:48.080 So you're encrypting it classically and then you're encrypting it in a way that's, 13:48.080 --> 13:50.320 that we think is resistant to quantum computers. 13:52.320 --> 13:56.640 Um, there are sort of three types of things in this library, 13:56.640 --> 14:01.920 um, which, um, you know, are all, um, 14:01.920 --> 14:06.000 available to use. So there's, there's quantum signatures, 14:06.000 --> 14:10.240 there's, there's both classical and, there's both classical and post quantum 14:10.240 --> 14:13.600 signature primitives. Um, there, um, 14:13.600 --> 14:18.560 non-interactive key exchange primitives is sort of what you usually think of 14:18.560 --> 14:22.480 public key cryptography, um, like sort of, you know, like, 14:22.480 --> 14:25.120 diffi-helmon-style cryptography. 14:25.120 --> 14:30.080 And then key encapsulation mechanisms are a ways to, um, 14:30.080 --> 14:35.040 when, in some sense, you can take those and turn them into 14:35.040 --> 14:40.960 chem algorithms and give them extra properties and make, um, 14:40.960 --> 14:46.160 and make, in some sense, that gives them additional resistance, but also, 14:46.240 --> 14:49.040 it requires more interaction. 14:49.040 --> 14:53.360 So this is a list of primitives that's incomplete, but it's for future 14:53.360 --> 14:58.880 reference and not going to go, uh, go through the whole thing, uh, 14:58.880 --> 15:04.880 but if someone, if someone wants to go through that library and use it, 15:04.880 --> 15:10.000 then these are, are available. Oh, sorry. 15:10.000 --> 15:14.240 Um, and example code, this is just a simple example. It doesn't actually 15:14.320 --> 15:21.840 do anything useful, but, you know, sort of code the library and you generate keys 15:21.840 --> 15:25.840 encrypted. There's, there's schemes for every one of those, uh, 15:25.840 --> 15:29.200 for every one of those primitives and you could, you'd basically just replace the 15:29.200 --> 15:34.960 name, um, X to 5151, 19 as a sort of a very widely used 15:34.960 --> 15:40.800 elliptic curve primitive that, um, there are also other, other ways to 15:40.800 --> 15:46.240 implement it, um, but you can replace it with any other one, 15:46.240 --> 15:53.440 anyone, any other of those, um, primitives, and then very much similar away. 15:53.440 --> 15:59.360 All right, so here's some takeaways. Um, 15:59.360 --> 16:05.600 surveillance is bad, but it's not all hopeless. Um, we are really trying, 16:05.600 --> 16:10.480 it's very hard. We don't want to over promise, 16:10.480 --> 16:15.680 but we're, you know, we can't give up because without privacy, 16:15.680 --> 16:19.760 we really have very little chance of addressing the world's problems. 16:19.760 --> 16:25.360 And I really invite you to look at that paper on the archive that, uh, 16:25.360 --> 16:31.520 has all the details of the design and, um, and I really invite you to talk to me 16:31.520 --> 16:37.760 about contributing to the project because we could really use that. 16:37.840 --> 16:42.080 And check out the code base and all of its tools. And hopefully in the near future, 16:42.080 --> 16:49.760 it will also have sort of a more, like, more tools that are easily usable. 16:49.760 --> 16:52.800 Um, 16:52.800 --> 16:54.640 all right, thank you. 16:54.640 --> 16:58.720 A class. 16:58.720 --> 17:01.120 Thank you, questions. 17:01.120 --> 17:06.240 Any questions I will run with the microphone to you? 17:06.240 --> 17:08.240 No, you cannot yell. It's online. 17:08.240 --> 17:09.600 All right, sorry. 17:09.600 --> 17:12.320 Uh, how does it compare to signal? Sorry? 17:12.320 --> 17:13.920 How does it compare to signal? 17:13.920 --> 17:19.600 Okay, um, well, signal is very good at interpreting the content of its communications, 17:19.600 --> 17:24.080 but it doesn't do much when it comes to metadata role. In fact, it's also centralized, 17:24.080 --> 17:30.080 and it's hosted on, I think, Amazon. Um, so it doesn't really try to, 17:30.080 --> 17:31.920 do anything with your metadata. 17:31.920 --> 17:36.080 But it is very good for interpreting the content of your messages. 17:36.720 --> 17:39.200 Uh, one question over there. 17:39.200 --> 17:41.600 One second, this is my fitness for today. 17:41.600 --> 17:45.600 Keep your hand up, please, then I can find you. Thank you. 17:47.600 --> 17:52.400 So, uh, does it use the tool network or is it its own mix network? 17:52.400 --> 17:58.480 It's, it's own network. Um, it does use some things that are inspired by tour solutions. 17:59.520 --> 18:03.520 Um, there's, in fact, I mean, those are kind of like a very detailed 18:03.680 --> 18:10.240 things. There's, there's ways that in the messaging, we sort of generate, uh, addresses for each 18:10.240 --> 18:14.720 message and like a suitor on them way, which is kind of inspired by something toyed for its hidden 18:14.720 --> 18:21.520 services. Uh, but it's not, it's, it's trying to do something different than tour is doing. 18:22.560 --> 18:28.560 Um, we, we are not trying to do what tour does, which is let you browse the internet in a way that's 18:29.520 --> 18:34.160 basically indistinguishable from not doing it through tour at this point, which is great. 18:35.360 --> 18:40.640 But we are also like this, this, this, this protects from things that tour doesn't protect you from. 18:42.960 --> 18:47.360 All right. Yeah, one question over there. Can you quickly pause on the microphone, please? 18:48.160 --> 19:02.080 As well as to ask how, um, a hybrid, how does a hybrid quantum, um, hybrid post quantum and 19:02.080 --> 19:08.480 classical cryptography, um, system work? Is it all those quantum resistance? I was like, 19:09.440 --> 19:17.120 some of the useful places. Okay. So there are some ways to encrypt a thing, um, that have not yet been 19:17.120 --> 19:21.120 broken by any quantum algorithm that we know of, right? That's what we refer to as quantum 19:21.120 --> 19:28.080 resistance. We don't, we never, with no cryptography, we, um, we don't, we don't have like a full 19:28.080 --> 19:34.160 certainty that it will never be broken, right? So basically, you take, you take a message and you 19:34.320 --> 19:39.920 encrypt it with something that's not been broken by a quantum algorithm and then you encrypted 19:39.920 --> 19:44.640 by something that we've been using for decades that's not been broken by a non quantum algorithm, 19:44.640 --> 19:51.600 and you have sort of two layers of encryption around it. That's how we can give you the most 19:51.600 --> 20:01.520 possible security that we know how to do. Any more questions? Here in the front? 20:01.840 --> 20:03.840 One second. 20:07.840 --> 20:13.040 Thank you. Yeah, thanks for your talk. Um, do you have, like, have we any, um, 20:13.040 --> 20:19.440 any insights on, on scaleability of this? Because like, uh, we went to, uh, yeah, uh, 20:19.440 --> 20:24.800 send and receive messages, uh, and, and, uh, yeah, the distinguished rule from, from not sending. 20:26.160 --> 20:29.600 Do you have, uh, so have we any hopes that this scales on her, like, signal level? 20:30.480 --> 20:42.720 Uh, yes. Yes. So, um, there's, it, basically, as long as you don't, um, okay, look, I don't want to 20:42.720 --> 20:47.920 extend here and compare things, compare, compare things with other projects and be like, well, 20:47.920 --> 20:53.680 we don't have that problem. But for example, as simplex, when it has a grip chat, it kind of creates 20:53.680 --> 20:58.080 a connection between each two people. So that is a problem for scalability because you have 20:58.080 --> 21:04.000 sort of end-squared connections, right? Um, our messaging design doesn't do that. You're kind of, 21:04.000 --> 21:10.560 like, everyone has, like, a one-to-many broadcast in the group setting. Uh, so that should scale. 21:10.560 --> 21:16.320 A for connection. Yeah, you have a steady connection to the network. Um, so obviously, 21:16.320 --> 21:20.400 you're not going to have a ton of bandwidth, right? Because that would add up super quick, 21:20.400 --> 21:24.400 because you're going to have to keep up this bandwidth around the clock if you really want to be 21:24.720 --> 21:32.000 super secure. Um, so that's a limitation for sure. But for having lots of users, that shouldn't 21:32.000 --> 21:37.600 be a problem as long as you have enough nodes to, you know, sort of scale with that, I guess. But 21:38.240 --> 21:44.880 it also, um, you know, we have the capacity for lots and lots of users already with just not that 21:44.880 --> 21:52.640 much infrastructure, right? So basically, um, there's like layers of relays, and you just add more 21:52.720 --> 22:05.200 relays to a layer, this becomes a problem. Any last question? Um, I don't see any resistance. 22:06.720 --> 22:10.480 In that case, run of applause. Thank you.