0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/63 Thanks! 1 00:00:11,210 --> 00:00:13,379 OK, so now I shall 2 00:00:13,380 --> 00:00:16,109 announce the speaker. 3 00:00:16,110 --> 00:00:18,349 Um, that's because, uh, because 4 00:00:18,350 --> 00:00:20,799 John got off his stomach, uh, my turn off 5 00:00:20,800 --> 00:00:22,969 Brunet and she is 6 00:00:22,970 --> 00:00:25,309 assisted by Florian 7 00:00:25,310 --> 00:00:27,619 Dawdled, who was, uh, sitting 8 00:00:27,620 --> 00:00:30,469 there and as a student, uh, to 9 00:00:30,470 --> 00:00:32,658 Munich and as a 10 00:00:32,659 --> 00:00:34,549 student assistant for the same project. 11 00:00:35,630 --> 00:00:37,779 Um, and it's about, uh, what 12 00:00:37,780 --> 00:00:40,059 is the alternative 13 00:00:40,060 --> 00:00:41,299 have to the. 14 00:00:41,300 --> 00:00:43,099 So have fun. 15 00:00:43,100 --> 00:00:44,100 Thank you. 16 00:00:50,320 --> 00:00:51,919 Now, I want to begin by saying this is 17 00:00:51,920 --> 00:00:53,689 not just, you know, the two of us working 18 00:00:53,690 --> 00:00:54,789 on it. 19 00:00:54,790 --> 00:00:56,279 In particular, I have some coauthors, 20 00:00:56,280 --> 00:00:58,969 Smartass and Martin Johnson. 21 00:00:58,970 --> 00:01:00,319 And then there are a bunch of people who 22 00:01:00,320 --> 00:01:02,429 have contributed code ideas. 23 00:01:02,430 --> 00:01:03,949 I'm not going to read the names for it to 24 00:01:03,950 --> 00:01:06,349 you here, but it's a long list, and 25 00:01:06,350 --> 00:01:07,459 I might want to mention that this was 26 00:01:07,460 --> 00:01:09,409 funded by the DFG, as some people really 27 00:01:09,410 --> 00:01:11,179 are afraid of government funding, but 28 00:01:11,180 --> 00:01:13,159 they didn't do any involvement. 29 00:01:13,160 --> 00:01:14,779 We didn't get any calls. 30 00:01:14,780 --> 00:01:16,879 OK, so where 31 00:01:16,880 --> 00:01:18,949 are we? Well, we are in a 32 00:01:18,950 --> 00:01:21,439 world with environmental disasters, 33 00:01:21,440 --> 00:01:24,199 and the resulting unrest 34 00:01:24,200 --> 00:01:26,449 among the civil population is being 35 00:01:26,450 --> 00:01:29,299 countered by authoritarian institutions. 36 00:01:29,300 --> 00:01:32,389 The surveillance to suppress dissent 37 00:01:32,390 --> 00:01:34,549 and, well, 38 00:01:34,550 --> 00:01:37,129 it's a difficult situation. 39 00:01:37,130 --> 00:01:39,229 So in this situation, we want to 40 00:01:39,230 --> 00:01:41,329 protect our privacy, our civil 41 00:01:41,330 --> 00:01:43,459 liberties and so our adversary 42 00:01:43,460 --> 00:01:45,649 model, as we now know, 43 00:01:45,650 --> 00:01:47,939 has to be a rather strong one. 44 00:01:47,940 --> 00:01:49,069 So we have to assume that first, we can 45 00:01:49,070 --> 00:01:51,109 have any role, can have multiple 46 00:01:51,110 --> 00:01:53,149 identities, has lots of computational 47 00:01:53,150 --> 00:01:55,399 power, has legal power 48 00:01:55,400 --> 00:01:56,719 in our national security that are 49 00:01:56,720 --> 00:01:58,279 subpoenas. Give me your private key, 50 00:01:58,280 --> 00:01:59,449 please. 51 00:01:59,450 --> 00:02:01,279 Now we still want to assume that you 52 00:02:01,280 --> 00:02:02,959 can't break or prevent the use of 53 00:02:02,960 --> 00:02:05,029 cryptography because, well, if you can do 54 00:02:05,030 --> 00:02:06,139 that, we're pretty much screwed. 55 00:02:07,580 --> 00:02:09,379 We hope he doesn't compromise every end 56 00:02:09,380 --> 00:02:11,629 user system out there, and 57 00:02:11,630 --> 00:02:13,009 that's a bit of a strong assumption. 58 00:02:13,010 --> 00:02:15,079 But again, if he does that, I can't 59 00:02:15,080 --> 00:02:17,179 help and we assume he doesn't 60 00:02:17,180 --> 00:02:18,859 want to prevent network communication 61 00:02:18,860 --> 00:02:21,289 overall again, that the economic 62 00:02:21,290 --> 00:02:23,059 cost of doing so, the economic costs of 63 00:02:23,060 --> 00:02:25,179 controlling all communication is formed 64 00:02:25,180 --> 00:02:26,719 presumably too high, even for that kind 65 00:02:26,720 --> 00:02:27,720 of adversary. 66 00:02:29,000 --> 00:02:31,159 So if you have the kind of adversary 67 00:02:31,160 --> 00:02:32,899 and we say, OK, we want to secure our 68 00:02:32,900 --> 00:02:35,359 communication by using encryption. 69 00:02:35,360 --> 00:02:37,639 One fundamental thing all of our 70 00:02:37,640 --> 00:02:38,989 systems rely on is a public key 71 00:02:38,990 --> 00:02:41,089 infrastructure, and the public 72 00:02:41,090 --> 00:02:42,919 key infrastructure is broken under this 73 00:02:42,920 --> 00:02:45,169 adversary model that we have. 74 00:02:45,170 --> 00:02:47,239 And so and we look at the 75 00:02:47,240 --> 00:02:48,319 various systems that have been 76 00:02:48,320 --> 00:02:49,549 compromised recently. 77 00:02:49,550 --> 00:02:52,099 You know, Skype bought by Microsoft 78 00:02:52,100 --> 00:02:54,649 and now easily controlled Lavabit. 79 00:02:54,650 --> 00:02:55,609 Give me your keys. 80 00:02:55,610 --> 00:02:56,899 Thank you very much. 81 00:02:56,900 --> 00:02:58,579 PRISM. I have sent stuff to a central 82 00:02:58,580 --> 00:03:00,799 server. Central servers easily 83 00:03:00,800 --> 00:03:01,789 taken over. 84 00:03:01,790 --> 00:03:04,219 Did you know Tor? Well, I've trusted some 85 00:03:04,220 --> 00:03:06,289 authority and 12th the trust was somewhat 86 00:03:06,290 --> 00:03:07,579 misplaced. 87 00:03:07,580 --> 00:03:08,929 It doesn't matter if my encryption is the 88 00:03:08,930 --> 00:03:10,519 best encryption on the planet. 89 00:03:10,520 --> 00:03:12,379 If the PCA is broken, everything is lost, 90 00:03:12,380 --> 00:03:13,380 right? 91 00:03:14,370 --> 00:03:16,499 So we must decentralize really 92 00:03:16,500 --> 00:03:17,669 to look at this centralized 93 00:03:17,670 --> 00:03:18,839 infrastructure, as we have today, is 94 00:03:18,840 --> 00:03:21,629 easily controlled, I.A. 95 00:03:21,630 --> 00:03:23,309 controls no resources. 96 00:03:23,310 --> 00:03:25,059 There's the roots on the DNA school 97 00:03:25,060 --> 00:03:27,329 certificate, ex-boyfriend case, 98 00:03:27,330 --> 00:03:28,889 major browser vendors. All of these live 99 00:03:28,890 --> 00:03:30,509 in one country pretty much, or have a 100 00:03:30,510 --> 00:03:32,339 significant business presence in one 101 00:03:32,340 --> 00:03:34,319 country and are therefore subject to the 102 00:03:34,320 --> 00:03:36,119 laws of that country. 103 00:03:36,120 --> 00:03:37,469 And we know that that country is not 104 00:03:37,470 --> 00:03:39,509 known for respecting users privacy. 105 00:03:40,590 --> 00:03:42,719 So we need to decentralize 106 00:03:44,100 --> 00:03:45,989 now when we try to build a decentralized 107 00:03:45,990 --> 00:03:47,159 Pichai. 108 00:03:47,160 --> 00:03:48,809 One of the fundamental insights into this 109 00:03:48,810 --> 00:03:49,860 domain comes from Zuku. 110 00:03:50,910 --> 00:03:52,589 It's called Zuko's triangle. 111 00:03:52,590 --> 00:03:53,669 Some of you might have heard about it 112 00:03:53,670 --> 00:03:55,739 before. And what he said is, Well, we 113 00:03:55,740 --> 00:03:57,209 want three things to one name system. 114 00:03:57,210 --> 00:03:58,829 We want it to be secure. 115 00:03:58,830 --> 00:04:00,149 We want the names to be global. 116 00:04:00,150 --> 00:04:01,409 We want the names to be memorable. 117 00:04:02,490 --> 00:04:04,439 OK, global names means the meaning for 118 00:04:04,440 --> 00:04:05,789 name is the same for everybody on the 119 00:04:05,790 --> 00:04:07,799 planet. If they ask for it, they get the 120 00:04:07,800 --> 00:04:09,869 same value. Ideally memorable 121 00:04:09,870 --> 00:04:11,559 means I can pick names that are like 122 00:04:11,560 --> 00:04:13,619 Alice Bob, not he has some cryptographic 123 00:04:13,620 --> 00:04:14,829 512 bit identifier. 124 00:04:14,830 --> 00:04:17,369 Remember that and type it incorrectly 125 00:04:17,370 --> 00:04:19,499 every time and secure 126 00:04:19,500 --> 00:04:21,569 it? Well, secure is kind of a bit fuzzy. 127 00:04:21,570 --> 00:04:22,919 You know, what does it all include? 128 00:04:22,920 --> 00:04:25,469 But we have to think secure as 129 00:04:25,470 --> 00:04:26,909 with respect to the adversary model we 130 00:04:26,910 --> 00:04:28,919 have, if we have a trust anchor like the 131 00:04:28,920 --> 00:04:31,259 DNS root zone, like the next five or nine 132 00:04:31,260 --> 00:04:33,209 certificate authority, that's no longer 133 00:04:33,210 --> 00:04:34,889 secure, right? 134 00:04:34,890 --> 00:04:36,629 And if you decide, well, secure is not 135 00:04:36,630 --> 00:04:38,489 that strong, the adversary, then well, 136 00:04:38,490 --> 00:04:39,959 Zuko's triangle doesn't hold. 137 00:04:39,960 --> 00:04:41,309 But if you really look at this adversary 138 00:04:41,310 --> 00:04:42,899 model, you have to say, OK, we can't have 139 00:04:42,900 --> 00:04:43,900 all three. 140 00:04:44,910 --> 00:04:46,679 Let's look at some examples for those 141 00:04:46,680 --> 00:04:48,389 systems that have two of them. 142 00:04:48,390 --> 00:04:49,889 So it's global and memorable names. 143 00:04:49,890 --> 00:04:51,239 We have hierarchical registration in the 144 00:04:51,240 --> 00:04:52,949 classical domain name system. 145 00:04:52,950 --> 00:04:54,599 I assume everybody is somewhat familiar 146 00:04:54,600 --> 00:04:55,889 with that. 147 00:04:55,890 --> 00:04:57,539 With cryptographic identifiers. 148 00:04:57,540 --> 00:04:59,009 We have global names that are perfectly 149 00:04:59,010 --> 00:05:00,119 secure with the public key. 150 00:05:00,120 --> 00:05:02,279 It's in the name, so we can then 151 00:05:02,280 --> 00:05:03,929 sign the records with state publication 152 00:05:03,930 --> 00:05:06,119 of the crypto is fine. It's all good, but 153 00:05:06,120 --> 00:05:07,769 well, they're not memorable. 154 00:05:07,770 --> 00:05:09,269 Not yet seen a crypto system that has a 155 00:05:09,270 --> 00:05:10,950 public key that I can memorize easily 156 00:05:12,750 --> 00:05:14,699 and memorable and secure. 157 00:05:14,700 --> 00:05:15,749 Well, this pet name system. 158 00:05:15,750 --> 00:05:17,339 So the easiest example of this is it's 159 00:05:17,340 --> 00:05:19,019 the host file in there. 160 00:05:19,020 --> 00:05:20,669 You can put a memorable name and a 161 00:05:20,670 --> 00:05:22,559 number, and as long as your computer 162 00:05:22,560 --> 00:05:23,609 isn't compromised, you don't even need 163 00:05:23,610 --> 00:05:25,679 crypto. You will get that name up to a 164 00:05:25,680 --> 00:05:27,089 number, but it's not useful for anybody 165 00:05:27,090 --> 00:05:28,739 else. It's the least global system. 166 00:05:28,740 --> 00:05:29,740 It's only for, you 167 00:05:31,890 --> 00:05:33,959 know, their designs to try to improve 168 00:05:33,960 --> 00:05:34,949 this. 169 00:05:34,950 --> 00:05:36,779 If you look at DNS, sic where we add 170 00:05:36,780 --> 00:05:38,849 certificates to DNS, that's trying to 171 00:05:38,850 --> 00:05:41,049 make DNS a bit more secure 172 00:05:41,050 --> 00:05:43,199 if we don't quite get all the way secure 173 00:05:43,200 --> 00:05:45,769 given our adversary model, there's 174 00:05:45,770 --> 00:05:47,549 a monarchy or else we're serious, OK, 175 00:05:47,550 --> 00:05:49,499 let's make a phrase that makes it easy to 176 00:05:49,500 --> 00:05:50,999 remember this Python 12 bit string. 177 00:05:53,370 --> 00:05:54,939 It's a suggestion by the guys at the sera 178 00:05:54,940 --> 00:05:57,059 suggestion. And the problem is 179 00:05:57,060 --> 00:05:58,829 for me, when I define memorable, I say 180 00:05:58,830 --> 00:06:00,509 low entropy. And of course, I don't get 181 00:06:00,510 --> 00:06:02,309 away with C entropy. I need to keep the 182 00:06:02,310 --> 00:06:03,269 information there. 183 00:06:03,270 --> 00:06:05,189 And yes, maybe this broken English 184 00:06:05,190 --> 00:06:06,539 sentence is a bit easier to remember than 185 00:06:06,540 --> 00:06:07,799 if iPhone 12 bit key. 186 00:06:07,800 --> 00:06:09,419 But again, we don't really get memorable, 187 00:06:09,420 --> 00:06:10,679 right? 188 00:06:10,680 --> 00:06:12,389 And then there is an approach called 189 00:06:12,390 --> 00:06:14,399 sudsy, which effectively says, OK, we 190 00:06:14,400 --> 00:06:15,419 have these pet name systems. 191 00:06:15,420 --> 00:06:16,979 How about I make my pet names available 192 00:06:16,980 --> 00:06:18,239 to you? 193 00:06:18,240 --> 00:06:20,819 So I put them into a public database 194 00:06:20,820 --> 00:06:22,559 and then you can carry my names as long 195 00:06:22,560 --> 00:06:24,149 as you have a name for me. 196 00:06:24,150 --> 00:06:25,799 So we get kind of transitivity. 197 00:06:25,800 --> 00:06:27,599 You can use my name so no longer just for 198 00:06:27,600 --> 00:06:29,939 me, but they're not truly global. 199 00:06:29,940 --> 00:06:31,469 But everybody has its own his own 200 00:06:31,470 --> 00:06:33,239 perspective, and this is kind of the 201 00:06:33,240 --> 00:06:35,009 foundation for the new name system. 202 00:06:37,560 --> 00:06:39,329 Now, some people here might say, OK, what 203 00:06:39,330 --> 00:06:40,769 about name coin? 204 00:06:40,770 --> 00:06:42,869 And was a nice article by Aaron 205 00:06:42,870 --> 00:06:44,219 Schwartz, who said squaring Zuko's 206 00:06:44,220 --> 00:06:46,799 triangle and said Name coin right bitcoin 207 00:06:46,800 --> 00:06:49,079 allows us to fix that. 208 00:06:49,080 --> 00:06:50,789 OK, well, the names and income I give 209 00:06:50,790 --> 00:06:51,929 them, they're memorable. 210 00:06:51,930 --> 00:06:54,239 Check that the global check 211 00:06:54,240 --> 00:06:56,189 that are they secure? 212 00:06:56,190 --> 00:06:57,449 Well, if they have a different adversary 213 00:06:57,450 --> 00:07:00,239 model to start with 214 00:07:00,240 --> 00:07:01,409 availability of names. 215 00:07:01,410 --> 00:07:03,659 So availability is a security goal. 216 00:07:03,660 --> 00:07:05,069 Well, they limit the registration rate. 217 00:07:05,070 --> 00:07:06,479 I can't just register building domains 218 00:07:06,480 --> 00:07:08,069 too, but it's not enough name coin out 219 00:07:08,070 --> 00:07:09,239 there to do that. 220 00:07:09,240 --> 00:07:10,619 And the second problem is that first, we 221 00:07:10,620 --> 00:07:11,759 must not have fifty one percent off the 222 00:07:11,760 --> 00:07:12,989 compute power. 223 00:07:12,990 --> 00:07:15,179 So aside, for inefficient and so on, 224 00:07:15,180 --> 00:07:17,039 the assumption that it's made is adverse. 225 00:07:17,040 --> 00:07:19,319 So it's not very strong computationally. 226 00:07:19,320 --> 00:07:20,939 I'm not sure that that is necessarily 227 00:07:20,940 --> 00:07:23,039 true, given what we 228 00:07:23,040 --> 00:07:24,659 know about the buildings in Utah and the 229 00:07:24,660 --> 00:07:26,339 rest of the world. 230 00:07:26,340 --> 00:07:28,019 Or, you know, maybe the NSA has a nice 231 00:07:28,020 --> 00:07:29,020 botnet to. 232 00:07:31,430 --> 00:07:32,569 They do it. 233 00:07:32,570 --> 00:07:34,699 OK, so let's talk about the new 234 00:07:34,700 --> 00:07:36,139 name system. 235 00:07:36,140 --> 00:07:37,519 So we have a decentralized name system is 236 00:07:37,520 --> 00:07:38,629 secure, memorable names. 237 00:07:38,630 --> 00:07:40,699 So you start by editing your 238 00:07:40,700 --> 00:07:42,889 own zone and you can 239 00:07:42,890 --> 00:07:44,719 make those names available to others by 240 00:07:44,720 --> 00:07:47,479 signing them and publishing them online. 241 00:07:47,480 --> 00:07:49,009 As I said, you get this delegation 242 00:07:49,010 --> 00:07:50,929 property from Sazi that others when they 243 00:07:50,930 --> 00:07:52,999 have learned your zones, can look up 244 00:07:53,000 --> 00:07:54,889 names in your zone. 245 00:07:54,890 --> 00:07:56,389 We also support global unique secure 246 00:07:56,390 --> 00:07:58,489 identifier, so the dot onion 247 00:07:58,490 --> 00:08:00,049 style where you have your publication, if 248 00:08:00,050 --> 00:08:01,909 you can use that to, you know, nobody 249 00:08:01,910 --> 00:08:04,309 said that you cannot have two different 250 00:08:04,310 --> 00:08:06,379 name systems combined, so you can take 251 00:08:06,380 --> 00:08:07,999 this side of the triangle, that side of 252 00:08:08,000 --> 00:08:09,499 the triangle, that side of the triangle 253 00:08:09,500 --> 00:08:10,429 and mix and match. 254 00:08:10,430 --> 00:08:11,989 We just don't get one name that has all 255 00:08:11,990 --> 00:08:12,990 of them at the same time. 256 00:08:15,140 --> 00:08:16,140 We 257 00:08:17,570 --> 00:08:19,789 have additional indigenous query 258 00:08:19,790 --> 00:08:20,729 and response privacy. 259 00:08:20,730 --> 00:08:22,639 So when you do a query in the system in 260 00:08:22,640 --> 00:08:24,829 DNS, everybody OK, everybody 261 00:08:24,830 --> 00:08:26,419 at the NSA can see what name you're 262 00:08:26,420 --> 00:08:27,649 looking up and what the answer was that 263 00:08:27,650 --> 00:08:28,819 you got back. 264 00:08:28,820 --> 00:08:30,499 In our case, we want to make sure that we 265 00:08:30,500 --> 00:08:31,969 make this as private as possible, so it's 266 00:08:31,970 --> 00:08:33,499 not trivial for anybody to figure out 267 00:08:33,500 --> 00:08:34,500 what you did. 268 00:08:35,270 --> 00:08:37,308 And as a result, we get an alternative 269 00:08:37,309 --> 00:08:38,749 public infrastructure. 270 00:08:38,750 --> 00:08:40,519 And I say it this way because we can use 271 00:08:40,520 --> 00:08:42,349 this to replace the web of trust. 272 00:08:42,350 --> 00:08:43,849 We can use this to replace six five four 273 00:08:43,850 --> 00:08:45,619 nine six. We can use this to replace the 274 00:08:45,620 --> 00:08:47,779 NSIC doesn't mean 275 00:08:47,780 --> 00:08:49,219 any of these are the best things to 276 00:08:49,220 --> 00:08:50,569 replace. 277 00:08:50,570 --> 00:08:52,789 We first want to focus on peer-to-peer 278 00:08:52,790 --> 00:08:54,140 network social applications, 279 00:08:55,520 --> 00:08:56,869 identity management in this kind of 280 00:08:56,870 --> 00:08:58,279 scenarios because we don't have to worry 281 00:08:58,280 --> 00:08:59,599 about interoperability so much. 282 00:08:59,600 --> 00:09:00,829 But in principle, for all of these 283 00:09:00,830 --> 00:09:03,109 things, we have a new public 284 00:09:03,110 --> 00:09:05,329 infrastructure and we can 285 00:09:05,330 --> 00:09:06,769 be interoperable with Dennis by making 286 00:09:06,770 --> 00:09:09,109 all record types will 287 00:09:09,110 --> 00:09:10,849 be the same as the network of types. 288 00:09:10,850 --> 00:09:11,850 And then we have some more. 289 00:09:13,680 --> 00:09:15,179 OK, let me first start with what does 290 00:09:15,180 --> 00:09:16,739 this really look like from the user's 291 00:09:16,740 --> 00:09:17,969 perspective? 292 00:09:17,970 --> 00:09:20,129 And this is not the user quite that, 293 00:09:20,130 --> 00:09:21,959 you know, we might want in the end for 294 00:09:21,960 --> 00:09:23,609 usability purpose, but suppose your 295 00:09:23,610 --> 00:09:25,229 current your DNS administrator 296 00:09:25,230 --> 00:09:26,219 administering a zone. 297 00:09:26,220 --> 00:09:27,509 What does it mean for you to switch to 298 00:09:27,510 --> 00:09:28,559 DNS? 299 00:09:28,560 --> 00:09:30,689 Well, we have a zone editor 300 00:09:30,690 --> 00:09:31,889 which is geographically. 301 00:09:33,030 --> 00:09:34,049 All of the screenshots are real. 302 00:09:34,050 --> 00:09:35,549 By the way, if somebody questions that 303 00:09:35,550 --> 00:09:36,770 before finally real, 304 00:09:37,830 --> 00:09:39,509 you have your normal labels, the record 305 00:09:39,510 --> 00:09:41,429 types, the values you want to map to and 306 00:09:41,430 --> 00:09:42,599 some expiration time. 307 00:09:42,600 --> 00:09:43,859 So you pretty much get the same 308 00:09:43,860 --> 00:09:45,599 experience as you would get from DNS in 309 00:09:45,600 --> 00:09:46,600 terms of managing a zone, 310 00:09:47,700 --> 00:09:49,020 but nothing really changes there. 311 00:09:50,820 --> 00:09:52,559 So suppose we have Bob here, he says. 312 00:09:52,560 --> 00:09:54,239 Web server and he puts into his local 313 00:09:54,240 --> 00:09:56,459 zone. WW Do is reachable 314 00:09:56,460 --> 00:09:58,809 at the IP address. Five six seven eight. 315 00:09:58,810 --> 00:10:00,059 Good. 316 00:10:00,060 --> 00:10:01,709 Next thing he's going to do, it's going 317 00:10:01,710 --> 00:10:03,599 to make himself a little business card 318 00:10:03,600 --> 00:10:05,009 like the ones that Holland Foundation is 319 00:10:05,010 --> 00:10:06,479 willing to print for you guys at this 320 00:10:06,480 --> 00:10:08,639 event and on this business card, 321 00:10:08,640 --> 00:10:09,839 he's going to put his public key. 322 00:10:11,250 --> 00:10:12,149 OK. 323 00:10:12,150 --> 00:10:13,559 And was that he can introduce himself to 324 00:10:13,560 --> 00:10:15,719 his friends. So he 325 00:10:15,720 --> 00:10:17,229 goes to Alice. 326 00:10:17,230 --> 00:10:19,439 Alice learns Bob's public key 327 00:10:19,440 --> 00:10:21,629 and puts into her own under 328 00:10:21,630 --> 00:10:23,639 the table Bob Bob's public key, and he 329 00:10:23,640 --> 00:10:24,929 has a new record Typekit we have for the 330 00:10:24,930 --> 00:10:26,609 public key of another entity. 331 00:10:28,140 --> 00:10:29,909 Once he's done that, she can reach Bob's 332 00:10:29,910 --> 00:10:31,589 web server under WW Dot Bob Dot. 333 00:10:31,590 --> 00:10:33,899 Going to notice Dot 334 00:10:33,900 --> 00:10:36,449 stands for me because that's 335 00:10:36,450 --> 00:10:38,309 myself, my zone, the one that I control, 336 00:10:38,310 --> 00:10:40,269 that I have all freedoms over. 337 00:10:40,270 --> 00:10:41,249 All right, the freedom to give it to 338 00:10:41,250 --> 00:10:43,169 others. The freedom to change any name I 339 00:10:43,170 --> 00:10:44,170 want. 340 00:10:46,310 --> 00:10:47,310 Yeah. 341 00:10:47,660 --> 00:10:49,019 Now, how does this work? 342 00:10:49,020 --> 00:10:51,189 No, we have the following set up Bob has 343 00:10:51,190 --> 00:10:53,179 his own database, Alice has hers on the 344 00:10:53,180 --> 00:10:55,319 service was an entry for Bob and we have 345 00:10:55,320 --> 00:10:56,209 from the middle of the peer-to-peer 346 00:10:56,210 --> 00:10:58,399 network with a distributed hash table. 347 00:10:58,400 --> 00:10:59,599 So this is a test table for those who 348 00:10:59,600 --> 00:11:01,659 don't know. Just think hash table. 349 00:11:01,660 --> 00:11:02,660 All right. 350 00:11:05,210 --> 00:11:07,099 OK, so first thing, Bob, what Bob does is 351 00:11:07,100 --> 00:11:08,689 he periodically stores the records from 352 00:11:08,690 --> 00:11:10,399 his database in the DHT. 353 00:11:10,400 --> 00:11:12,709 Just store them periodically 354 00:11:12,710 --> 00:11:14,269 because, well, records in the distributor 355 00:11:14,270 --> 00:11:15,679 hash table tend to sometimes go away. 356 00:11:17,180 --> 00:11:19,219 Now, when Ellis says, OK, who is Bob Dole 357 00:11:19,220 --> 00:11:20,929 going to first thing herself with us? 358 00:11:20,930 --> 00:11:22,969 It's OK, new means it's my own zone. 359 00:11:22,970 --> 00:11:24,179 Who is? Bob asked. 360 00:11:24,180 --> 00:11:25,819 Put it up. Who's Bob? 361 00:11:25,820 --> 00:11:27,529 Davis comes back and says Bob's public 362 00:11:27,530 --> 00:11:30,049 key is whatever some public key. 363 00:11:30,050 --> 00:11:31,050 And she says, OK, 364 00:11:32,210 --> 00:11:34,070 the ADHD, who is 365 00:11:35,960 --> 00:11:37,909 in that zone and ADHD comes back and 366 00:11:37,910 --> 00:11:39,080 says, OK, here's your record. 367 00:11:40,160 --> 00:11:42,320 Now that was easy, right? 368 00:11:43,790 --> 00:11:45,259 And if we have that and we have the 369 00:11:45,260 --> 00:11:47,599 security, we can put creative records 370 00:11:47,600 --> 00:11:48,769 in there, for example here. 371 00:11:48,770 --> 00:11:50,479 I have an actual screenshot of Firefox, 372 00:11:50,480 --> 00:11:52,699 where I put into my own freedom, Daugunu 373 00:11:52,700 --> 00:11:54,049 putting Kanu's IP address. 374 00:11:54,050 --> 00:11:55,909 And can you tell us record and my 375 00:11:55,910 --> 00:11:57,469 browser? And I said, Oh, I validated this 376 00:11:57,470 --> 00:11:58,879 against the new name System Certificate 377 00:11:58,880 --> 00:12:00,949 Authority because, well, that's what 378 00:12:00,950 --> 00:12:03,019 the proxy says the CIA was when 379 00:12:03,020 --> 00:12:04,909 it created the respective validation 380 00:12:04,910 --> 00:12:05,910 certificates on the fly. 381 00:12:07,160 --> 00:12:08,059 Great. 382 00:12:08,060 --> 00:12:09,879 Now where's the security problem here? 383 00:12:09,880 --> 00:12:11,779 Well, we have this little thing in the 384 00:12:11,780 --> 00:12:14,299 middle, right? The Magic Box, 385 00:12:14,300 --> 00:12:16,459 right? So what we have here is what, 386 00:12:16,460 --> 00:12:17,929 but it looks like it's ADHD can see 387 00:12:17,930 --> 00:12:19,789 what's being put in when I get out and 388 00:12:19,790 --> 00:12:21,079 well, they could do whatever they want to 389 00:12:21,080 --> 00:12:22,309 their contents, right? 390 00:12:22,310 --> 00:12:23,389 So here's what we need crypto. 391 00:12:25,890 --> 00:12:26,949 OK, here comes the crypto. 392 00:12:29,120 --> 00:12:31,339 So we use elliptic curves. 393 00:12:31,340 --> 00:12:33,529 That's wonderful curve, because 394 00:12:33,530 --> 00:12:35,899 it's short in terms of public key size. 395 00:12:35,900 --> 00:12:38,059 So in elliptic curve cryptography, 396 00:12:38,060 --> 00:12:40,009 I'm just giving a brief refresher here. 397 00:12:40,010 --> 00:12:41,010 You have a generator. 398 00:12:42,290 --> 00:12:44,419 The point on the curve, the size 399 00:12:44,420 --> 00:12:46,579 of the Elliptic Curve Group, and it's 400 00:12:46,580 --> 00:12:47,580 a prime number. 401 00:12:48,410 --> 00:12:50,179 So these are publicly known values that 402 00:12:50,180 --> 00:12:51,169 everybody knows. 403 00:12:51,170 --> 00:12:53,179 They were set in stone once per curve 404 00:12:53,180 --> 00:12:54,469 forever. 405 00:12:54,470 --> 00:12:55,639 Then I have a private key, which I'm 406 00:12:55,640 --> 00:12:57,349 going to refer to as small x. 407 00:12:57,350 --> 00:12:59,179 So that's the secret for my zone that I 408 00:12:59,180 --> 00:13:01,279 have to protect, obviously, and 409 00:13:01,280 --> 00:13:02,329 I have a public key. 410 00:13:02,330 --> 00:13:04,249 That's the point on the curve, which is 411 00:13:04,250 --> 00:13:06,499 calculated by, well, during 412 00:13:06,500 --> 00:13:07,399 X times. 413 00:13:07,400 --> 00:13:09,109 Remember, X is a number, so x times she 414 00:13:09,110 --> 00:13:11,269 just means adding the pointy x times to 415 00:13:11,270 --> 00:13:14,089 itself. That gives me another point p 416 00:13:14,090 --> 00:13:16,639 if I know what Curve Point Edition is, 417 00:13:16,640 --> 00:13:18,409 and all we need to know is elliptic 418 00:13:18,410 --> 00:13:20,959 curve. Cryptography says given p 419 00:13:20,960 --> 00:13:22,100 i cannot get back to x 420 00:13:23,650 --> 00:13:25,939 height, I can't really prove 421 00:13:25,940 --> 00:13:27,469 that fundamentally, we just don't know 422 00:13:27,470 --> 00:13:29,119 anybody who knows how to do that. 423 00:13:29,120 --> 00:13:30,469 And it's like factoring 424 00:13:31,670 --> 00:13:33,829 large, uh, products. 425 00:13:33,830 --> 00:13:35,959 OK, now well, we also have this. 426 00:13:35,960 --> 00:13:37,579 We have a label for the record, the zone. 427 00:13:37,580 --> 00:13:39,919 So that's the W W, for example, height 428 00:13:39,920 --> 00:13:41,299 or the name Bob. 429 00:13:41,300 --> 00:13:42,529 All right. So that's again, we're going 430 00:13:42,530 --> 00:13:44,270 to map that label to a number more and 431 00:13:45,380 --> 00:13:46,969 then we have a set of records for the 432 00:13:46,970 --> 00:13:48,429 label L end zone P. 433 00:13:48,430 --> 00:13:50,269 So that's the plaintext records like the 434 00:13:50,270 --> 00:13:52,099 IP address for the web server is one two 435 00:13:52,100 --> 00:13:54,919 three four five and 436 00:13:54,920 --> 00:13:56,309 then we have the query hash, which is 437 00:13:56,310 --> 00:13:57,439 what we want to use to store the 438 00:13:57,440 --> 00:13:59,149 information under in the D. 439 00:13:59,150 --> 00:14:00,799 So I didn't quite say how I get this, but 440 00:14:00,800 --> 00:14:02,599 we have to have some hash code for the 441 00:14:02,600 --> 00:14:04,669 hash table and in the hash 442 00:14:04,670 --> 00:14:06,259 table. We're not going to store the 443 00:14:06,260 --> 00:14:07,609 records in plaintext. 444 00:14:07,610 --> 00:14:09,409 We're going to store them in encrypted 445 00:14:09,410 --> 00:14:11,569 forms. I'm going to call that the BPL, 446 00:14:11,570 --> 00:14:13,639 the block for Zone P 447 00:14:13,640 --> 00:14:15,559 and the label L with all of the records 448 00:14:15,560 --> 00:14:16,969 under that label. 449 00:14:16,970 --> 00:14:19,129 OK, let's just basic 450 00:14:19,130 --> 00:14:20,130 terms. 451 00:14:20,900 --> 00:14:23,839 So given this, how do I publish? 452 00:14:23,840 --> 00:14:26,989 First thing I do is I calculate 453 00:14:26,990 --> 00:14:29,059 the hash of the label and the public 454 00:14:29,060 --> 00:14:31,279 key, some hash function 455 00:14:31,280 --> 00:14:33,379 and I get a small h and 456 00:14:33,380 --> 00:14:35,329 then it's just a number again, contagion 457 00:14:35,330 --> 00:14:37,459 hash just a number when I multiply hash 458 00:14:37,460 --> 00:14:39,799 with the second X to get a derived 459 00:14:39,800 --> 00:14:41,959 secrets, d so d is now 460 00:14:41,960 --> 00:14:44,029 another private key in this on 461 00:14:44,030 --> 00:14:46,190 the same curve, but just a number. 462 00:14:47,270 --> 00:14:48,979 That's why it's all so modern. 463 00:14:48,980 --> 00:14:51,319 Now using that d, I can 464 00:14:51,320 --> 00:14:53,839 sign using AC DC. 465 00:14:53,840 --> 00:14:55,159 What I'm going to sign is I'm going to 466 00:14:55,160 --> 00:14:56,929 encrypt. The Reichardt's was a key 467 00:14:56,930 --> 00:14:58,339 derived again from the label and the 468 00:14:58,340 --> 00:14:59,449 public key. 469 00:14:59,450 --> 00:15:01,219 So it's a hash key derivation function 470 00:15:01,220 --> 00:15:03,469 here, and I'm going to add D times 471 00:15:03,470 --> 00:15:05,059 g at the end. That's the public key 472 00:15:05,060 --> 00:15:06,060 corresponding to D 473 00:15:07,430 --> 00:15:09,199 so that people can verify that signature 474 00:15:09,200 --> 00:15:10,200 using that information. 475 00:15:11,720 --> 00:15:13,969 I'm going to store all of this under the 476 00:15:13,970 --> 00:15:15,919 hash of D times G. 477 00:15:15,920 --> 00:15:16,920 That's my query. 478 00:15:24,060 --> 00:15:26,339 What does this mean for an attacker? 479 00:15:26,340 --> 00:15:28,559 Well, given 480 00:15:28,560 --> 00:15:30,119 the information stored on the hash table 481 00:15:30,120 --> 00:15:32,279 D Times G, I can't get back to X, I can't 482 00:15:32,280 --> 00:15:34,199 get back to H. 483 00:15:34,200 --> 00:15:35,969 That's the standard assumption that we 484 00:15:35,970 --> 00:15:38,279 have given 485 00:15:38,280 --> 00:15:39,809 that the records were encrypted with the 486 00:15:39,810 --> 00:15:42,269 label and the public key of the zone. 487 00:15:42,270 --> 00:15:44,009 Unless I know exactly what label and what 488 00:15:44,010 --> 00:15:45,960 public key it was, I can't decrypt 489 00:15:46,980 --> 00:15:48,329 now if I know what the label and the 490 00:15:48,330 --> 00:15:50,009 public key was. Well, then I could ask 491 00:15:50,010 --> 00:15:51,479 the same question. Then I have to be able 492 00:15:51,480 --> 00:15:52,949 to decrypt if it's a public record, so we 493 00:15:52,950 --> 00:15:55,379 can't fix that, right? 494 00:15:55,380 --> 00:15:57,389 But unless I can guess exactly the label 495 00:15:57,390 --> 00:15:58,919 and the public key, I will learn nothing. 496 00:15:58,920 --> 00:15:59,909 I will not be able to decrypt the 497 00:15:59,910 --> 00:16:02,009 records, but I can 498 00:16:02,010 --> 00:16:03,359 still verify that the signature is 499 00:16:03,360 --> 00:16:04,360 correct. 500 00:16:05,190 --> 00:16:08,339 I can say, Oh yeah, that signature is the 501 00:16:08,340 --> 00:16:09,239 same as the private key. 502 00:16:09,240 --> 00:16:10,799 Demetris was this public key. 503 00:16:11,970 --> 00:16:13,649 So intermediaries in the DHT can verify 504 00:16:13,650 --> 00:16:14,759 that the records are correct. 505 00:16:14,760 --> 00:16:17,489 They will not even cash invalid records, 506 00:16:17,490 --> 00:16:18,839 but they cannot decrypt what the contents 507 00:16:18,840 --> 00:16:19,919 were. They cannot tell which don't they 508 00:16:19,920 --> 00:16:20,920 belong to. None of that. 509 00:16:22,150 --> 00:16:23,759 But when I look for a label 510 00:16:25,080 --> 00:16:26,369 for the release, what I do is again, I 511 00:16:26,370 --> 00:16:28,739 can regulate small h of LNP 512 00:16:28,740 --> 00:16:30,029 hashing those. 513 00:16:30,030 --> 00:16:31,080 Now I can calculate 514 00:16:32,700 --> 00:16:34,769 h times 515 00:16:34,770 --> 00:16:37,019 p load, which is the same 516 00:16:37,020 --> 00:16:38,759 as H Times X Times three, which is the 517 00:16:38,760 --> 00:16:40,080 same as H Times D Times G, 518 00:16:41,340 --> 00:16:42,419 which gives me the query. 519 00:16:43,530 --> 00:16:45,299 And then I can use this to obtain the 520 00:16:45,300 --> 00:16:47,279 encrypted block from the DHT and I can 521 00:16:47,280 --> 00:16:49,079 decrypt again because I can do the HKT 522 00:16:49,080 --> 00:16:50,080 myself also. 523 00:16:51,420 --> 00:16:53,039 So here I've got very privacy. 524 00:16:54,270 --> 00:16:56,129 And, of course, integrity checking 525 00:16:56,130 --> 00:16:57,390 authenticity at the same time. 526 00:17:00,030 --> 00:17:02,609 OK. One issue that we 527 00:17:02,610 --> 00:17:04,439 sometimes face is that people lose their 528 00:17:04,440 --> 00:17:05,419 keys. 529 00:17:05,420 --> 00:17:07,169 We might want to revoke them and say, OK, 530 00:17:07,170 --> 00:17:08,339 don't use this anymore. 531 00:17:11,700 --> 00:17:13,289 The basic idea of revocation is, of 532 00:17:13,290 --> 00:17:14,189 course, likely the revocation 533 00:17:14,190 --> 00:17:15,838 certificate, which I'm saying this 534 00:17:15,839 --> 00:17:17,159 private keys is no longer valid, so I'm 535 00:17:17,160 --> 00:17:18,629 using my private keys, sign a message and 536 00:17:18,630 --> 00:17:21,118 say, forget about this private key. 537 00:17:21,119 --> 00:17:23,729 Now, whenever a peer receives 538 00:17:23,730 --> 00:17:25,409 a valid vocations certificates, what we 539 00:17:25,410 --> 00:17:27,149 do is be flooded to all of the neighbors 540 00:17:27,150 --> 00:17:28,229 because a piece of your phone is really 541 00:17:28,230 --> 00:17:29,419 hard to stop. 542 00:17:29,420 --> 00:17:30,539 Right? Even if we got a couple of 543 00:17:30,540 --> 00:17:31,889 compromised guys will, they'll just flood 544 00:17:31,890 --> 00:17:32,849 around them. All right. 545 00:17:32,850 --> 00:17:34,079 Just islands in the ocean. 546 00:17:35,400 --> 00:17:37,469 All of the peers that receive 547 00:17:37,470 --> 00:17:38,729 reparations for to get us going to store 548 00:17:38,730 --> 00:17:40,829 it forever. And whenever they encounter a 549 00:17:40,830 --> 00:17:41,999 certificate or private key, they're going 550 00:17:42,000 --> 00:17:43,439 to check against the list has it's been 551 00:17:43,440 --> 00:17:44,440 revoked. 552 00:17:44,940 --> 00:17:46,619 Now this is, of course, an expensive 553 00:17:46,620 --> 00:17:48,179 operation flooding the network. 554 00:17:48,180 --> 00:17:50,009 We must not be able to do this every five 555 00:17:50,010 --> 00:17:51,179 milliseconds that will take down the 556 00:17:51,180 --> 00:17:52,769 network and storing it forever. 557 00:17:52,770 --> 00:17:54,419 Well, we don't want people to be able to 558 00:17:54,420 --> 00:17:55,949 store stuff even on machines. 559 00:17:55,950 --> 00:17:57,329 So here we're going to use inexpensive 560 00:17:57,330 --> 00:17:59,069 proof of work using the script hash 561 00:17:59,070 --> 00:18:00,689 function, effectively forcing you to do a 562 00:18:00,690 --> 00:18:02,249 calculation on your computer for a couple 563 00:18:02,250 --> 00:18:04,079 of days before you can cause this flood 564 00:18:04,080 --> 00:18:05,130 that will have to be stored forever. 565 00:18:06,330 --> 00:18:07,769 But once you've done that, it's pretty 566 00:18:07,770 --> 00:18:09,479 much impossible to stop the revocation. 567 00:18:11,190 --> 00:18:12,539 And then there's also no latency for 568 00:18:12,540 --> 00:18:13,919 checking, has this private key be 569 00:18:13,920 --> 00:18:14,920 revoked? 570 00:18:15,570 --> 00:18:17,159 That's a bit more revocation magic needed 571 00:18:17,160 --> 00:18:18,160 here. 572 00:18:18,480 --> 00:18:19,949 And specifically, there might be peers 573 00:18:19,950 --> 00:18:21,269 that are offline during the initial 574 00:18:21,270 --> 00:18:23,069 flood. So they might have missed that 575 00:18:23,070 --> 00:18:24,539 this thing was revoked. 576 00:18:24,540 --> 00:18:26,579 Or I might have a network that was 577 00:18:26,580 --> 00:18:28,109 partitioned and might have had, you know, 578 00:18:28,110 --> 00:18:29,549 Egypt being cut off from the internet for 579 00:18:29,550 --> 00:18:31,289 a couple of months and all these guys 580 00:18:31,290 --> 00:18:32,559 come back online. They've missed a lot of 581 00:18:32,560 --> 00:18:33,509 replication that might have been 582 00:18:33,510 --> 00:18:34,409 important to them. 583 00:18:34,410 --> 00:18:35,639 If they really were cut off, I couldn't 584 00:18:35,640 --> 00:18:36,599 have gotten to them during the time. 585 00:18:36,600 --> 00:18:38,249 But now that we're reconnecting, I need 586 00:18:38,250 --> 00:18:40,139 to kind of get the set back together. 587 00:18:40,140 --> 00:18:41,759 So we need to reconcile the revocation 588 00:18:41,760 --> 00:18:43,889 sets whenever peers 589 00:18:43,890 --> 00:18:44,890 connect to each other, 590 00:18:46,020 --> 00:18:48,119 so need to compute the set. 591 00:18:48,120 --> 00:18:49,769 Union also certification set. 592 00:18:51,340 --> 00:18:53,409 And that sounds expensive, right? 593 00:18:53,410 --> 00:18:54,429 Not quite fly. 594 00:18:57,610 --> 00:19:00,119 All right, so let's just make 595 00:19:00,120 --> 00:19:02,279 yes. So let's do efficient set 596 00:19:02,280 --> 00:19:04,859 union. So just from this idea is 597 00:19:04,860 --> 00:19:07,529 not ours, but based on 598 00:19:07,530 --> 00:19:10,179 an idea by Epstein and others. 599 00:19:10,180 --> 00:19:12,689 And this was first prison in 2011. 600 00:19:12,690 --> 00:19:15,329 So this is kind of prison work, and 601 00:19:15,330 --> 00:19:17,429 we were the first one to provide 602 00:19:17,430 --> 00:19:20,639 public and free software implementation. 603 00:19:20,640 --> 00:19:22,949 So the basic setting here is that we 604 00:19:22,950 --> 00:19:25,409 have our two players, Bob and Alice, 605 00:19:25,410 --> 00:19:28,169 and they have two sets and B 606 00:19:28,170 --> 00:19:30,299 and those sets are very 607 00:19:30,300 --> 00:19:32,379 large. They contain all the 608 00:19:32,380 --> 00:19:33,659 revocations of the system, 609 00:19:34,770 --> 00:19:36,509 but they're symmetric. 610 00:19:36,510 --> 00:19:38,789 Difference is really low and 611 00:19:38,790 --> 00:19:41,129 we want to explore exactly of that to 612 00:19:41,130 --> 00:19:43,499 reconcile them efficiently. 613 00:19:43,500 --> 00:19:44,789 So what are you going to do? Ellis wants 614 00:19:44,790 --> 00:19:46,919 to know the a b minus. 615 00:19:46,920 --> 00:19:49,409 That's the stuff she doesn't know, and 616 00:19:49,410 --> 00:19:51,269 Bob wants to know A-minus B. 617 00:19:51,270 --> 00:19:53,369 Those are exactly the only keys missing. 618 00:19:54,540 --> 00:19:56,639 So let's talk about how 619 00:19:56,640 --> 00:19:58,349 we can do this efficiently. 620 00:19:58,350 --> 00:20:00,419 The first approach, which is a really bad 621 00:20:00,420 --> 00:20:02,699 solution, would be just to have 622 00:20:02,700 --> 00:20:05,279 Alice send her set to Bob. 623 00:20:05,280 --> 00:20:07,869 Then Bob can come shoot what 624 00:20:07,870 --> 00:20:10,229 Lawrence Ellis needs and 625 00:20:10,230 --> 00:20:11,429 sends back. 626 00:20:11,430 --> 00:20:13,529 And then you do accept the reverse 627 00:20:13,530 --> 00:20:15,869 thing. But that's really bad to 628 00:20:15,870 --> 00:20:17,369 has a real bad communication course 629 00:20:17,370 --> 00:20:18,899 because it grows with the size of the 630 00:20:18,900 --> 00:20:20,849 whole revocations set. 631 00:20:20,850 --> 00:20:22,289 What we want to do is we want to have an 632 00:20:22,290 --> 00:20:25,409 algorithm that can do the reconciliation 633 00:20:25,410 --> 00:20:27,779 and time proportional to 634 00:20:27,780 --> 00:20:31,079 the symmetric set's difference. 635 00:20:31,080 --> 00:20:33,869 So only the elements 636 00:20:33,870 --> 00:20:35,849 that we missed, for example, because we 637 00:20:35,850 --> 00:20:38,129 had a down time who 638 00:20:38,130 --> 00:20:40,169 are actually counting into the runtime 639 00:20:40,170 --> 00:20:41,789 time for other rhythm. 640 00:20:41,790 --> 00:20:44,129 So one frozen problem 641 00:20:44,130 --> 00:20:45,779 that doesn't really work, we can just 642 00:20:45,780 --> 00:20:47,939 slot some whole elements, but 643 00:20:47,940 --> 00:20:50,009 the hashes of elements that that 644 00:20:50,010 --> 00:20:52,289 doesn't improve the runtime that just 645 00:20:52,290 --> 00:20:54,029 makes each element smaller. 646 00:20:54,030 --> 00:20:56,099 So let's look at some 647 00:20:56,100 --> 00:20:57,509 more fancy protocol. 648 00:20:57,510 --> 00:21:00,209 So a very important basic 649 00:21:00,210 --> 00:21:02,009 building block for that that most of you 650 00:21:02,010 --> 00:21:04,109 probably know from not working, 651 00:21:04,110 --> 00:21:06,029 as are blue filters. 652 00:21:06,030 --> 00:21:08,129 So Bloomfield Terrace is basically 653 00:21:08,130 --> 00:21:11,039 a data structure that has a fixed size 654 00:21:11,040 --> 00:21:13,229 that is some kind of summary 655 00:21:13,230 --> 00:21:14,249 for a set. 656 00:21:14,250 --> 00:21:16,349 So the basic operations for that, you 657 00:21:16,350 --> 00:21:18,989 can create one and then you specify 658 00:21:18,990 --> 00:21:20,729 a size for it. 659 00:21:20,730 --> 00:21:23,099 And the size of the blue filter 660 00:21:23,100 --> 00:21:25,439 and the memory necessary represented 661 00:21:25,440 --> 00:21:27,239 will never change. 662 00:21:27,240 --> 00:21:29,519 You can insert elements into the bloom 663 00:21:29,520 --> 00:21:31,979 filter and then you can 664 00:21:31,980 --> 00:21:34,319 check whether an element 665 00:21:34,320 --> 00:21:36,479 was previously inserted in blue filter. 666 00:21:36,480 --> 00:21:38,849 And this operation is 667 00:21:38,850 --> 00:21:41,629 not this 668 00:21:41,630 --> 00:21:43,109 just probabilistic. 669 00:21:43,110 --> 00:21:45,329 So you get an answer that 670 00:21:45,330 --> 00:21:47,399 either size says the element 671 00:21:47,400 --> 00:21:49,799 is definitely not in the set 672 00:21:49,800 --> 00:21:51,229 or you'll get an answer. 673 00:21:51,230 --> 00:21:53,519 The other one probably is of a set. 674 00:21:53,520 --> 00:21:55,559 So let's look at how this works. 675 00:21:55,560 --> 00:21:57,779 So basically, blue filter is 676 00:21:57,780 --> 00:22:00,239 just an array of buckets 677 00:22:00,240 --> 00:22:01,989 and those binary buckets, so they start 678 00:22:01,990 --> 00:22:04,199 either zero or one and let some sort 679 00:22:04,200 --> 00:22:05,759 of an element element in this. 680 00:22:05,760 --> 00:22:08,129 This element one here gets sent 681 00:22:08,130 --> 00:22:10,169 to a hash function, and this hash 682 00:22:10,170 --> 00:22:12,359 function just gives us a number 683 00:22:12,360 --> 00:22:13,379 of buckets. 684 00:22:13,380 --> 00:22:15,689 So there's indices for this buckets. 685 00:22:15,690 --> 00:22:17,130 So, for example, a one 686 00:22:18,240 --> 00:22:20,699 to three and seven. 687 00:22:20,700 --> 00:22:23,249 So let's insert our element into this. 688 00:22:24,330 --> 00:22:25,949 It's obvious we just started to. 689 00:22:25,950 --> 00:22:28,049 One was insert another 690 00:22:28,050 --> 00:22:29,069 element. 691 00:22:29,070 --> 00:22:31,499 This hashes to different world use 692 00:22:31,500 --> 00:22:33,899 and we just 693 00:22:33,900 --> 00:22:34,949 said those two one. 694 00:22:36,390 --> 00:22:38,699 Now that we have inserted those 695 00:22:38,700 --> 00:22:40,769 two elements, we can 696 00:22:40,770 --> 00:22:43,259 check membership by just also 697 00:22:43,260 --> 00:22:45,749 hashing the element and checking 698 00:22:45,750 --> 00:22:48,239 if all the buckets that this element 699 00:22:48,240 --> 00:22:50,369 hashes into are sets 700 00:22:50,370 --> 00:22:51,370 to one. 701 00:22:52,050 --> 00:22:54,119 So if one 702 00:22:54,120 --> 00:22:56,279 of the buckets is zero, 703 00:22:56,280 --> 00:22:58,769 the elements could not have been inserted 704 00:22:58,770 --> 00:23:00,299 into the set. 705 00:23:00,300 --> 00:23:02,519 But now here's a more problematic case 706 00:23:02,520 --> 00:23:04,859 with an element that's definitely 707 00:23:04,860 --> 00:23:07,169 not in the set as this element for, 708 00:23:07,170 --> 00:23:09,779 but incidentally, it hashes. 709 00:23:09,780 --> 00:23:13,199 Uh, two buckets were previously 710 00:23:13,200 --> 00:23:15,779 some other element hashed into, 711 00:23:15,780 --> 00:23:17,939 and then we'll get a false 712 00:23:17,940 --> 00:23:19,049 positive. 713 00:23:19,050 --> 00:23:21,359 So bloom filters are 714 00:23:21,360 --> 00:23:23,579 not enough to do a set reconciliation. 715 00:23:23,580 --> 00:23:25,899 We need to do some extensions on them. 716 00:23:25,900 --> 00:23:27,359 The first extensions are counting bloom 717 00:23:27,360 --> 00:23:29,429 filters, so it's the same as 718 00:23:29,430 --> 00:23:30,809 another one filter. 719 00:23:30,810 --> 00:23:33,389 But the bucket does not store 720 00:23:33,390 --> 00:23:35,429 binary. Well, yes, but it stores the 721 00:23:35,430 --> 00:23:36,389 count. 722 00:23:36,390 --> 00:23:38,549 And by this, you 723 00:23:38,550 --> 00:23:40,619 can also remove elements 724 00:23:40,620 --> 00:23:42,869 from the set because 725 00:23:42,870 --> 00:23:44,939 if you only have a binary count and 726 00:23:44,940 --> 00:23:47,129 then removing the element, you 727 00:23:47,130 --> 00:23:48,959 don't know if there was a previous 728 00:23:48,960 --> 00:23:51,329 element in exactly that bucket that had 729 00:23:51,330 --> 00:23:52,349 been inserted. 730 00:23:52,350 --> 00:23:54,629 So you need to have a real challenge 731 00:23:54,630 --> 00:23:56,219 as a binary. 732 00:23:56,220 --> 00:23:57,339 The problem with. 733 00:23:57,340 --> 00:23:59,019 But it's really important that you can 734 00:23:59,020 --> 00:24:00,849 have false negatives if you remove an 735 00:24:00,850 --> 00:24:03,159 element from a boom filter that was 736 00:24:03,160 --> 00:24:04,359 not previously insurgents. 737 00:24:05,620 --> 00:24:07,809 But that's also not sufficient for 738 00:24:07,810 --> 00:24:08,799 reconciliation. 739 00:24:08,800 --> 00:24:10,389 For that, we need in virtual bloom 740 00:24:10,390 --> 00:24:11,349 filters. 741 00:24:11,350 --> 00:24:13,659 So here we also allow negative counts, 742 00:24:13,660 --> 00:24:15,279 and we do not only have the current 743 00:24:15,280 --> 00:24:17,739 field, but we also store 744 00:24:17,740 --> 00:24:19,809 an X or some of 745 00:24:19,810 --> 00:24:21,909 element hashes in the buckets. 746 00:24:21,910 --> 00:24:23,769 We'll see an example soon. 747 00:24:23,770 --> 00:24:25,509 And they're called in virtual bloom 748 00:24:25,510 --> 00:24:28,929 filters because for them, you 749 00:24:28,930 --> 00:24:31,689 can often extract operation that 750 00:24:31,690 --> 00:24:33,849 gives you the hash of an element 751 00:24:33,850 --> 00:24:35,529 that you previously inserted, which is 752 00:24:35,530 --> 00:24:37,119 really nice. 753 00:24:37,120 --> 00:24:39,069 And this does not always work because 754 00:24:39,070 --> 00:24:40,479 it's filter. 755 00:24:40,480 --> 00:24:42,549 It's a data structure with a fixed size, 756 00:24:42,550 --> 00:24:44,829 and we can insert as many 757 00:24:44,830 --> 00:24:46,479 elements as we want into it. 758 00:24:46,480 --> 00:24:49,659 So the extractor operation will 759 00:24:49,660 --> 00:24:52,149 return a result code that 760 00:24:52,150 --> 00:24:54,969 says either yes, we 761 00:24:54,970 --> 00:24:57,129 could extract the element and it had 762 00:24:57,130 --> 00:24:58,599 a negative count. 763 00:24:58,600 --> 00:25:00,489 We can extract the element and head out a 764 00:25:00,490 --> 00:25:02,169 positive count. 765 00:25:02,170 --> 00:25:04,119 We're done. So there's no more elements 766 00:25:04,120 --> 00:25:06,219 in the original one filter or it just 767 00:25:06,220 --> 00:25:07,480 failed than we are out of luck. 768 00:25:09,010 --> 00:25:10,779 The next version, you can also do fine on 769 00:25:10,780 --> 00:25:13,209 those filters, so 770 00:25:13,210 --> 00:25:14,589 there's no reason for the symmetric 771 00:25:14,590 --> 00:25:15,669 difference. 772 00:25:15,670 --> 00:25:17,839 So you put two in virtual 773 00:25:17,840 --> 00:25:19,989 one filters into it and you get another 774 00:25:19,990 --> 00:25:23,409 one that represents exactly 775 00:25:23,410 --> 00:25:25,749 bloom filter, where the symmetric 776 00:25:25,750 --> 00:25:28,119 difference of the two sets is 777 00:25:28,120 --> 00:25:29,559 stored in. 778 00:25:29,560 --> 00:25:31,809 But you tag 779 00:25:31,810 --> 00:25:33,939 from which sides the element 780 00:25:33,940 --> 00:25:36,489 comes from with either positive 781 00:25:36,490 --> 00:25:38,079 or a negative count. 782 00:25:38,080 --> 00:25:40,209 So let's look in, except for this one 783 00:25:40,210 --> 00:25:41,210 filters 784 00:25:42,460 --> 00:25:44,619 just this produce from 785 00:25:44,620 --> 00:25:46,839 the usual bloom filter, and here 786 00:25:46,840 --> 00:25:48,729 we have our additional bucket with the 787 00:25:48,730 --> 00:25:49,629 hashes. 788 00:25:49,630 --> 00:25:51,129 So in our hash function does not only 789 00:25:51,130 --> 00:25:53,469 give us the list of buckets, but 790 00:25:53,470 --> 00:25:55,539 also a hash 791 00:25:55,540 --> 00:25:57,709 value that we can insert 792 00:25:57,710 --> 00:26:00,009 to assess the lesson so that this element 793 00:26:00,010 --> 00:26:02,529 just the extra with zero results 794 00:26:02,530 --> 00:26:03,909 in the number itself. 795 00:26:03,910 --> 00:26:05,919 And if we have the count listeners, there 796 00:26:05,920 --> 00:26:07,179 is another element. 797 00:26:07,180 --> 00:26:09,279 So here the 798 00:26:09,280 --> 00:26:11,439 differences are you actually count 799 00:26:11,440 --> 00:26:12,519 to two. 800 00:26:12,520 --> 00:26:15,999 And here you just compute the XOR. 801 00:26:16,000 --> 00:26:18,189 So now that we have inserted all those 802 00:26:18,190 --> 00:26:20,529 elements, we want to extract them. 803 00:26:20,530 --> 00:26:22,869 And for that, we use 804 00:26:22,870 --> 00:26:24,499 so-called pure buckets for pure workers 805 00:26:24,500 --> 00:26:25,779 is a bucket with only one element 806 00:26:25,780 --> 00:26:26,889 inserted. 807 00:26:26,890 --> 00:26:29,619 And there's only one element 808 00:26:29,620 --> 00:26:31,779 in this field here stirs the 809 00:26:31,780 --> 00:26:34,809 hash, which is exactly what we want, so 810 00:26:34,810 --> 00:26:37,149 we can extract the hash and reverse 811 00:26:37,150 --> 00:26:38,979 the operation for all of the other 812 00:26:38,980 --> 00:26:41,109 buckets. So this 813 00:26:41,110 --> 00:26:42,759 bucket here that currently has a kind of 814 00:26:42,760 --> 00:26:44,859 two, we'll get a count of one 815 00:26:44,860 --> 00:26:47,409 and then we can use the extract operation 816 00:26:47,410 --> 00:26:49,809 again to get the next element. 817 00:26:49,810 --> 00:26:51,399 But this, of course, will only work if we 818 00:26:51,400 --> 00:26:53,109 initially have a pure bucket. 819 00:26:53,110 --> 00:26:54,519 So the more elements we have in our 820 00:26:54,520 --> 00:26:56,889 Bloomfield are, the less 821 00:26:56,890 --> 00:26:58,959 the chance that we can actually 822 00:26:58,960 --> 00:26:59,889 extract elements. 823 00:26:59,890 --> 00:27:02,139 So and then really full 824 00:27:02,140 --> 00:27:04,179 IBF, we will not be able to extract 825 00:27:04,180 --> 00:27:05,619 little filters. 826 00:27:05,620 --> 00:27:08,109 So let's define 827 00:27:08,110 --> 00:27:10,879 the symmetric difference operations. 828 00:27:10,880 --> 00:27:12,279 And this is really easy to compute. 829 00:27:12,280 --> 00:27:14,349 We just subtract the counts, 830 00:27:14,350 --> 00:27:16,789 obviously, and then we 831 00:27:16,790 --> 00:27:18,669 extract the hashes. 832 00:27:18,670 --> 00:27:20,919 So let's see how we can use this for 833 00:27:20,920 --> 00:27:22,719 the set reconciliation protocol. 834 00:27:22,720 --> 00:27:24,669 So our two players could all their 835 00:27:24,670 --> 00:27:27,129 elements in an IBF and 836 00:27:27,130 --> 00:27:29,379 then exchange it and compute 837 00:27:29,380 --> 00:27:30,879 the symmetric difference. 838 00:27:30,880 --> 00:27:32,379 And now they can start extracting 839 00:27:32,380 --> 00:27:34,719 elements because there's 840 00:27:34,720 --> 00:27:36,819 only the symmetric difference in 841 00:27:36,820 --> 00:27:39,129 the bloom filter and we set 842 00:27:39,130 --> 00:27:41,829 the symmetric difference is really 843 00:27:41,830 --> 00:27:43,029 small. 844 00:27:43,030 --> 00:27:45,189 It will be very likely that 845 00:27:45,190 --> 00:27:47,469 there are some pure buckets and 846 00:27:47,470 --> 00:27:49,599 the resulting difference IBF and we can 847 00:27:49,600 --> 00:27:50,979 start to extract. 848 00:27:50,980 --> 00:27:53,109 And if that fails, we 849 00:27:53,110 --> 00:27:55,509 have just to repeat 850 00:27:55,510 --> 00:27:57,339 that the larger IBF. 851 00:27:58,420 --> 00:28:00,699 So one thing that's missing 852 00:28:00,700 --> 00:28:03,039 here is that we have no idea 853 00:28:03,040 --> 00:28:05,139 how large the IBF should initially 854 00:28:05,140 --> 00:28:07,389 be. So for that, there 855 00:28:07,390 --> 00:28:09,699 is an additional additional step. 856 00:28:09,700 --> 00:28:11,929 Previous Firstly, where we 857 00:28:11,930 --> 00:28:13,779 do differences to measure. 858 00:28:13,780 --> 00:28:16,119 So we could estimate the size 859 00:28:16,120 --> 00:28:17,769 of the somatic reference for the sets. 860 00:28:19,270 --> 00:28:21,639 It turns out we can 861 00:28:21,640 --> 00:28:23,499 reuse IBF for that. 862 00:28:23,500 --> 00:28:25,659 They're really suitable here 863 00:28:25,660 --> 00:28:27,759 because you can 864 00:28:27,760 --> 00:28:29,989 estimate the difference 865 00:28:29,990 --> 00:28:32,349 actually for especially 866 00:28:32,350 --> 00:28:34,569 when it is very small. 867 00:28:34,570 --> 00:28:37,119 So other approaches to that 868 00:28:37,120 --> 00:28:38,979 work much better when the difference is 869 00:28:38,980 --> 00:28:40,689 really large. But that's not our case. 870 00:28:40,690 --> 00:28:41,980 Here are 871 00:28:43,180 --> 00:28:45,129 the basic ideas for the difference. 872 00:28:45,130 --> 00:28:47,499 Estimation is that you sample 873 00:28:47,500 --> 00:28:50,379 your sets by looking at 874 00:28:50,380 --> 00:28:52,509 the hash. 875 00:28:52,510 --> 00:28:54,429 So, for example, the number of leading 876 00:28:54,430 --> 00:28:56,929 zeros and then. 877 00:28:56,930 --> 00:28:58,879 You put it in this structure here, those 878 00:28:58,880 --> 00:29:01,219 are all in reversible filters. 879 00:29:01,220 --> 00:29:03,289 And here many 880 00:29:03,290 --> 00:29:05,389 elements are sampled and the 881 00:29:05,390 --> 00:29:07,189 more we get to the outside, less elements 882 00:29:07,190 --> 00:29:08,190 are sampled. 883 00:29:08,810 --> 00:29:11,029 So now that we have created 884 00:29:11,030 --> 00:29:13,339 this data structure, of course, 885 00:29:13,340 --> 00:29:15,469 both peers have to 886 00:29:15,470 --> 00:29:17,749 create this data structure and then 887 00:29:17,750 --> 00:29:19,979 subtract the variable 888 00:29:19,980 --> 00:29:22,279 and filters element element 889 00:29:22,280 --> 00:29:24,469 and then we can try to decode 890 00:29:24,470 --> 00:29:27,019 them. So the first one will 891 00:29:27,020 --> 00:29:28,759 probably work. And let's say we have 892 00:29:28,760 --> 00:29:30,529 three elements out of that's three times 893 00:29:30,530 --> 00:29:32,929 the extraction succeeded 894 00:29:32,930 --> 00:29:34,859 and we're done with it. 895 00:29:34,860 --> 00:29:36,949 Next one succeeds two 896 00:29:36,950 --> 00:29:39,019 and we get more elements because we have 897 00:29:39,020 --> 00:29:41,299 sampled more elements into 898 00:29:41,300 --> 00:29:42,649 this structure. 899 00:29:42,650 --> 00:29:44,339 And let's say the next one fails. 900 00:29:44,340 --> 00:29:46,279 So we have no idea how elements, how many 901 00:29:46,280 --> 00:29:48,619 elements are in this 902 00:29:48,620 --> 00:29:51,649 one. But now we can do an estimation 903 00:29:51,650 --> 00:29:54,529 because we have a relation 904 00:29:54,530 --> 00:29:56,689 to how many of 905 00:29:56,690 --> 00:29:59,149 how many items we have sampled into 906 00:29:59,150 --> 00:30:01,519 this bloom filter to this pool filter. 907 00:30:01,520 --> 00:30:02,660 So for example, we can say 908 00:30:03,710 --> 00:30:05,959 in one hour delay of there will 909 00:30:05,960 --> 00:30:08,389 be just half of the elements. 910 00:30:08,390 --> 00:30:10,169 So let's look at this. 911 00:30:10,170 --> 00:30:13,399 Uh, here we 912 00:30:13,400 --> 00:30:15,589 have counted three, four, seven, so 913 00:30:15,590 --> 00:30:16,819 10 elements. 914 00:30:16,820 --> 00:30:19,249 And then there are those blue filters 915 00:30:19,250 --> 00:30:21,379 that did not decode because they 916 00:30:21,380 --> 00:30:23,209 had a large number of elements. 917 00:30:23,210 --> 00:30:25,369 But we can just estimate 918 00:30:25,370 --> 00:30:27,589 that because this one will 919 00:30:27,590 --> 00:30:30,019 contain them twice 920 00:30:30,020 --> 00:30:31,979 as much as those combined. 921 00:30:31,980 --> 00:30:33,859 And this again will contain twice as much 922 00:30:33,860 --> 00:30:36,079 combined. So if you multiply it by 923 00:30:36,080 --> 00:30:38,239 four, we have an estimate for the 924 00:30:38,240 --> 00:30:39,229 set of friends. 925 00:30:39,230 --> 00:30:41,089 And then we can use our IBF. 926 00:30:43,340 --> 00:30:44,340 Thank you. 927 00:30:50,430 --> 00:30:52,049 So as you can see in a tiny problem like 928 00:30:52,050 --> 00:30:53,369 revocation, there's always a bigger 929 00:30:53,370 --> 00:30:55,349 problem. Now the nice thing is if you use 930 00:30:55,350 --> 00:30:56,729 the internet framework providing you own 931 00:30:56,730 --> 00:30:58,379 applications, you have this efficient set 932 00:30:58,380 --> 00:30:59,939 on conservation. That's a nice API and 933 00:30:59,940 --> 00:31:02,109 you don't have to care about the details 934 00:31:02,110 --> 00:31:04,139 in case you want it. 935 00:31:04,140 --> 00:31:05,140 You're welcome. 936 00:31:06,150 --> 00:31:08,009 Now back to the new name system now that 937 00:31:08,010 --> 00:31:09,119 we know how to do is replication. 938 00:31:10,710 --> 00:31:12,959 There's also, as I mentioned, global 939 00:31:12,960 --> 00:31:14,069 cryptographic identifiers. 940 00:31:14,070 --> 00:31:15,869 That's what we call the Zwicky TLT. 941 00:31:15,870 --> 00:31:17,219 So when you have the memorable ones, you 942 00:31:17,220 --> 00:31:19,319 add new at the end, if you have a 943 00:31:19,320 --> 00:31:21,359 public key and you have typed it in 944 00:31:21,360 --> 00:31:23,849 painful, I know, then you put dots 945 00:31:23,850 --> 00:31:25,259 at the end you have a global name. 946 00:31:25,260 --> 00:31:26,939 Now this is your entry point, right? 947 00:31:26,940 --> 00:31:28,589 You entries before that global name, you 948 00:31:28,590 --> 00:31:30,149 can again put arbitrary labels that 949 00:31:30,150 --> 00:31:31,259 follow the normal delegation 950 00:31:32,430 --> 00:31:34,109 and are readable. 951 00:31:34,110 --> 00:31:35,309 So this kind of works a bit like the 952 00:31:35,310 --> 00:31:36,310 onion. 953 00:31:37,410 --> 00:31:39,329 Now then we also have the problem that if 954 00:31:39,330 --> 00:31:40,559 you have these delegation teams, they 955 00:31:40,560 --> 00:31:41,699 might get a bit long at times. 956 00:31:41,700 --> 00:31:43,599 So might be Elliston the bottom, but that 957 00:31:43,600 --> 00:31:45,569 they've taken to it's not well defined, 958 00:31:45,570 --> 00:31:47,279 but not quite usable. 959 00:31:47,280 --> 00:31:48,659 Not to mention, every time you type this 960 00:31:48,660 --> 00:31:50,099 in, we have to kind of trust the zone of 961 00:31:50,100 --> 00:31:52,049 day. If there's one off carol of Bob to 962 00:31:52,050 --> 00:31:54,599 get to Ellis, so well, 963 00:31:54,600 --> 00:31:55,600 we can do better 964 00:31:56,880 --> 00:31:59,879 if I'm on my problem. 965 00:31:59,880 --> 00:32:01,619 Ellis, what we have here would we like to 966 00:32:01,620 --> 00:32:03,049 be called Krista? 967 00:32:03,050 --> 00:32:05,279 I just Bob Colter Ellis, but you know, 968 00:32:05,280 --> 00:32:08,339 that's a slander attack, right? 969 00:32:08,340 --> 00:32:10,529 So what we do is we add a new record 970 00:32:10,530 --> 00:32:11,759 type we call Nick Records. 971 00:32:11,760 --> 00:32:13,409 Let's say Chris specifies that her 972 00:32:13,410 --> 00:32:14,670 preferred nickname is Krista. 973 00:32:15,690 --> 00:32:16,949 We add this to every record said 974 00:32:16,950 --> 00:32:19,019 automatically once it's configured. 975 00:32:19,020 --> 00:32:21,119 And so when Eve first uses that name 976 00:32:21,120 --> 00:32:22,499 for the first time, she notes that 977 00:32:22,500 --> 00:32:24,659 nickname and she puts into her database 978 00:32:24,660 --> 00:32:26,639 and entry, saying crystal shorter can to 979 00:32:26,640 --> 00:32:28,049 the short version of this long thing. 980 00:32:28,050 --> 00:32:29,369 It's not quite so short. 981 00:32:29,370 --> 00:32:31,079 She learned this automatically now, in 982 00:32:31,080 --> 00:32:32,849 the future, she just has this much 983 00:32:32,850 --> 00:32:34,049 shorter name for it that she got 984 00:32:34,050 --> 00:32:35,189 automatically. 985 00:32:35,190 --> 00:32:37,139 Now, Krista has an important incentive 986 00:32:37,140 --> 00:32:38,459 here. She needs to pick a unique 987 00:32:38,460 --> 00:32:40,949 pseudonym for too many crystals 988 00:32:40,950 --> 00:32:42,419 out there. This will not work because 989 00:32:42,420 --> 00:32:44,009 they can only be one crystal or shorter 990 00:32:44,010 --> 00:32:45,259 group. 991 00:32:45,260 --> 00:32:47,309 It doesn't have to be global unique just 992 00:32:47,310 --> 00:32:48,779 within her social context. 993 00:32:48,780 --> 00:32:49,919 It has to be unique. 994 00:32:49,920 --> 00:32:50,920 All right. 995 00:32:52,250 --> 00:32:54,439 So in short, we get a memorable 996 00:32:54,440 --> 00:32:56,809 short trespass for future use 997 00:32:56,810 --> 00:32:58,639 and can consider as a form of tofu trust 998 00:32:58,640 --> 00:32:59,759 on first use. 999 00:32:59,760 --> 00:33:01,879 All right. Once I've looked it up, I know 1000 00:33:01,880 --> 00:33:03,859 I have a short handle for it. 1001 00:33:03,860 --> 00:33:06,259 OK, one other problem 1002 00:33:06,260 --> 00:33:08,599 is we use this to you now in the DRC, 1003 00:33:08,600 --> 00:33:10,609 you have latency. I might put a record in 1004 00:33:10,610 --> 00:33:12,079 and it takes some time for the record to 1005 00:33:12,080 --> 00:33:13,819 be propagated, replicating the be 1006 00:33:13,820 --> 00:33:15,469 available, be fetched by users from the 1007 00:33:15,470 --> 00:33:16,519 DHT. 1008 00:33:16,520 --> 00:33:19,099 And sometimes when I have a 1009 00:33:19,100 --> 00:33:20,779 DNS like system, I want to change. 1010 00:33:20,780 --> 00:33:22,459 The mapping might be my server. 1011 00:33:22,460 --> 00:33:23,839 It's going to be moved from the US to 1012 00:33:23,840 --> 00:33:26,509 Europe on the 1st of January, 1013 00:33:26,510 --> 00:33:28,519 and I really would not like to have the 1014 00:33:28,520 --> 00:33:31,249 old records be valid at that point, 1015 00:33:31,250 --> 00:33:32,659 and I need to use this to get to the new 1016 00:33:32,660 --> 00:33:33,919 records. But I don't want to be down for 1017 00:33:33,920 --> 00:33:35,219 three days while things propagate in the 1018 00:33:35,220 --> 00:33:36,679 DHT. 1019 00:33:36,680 --> 00:33:38,229 Maybe three days is a bit long for the 1020 00:33:38,230 --> 00:33:41,089 team. But ideally we have no downtime. 1021 00:33:41,090 --> 00:33:42,229 So how do we do this? 1022 00:33:42,230 --> 00:33:44,479 Well, you can put into your normal 1023 00:33:44,480 --> 00:33:46,699 record set. Shadow records a shadow 1024 00:33:46,700 --> 00:33:48,319 record as effectively saying this record 1025 00:33:48,320 --> 00:33:50,299 is not valid as long as any other record 1026 00:33:50,300 --> 00:33:51,769 under the same label was the same type is 1027 00:33:51,770 --> 00:33:52,969 valid. 1028 00:33:52,970 --> 00:33:54,469 So you say they set the expiration date 1029 00:33:54,470 --> 00:33:57,199 for the old one to the 31st of 1030 00:33:57,200 --> 00:33:58,309 December? All right. 1031 00:33:58,310 --> 00:33:59,659 Put in a shadow record that has a 1032 00:33:59,660 --> 00:34:01,759 validity of twenty fourteen and 1033 00:34:01,760 --> 00:34:03,889 then the shadow records will not be 1034 00:34:03,890 --> 00:34:07,249 considered as valid until the time 1035 00:34:07,250 --> 00:34:08,629 when the other record expires. 1036 00:34:08,630 --> 00:34:10,908 So it's a little trick to make this 1037 00:34:10,909 --> 00:34:13,069 caching work nicely without having 1038 00:34:13,070 --> 00:34:15,379 this problem that we need to at this 1039 00:34:15,380 --> 00:34:17,718 very particular time, get an update 1040 00:34:17,719 --> 00:34:18,719 to everybody in the network. 1041 00:34:20,000 --> 00:34:21,229 So it's just a flag in the network. 1042 00:34:22,850 --> 00:34:24,709 OK, now practical concerns. 1043 00:34:24,710 --> 00:34:26,809 Well, I wanted to address a couple of 1044 00:34:26,810 --> 00:34:28,309 them. So first name registration support 1045 00:34:28,310 --> 00:34:29,599 for browsing new record types, 1046 00:34:29,600 --> 00:34:30,829 integration of applications set of the 1047 00:34:30,830 --> 00:34:33,019 implementation for five minutes. 1048 00:34:33,020 --> 00:34:34,020 OK. 1049 00:34:35,949 --> 00:34:37,479 So registering a name in Genesis, OK, we 1050 00:34:37,480 --> 00:34:38,919 saw the first version, you know, I give 1051 00:34:38,920 --> 00:34:40,658 you my card and you have it. 1052 00:34:40,659 --> 00:34:42,079 Second possibility is we can, of course, 1053 00:34:42,080 --> 00:34:43,329 still have a register. 1054 00:34:43,330 --> 00:34:44,859 We are running the unit, FCF is 1055 00:34:44,860 --> 00:34:46,599 registering with it or you can go there 1056 00:34:46,600 --> 00:34:47,829 first, come first serve. 1057 00:34:47,830 --> 00:34:50,138 If you trust our registrar, it promises 1058 00:34:50,139 --> 00:34:52,238 it will never remove your keys and you 1059 00:34:52,239 --> 00:34:53,349 can use it and we actually ship. 1060 00:34:53,350 --> 00:34:54,968 That was the distribution as a public key 1061 00:34:54,969 --> 00:34:56,379 underpin, not canoe. 1062 00:34:56,380 --> 00:34:57,999 So if you see somebody food or pinned, 1063 00:34:58,000 --> 00:34:59,019 you can do it while you're using our 1064 00:34:59,020 --> 00:35:01,089 registrar, but you have very good trust 1065 00:35:01,090 --> 00:35:02,189 agility here. 1066 00:35:02,190 --> 00:35:03,309 You can choose to put another register 1067 00:35:03,310 --> 00:35:04,629 you can on your own. 1068 00:35:04,630 --> 00:35:05,649 Either way, it doesn't matter. 1069 00:35:05,650 --> 00:35:07,929 And many paths can lead to the same 1070 00:35:07,930 --> 00:35:09,469 user of the same zone. 1071 00:35:09,470 --> 00:35:11,469 All right. So if one register is bad, 1072 00:35:11,470 --> 00:35:13,209 we'll just use another one. 1073 00:35:13,210 --> 00:35:14,799 Not quite so easy with dot com these 1074 00:35:14,800 --> 00:35:15,800 days. 1075 00:35:18,910 --> 00:35:21,009 Yeah. So after this import, 1076 00:35:21,010 --> 00:35:23,349 we can resolve. But now from 1077 00:35:23,350 --> 00:35:25,539 DNS to DNS, well and DNS 1078 00:35:25,540 --> 00:35:27,609 names are not global unique, but we 1079 00:35:27,610 --> 00:35:29,589 have these issues. We do web browsing 1080 00:35:29,590 --> 00:35:31,809 like virtual hosting and SSL, 1081 00:35:31,810 --> 00:35:32,749 where existing protocol. 1082 00:35:32,750 --> 00:35:34,539 Let's assume that the HDP host header 1083 00:35:34,540 --> 00:35:37,029 contains the hostname, 1084 00:35:37,030 --> 00:35:38,979 and the web server really wants it to be 1085 00:35:38,980 --> 00:35:39,879 the right one. 1086 00:35:39,880 --> 00:35:42,009 And the SSL certificates it says, you 1087 00:35:42,010 --> 00:35:44,319 know, got off the mark 1088 00:35:44,320 --> 00:35:46,269 and it doesn't say growth of that group, 1089 00:35:46,270 --> 00:35:48,039 and hence browsers will hate it. 1090 00:35:49,120 --> 00:35:50,799 So one solution for this be deployed is 1091 00:35:50,800 --> 00:35:53,079 the client side Sox proxy, effectively 1092 00:35:53,080 --> 00:35:55,029 proxy that will fix everything up for the 1093 00:35:55,030 --> 00:35:56,080 browser and makes us happy. 1094 00:35:57,650 --> 00:35:59,889 Right? So you can put into DNS 1095 00:35:59,890 --> 00:36:01,179 a legacy hostname, which effectively 1096 00:36:01,180 --> 00:36:02,949 says, Well, yeah, you know this good of 1097 00:36:02,950 --> 00:36:05,049 the glue guy and the legacy system. 1098 00:36:05,050 --> 00:36:06,669 It's called good off the mark. 1099 00:36:06,670 --> 00:36:08,769 So when you go and validate against the 1100 00:36:08,770 --> 00:36:11,079 system, if you have to, well, 1101 00:36:11,080 --> 00:36:12,699 if the certificate says go of that, OK, 1102 00:36:12,700 --> 00:36:14,169 that's OK. 1103 00:36:14,170 --> 00:36:15,849 All right. And if you have to talk to a 1104 00:36:15,850 --> 00:36:17,259 legacy web server on that machine, just 1105 00:36:17,260 --> 00:36:18,849 put in a whole set of says I'm going to 1106 00:36:18,850 --> 00:36:20,919 go to talk as opposed to going after 1107 00:36:20,920 --> 00:36:23,349 going to ISO, 1108 00:36:23,350 --> 00:36:24,939 the web server goes and says, I want a 1109 00:36:24,940 --> 00:36:27,189 WWE body talking to the proxy translator 1110 00:36:27,190 --> 00:36:28,729 to, Oh yeah, I'm going to go to college 1111 00:36:28,730 --> 00:36:30,189 degree, but I'm going to put in Bob's 1112 00:36:30,190 --> 00:36:31,929 website dot com, right? 1113 00:36:33,440 --> 00:36:35,259 And yeah. 1114 00:36:35,260 --> 00:36:36,879 Second possibility again, as this 1115 00:36:36,880 --> 00:36:39,069 certificate, the local proxy effectively 1116 00:36:39,070 --> 00:36:40,509 is a certificate authority. 1117 00:36:40,510 --> 00:36:42,189 We have scripts to automatically import 1118 00:36:42,190 --> 00:36:43,599 the certificate of this certificate 1119 00:36:43,600 --> 00:36:44,859 authority that runs on your own machine 1120 00:36:44,860 --> 00:36:46,389 into your own browser. 1121 00:36:46,390 --> 00:36:48,809 So you're trusting just on loop back here 1122 00:36:48,810 --> 00:36:50,439 what you're doing yourself a mat in the 1123 00:36:50,440 --> 00:36:51,440 middle, right? 1124 00:36:52,450 --> 00:36:53,829 That's safe. 1125 00:36:53,830 --> 00:36:55,149 If your own machine is safe. 1126 00:36:57,070 --> 00:36:59,199 So again, the web request goes to Bob 1127 00:36:59,200 --> 00:37:01,209 Duncan, who actually goes up to Bob's 1128 00:37:01,210 --> 00:37:02,199 website dot com. 1129 00:37:02,200 --> 00:37:03,639 We validate the answer. 1130 00:37:03,640 --> 00:37:05,919 Again, we can vote against x 5.9 PCI, 1131 00:37:05,920 --> 00:37:07,209 or we could vote against the tell us. 1132 00:37:07,210 --> 00:37:08,709 A record depends on whatever is in the 1133 00:37:08,710 --> 00:37:10,809 DNS system, and we tell the 1134 00:37:10,810 --> 00:37:11,919 browser, Yeah, this is a valid 1135 00:37:11,920 --> 00:37:14,059 certificate for Bob. They're going to 1136 00:37:14,060 --> 00:37:15,879 tell you will trust us because we are his 1137 00:37:15,880 --> 00:37:16,880 trusted CAA. 1138 00:37:18,600 --> 00:37:20,829 OK, now proxies 1139 00:37:20,830 --> 00:37:22,209 are a mess. 1140 00:37:22,210 --> 00:37:23,529 Let me just say this is the proxy does 1141 00:37:23,530 --> 00:37:25,089 not work as well as I would like it to. 1142 00:37:26,650 --> 00:37:28,029 So in the long term, it would of course, 1143 00:37:28,030 --> 00:37:29,559 be nicer to just integrate this 1144 00:37:29,560 --> 00:37:30,880 understanding into the browser. 1145 00:37:32,800 --> 00:37:34,869 And if 1146 00:37:34,870 --> 00:37:36,189 we have virtual hosting, we could, of 1147 00:37:36,190 --> 00:37:38,169 course, just put another headline saying, 1148 00:37:38,170 --> 00:37:40,269 OK, please don't go for the legacy 1149 00:37:40,270 --> 00:37:41,469 hostname. Here's the DNS zone. 1150 00:37:41,470 --> 00:37:43,869 I want this public key swept web server 1151 00:37:43,870 --> 00:37:45,699 instead of a hostname record. 1152 00:37:45,700 --> 00:37:47,439 And again, if we move to Telus Records as 1153 00:37:47,440 --> 00:37:49,599 opposed to using X17 existing 1154 00:37:49,600 --> 00:37:51,669 picker, we are again better off 1155 00:37:51,670 --> 00:37:52,670 there. 1156 00:37:53,470 --> 00:37:54,470 OK. 1157 00:37:55,510 --> 00:37:57,969 Relative names. So we have this notion 1158 00:37:57,970 --> 00:38:00,159 that in some DNS record types, I can 1159 00:38:00,160 --> 00:38:02,319 put in names of other, 1160 00:38:02,320 --> 00:38:04,539 uh, uh, 1161 00:38:04,540 --> 00:38:06,069 other names. For example, in the NSA 1162 00:38:06,070 --> 00:38:08,409 record, I can put mail dot 1163 00:38:08,410 --> 00:38:10,089 dot org right or in C. 1164 00:38:10,090 --> 00:38:11,739 name records. I put whatever the real 1165 00:38:11,740 --> 00:38:12,849 canonical name of the machine is 1166 00:38:12,850 --> 00:38:15,009 something that's called something else. 1167 00:38:15,010 --> 00:38:16,539 Now here, if you put it in an absolute 1168 00:38:16,540 --> 00:38:18,909 name, I can delegates to DNS. 1169 00:38:18,910 --> 00:38:20,979 I can put into the Zwicky or I can 1170 00:38:20,980 --> 00:38:22,089 put it in the relative name. So if you 1171 00:38:22,090 --> 00:38:24,339 put Dot Plus at the end, says the name 1172 00:38:24,340 --> 00:38:26,019 I'm giving you in this record is relative 1173 00:38:26,020 --> 00:38:27,250 to what you've resulted from. 1174 00:38:28,720 --> 00:38:30,639 So we just use relative host names with 1175 00:38:30,640 --> 00:38:33,549 Dot Plus, which 1176 00:38:33,550 --> 00:38:35,139 again would be nice if browsers supported 1177 00:38:35,140 --> 00:38:36,140 those kind of links. 1178 00:38:38,710 --> 00:38:40,779 New record types we saw already, we 1179 00:38:40,780 --> 00:38:42,249 have public records, we've got neck 1180 00:38:42,250 --> 00:38:45,189 records and legacy hostname records. 1181 00:38:45,190 --> 00:38:47,409 We've added records genes to DNA 1182 00:38:47,410 --> 00:38:49,509 so we can say, OK, this sub domain, 1183 00:38:49,510 --> 00:38:51,129 I'll go back to DNS and resolve using 1184 00:38:51,130 --> 00:38:52,599 DNS. 1185 00:38:52,600 --> 00:38:54,339 We have VPN records, but we can say, OK, 1186 00:38:54,340 --> 00:38:56,469 this machine is actually hosted within 1187 00:38:56,470 --> 00:38:57,699 the peer-to-peer overlay. 1188 00:38:57,700 --> 00:38:59,139 Establish a peer-to-peer tunnel to the 1189 00:38:59,140 --> 00:39:01,389 target, relay the IP traffic over it. 1190 00:39:01,390 --> 00:39:03,459 And when a normal legacy application 1191 00:39:03,460 --> 00:39:04,929 comes and says I want an IP address, 1192 00:39:04,930 --> 00:39:05,889 we'll give it one of the virtual 1193 00:39:05,890 --> 00:39:07,689 interface and synthesize it. 1194 00:39:07,690 --> 00:39:09,670 We have phone records for conversation 1195 00:39:11,110 --> 00:39:14,229 and yeah, 1196 00:39:14,230 --> 00:39:15,639 that was a very short version of that. 1197 00:39:19,390 --> 00:39:20,739 But part of it wasn't all about 1198 00:39:20,740 --> 00:39:22,149 conversation. 1199 00:39:22,150 --> 00:39:24,199 Florian might present some more, and new 1200 00:39:24,200 --> 00:39:26,719 crypto at the assembly and 1201 00:39:26,720 --> 00:39:28,149 course represent our approach to 1202 00:39:28,150 --> 00:39:30,699 unlocking. So please come to our assembly 1203 00:39:30,700 --> 00:39:32,049 in the next couple of days and have more 1204 00:39:32,050 --> 00:39:33,429 fun with secure networking. 1205 00:39:35,800 --> 00:39:37,029 There are also, of course, concerns with 1206 00:39:37,030 --> 00:39:38,919 how to integrate. This is my application, 1207 00:39:38,920 --> 00:39:40,479 so we haven't set a socks proxy. 1208 00:39:40,480 --> 00:39:42,519 You can plug it into NSA Lipsy name 1209 00:39:42,520 --> 00:39:44,439 services switch as a plugin. 1210 00:39:44,440 --> 00:39:46,719 We can intercept DNS packets using DNS 1211 00:39:46,720 --> 00:39:48,039 servers, effectively revise your firewall 1212 00:39:48,040 --> 00:39:50,139 rules to give all DNS traffic to us, 1213 00:39:50,140 --> 00:39:51,670 and then we can mess with it if needed. 1214 00:39:52,720 --> 00:39:54,579 We have a API to access the whole thing 1215 00:39:54,580 --> 00:39:55,689 we have in the process. Communication 1216 00:39:55,690 --> 00:39:57,189 protocol if you hate, see, and there's a 1217 00:39:57,190 --> 00:39:59,469 command line tool, or 1218 00:39:59,470 --> 00:40:01,089 of course, you can write your little C 1219 00:40:01,090 --> 00:40:03,339 code and call our command module 1220 00:40:03,340 --> 00:40:05,039 many ways to integrate it. 1221 00:40:05,040 --> 00:40:06,879 Now Julius is part of Knutsen zero point 1222 00:40:06,880 --> 00:40:08,199 nine three, but we changed all of the 1223 00:40:08,200 --> 00:40:10,299 crypto and 0.10, 1224 00:40:10,300 --> 00:40:11,829 which is out like four days ago. 1225 00:40:11,830 --> 00:40:12,830 Now, 1226 00:40:14,350 --> 00:40:15,849 international domain names are supported. 1227 00:40:15,850 --> 00:40:17,259 In case you're wondering, the 1228 00:40:17,260 --> 00:40:18,969 installation of I should warn you is 1229 00:40:18,970 --> 00:40:19,970 non-trivial. 1230 00:40:21,260 --> 00:40:22,899 I wrote instructions for Start with 1231 00:40:22,900 --> 00:40:25,239 Debian stable and start with pinning and 1232 00:40:25,240 --> 00:40:26,829 mixing. Your system was unstable and 1233 00:40:26,830 --> 00:40:28,029 stable and then download a couple of 1234 00:40:28,030 --> 00:40:29,030 source codes. 1235 00:40:32,020 --> 00:40:34,179 Yeah, for not all of our 1236 00:40:34,180 --> 00:40:35,949 record types, we have a nice voice, but 1237 00:40:35,950 --> 00:40:36,950 for most of them, 1238 00:40:38,110 --> 00:40:40,239 we're trying to have a genius key 1239 00:40:40,240 --> 00:40:42,339 exchange party where you print your 1240 00:40:42,340 --> 00:40:44,529 QR codes and give them to your buddy that 1241 00:40:44,530 --> 00:40:46,239 they have been introduced. 1242 00:40:46,240 --> 00:40:48,009 Of course, you can then put into your DNS 1243 00:40:48,010 --> 00:40:50,109 owns your, you know, BGP keys if you 1244 00:40:50,110 --> 00:40:51,110 want. That's great. 1245 00:40:52,150 --> 00:40:54,009 So go ahead and start going today. 1246 00:40:54,010 --> 00:40:55,509 Create your private keys. 1247 00:40:55,510 --> 00:40:57,579 You can use BCD, the business 1248 00:40:57,580 --> 00:40:59,289 card daemon, to launch a web server where 1249 00:40:59,290 --> 00:41:00,609 you can type in your details and get the 1250 00:41:00,610 --> 00:41:02,619 PDF with your business card. 1251 00:41:02,620 --> 00:41:04,419 Need to install it, though, and you can 1252 00:41:04,420 --> 00:41:05,889 give the PDFs to Ireland for printing. 1253 00:41:07,180 --> 00:41:08,180 Thank you. 1254 00:41:20,660 --> 00:41:21,859 Thank you. 1255 00:41:21,860 --> 00:41:22,849 We are really quick. 1256 00:41:22,850 --> 00:41:25,039 Speak up and speed up 1257 00:41:25,040 --> 00:41:26,040 at no problem is the question. 1258 00:41:26,990 --> 00:41:28,189 I've seen this. 1259 00:41:28,190 --> 00:41:30,079 If you have any questions, you can ask 1260 00:41:30,080 --> 00:41:31,999 them now. And no, there's at least one 1261 00:41:32,000 --> 00:41:34,219 question on the internet, and I think 1262 00:41:34,220 --> 00:41:35,590 we start with this question. 1263 00:41:37,070 --> 00:41:39,139 User Pepper, 64, wants 1264 00:41:39,140 --> 00:41:41,299 to know about collision detection on 1265 00:41:41,300 --> 00:41:43,729 key look up, especially the short keys. 1266 00:41:45,640 --> 00:41:47,859 Traditional attacks on key look up, 1267 00:41:49,150 --> 00:41:51,010 the collision detection on key look up, 1268 00:41:52,750 --> 00:41:54,579 collision detection on key look up. 1269 00:41:54,580 --> 00:41:56,289 Yeah, what kind of collision we have for 1270 00:41:56,290 --> 00:41:57,909 the public is we don't even use hashes of 1271 00:41:57,910 --> 00:41:59,229 public keys here, so I'm not sure what 1272 00:41:59,230 --> 00:42:00,699 kind of collisions he's thinking about. 1273 00:42:00,700 --> 00:42:02,829 I think in the DHT, you saw 1274 00:42:02,830 --> 00:42:03,830 something. 1275 00:42:04,330 --> 00:42:06,519 OK, the DHT use five and 12 bit hashes. 1276 00:42:06,520 --> 00:42:08,349 We assume that there aren't collisions 1277 00:42:08,350 --> 00:42:09,819 there, the likelihood of there being a 1278 00:42:09,820 --> 00:42:11,949 512 bit collision that 1279 00:42:11,950 --> 00:42:13,989 was a decent hash function. 1280 00:42:13,990 --> 00:42:15,069 It's more likely you get hit by 1281 00:42:15,070 --> 00:42:16,070 lightning. 1282 00:42:16,630 --> 00:42:17,630 Way more likely. 1283 00:42:19,060 --> 00:42:20,920 OK, then microphone to 1284 00:42:21,970 --> 00:42:22,199 you. 1285 00:42:22,200 --> 00:42:24,129 A bit of a technical question, but I 1286 00:42:24,130 --> 00:42:26,289 don't quite understand how the how your 1287 00:42:26,290 --> 00:42:28,869 set different thing or set resolution 1288 00:42:28,870 --> 00:42:31,209 thing is that efficient because you rely 1289 00:42:31,210 --> 00:42:32,769 on the set up of all these boom filters. 1290 00:42:32,770 --> 00:42:34,749 And the way I understand it, like setting 1291 00:42:34,750 --> 00:42:36,019 up a bloom filter is over in. 1292 00:42:37,030 --> 00:42:38,769 Yeah, but you do this once you don't have 1293 00:42:38,770 --> 00:42:41,079 to do it for every interaction and never 1294 00:42:41,080 --> 00:42:43,339 choice, so each time. 1295 00:42:43,340 --> 00:42:45,499 With the revocation 1296 00:42:45,500 --> 00:42:46,500 comes to. 1297 00:42:48,830 --> 00:42:51,169 OK, I was so it's amateurish. 1298 00:42:51,170 --> 00:42:52,729 You can do it once ahead of time. 1299 00:42:52,730 --> 00:42:54,379 And most importantly, this is really only 1300 00:42:54,380 --> 00:42:56,089 local CPU consumption on the network. 1301 00:42:56,090 --> 00:42:57,349 You don't have to do this. 1302 00:42:57,350 --> 00:42:58,819 So what I'm as a networking person 1303 00:42:58,820 --> 00:43:00,019 concerned about is how much network 1304 00:43:00,020 --> 00:43:01,309 traffic do I have? 1305 00:43:01,310 --> 00:43:02,719 The fact that I might have a database 1306 00:43:02,720 --> 00:43:03,859 with a million entries have to do an 1307 00:43:03,860 --> 00:43:06,469 iteration of a once a 1308 00:43:06,470 --> 00:43:08,029 so circular. 1309 00:43:08,030 --> 00:43:10,039 I'm curious to see us having a million 1310 00:43:10,040 --> 00:43:11,269 revocation keys first. 1311 00:43:11,270 --> 00:43:13,339 Right? So the circular slide that 1312 00:43:13,340 --> 00:43:15,529 had like the multiple apps inside 1313 00:43:15,530 --> 00:43:16,999 each other. This is something that 1314 00:43:17,000 --> 00:43:18,519 continues to exist on your system, and 1315 00:43:18,520 --> 00:43:19,999 it's not something you compute when you 1316 00:43:20,000 --> 00:43:21,489 meet another peer to peer to peer server. 1317 00:43:22,760 --> 00:43:25,009 The strata estimate is 1318 00:43:25,010 --> 00:43:26,239 actually totally static. 1319 00:43:26,240 --> 00:43:29,359 So for the IWBF, 1320 00:43:29,360 --> 00:43:31,459 you may have to re 1321 00:43:31,460 --> 00:43:33,619 compute the larger one if some 1322 00:43:33,620 --> 00:43:36,319 of the reconciliations fail. 1323 00:43:36,320 --> 00:43:38,629 But this 1324 00:43:38,630 --> 00:43:40,849 data structures toys are static 1325 00:43:40,850 --> 00:43:41,850 for your whole set. 1326 00:43:42,860 --> 00:43:44,899 OK, that's another question. 1327 00:43:44,900 --> 00:43:47,929 Yeah, I had a question about, 1328 00:43:47,930 --> 00:43:50,119 for example, dynamic DNS what 1329 00:43:50,120 --> 00:43:52,189 we have today. And if you're 1330 00:43:52,190 --> 00:43:53,599 half changing IP addresses, 1331 00:43:54,620 --> 00:43:56,929 how fast can you propagate these in the 1332 00:43:56,930 --> 00:43:59,179 network if you don't know your 1333 00:43:59,180 --> 00:44:00,199 new IP address? 1334 00:44:00,200 --> 00:44:01,939 And yeah, yeah, OK. 1335 00:44:01,940 --> 00:44:03,769 So the question let me repeat it was 1336 00:44:03,770 --> 00:44:06,139 suppose to have didn't DNS and my telecom 1337 00:44:06,140 --> 00:44:07,579 changes my IP address every twenty four 1338 00:44:07,580 --> 00:44:08,899 hours and I can't predict. 1339 00:44:08,900 --> 00:44:10,969 So the shadow records won't help me at 1340 00:44:10,970 --> 00:44:13,159 all because I don't know what I'm having 1341 00:44:13,160 --> 00:44:14,209 as an IP address tomorrow. 1342 00:44:15,410 --> 00:44:17,059 Well, that's again a question of how good 1343 00:44:17,060 --> 00:44:18,019 is the DHT? 1344 00:44:18,020 --> 00:44:20,119 And yes, 1345 00:44:20,120 --> 00:44:22,009 you might have a downtime of a couple of 1346 00:44:22,010 --> 00:44:23,239 minutes or an hour, depending on how 1347 00:44:23,240 --> 00:44:25,489 aggressive you put stuff into the DHT. 1348 00:44:26,510 --> 00:44:28,249 But really, ultimately, I wouldn't even 1349 00:44:28,250 --> 00:44:30,409 want to use IP addresses 1350 00:44:30,410 --> 00:44:32,029 in. I want to hold stuff in the peer to 1351 00:44:32,030 --> 00:44:34,099 peer network. I want to, you know, have 1352 00:44:34,100 --> 00:44:35,689 social applications where I address my 1353 00:44:35,690 --> 00:44:37,819 friends and I may not have this 1354 00:44:37,820 --> 00:44:39,529 problem as IP is changing so much. 1355 00:44:39,530 --> 00:44:41,149 But yes, the DHT is then again, the 1356 00:44:41,150 --> 00:44:42,589 question of how fast to Google things. 1357 00:44:42,590 --> 00:44:44,659 So that's a performance issue, but 1358 00:44:44,660 --> 00:44:45,679 it's not a security issue. 1359 00:44:47,300 --> 00:44:49,460 OK. Another question that's microphone to 1360 00:44:50,900 --> 00:44:53,569 your well, what is 1361 00:44:53,570 --> 00:44:54,739 the use case? 1362 00:44:54,740 --> 00:44:56,959 I mean, I can see a lot of use case 1363 00:44:56,960 --> 00:44:59,659 for geeks and 1364 00:44:59,660 --> 00:45:01,099 some, but 1365 00:45:02,300 --> 00:45:04,519 in commercial applications 1366 00:45:04,520 --> 00:45:06,229 and a large scale. 1367 00:45:06,230 --> 00:45:08,899 Um, do you think there is a concept 1368 00:45:08,900 --> 00:45:10,880 how one can use that there? 1369 00:45:11,900 --> 00:45:13,849 Well, my first use case that I'm trying 1370 00:45:13,850 --> 00:45:16,069 to get implemented working nicely is 1371 00:45:16,070 --> 00:45:17,569 not conversation with it. 1372 00:45:17,570 --> 00:45:19,039 Ideas I want to call you. 1373 00:45:19,040 --> 00:45:20,569 I'm going to court, you know, you are 1374 00:45:20,570 --> 00:45:22,759 going to as a call, you can do, 1375 00:45:22,760 --> 00:45:23,899 and that's your address. 1376 00:45:23,900 --> 00:45:25,639 I don't need a, you know, company that I 1377 00:45:25,640 --> 00:45:27,169 trust was managing aims. 1378 00:45:27,170 --> 00:45:29,359 I don't need to exempt a trust 1379 00:45:29,360 --> 00:45:30,409 based federation. 1380 00:45:30,410 --> 00:45:31,709 I can just say, OK, I want to call you. 1381 00:45:31,710 --> 00:45:32,839 You gave me your business card. 1382 00:45:32,840 --> 00:45:34,189 Now you say, Hey, you should call my 1383 00:45:34,190 --> 00:45:36,439 buddy and I just his buddy that you took 1384 00:45:36,440 --> 00:45:38,209 two and a half your buddy securely. 1385 00:45:38,210 --> 00:45:39,649 Right? So for those kind of social 1386 00:45:39,650 --> 00:45:41,269 networking applications, these these are 1387 00:45:41,270 --> 00:45:43,639 my friends. These are my social 1388 00:45:43,640 --> 00:45:45,289 rooms that we meet or we exchange 1389 00:45:45,290 --> 00:45:47,389 information bulletin boards where 1390 00:45:47,390 --> 00:45:48,379 these kind of identity matching 1391 00:45:48,380 --> 00:45:49,369 applications that are fundamentally 1392 00:45:49,370 --> 00:45:51,079 decentralized. But right now, we can't 1393 00:45:51,080 --> 00:45:52,879 even get people to use DNS because they 1394 00:45:52,880 --> 00:45:54,109 don't want to pay the registration fees 1395 00:45:54,110 --> 00:45:56,179 and they can't administer DNS 1396 00:45:56,180 --> 00:45:57,739 printing out these business cards. 1397 00:45:57,740 --> 00:45:59,869 When you are able to install the software 1398 00:45:59,870 --> 00:46:01,429 and giving that to your friend and then 1399 00:46:01,430 --> 00:46:02,719 the friend saying, Oh, you know, I have 1400 00:46:02,720 --> 00:46:04,909 you as friends are going to vote and 1401 00:46:04,910 --> 00:46:06,799 now I can call you now I can access your 1402 00:46:06,800 --> 00:46:08,419 social profile. Now I can do all of these 1403 00:46:08,420 --> 00:46:10,849 things was that I think that is something 1404 00:46:10,850 --> 00:46:13,220 that we can get into the mainstream. 1405 00:46:16,010 --> 00:46:17,489 OK, thank you. 1406 00:46:17,490 --> 00:46:19,339 Yes, another question that's microphone 1407 00:46:19,340 --> 00:46:20,059 one, is it? 1408 00:46:20,060 --> 00:46:22,279 Yeah. So the way I understand 1409 00:46:22,280 --> 00:46:24,469 it, you provide authenticity 1410 00:46:24,470 --> 00:46:25,759 and integrity. 1411 00:46:25,760 --> 00:46:27,619 And so that means if I get a message, I 1412 00:46:27,620 --> 00:46:30,089 know it is from that person and so on. 1413 00:46:30,090 --> 00:46:32,599 And but what about robustness? 1414 00:46:32,600 --> 00:46:34,459 I mean, what if somebody actually tries 1415 00:46:34,460 --> 00:46:36,019 to screw up your system, maybe by 1416 00:46:36,020 --> 00:46:38,299 flooding it with wrong messages or 1417 00:46:38,300 --> 00:46:40,789 like, you know, like the NSA, 1418 00:46:40,790 --> 00:46:42,529 let's say it has a botnet and tries to 1419 00:46:42,530 --> 00:46:44,599 flood everything with wrong messages and 1420 00:46:44,600 --> 00:46:47,189 maybe tries to corrupt also 1421 00:46:47,190 --> 00:46:49,249 hash tables on your side and chooses and 1422 00:46:49,250 --> 00:46:50,599 chooses the message as well. 1423 00:46:50,600 --> 00:46:52,879 How would you say and basically use 1424 00:46:52,880 --> 00:46:53,889 your system? 1425 00:46:53,890 --> 00:46:55,849 OK. So the question is what if somebody 1426 00:46:55,850 --> 00:46:58,069 attacks the DHT effectively? 1427 00:46:58,070 --> 00:46:59,959 Well, firstly off the fence, we obviously 1428 00:46:59,960 --> 00:47:01,459 can't give us invalid requests that have 1429 00:47:01,460 --> 00:47:03,079 to be signed. 1430 00:47:03,080 --> 00:47:04,819 But yes, if you have lots of bandwidth 1431 00:47:04,820 --> 00:47:06,769 in, you know, you can just $d us. 1432 00:47:06,770 --> 00:47:08,839 And yeah, well, most systems don't 1433 00:47:08,840 --> 00:47:10,069 survive Adidas unless they are big 1434 00:47:10,070 --> 00:47:11,099 enough, right? 1435 00:47:11,100 --> 00:47:12,109 I can't fix that. 1436 00:47:12,110 --> 00:47:13,789 Overall, we of course, tried to avoid the 1437 00:47:13,790 --> 00:47:15,049 issue itself as efficient. 1438 00:47:15,050 --> 00:47:17,299 So you have a hard time making very 1439 00:47:17,300 --> 00:47:18,589 expensive operations happen. 1440 00:47:18,590 --> 00:47:19,939 We try to route around peers that are 1441 00:47:19,940 --> 00:47:21,270 misbehaving in the DHT. 1442 00:47:22,340 --> 00:47:23,599 But it's a question of how do we see of 1443 00:47:23,600 --> 00:47:25,069 the. I didn't talk about the DHT here 1444 00:47:25,070 --> 00:47:26,959 because I didn't have five hours. 1445 00:47:26,960 --> 00:47:29,689 So I'm sorry. But you can read 1446 00:47:29,690 --> 00:47:31,789 Nathan Evans, Ph.D., thesis or 1447 00:47:31,790 --> 00:47:33,439 our paper on our five end, which is to 1448 00:47:33,440 --> 00:47:35,569 ADHD, which has some more details 1449 00:47:35,570 --> 00:47:37,879 and measurements and experiments on our 1450 00:47:37,880 --> 00:47:39,799 current ADHD non-autistic new name 1451 00:47:39,800 --> 00:47:42,379 system. Yes, it needs ADHD. 1452 00:47:42,380 --> 00:47:44,659 The theory works with any DHT. 1453 00:47:44,660 --> 00:47:45,709 So if you have a better one? 1454 00:47:45,710 --> 00:47:47,239 Let us know. 1455 00:47:47,240 --> 00:47:49,039 OK. OK, we have another question on the 1456 00:47:49,040 --> 00:47:50,040 internet. 1457 00:47:50,630 --> 00:47:52,969 The question is if revocation 1458 00:47:52,970 --> 00:47:54,529 lists grow too big. 1459 00:47:54,530 --> 00:47:56,719 Is there a plan for a of 1460 00:47:56,720 --> 00:47:57,720 lists? 1461 00:47:59,060 --> 00:48:00,649 OK, so the question was the revocation 1462 00:48:00,650 --> 00:48:02,029 list go to a big they're plan for 1463 00:48:02,030 --> 00:48:03,769 versioning of lists. 1464 00:48:03,770 --> 00:48:05,899 There was a plan where I would sort of 1465 00:48:05,900 --> 00:48:07,819 in the far future, implementing a slight 1466 00:48:07,820 --> 00:48:09,349 exception for who would say if I've 1467 00:48:09,350 --> 00:48:11,089 talked to this peer recently and be 1468 00:48:11,090 --> 00:48:13,189 reconciled our revocation lists and 1469 00:48:13,190 --> 00:48:14,629 we know we had, you know, a thousand 1470 00:48:14,630 --> 00:48:16,189 entries in that revocation list. 1471 00:48:16,190 --> 00:48:17,809 I can just skip going over those thousand 1472 00:48:17,810 --> 00:48:19,189 at that point. 1473 00:48:19,190 --> 00:48:20,809 So if if I have interactive with stop 1474 00:48:20,810 --> 00:48:22,449 here recently before, I only have to go 1475 00:48:22,450 --> 00:48:23,719 over all of the entries that are newer 1476 00:48:23,720 --> 00:48:25,549 than that, but I don't quite see that 1477 00:48:25,550 --> 00:48:27,199 being necessary for quite some time. 1478 00:48:27,200 --> 00:48:29,749 Honestly, I have not 1479 00:48:29,750 --> 00:48:31,399 really gotten the data, but I don't think 1480 00:48:31,400 --> 00:48:33,439 even for X 5.9 Picard, they are all that 1481 00:48:33,440 --> 00:48:35,059 many revocations to worry about this. 1482 00:48:36,500 --> 00:48:37,500 Maybe there should be. But 1483 00:48:39,170 --> 00:48:40,969 in practice, I personally think 1484 00:48:40,970 --> 00:48:42,289 revocation is only going to be done by a 1485 00:48:42,290 --> 00:48:44,569 high profile users that really got badly 1486 00:48:44,570 --> 00:48:46,699 hit. And most users are probably going 1487 00:48:46,700 --> 00:48:48,019 to forget to create their replication 1488 00:48:48,020 --> 00:48:49,819 certificate and be not even noticed that 1489 00:48:49,820 --> 00:48:51,800 they got compromised or c not care. 1490 00:48:53,210 --> 00:48:54,829 So this is not really a feature for if 1491 00:48:54,830 --> 00:48:56,389 you, you know Jacob Appelbaum and you 1492 00:48:56,390 --> 00:48:57,559 really need to rip off your key, 1493 00:48:58,580 --> 00:49:00,169 then you have a mechanism and then you'll 1494 00:49:00,170 --> 00:49:01,170 be hard to stop it. 1495 00:49:02,060 --> 00:49:03,530 OK, another question over here. 1496 00:49:05,360 --> 00:49:07,189 I mean, I don't really understand why you 1497 00:49:07,190 --> 00:49:09,499 would need to keep the revocation 1498 00:49:09,500 --> 00:49:10,640 certificates forever. 1499 00:49:12,380 --> 00:49:14,329 Couldn't you just limit the lifetime of 1500 00:49:14,330 --> 00:49:16,729 everything that's put into the DHT? 1501 00:49:16,730 --> 00:49:18,259 OK, the question was, can you limit the 1502 00:49:18,260 --> 00:49:20,599 lifetime of everything in the in the. 1503 00:49:20,600 --> 00:49:22,309 Yes. But whenever I get something from 1504 00:49:22,310 --> 00:49:23,719 the DHT, what we didn't talk about here 1505 00:49:23,720 --> 00:49:25,729 was we have a local cache and the local 1506 00:49:25,730 --> 00:49:27,079 cache just looks at how long was this 1507 00:49:27,080 --> 00:49:28,489 record valid? 1508 00:49:28,490 --> 00:49:31,339 And I can, of course, say, you know, my 1509 00:49:31,340 --> 00:49:33,949 delegation to you is valid forever, 1510 00:49:33,950 --> 00:49:34,969 right? 1511 00:49:34,970 --> 00:49:37,219 And I can't take that back even right. 1512 00:49:37,220 --> 00:49:38,659 So the problem is, and somebody might 1513 00:49:38,660 --> 00:49:40,429 have taken that into his cache, which is 1514 00:49:40,430 --> 00:49:41,659 great. He doesn't need to go back to the 1515 00:49:41,660 --> 00:49:43,189 DHT. He doesn't need to have the 1516 00:49:43,190 --> 00:49:44,749 availability. All of that doesn't matter. 1517 00:49:44,750 --> 00:49:46,909 He has it all in his local cache, but 1518 00:49:46,910 --> 00:49:47,989 now it's in the local cache. 1519 00:49:49,040 --> 00:49:50,299 Even if the issue doesn't happen anymore, 1520 00:49:50,300 --> 00:49:51,499 it might still be used and we have to 1521 00:49:51,500 --> 00:49:52,500 prevent that. 1522 00:49:53,690 --> 00:49:54,589 So it's really for the case where 1523 00:49:54,590 --> 00:49:55,939 somebody picked an excessively long 1524 00:49:55,940 --> 00:49:58,009 expiration time for PKI 1525 00:49:58,010 --> 00:49:59,119 delegation. 1526 00:49:59,120 --> 00:50:00,919 But couldn't you just require that it 1527 00:50:00,920 --> 00:50:01,999 needs to be refreshed 1528 00:50:02,000 --> 00:50:04,409 after, say, six months or something 1529 00:50:04,410 --> 00:50:06,349 that if I require that something needs to 1530 00:50:06,350 --> 00:50:07,669 be refreshed, that again opens a 1531 00:50:07,670 --> 00:50:08,749 possibility for censorship? 1532 00:50:08,750 --> 00:50:10,579 I could say, OK, you know, I'm going to 1533 00:50:10,580 --> 00:50:12,799 force people to delete something. 1534 00:50:12,800 --> 00:50:14,059 I just want to remove something. 1535 00:50:14,060 --> 00:50:15,679 I want to make sure that, you know, if I 1536 00:50:15,680 --> 00:50:18,169 met this guy and nothing compromise 1537 00:50:18,170 --> 00:50:19,309 the security, no, it's going to stay 1538 00:50:19,310 --> 00:50:21,079 valid forever. But I don't need to have 1539 00:50:21,080 --> 00:50:23,089 another look up, don't need to expose to 1540 00:50:23,090 --> 00:50:24,019 the rest of the world, even that I'm 1541 00:50:24,020 --> 00:50:25,249 doing a lock up, even if they can't tell 1542 00:50:25,250 --> 00:50:26,250 what I'm doing. 1543 00:50:27,170 --> 00:50:28,170 OK? 1544 00:50:28,410 --> 00:50:30,559 OK. And back there another 1545 00:50:30,560 --> 00:50:31,560 question. 1546 00:50:32,150 --> 00:50:33,619 It seems to me that it's quite 1547 00:50:33,620 --> 00:50:35,689 complicated to fit this into 1548 00:50:35,690 --> 00:50:37,279 the current stack with the browser and 1549 00:50:37,280 --> 00:50:38,280 everything. 1550 00:50:38,750 --> 00:50:40,999 My question would be is that how 1551 00:50:41,000 --> 00:50:42,019 good? 1552 00:50:42,020 --> 00:50:44,839 How much better can you improve the this 1553 00:50:44,840 --> 00:50:46,460 technique that you just described? 1554 00:50:48,230 --> 00:50:49,609 OK, the question was how can how much 1555 00:50:49,610 --> 00:50:50,869 better can I improve the technique I 1556 00:50:50,870 --> 00:50:51,870 described? 1557 00:50:53,210 --> 00:50:54,919 I don't know. We don't know a better way. 1558 00:50:54,920 --> 00:50:55,940 Otherwise, we would have done it. 1559 00:50:57,020 --> 00:50:57,979 OK. 1560 00:50:57,980 --> 00:50:59,210 Let me rephrase it. 1561 00:51:00,710 --> 00:51:02,779 Do you think it would be 1562 00:51:02,780 --> 00:51:04,849 possible to get the cooperation 1563 00:51:04,850 --> 00:51:06,510 of browser vendors and stuff like that? 1564 00:51:07,670 --> 00:51:09,859 I think there is a certain browser vendor 1565 00:51:09,860 --> 00:51:12,349 which is called the Tor Browser Bundle, 1566 00:51:12,350 --> 00:51:13,909 and we've been talking with these people 1567 00:51:13,910 --> 00:51:16,129 a bit that might be rather interested 1568 00:51:16,130 --> 00:51:18,259 in adding support for this. 1569 00:51:18,260 --> 00:51:20,059 I do not think it's likely that we're 1570 00:51:20,060 --> 00:51:21,229 going to make it into IMS Explorer 1571 00:51:21,230 --> 00:51:22,230 anytime soon. 1572 00:51:24,530 --> 00:51:25,530 Thanks. 1573 00:51:33,370 --> 00:51:35,769 OK. I don't see any other questions. 1574 00:51:35,770 --> 00:51:37,719 We have five minutes left, but 1575 00:51:39,280 --> 00:51:40,839 you can decide if you want to sell 1576 00:51:40,840 --> 00:51:41,649 something. 1577 00:51:41,650 --> 00:51:43,059 No thank you. 1578 00:51:43,060 --> 00:51:45,159 Go spend those five minutes installing. 1579 00:51:45,160 --> 00:51:46,419 OK, then thank you. 1580 00:51:46,420 --> 00:51:47,559 Good luck. 1581 00:51:47,560 --> 00:51:48,560 Very nice to you.