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/155 Thanks! 1 00:00:08,950 --> 00:00:11,379 Hello, everybody, and welcome to our talk 2 00:00:11,380 --> 00:00:13,809 about wide box cryptography, 3 00:00:13,810 --> 00:00:15,819 the systématique of Patrick from the 4 00:00:15,820 --> 00:00:17,829 University of Luxembourg, and he will 5 00:00:17,830 --> 00:00:19,779 present this talk to us. 6 00:00:19,780 --> 00:00:21,879 Please, could I ask you to remain 7 00:00:21,880 --> 00:00:24,009 seated until the talk ends 8 00:00:24,010 --> 00:00:26,019 or to exit very quietly because it's 9 00:00:26,020 --> 00:00:28,179 disrespectful to the speaker if 10 00:00:28,180 --> 00:00:29,349 you leave? 11 00:00:29,350 --> 00:00:30,439 Yeah, and allow. 12 00:00:31,480 --> 00:00:33,579 And also, there will 13 00:00:33,580 --> 00:00:35,139 be no sitting in the aisles. 14 00:00:35,140 --> 00:00:37,149 I'm sorry if you need power, tape it or 15 00:00:37,150 --> 00:00:38,349 unplug it. 16 00:00:38,350 --> 00:00:40,449 OK, where ed start 17 00:00:40,450 --> 00:00:42,129 to floss is yours? 18 00:00:42,130 --> 00:00:43,839 Please give a warm round of applause to 19 00:00:43,840 --> 00:00:45,430 the military of its. 20 00:00:53,350 --> 00:00:54,759 Hello, everyone. 21 00:00:54,760 --> 00:00:56,889 So my talk 22 00:00:56,890 --> 00:00:59,049 is words of two white box cryptography 23 00:00:59,050 --> 00:01:01,449 today. It's a talk. 24 00:01:01,450 --> 00:01:03,669 It's partially inspired by the research 25 00:01:03,670 --> 00:01:04,719 we're doing at the University of 26 00:01:04,720 --> 00:01:06,729 Luxembourg in our cryptography group, 27 00:01:06,730 --> 00:01:08,799 together with Professor Alex Burakov. 28 00:01:10,210 --> 00:01:13,239 And this talk is intentionally 29 00:01:13,240 --> 00:01:14,679 not much technical. 30 00:01:14,680 --> 00:01:17,169 Well, I suppose you're somewhat familiar 31 00:01:17,170 --> 00:01:19,659 with the main cryptographic principles 32 00:01:19,660 --> 00:01:21,399 and some cryptographic tools. 33 00:01:21,400 --> 00:01:23,979 But I will not require much, 34 00:01:23,980 --> 00:01:26,049 and I will not go deeply into details 35 00:01:26,050 --> 00:01:28,509 of white box implementations. 36 00:01:28,510 --> 00:01:30,099 So I suppose that those who are 37 00:01:30,100 --> 00:01:32,169 interested will just 38 00:01:32,170 --> 00:01:34,569 go for a reference and to 39 00:01:34,570 --> 00:01:35,889 read appropriate papers. 40 00:01:35,890 --> 00:01:37,989 And the purpose of my talk would be 41 00:01:37,990 --> 00:01:40,479 to somehow give you 42 00:01:40,480 --> 00:01:42,579 a brief picture of what white box 43 00:01:42,580 --> 00:01:44,949 cryptography is and what the problems 44 00:01:44,950 --> 00:01:46,090 are in this area. 45 00:01:47,580 --> 00:01:49,719 So probably many of you had heard 46 00:01:49,720 --> 00:01:52,289 of this term, and but 47 00:01:52,290 --> 00:01:54,509 you might have had some troubles in 48 00:01:54,510 --> 00:01:55,799 actually defining it. 49 00:01:55,800 --> 00:01:58,019 But I should agree that it's either not 50 00:01:58,020 --> 00:01:59,739 a well defined notion this wide box 51 00:01:59,740 --> 00:02:00,689 psychographic. 52 00:02:00,690 --> 00:02:02,429 So some people think that its 53 00:02:02,430 --> 00:02:03,430 application. 54 00:02:04,770 --> 00:02:07,259 Maybe some people think that it's 55 00:02:07,260 --> 00:02:08,589 almost the same as public use 56 00:02:08,590 --> 00:02:09,659 cryptography. 57 00:02:09,660 --> 00:02:11,789 Yes, it's also partially true. 58 00:02:11,790 --> 00:02:14,069 Some people think that the just 59 00:02:14,070 --> 00:02:16,019 so not so better defined that no one 60 00:02:16,020 --> 00:02:17,219 knows exactly what wide box 61 00:02:17,220 --> 00:02:18,809 photography's. 62 00:02:18,810 --> 00:02:20,939 Well, all this versions 63 00:02:20,940 --> 00:02:22,050 of bars are true. 64 00:02:23,610 --> 00:02:26,369 OK, so I will president 65 00:02:26,370 --> 00:02:28,589 first, I will give you some more or less 66 00:02:28,590 --> 00:02:30,359 details of three of my talks, so you 67 00:02:30,360 --> 00:02:32,429 would know what to see in the 68 00:02:32,430 --> 00:02:33,419 next slides. 69 00:02:33,420 --> 00:02:35,609 So first, I will talk about 70 00:02:35,610 --> 00:02:37,199 adversary models. 71 00:02:37,200 --> 00:02:39,359 So when we talk about security 72 00:02:39,360 --> 00:02:41,879 of cryptographic primitives and schemes, 73 00:02:41,880 --> 00:02:43,979 we usually assume some standard model of 74 00:02:43,980 --> 00:02:45,119 an adversary. 75 00:02:45,120 --> 00:02:47,219 And when they when white 76 00:02:47,220 --> 00:02:50,219 box cryptography takes place, 77 00:02:50,220 --> 00:02:52,349 the model is nonstandard, some 78 00:02:52,350 --> 00:02:53,699 unorthodox model. 79 00:02:53,700 --> 00:02:56,219 And this it's sometimes called 80 00:02:56,220 --> 00:02:58,289 manner the end model. 81 00:02:58,290 --> 00:03:00,599 I will introduce this model 82 00:03:00,600 --> 00:03:02,489 to you. Talk about some difference to the 83 00:03:02,490 --> 00:03:03,749 standard model. 84 00:03:03,750 --> 00:03:05,639 I will introduce you. 85 00:03:05,640 --> 00:03:07,349 I will introduce this model to you in the 86 00:03:07,350 --> 00:03:09,539 context of contact protection. 87 00:03:09,540 --> 00:03:11,759 A protection of some media while 88 00:03:11,760 --> 00:03:13,409 movies, songs, whatever. 89 00:03:13,410 --> 00:03:15,299 I will give you some details about 90 00:03:15,300 --> 00:03:17,399 current protection schemes and you 91 00:03:17,400 --> 00:03:19,799 will see when this model 92 00:03:19,800 --> 00:03:20,909 appears. 93 00:03:20,910 --> 00:03:22,649 And you will see that the main problem in 94 00:03:22,650 --> 00:03:24,899 this model is how to hide 95 00:03:24,900 --> 00:03:27,059 cryptographic keys, the keys that 96 00:03:27,060 --> 00:03:28,589 are assumed to be secrets and send 97 00:03:28,590 --> 00:03:30,779 models. But in this model, they 98 00:03:30,780 --> 00:03:32,669 are not secret until our big problem is 99 00:03:32,670 --> 00:03:34,050 to hide them somewhere. 100 00:03:35,190 --> 00:03:37,259 Then naturally, the notion of white 101 00:03:37,260 --> 00:03:39,389 box cryptography comes, and the 102 00:03:39,390 --> 00:03:40,390 crucial 103 00:03:41,580 --> 00:03:43,469 notion in the area of white box tipped 104 00:03:43,470 --> 00:03:45,659 over is the white box implementation 105 00:03:45,660 --> 00:03:47,699 of some cipher or a function. 106 00:03:47,700 --> 00:03:50,069 Whatever you will see that 107 00:03:50,070 --> 00:03:52,529 the majority of white box implementations 108 00:03:52,530 --> 00:03:54,599 of ciphers I build 109 00:03:54,600 --> 00:03:56,969 up on the so-called lookup table 110 00:03:56,970 --> 00:03:59,069 suggests a large, stable start in the 111 00:03:59,070 --> 00:04:01,169 memory, and you will see why this 112 00:04:01,170 --> 00:04:02,669 method is important. 113 00:04:02,670 --> 00:04:04,739 You will see how the famous 114 00:04:04,740 --> 00:04:07,079 block cipher, a current encryption 115 00:04:07,080 --> 00:04:09,719 standard, is white box. 116 00:04:09,720 --> 00:04:12,029 How a white box in current office 117 00:04:12,030 --> 00:04:12,929 looks like. 118 00:04:12,930 --> 00:04:15,329 You will see how it can decrypt analyze 119 00:04:15,330 --> 00:04:17,518 how an attack can be constructed and how 120 00:04:17,519 --> 00:04:19,949 actually. And you will see why 121 00:04:19,950 --> 00:04:22,109 the initial proposal for a white 122 00:04:22,110 --> 00:04:24,239 box is weak and you will see why 123 00:04:24,240 --> 00:04:25,499 it is weak. And actually, you will see 124 00:04:25,500 --> 00:04:27,209 that many of such proposals are weak and 125 00:04:27,210 --> 00:04:28,709 actually no one is strong. 126 00:04:29,880 --> 00:04:32,159 I will then talk about weak 127 00:04:32,160 --> 00:04:34,079 and stronger sidewalks implementations 128 00:04:34,080 --> 00:04:35,279 because there can be different 129 00:04:35,280 --> 00:04:37,409 definitions in this aspect. 130 00:04:37,410 --> 00:04:39,779 And I will tell you that while weak 131 00:04:39,780 --> 00:04:41,249 white box implementations can be 132 00:04:41,250 --> 00:04:43,529 constructed somehow, but with strong 133 00:04:43,530 --> 00:04:45,689 white box implementation, we have serious 134 00:04:45,690 --> 00:04:47,939 problems. So third scale background 135 00:04:47,940 --> 00:04:50,159 doesn't allow us to build this sort 136 00:04:50,160 --> 00:04:52,229 of cryptography, so-called strong 137 00:04:52,230 --> 00:04:53,759 white box cryptography. 138 00:04:53,760 --> 00:04:55,730 And then they will give us some. 139 00:04:57,060 --> 00:05:00,239 I will explain some new directions 140 00:05:00,240 --> 00:05:02,519 how we try to build white 141 00:05:02,520 --> 00:05:04,469 box implementations, white box usable 142 00:05:04,470 --> 00:05:06,479 ciphers from scratch, how we construct 143 00:05:06,480 --> 00:05:08,579 that, the weak white box candidate, how 144 00:05:08,580 --> 00:05:10,409 we face the nonlinear stability problem. 145 00:05:10,410 --> 00:05:12,809 And finally, how we try to construct 146 00:05:12,810 --> 00:05:14,909 white box cryptography schemes from 147 00:05:14,910 --> 00:05:18,149 polynomials in final fields. 148 00:05:18,150 --> 00:05:20,369 So this is a long cover your 149 00:05:20,370 --> 00:05:22,709 my token. Now I will go 150 00:05:22,710 --> 00:05:23,759 deep into details. 151 00:05:25,040 --> 00:05:27,109 So throughout my talk, we can, I 152 00:05:27,110 --> 00:05:28,879 consider a projection of really large 153 00:05:28,880 --> 00:05:29,959 amounts of data. 154 00:05:29,960 --> 00:05:32,029 So these are huge databases, 155 00:05:32,030 --> 00:05:34,279 this digital media sort of gigabytes 156 00:05:34,280 --> 00:05:36,019 or terabytes large. 157 00:05:36,020 --> 00:05:38,449 This is some scientific experiments data. 158 00:05:38,450 --> 00:05:40,429 So there is a huge amount to start our 159 00:05:40,430 --> 00:05:42,949 hard drive storing data centers. 160 00:05:42,950 --> 00:05:45,049 And of course, one person and protecting 161 00:05:45,050 --> 00:05:47,479 this large amounts of data performance 162 00:05:47,480 --> 00:05:48,439 is crucial. 163 00:05:48,440 --> 00:05:50,569 So we have to deal with 164 00:05:50,570 --> 00:05:52,849 parameters that are fast enough to 165 00:05:52,850 --> 00:05:55,069 to enable a reasonable person 166 00:05:55,070 --> 00:05:56,359 the data and a reasonable time. 167 00:05:57,700 --> 00:05:59,919 And when they talk about performance 168 00:05:59,920 --> 00:06:02,259 and security simultaneously, 169 00:06:02,260 --> 00:06:03,260 we usually 170 00:06:04,510 --> 00:06:06,009 work with so-called asymmetric 171 00:06:06,010 --> 00:06:08,049 cryptography, so symmetrical cryptography 172 00:06:08,050 --> 00:06:10,119 is some part of cryptography. 173 00:06:10,120 --> 00:06:12,429 It's it's called symmetric because 174 00:06:12,430 --> 00:06:14,199 secret components of some sort of 175 00:06:14,200 --> 00:06:16,239 ciphers, usually secret keys are shared 176 00:06:16,240 --> 00:06:18,819 between parties shared by parties. 177 00:06:18,820 --> 00:06:19,820 And 178 00:06:21,100 --> 00:06:22,179 the feature is there. 179 00:06:22,180 --> 00:06:24,429 It's really fast, really fast compared 180 00:06:24,430 --> 00:06:26,589 to noncompetitive close to a public key 181 00:06:26,590 --> 00:06:27,729 cryptography. 182 00:06:27,730 --> 00:06:30,069 So confidentiality and 183 00:06:30,070 --> 00:06:32,169 privacy are achieved 184 00:06:32,170 --> 00:06:34,359 with usually with ciphers, 185 00:06:34,360 --> 00:06:36,619 of which the most widely known is a 186 00:06:36,620 --> 00:06:38,409 yes block cipher. 187 00:06:38,410 --> 00:06:40,269 There are three versions of it, and the 188 00:06:40,270 --> 00:06:42,129 versions differ only in the key size for 189 00:06:42,130 --> 00:06:44,229 us is not really important what the key 190 00:06:44,230 --> 00:06:45,309 size is. 191 00:06:45,310 --> 00:06:47,229 So the block cipher, it's called a block 192 00:06:47,230 --> 00:06:49,449 cipher because that process it blocks 193 00:06:49,450 --> 00:06:51,519 are fixed size and to process large 194 00:06:51,520 --> 00:06:53,259 amounts of data. 195 00:06:53,260 --> 00:06:55,599 Some modes of operation has to be used 196 00:06:55,600 --> 00:06:57,429 so called there are counter and chain 197 00:06:57,430 --> 00:06:58,539 modes of operation. 198 00:06:58,540 --> 00:07:00,129 So you've just provided some 199 00:07:00,130 --> 00:07:02,349 abbreviations to help with some 200 00:07:02,350 --> 00:07:03,350 sort of recall. 201 00:07:04,870 --> 00:07:06,669 I think you've probably seen in wireless 202 00:07:06,670 --> 00:07:09,759 cryptographic implementations and 203 00:07:09,760 --> 00:07:11,979 when we talk about when we want 204 00:07:11,980 --> 00:07:13,329 to shift out in this situation, we want 205 00:07:13,330 --> 00:07:14,919 to protect integrity of the data. 206 00:07:14,920 --> 00:07:16,599 We usually deal with hash functions, 207 00:07:16,600 --> 00:07:19,059 message authentication codes or 208 00:07:19,060 --> 00:07:20,979 a larger, authenticated encryption 209 00:07:20,980 --> 00:07:21,980 schemes. 210 00:07:22,810 --> 00:07:24,909 I give so much details 211 00:07:24,910 --> 00:07:27,639 about symmetric things because 212 00:07:27,640 --> 00:07:29,499 they are not to blame. 213 00:07:29,500 --> 00:07:31,819 They have interest in feature 214 00:07:31,820 --> 00:07:33,999 so-called. So first, I say that 215 00:07:34,000 --> 00:07:35,769 all these designs withstood two years of 216 00:07:35,770 --> 00:07:37,509 cryptanalysis. 217 00:07:37,510 --> 00:07:39,609 Years of attacks by different people 218 00:07:39,610 --> 00:07:41,200 and their security are often 219 00:07:42,490 --> 00:07:44,319 backed up with various sorts of security 220 00:07:44,320 --> 00:07:46,539 proofs and arguments, but not so often 221 00:07:46,540 --> 00:07:48,459 with formal and rigorous mathematical 222 00:07:48,460 --> 00:07:50,739 proofs. Quite often, the security 223 00:07:50,740 --> 00:07:52,809 of all the schemes are based upon 224 00:07:52,810 --> 00:07:54,519 just observations. 225 00:07:54,520 --> 00:07:56,559 Just some ideas why this particular 226 00:07:56,560 --> 00:07:59,229 cipher is strong and secure, 227 00:07:59,230 --> 00:08:01,449 and performance. 228 00:08:01,450 --> 00:08:02,799 Why we love symmetric orthography. 229 00:08:02,800 --> 00:08:04,659 As for performance performance, and it 230 00:08:04,660 --> 00:08:05,769 has some cost. 231 00:08:05,770 --> 00:08:08,259 While the RSA encryption 232 00:08:08,260 --> 00:08:10,479 is believed to be secure because 233 00:08:10,480 --> 00:08:12,699 it's directly related to a well 234 00:08:12,700 --> 00:08:14,889 known mathematical problems, which is 235 00:08:14,890 --> 00:08:16,719 believed has been believed to be HIH's 236 00:08:16,720 --> 00:08:18,939 for centuries, the hardness of factor 237 00:08:18,940 --> 00:08:21,309 in large numbers, in contrast, 238 00:08:21,310 --> 00:08:23,559 is look, cipher is believed to be secure 239 00:08:23,560 --> 00:08:25,839 just because no one has ever 240 00:08:25,840 --> 00:08:28,089 broken it ever 241 00:08:28,090 --> 00:08:29,739 published a successful attack. 242 00:08:29,740 --> 00:08:31,299 And many people try it. 243 00:08:31,300 --> 00:08:33,399 Ace was designed so that 244 00:08:33,400 --> 00:08:35,379 it's easy enough to understand and is 245 00:08:35,380 --> 00:08:37,719 enough to try and sort of attack. 246 00:08:37,720 --> 00:08:39,879 But it wasn't designed for the forum 247 00:08:39,880 --> 00:08:42,428 tiger security proof inside. 248 00:08:42,429 --> 00:08:44,469 So here's the important difference. 249 00:08:44,470 --> 00:08:46,689 So here we achieve performance at 250 00:08:46,690 --> 00:08:48,759 the cost of not so much a rigorous 251 00:08:48,760 --> 00:08:49,760 proofs. 252 00:08:51,320 --> 00:08:53,569 And when they talk about 253 00:08:53,570 --> 00:08:55,939 proofs and arguments, when the doc that 254 00:08:55,940 --> 00:08:58,219 some cipher is secure, 255 00:08:58,220 --> 00:09:00,139 we usually, of course, assume some more 256 00:09:00,140 --> 00:09:02,299 or less formal model of an adversary of 257 00:09:02,300 --> 00:09:03,300 an attacker. 258 00:09:04,970 --> 00:09:07,069 A standard model wherein 259 00:09:07,070 --> 00:09:09,109 where most of cryptographic algorithm 260 00:09:09,110 --> 00:09:11,149 Cipher Subhash, for instance, are related 261 00:09:11,150 --> 00:09:13,189 validated. This model dates back to the 262 00:09:13,190 --> 00:09:15,439 previous centuries, and 263 00:09:15,440 --> 00:09:17,089 usually we assume that the algorithm 264 00:09:17,090 --> 00:09:19,459 itself is open publicly 265 00:09:19,460 --> 00:09:22,279 available for scrutiny, so everyone 266 00:09:22,280 --> 00:09:24,379 may try to find some weakness 267 00:09:24,380 --> 00:09:25,669 in the algorithm itself. 268 00:09:25,670 --> 00:09:27,919 But when the algorithm, when a scheme 269 00:09:27,920 --> 00:09:30,199 is used, the key a secret key 270 00:09:30,200 --> 00:09:31,279 is secret. 271 00:09:31,280 --> 00:09:33,469 Key is stored somewhere when adversity 272 00:09:33,470 --> 00:09:34,609 cannot access it. 273 00:09:34,610 --> 00:09:36,679 It's in the reality, in hidden and in 274 00:09:36,680 --> 00:09:38,749 hardware. It's the code is 275 00:09:38,750 --> 00:09:41,119 running in some remote computer and what 276 00:09:41,120 --> 00:09:43,189 an adversary is able to do is usually to 277 00:09:43,190 --> 00:09:45,319 observe inputs and 278 00:09:45,320 --> 00:09:47,989 outputs of a cipher, or possibly 279 00:09:47,990 --> 00:09:49,849 an endorser can supply some desired 280 00:09:49,850 --> 00:09:51,259 inputs to decipher and observe its 281 00:09:51,260 --> 00:09:53,600 output. But it cannot control the key. 282 00:09:54,800 --> 00:09:56,399 And this is the standard model. 283 00:09:56,400 --> 00:09:57,889 This is the model that's usually used to 284 00:09:57,890 --> 00:10:00,739 assessing the security of cryptographic 285 00:10:00,740 --> 00:10:01,849 algorithms. 286 00:10:01,850 --> 00:10:04,369 However, quite often in practice, 287 00:10:04,370 --> 00:10:06,169 the latter assumption is very difficult 288 00:10:06,170 --> 00:10:08,689 to establish and sometimes just 289 00:10:08,690 --> 00:10:09,769 doesn't hold. 290 00:10:09,770 --> 00:10:11,629 I mean, not it doesn't hold, not in the 291 00:10:11,630 --> 00:10:13,519 sense that the key is public knowledge, 292 00:10:13,520 --> 00:10:15,859 but it's quite difficult to hide the key. 293 00:10:15,860 --> 00:10:17,689 And at some point we have to assume that 294 00:10:17,690 --> 00:10:19,699 we can't find the key and we have to 295 00:10:19,700 --> 00:10:21,889 present it within the algorithm, 296 00:10:21,890 --> 00:10:24,049 but in quite a sophisticated way. 297 00:10:25,650 --> 00:10:26,650 When that happens. 298 00:10:29,530 --> 00:10:31,689 So the model when the 299 00:10:31,690 --> 00:10:34,209 adversary has access to 300 00:10:34,210 --> 00:10:36,489 also to the key is called man 301 00:10:36,490 --> 00:10:38,049 at the end because 302 00:10:39,760 --> 00:10:41,499 it's usually usually the we deal with 303 00:10:41,500 --> 00:10:43,749 some sort of application where 304 00:10:43,750 --> 00:10:46,599 cryptographic algorithms are performed 305 00:10:46,600 --> 00:10:48,849 and an adversary has full access 306 00:10:48,850 --> 00:10:49,899 to this application. 307 00:10:54,000 --> 00:10:56,309 A typical example of 308 00:10:56,310 --> 00:10:58,589 a man event model is as follows, 309 00:10:58,590 --> 00:11:00,689 so suppose you are 310 00:11:00,690 --> 00:11:03,179 a legitimate user or a legitimate user. 311 00:11:03,180 --> 00:11:05,279 Some Ania Tucker, just she 312 00:11:05,280 --> 00:11:07,379 just downloads a protected song from a 313 00:11:07,380 --> 00:11:09,719 server I know from via 314 00:11:09,720 --> 00:11:11,999 iTunes or whatever, and plays 315 00:11:12,000 --> 00:11:14,159 this song on an authorized 316 00:11:14,160 --> 00:11:15,749 music player. 317 00:11:15,750 --> 00:11:18,029 Of course, ideally their copyright 318 00:11:18,030 --> 00:11:20,189 owners want to protect it in the sense 319 00:11:20,190 --> 00:11:22,499 that a person can file form 320 00:11:22,500 --> 00:11:23,639 is downloaded about it. 321 00:11:23,640 --> 00:11:24,689 Kind of. 322 00:11:24,690 --> 00:11:26,729 A user is not supposed to be able to 323 00:11:26,730 --> 00:11:28,889 distribute to share this 324 00:11:28,890 --> 00:11:31,229 music elsewhere. 325 00:11:31,230 --> 00:11:33,389 And of course, adversaries 326 00:11:33,390 --> 00:11:35,519 may try to break this 327 00:11:35,520 --> 00:11:36,779 sort of protection. 328 00:11:36,780 --> 00:11:39,329 And in this game, industry 329 00:11:39,330 --> 00:11:41,669 has, well, generally speaking, has 330 00:11:41,670 --> 00:11:43,919 a lot of way to do this because 331 00:11:43,920 --> 00:11:46,469 internet connection can be eavesdropped. 332 00:11:46,470 --> 00:11:48,809 The music player code can be 333 00:11:48,810 --> 00:11:49,859 viewed. 334 00:11:49,860 --> 00:11:52,469 Also, the code can be 335 00:11:52,470 --> 00:11:53,819 dynamically executed. 336 00:11:53,820 --> 00:11:56,099 And if there is some cryptographic 337 00:11:56,100 --> 00:11:58,229 transformation within some crazy 338 00:11:58,230 --> 00:12:00,299 procedure, some schemas running, then 339 00:12:00,300 --> 00:12:02,309 it's possible to view its internal 340 00:12:02,310 --> 00:12:04,799 variables and possibly 341 00:12:04,800 --> 00:12:07,169 read even the key. 342 00:12:07,170 --> 00:12:08,819 Because, well, in cryptographic 343 00:12:08,820 --> 00:12:11,909 algorithms, it's usually if it's 344 00:12:11,910 --> 00:12:14,069 just normal code, that's quite easy to 345 00:12:14,070 --> 00:12:16,199 see when where the 346 00:12:16,200 --> 00:12:18,839 secret variable self-catered, and it's 347 00:12:18,840 --> 00:12:21,119 quite easy to locate the key if if 348 00:12:21,120 --> 00:12:22,769 there are not hidden. 349 00:12:22,770 --> 00:12:25,139 And in this in this scheme, 350 00:12:25,140 --> 00:12:27,269 it's rather difficult to hide the key 351 00:12:27,270 --> 00:12:29,429 because, well, when in a software music 352 00:12:29,430 --> 00:12:31,769 player, there is no match, way too 353 00:12:31,770 --> 00:12:33,690 much way to store it. 354 00:12:35,850 --> 00:12:38,009 Of course, downloading songs is not the 355 00:12:38,010 --> 00:12:40,079 only application where you can find 356 00:12:40,080 --> 00:12:41,249 the source of problem. 357 00:12:41,250 --> 00:12:43,349 So when you work with the 358 00:12:43,350 --> 00:12:45,089 larger media, with the movies, for 359 00:12:45,090 --> 00:12:47,549 example, when movie owners 360 00:12:47,550 --> 00:12:50,579 broadcast the just produced 361 00:12:50,580 --> 00:12:52,649 cinema to movie theaters and 362 00:12:52,650 --> 00:12:54,959 want to protect it when you're 363 00:12:54,960 --> 00:12:57,119 playing, when you download and play 364 00:12:57,120 --> 00:12:59,339 encrypted movies in some authorized 365 00:12:59,340 --> 00:13:01,649 players, or you just stream 366 00:13:01,650 --> 00:13:03,659 protected media directly. 367 00:13:04,830 --> 00:13:07,139 Pretty much the same problems appear, 368 00:13:07,140 --> 00:13:09,239 and you probably heard that 369 00:13:09,240 --> 00:13:10,979 quite many of these protocols have been 370 00:13:10,980 --> 00:13:12,569 previously attacked. 371 00:13:12,570 --> 00:13:14,669 Well, how they were 372 00:13:14,670 --> 00:13:15,809 attacked. 373 00:13:15,810 --> 00:13:18,839 I've already described several 374 00:13:18,840 --> 00:13:20,759 Wallner ability points, some potential 375 00:13:20,760 --> 00:13:22,049 vulnerability points. 376 00:13:22,050 --> 00:13:24,569 And indeed, there are quite many 377 00:13:24,570 --> 00:13:27,359 ways to attack those algorithms. 378 00:13:27,360 --> 00:13:29,610 Consider some specific example. 379 00:13:30,750 --> 00:13:32,879 For example, a protect in digital cinema 380 00:13:32,880 --> 00:13:35,279 is just a Real-Life example how 381 00:13:35,280 --> 00:13:37,169 movies are distributed from their own art 382 00:13:37,170 --> 00:13:38,489 to movie theaters. 383 00:13:38,490 --> 00:13:40,559 So First Server possesses some 384 00:13:40,560 --> 00:13:42,749 media, and then since 385 00:13:42,750 --> 00:13:45,149 the content is rather large, 386 00:13:45,150 --> 00:13:47,849 it's encrypted with symmetric cipher 387 00:13:47,850 --> 00:13:50,159 s, for instance. 388 00:13:51,180 --> 00:13:53,879 And but the player 389 00:13:53,880 --> 00:13:55,979 doesn't know by default the 390 00:13:55,980 --> 00:13:58,099 key, which was used to encrypt 391 00:13:58,100 --> 00:13:59,100 a particular. 392 00:14:01,020 --> 00:14:03,119 Movie and the 393 00:14:03,120 --> 00:14:05,219 Askey must be attached somehow 394 00:14:05,220 --> 00:14:07,289 to the media, as 395 00:14:07,290 --> 00:14:08,759 you see here. 396 00:14:08,760 --> 00:14:11,219 So we have encrypted 397 00:14:11,220 --> 00:14:13,109 the content with the ASCII and you have 398 00:14:13,110 --> 00:14:14,339 to send it to the player. 399 00:14:14,340 --> 00:14:16,719 However, if if we send a key any 400 00:14:16,720 --> 00:14:19,259 ASCII as a plain text, then 401 00:14:19,260 --> 00:14:21,869 it would be possible just directly to 402 00:14:21,870 --> 00:14:23,789 intercept it, tend to use it and decrypt 403 00:14:23,790 --> 00:14:25,199 the media elsewhere. 404 00:14:25,200 --> 00:14:27,509 So the ASCII must be protected 405 00:14:27,510 --> 00:14:29,789 somehow. To do this, public 406 00:14:29,790 --> 00:14:32,309 key cryptography takes place. 407 00:14:32,310 --> 00:14:34,979 So RSA algorithm 408 00:14:34,980 --> 00:14:37,079 is much slower compared 409 00:14:37,080 --> 00:14:38,009 to a year. 410 00:14:38,010 --> 00:14:40,349 But to encrypt 411 00:14:40,350 --> 00:14:42,509 not so large key, it's pretty much 412 00:14:42,510 --> 00:14:43,589 sufficient. 413 00:14:43,590 --> 00:14:45,929 So in our algorithm, 414 00:14:45,930 --> 00:14:48,029 there are two keys public key and 415 00:14:48,030 --> 00:14:49,049 private key. 416 00:14:49,050 --> 00:14:51,299 So suppose the player 417 00:14:51,300 --> 00:14:52,889 has RC private key. 418 00:14:52,890 --> 00:14:54,989 Then the server uses 419 00:14:54,990 --> 00:14:57,419 its counterpart public key to encrypt 420 00:14:57,420 --> 00:14:59,609 their key and then 421 00:14:59,610 --> 00:15:01,649 attach it in an encrypted form. 422 00:15:01,650 --> 00:15:03,629 The cipher text of the key, attach it to 423 00:15:03,630 --> 00:15:06,419 the media and send it over 424 00:15:06,420 --> 00:15:08,069 to the player. 425 00:15:08,070 --> 00:15:10,439 And on the player side, the backlogs 426 00:15:10,440 --> 00:15:12,239 process is initiated. 427 00:15:12,240 --> 00:15:14,459 It means that the player uses its own 428 00:15:14,460 --> 00:15:16,979 private key to decrypt 429 00:15:16,980 --> 00:15:18,179 their ASCII. 430 00:15:19,230 --> 00:15:21,359 Then this ASCII is 431 00:15:21,360 --> 00:15:23,729 used to decrypt the media and 432 00:15:23,730 --> 00:15:26,819 to stream the content to a TV, 433 00:15:26,820 --> 00:15:28,949 to a screen wherever, 434 00:15:28,950 --> 00:15:31,379 and quite typical 435 00:15:31,380 --> 00:15:33,539 that the server wants to reduce his 436 00:15:33,540 --> 00:15:34,830 own workload. And 437 00:15:36,000 --> 00:15:38,369 if Sarah distributes the movie to 438 00:15:38,370 --> 00:15:40,979 thousands of theaters, then 439 00:15:40,980 --> 00:15:42,539 he does want to encrypt the movie a 440 00:15:42,540 --> 00:15:44,759 thousand times. That can be quite. 441 00:15:47,900 --> 00:15:48,919 Quite costly. 442 00:15:48,920 --> 00:15:51,079 And the key 443 00:15:51,080 --> 00:15:53,419 may repeat over theaters 444 00:15:53,420 --> 00:15:54,440 over distributions. 445 00:15:55,500 --> 00:15:57,869 So in this quite much complicated 446 00:15:57,870 --> 00:15:59,579 schemes, you have probably noticed a lot 447 00:15:59,580 --> 00:16:01,799 of well in our Bill 2.0, 448 00:16:01,800 --> 00:16:03,449 a lot of points where this scheme can be 449 00:16:03,450 --> 00:16:04,349 attacked. 450 00:16:04,350 --> 00:16:06,599 So if we don't protect a device, 451 00:16:06,600 --> 00:16:09,149 it's called the use of memory, 452 00:16:09,150 --> 00:16:11,489 then wonder 453 00:16:11,490 --> 00:16:12,490 how it. 454 00:16:15,190 --> 00:16:17,259 For example, an attacker 455 00:16:17,260 --> 00:16:19,389 might try to read the RSA key 456 00:16:19,390 --> 00:16:21,609 directly from the device memory 457 00:16:21,610 --> 00:16:23,679 and use it subsequently 458 00:16:23,680 --> 00:16:26,079 to decrypt to make the letter 459 00:16:26,080 --> 00:16:27,939 steps on his own. 460 00:16:27,940 --> 00:16:30,189 An attacker might try to read the RSA 461 00:16:30,190 --> 00:16:32,259 private key at the moment, where 462 00:16:32,260 --> 00:16:34,779 it's used for decryption of a 463 00:16:34,780 --> 00:16:37,119 key. Or finally, an attacker 464 00:16:37,120 --> 00:16:39,399 might try to eavesdrop 465 00:16:39,400 --> 00:16:41,589 the decryption process 466 00:16:41,590 --> 00:16:44,049 of the large contact and may try to 467 00:16:44,050 --> 00:16:46,419 to obtain 468 00:16:46,420 --> 00:16:48,159 the key itself. 469 00:16:48,160 --> 00:16:50,649 And quite famous 470 00:16:50,650 --> 00:16:51,650 attacks on 471 00:16:52,870 --> 00:16:55,269 DRM protects media protocols 472 00:16:55,270 --> 00:16:57,399 like CIUSSS and the course they 473 00:16:57,400 --> 00:16:58,689 all. 474 00:16:58,690 --> 00:16:59,949 All this first could have been broken 475 00:16:59,950 --> 00:17:02,469 along this line, so attackers 476 00:17:02,470 --> 00:17:04,539 found the weakest link 477 00:17:04,540 --> 00:17:07,749 in such schemes and obtained 478 00:17:07,750 --> 00:17:09,879 our obtained encryption keys. 479 00:17:09,880 --> 00:17:12,189 And after those keys are obtained, 480 00:17:12,190 --> 00:17:15,159 it's it became rather easy to decrypt 481 00:17:15,160 --> 00:17:16,270 quite a lot of content. 482 00:17:18,579 --> 00:17:21,309 Well, you might wonder why 483 00:17:21,310 --> 00:17:23,529 we want to use why 484 00:17:23,530 --> 00:17:25,419 we want to extract the keys while it's 485 00:17:25,420 --> 00:17:27,669 sometimes possible to, we 486 00:17:27,670 --> 00:17:29,739 have the methods of lifting to adjust, 487 00:17:29,740 --> 00:17:31,839 extract the entire code of a player and 488 00:17:31,840 --> 00:17:33,339 use it for decryption. 489 00:17:33,340 --> 00:17:35,259 Well, quite often it's possible, but also 490 00:17:35,260 --> 00:17:37,389 quite often it's complicated because the 491 00:17:37,390 --> 00:17:39,699 decryption routine might not be isolated 492 00:17:39,700 --> 00:17:41,799 so easily, and 493 00:17:41,800 --> 00:17:44,139 handling keys is easier because 494 00:17:44,140 --> 00:17:45,439 keys are smaller. 495 00:17:45,440 --> 00:17:46,959 There is it to distribute. 496 00:17:46,960 --> 00:17:49,299 It's easier to update a particular key 497 00:17:49,300 --> 00:17:51,339 if it's changed by a server. 498 00:17:51,340 --> 00:17:53,289 The keys are much more difficult to 499 00:17:53,290 --> 00:17:55,389 trace. So, for example, a 500 00:17:55,390 --> 00:17:56,859 software can be watermarked 501 00:17:58,000 --> 00:18:00,219 and well, if you can extract 502 00:18:00,220 --> 00:18:02,729 keys, it's always much better. 503 00:18:02,730 --> 00:18:04,899 And in the further text, we assume 504 00:18:04,900 --> 00:18:05,900 that. 505 00:18:07,170 --> 00:18:08,639 So in the front of the textbook and said 506 00:18:08,640 --> 00:18:11,189 the problem of hide and keys, not 507 00:18:11,190 --> 00:18:13,499 the problem of protecting their 508 00:18:13,500 --> 00:18:15,089 code from code lifting. 509 00:18:16,090 --> 00:18:17,739 So how can we hide 510 00:18:19,180 --> 00:18:21,309 those secret keys in such 511 00:18:21,310 --> 00:18:22,310 schemes? 512 00:18:23,270 --> 00:18:25,489 There are two well known ways 513 00:18:25,490 --> 00:18:27,080 of hide in 514 00:18:28,130 --> 00:18:29,899 secret kiss first awake. 515 00:18:29,900 --> 00:18:32,059 One can try to store a key in 516 00:18:32,060 --> 00:18:34,219 the well protected hardware, 517 00:18:34,220 --> 00:18:36,109 which is tamper proof. 518 00:18:36,110 --> 00:18:38,239 Well, it's a success 519 00:18:38,240 --> 00:18:40,469 story. So this method works, and 520 00:18:40,470 --> 00:18:42,739 it has worked for four years. 521 00:18:42,740 --> 00:18:45,019 Of course, it's obviously increases 522 00:18:45,020 --> 00:18:48,109 the costs of an attack for an adversary, 523 00:18:48,110 --> 00:18:49,110 but. 524 00:18:49,550 --> 00:18:51,919 Well, it does make it usually a hardware 525 00:18:51,920 --> 00:18:53,599 storage. Does it make that an attack 526 00:18:53,600 --> 00:18:55,729 impossible? But it makes it much 527 00:18:55,730 --> 00:18:57,229 more expensive? 528 00:18:57,230 --> 00:18:59,359 But on the other hand, while making 529 00:18:59,360 --> 00:19:01,279 that tech expensive for a foreign 530 00:19:01,280 --> 00:19:04,609 adversary, this hardware method also 531 00:19:04,610 --> 00:19:07,219 makes the procedure 532 00:19:07,220 --> 00:19:09,619 itself for the protection the defense 533 00:19:09,620 --> 00:19:11,689 more expensive for users 534 00:19:11,690 --> 00:19:13,849 because, well, hardware has 535 00:19:13,850 --> 00:19:16,519 some non-zero costs. 536 00:19:16,520 --> 00:19:18,259 It's much less agile. 537 00:19:18,260 --> 00:19:20,929 It's much more difficult to update, 538 00:19:20,930 --> 00:19:23,059 and it can be vulnerable to all sorts 539 00:19:23,060 --> 00:19:24,859 of side channel attacks like Diamond of 540 00:19:24,860 --> 00:19:25,880 Power Analysis. 541 00:19:27,250 --> 00:19:29,349 So you're starting keys and hardware 542 00:19:29,350 --> 00:19:31,419 is one way and another way 543 00:19:31,420 --> 00:19:33,609 is stored in here, somewhere in 544 00:19:33,610 --> 00:19:34,839 software. 545 00:19:34,840 --> 00:19:36,939 And when we talk about 546 00:19:36,940 --> 00:19:39,099 hiding the software, then turn 547 00:19:39,100 --> 00:19:41,319 the variables in the source code 548 00:19:41,320 --> 00:19:43,569 somewhere. This is pretty much the same 549 00:19:43,570 --> 00:19:46,559 as we know as obfuscation. 550 00:19:46,560 --> 00:19:48,899 So obfuscation is another not 551 00:19:48,900 --> 00:19:51,209 really a well-defined term, but 552 00:19:51,210 --> 00:19:52,919 we'll understand that it's just the 553 00:19:52,920 --> 00:19:55,049 method somewhat of concealing programs, 554 00:19:55,050 --> 00:19:56,340 logic or behavior. 555 00:19:57,770 --> 00:19:59,509 There are quite many heuristic methods 556 00:19:59,510 --> 00:20:02,569 that are full scale programs, but 557 00:20:02,570 --> 00:20:05,269 they all have some issues that 558 00:20:05,270 --> 00:20:07,519 do not a law allow us directly 559 00:20:07,520 --> 00:20:10,549 to use it to hide 560 00:20:10,550 --> 00:20:11,839 cryptographic keys. 561 00:20:11,840 --> 00:20:13,729 So some of them do not target here 562 00:20:13,730 --> 00:20:14,719 specifically. 563 00:20:14,720 --> 00:20:16,339 Some of them are vulnerable to. 564 00:20:19,130 --> 00:20:20,959 Dwyer sorts of static and dynamic 565 00:20:20,960 --> 00:20:21,979 analysis. 566 00:20:21,980 --> 00:20:24,709 And another problem is that 567 00:20:24,710 --> 00:20:26,929 the application is not well supported 568 00:20:26,930 --> 00:20:28,159 by theory. 569 00:20:28,160 --> 00:20:30,559 So on the third scale site, we have quite 570 00:20:30,560 --> 00:20:32,689 many negative while also positive 571 00:20:32,690 --> 00:20:34,249 results, but we also have a negative 572 00:20:34,250 --> 00:20:36,679 results of sorts that we cannot 573 00:20:36,680 --> 00:20:39,319 build to program that can obfuscate 574 00:20:39,320 --> 00:20:40,320 everything 575 00:20:42,230 --> 00:20:44,479 on the end. On the other hand, we 576 00:20:44,480 --> 00:20:46,849 can obfuscate some very, very simple 577 00:20:46,850 --> 00:20:49,099 function, so-called by functions, 578 00:20:49,100 --> 00:20:51,589 but there is no good results in between. 579 00:20:51,590 --> 00:20:53,659 There is no theoretical method that 580 00:20:53,660 --> 00:20:55,579 is just for the moment flow in theory, 581 00:20:55,580 --> 00:20:57,499 but just waits for its optimization. 582 00:20:57,500 --> 00:20:59,569 No, the situation is worse, and there 583 00:20:59,570 --> 00:21:01,849 are quite many holistic methods 584 00:21:01,850 --> 00:21:03,919 which are, well, not 585 00:21:03,920 --> 00:21:06,679 provable. They are very far from being 586 00:21:06,680 --> 00:21:09,469 provably secure 587 00:21:09,470 --> 00:21:11,089 while even convincingly secure. 588 00:21:12,800 --> 00:21:13,879 OK. What? 589 00:21:13,880 --> 00:21:15,979 I would like to elaborate a bit more 590 00:21:15,980 --> 00:21:16,980 on obfuscation. 591 00:21:18,020 --> 00:21:20,179 So if we cannot make something provably 592 00:21:20,180 --> 00:21:22,309 unbreakable proof the secure, we 593 00:21:22,310 --> 00:21:24,019 can follow the strategy of designing the 594 00:21:24,020 --> 00:21:26,089 block cipher and at least try to make 595 00:21:26,090 --> 00:21:27,919 something similar breakable, seemingly 596 00:21:27,920 --> 00:21:31,159 secure and convincingly secure. 597 00:21:31,160 --> 00:21:33,229 We may remember that in the beginning 598 00:21:33,230 --> 00:21:35,359 of public cryptography, the 599 00:21:35,360 --> 00:21:37,459 way of obfuscation cipher was 600 00:21:37,460 --> 00:21:38,719 proposed, but eventually 601 00:21:39,740 --> 00:21:42,169 public cryptography was built 602 00:21:42,170 --> 00:21:44,329 on mathematically heart 603 00:21:44,330 --> 00:21:45,330 problems. 604 00:21:48,260 --> 00:21:50,899 OK, so if we talk about obfuscation, 605 00:21:50,900 --> 00:21:53,029 so how could we officiate Key's 606 00:21:53,030 --> 00:21:55,849 secret kiss and what sort of security 607 00:21:55,850 --> 00:21:57,559 we actually get? 608 00:21:57,560 --> 00:21:59,719 I mean, can we formally 609 00:21:59,720 --> 00:22:00,679 defy and then, you know? 610 00:22:00,680 --> 00:22:02,659 And security can be achieved this year. 611 00:22:02,660 --> 00:22:04,849 Can we somehow prove that we indeed 612 00:22:04,850 --> 00:22:06,829 get this sort of security from a 613 00:22:06,830 --> 00:22:09,049 particular implementation and 614 00:22:09,050 --> 00:22:11,689 that's where it box cryptography appears? 615 00:22:11,690 --> 00:22:13,279 So white box approach appropriately deals 616 00:22:13,280 --> 00:22:14,960 with the plus in 617 00:22:16,280 --> 00:22:18,949 secret cryptographic keys in 618 00:22:18,950 --> 00:22:19,950 cryptographic. 619 00:22:21,100 --> 00:22:23,049 In the software algorithms. 620 00:22:23,050 --> 00:22:25,149 So the crucial point 621 00:22:25,150 --> 00:22:27,399 for why it works cryptography is 622 00:22:27,400 --> 00:22:30,159 why it works implementation of a cipher. 623 00:22:30,160 --> 00:22:32,589 It can be can be simpler stated 624 00:22:32,590 --> 00:22:34,599 that why it books cryptography is the 625 00:22:34,600 --> 00:22:36,129 white box implementation. 626 00:22:36,130 --> 00:22:38,349 So white box implementation is 627 00:22:38,350 --> 00:22:40,569 a pure software without any 628 00:22:40,570 --> 00:22:42,759 hardware help and rendition of a cipher 629 00:22:42,760 --> 00:22:44,619 with key insights, so it's either 630 00:22:44,620 --> 00:22:46,659 decryption or encryption routine. 631 00:22:46,660 --> 00:22:48,099 It doesn't matter much because they're 632 00:22:48,100 --> 00:22:50,199 usually symmetric. 633 00:22:50,200 --> 00:22:53,079 And when analyzing it security, 634 00:22:53,080 --> 00:22:55,449 we first assume that this implementation 635 00:22:55,450 --> 00:22:57,739 is fully available to an adversary in 636 00:22:57,740 --> 00:22:59,529 the source code. So all the internal 637 00:22:59,530 --> 00:23:01,629 constants, tables, whatever are fully 638 00:23:01,630 --> 00:23:04,059 available to an adversary and 639 00:23:04,060 --> 00:23:06,399 for defining security. 640 00:23:06,400 --> 00:23:09,069 Well, first I use some not really 641 00:23:09,070 --> 00:23:11,169 well, some vague definition 642 00:23:11,170 --> 00:23:12,879 of security, but at least it gives you 643 00:23:12,880 --> 00:23:14,829 some understanding what you want. 644 00:23:14,830 --> 00:23:17,019 So for a good wide box 645 00:23:17,020 --> 00:23:19,209 implementation, an adversary that 646 00:23:19,210 --> 00:23:21,399 looks into it, she gets 647 00:23:21,400 --> 00:23:23,769 no while little to no advantage 648 00:23:23,770 --> 00:23:25,899 over a just black box implementation, so 649 00:23:25,900 --> 00:23:27,699 block black box implementation. 650 00:23:27,700 --> 00:23:29,379 It's the same implementation of a cipher, 651 00:23:29,380 --> 00:23:31,509 but where the key is hidden and we 652 00:23:31,510 --> 00:23:33,789 observe only plaintext and ciphertext, 653 00:23:33,790 --> 00:23:36,129 but no internal variables. 654 00:23:36,130 --> 00:23:38,649 So if our white box implementation 655 00:23:38,650 --> 00:23:40,779 provides the same information as a black 656 00:23:40,780 --> 00:23:42,009 box one, it's good. 657 00:23:43,140 --> 00:23:45,239 But it's not a very rigorous 658 00:23:45,240 --> 00:23:47,219 definition will proceed with the 659 00:23:47,220 --> 00:23:48,220 definition of further. 660 00:23:49,290 --> 00:23:51,419 So when you look at 661 00:23:51,420 --> 00:23:53,519 this list of requirements, you will see 662 00:23:53,520 --> 00:23:55,169 that this pretty much resembles public 663 00:23:55,170 --> 00:23:57,630 key cryptography, so why not using 664 00:23:58,780 --> 00:24:00,929 encryption schemes like RSA? 665 00:24:00,930 --> 00:24:03,119 Well, clearly because of 666 00:24:03,120 --> 00:24:04,259 performance. 667 00:24:04,260 --> 00:24:05,939 Yeah, we have remember we remember that 668 00:24:05,940 --> 00:24:07,619 performance is important, and we know 669 00:24:07,620 --> 00:24:10,229 that RSA is several 670 00:24:10,230 --> 00:24:12,509 orders of magnitude slower 671 00:24:12,510 --> 00:24:14,549 than a yes. So for as I think and of 672 00:24:14,550 --> 00:24:17,279 course, the the fastest implementation 673 00:24:17,280 --> 00:24:19,679 on the recent Intel processors 674 00:24:19,680 --> 00:24:20,819 with appropriate instructions. 675 00:24:20,820 --> 00:24:22,949 So RSA also can be optimized somehow, 676 00:24:22,950 --> 00:24:25,349 but still a huge gap 677 00:24:25,350 --> 00:24:28,079 exists between the public key and 678 00:24:28,080 --> 00:24:29,729 symmetric cryptography speed. 679 00:24:29,730 --> 00:24:31,499 And when we talk about white box 680 00:24:31,500 --> 00:24:33,779 implementation of some cipher, 681 00:24:33,780 --> 00:24:35,599 of course we want that performance loss 682 00:24:35,600 --> 00:24:37,079 should be minimal. So of course, we 683 00:24:37,080 --> 00:24:39,539 cannot achieve the speed of 684 00:24:39,540 --> 00:24:41,789 naked. Yes, we can achieve 685 00:24:41,790 --> 00:24:43,919 one cycle per bias, but we can 686 00:24:43,920 --> 00:24:45,049 achieve something in between. 687 00:24:46,130 --> 00:24:47,130 Possibly. 688 00:24:48,180 --> 00:24:50,369 So that was the goal of 689 00:24:51,720 --> 00:24:53,309 the first designers of a wide box 690 00:24:53,310 --> 00:24:55,439 implementation of some cipher to obtain 691 00:24:55,440 --> 00:24:57,299 a white box implementation of a yes or a 692 00:24:57,300 --> 00:24:58,300 similar cipher. 693 00:24:59,400 --> 00:25:01,739 And apparently, people 694 00:25:01,740 --> 00:25:03,899 quickly realized that when the design 695 00:25:03,900 --> 00:25:05,339 in the white box implementation of a 696 00:25:05,340 --> 00:25:07,529 cipher, our tools are very 697 00:25:07,530 --> 00:25:09,669 limited. Because when can we hide 698 00:25:09,670 --> 00:25:11,729 the key if everything is available to 699 00:25:11,730 --> 00:25:12,749 an adversary? 700 00:25:12,750 --> 00:25:14,579 So if historic is a constant and 701 00:25:14,580 --> 00:25:16,679 adversity will seize if restore 702 00:25:16,680 --> 00:25:18,509 a key is a function of adversarial, read 703 00:25:18,510 --> 00:25:20,429 this function and this function is pretty 704 00:25:20,430 --> 00:25:21,809 much equivalent to key. 705 00:25:21,810 --> 00:25:23,639 So where to hide it? 706 00:25:23,640 --> 00:25:25,769 Well, probably only in 707 00:25:25,770 --> 00:25:27,809 some sort of table, since some where your 708 00:25:27,810 --> 00:25:29,939 large tables swell, from which the 709 00:25:29,940 --> 00:25:33,419 keys are are quite difficult to extract, 710 00:25:33,420 --> 00:25:35,759 and what a naive way to hide. 711 00:25:35,760 --> 00:25:38,249 The key is just compose 712 00:25:38,250 --> 00:25:40,979 out a full so-called full codebook, 713 00:25:40,980 --> 00:25:43,319 a look up table for every plaintext. 714 00:25:43,320 --> 00:25:46,079 So given the key we are 715 00:25:46,080 --> 00:25:48,269 and forever plaintext the computer cipher 716 00:25:48,270 --> 00:25:49,470 text and store it in a 717 00:25:50,580 --> 00:25:52,379 large lookup table. 718 00:25:52,380 --> 00:25:54,959 But the problem is that conventional 719 00:25:54,960 --> 00:25:56,849 ciphers and that's a requirement they 720 00:25:56,850 --> 00:25:59,099 have quite large blocks at, 721 00:25:59,100 --> 00:26:01,019 well, usually 128 bit. 722 00:26:01,020 --> 00:26:02,969 And such a table, of course, is 723 00:26:02,970 --> 00:26:04,829 impossible to generate and store. 724 00:26:06,270 --> 00:26:08,789 But the idea of hiding something 725 00:26:08,790 --> 00:26:10,979 in a large lookup table is 726 00:26:10,980 --> 00:26:11,980 really profitable. 727 00:26:13,260 --> 00:26:15,249 And well, how about smaller, key 728 00:26:15,250 --> 00:26:16,250 dependent tables? 729 00:26:17,310 --> 00:26:19,859 Well, they implement. 730 00:26:19,860 --> 00:26:21,809 They can implement any function in the 731 00:26:21,810 --> 00:26:23,039 appropriate domain. 732 00:26:23,040 --> 00:26:25,319 So if we talk about 733 00:26:25,320 --> 00:26:27,509 tables that process 32 bit inputs, 734 00:26:27,510 --> 00:26:28,569 it's several gigabytes. 735 00:26:28,570 --> 00:26:30,809 Well, not for like here, but a bit more. 736 00:26:32,820 --> 00:26:35,369 So they can serve our purpose. 737 00:26:35,370 --> 00:26:37,619 But note and it's very important that 738 00:26:37,620 --> 00:26:39,809 all lookup tables that compose 739 00:26:39,810 --> 00:26:41,489 are easily convertible. 740 00:26:41,490 --> 00:26:43,589 We will face then 741 00:26:43,590 --> 00:26:45,419 inverse ability problem in the fertile 742 00:26:45,420 --> 00:26:46,680 slides. But 743 00:26:47,760 --> 00:26:50,609 you will see that if you are given 744 00:26:50,610 --> 00:26:52,919 a look up table, then by properly 745 00:26:52,920 --> 00:26:54,539 sorting inputs or outputs that can be 746 00:26:54,540 --> 00:26:55,540 easily inverted. 747 00:26:57,850 --> 00:26:59,919 And here we comes to a white box 748 00:26:59,920 --> 00:27:02,259 implementation of a yes, the first 749 00:27:02,260 --> 00:27:04,479 implement, the first, the design 750 00:27:04,480 --> 00:27:05,619 of this kind. 751 00:27:05,620 --> 00:27:07,809 So a group of researchers led by Stanley 752 00:27:07,810 --> 00:27:09,999 Cho in 2002, they simultaneously 753 00:27:10,000 --> 00:27:11,439 proposed a white box. 754 00:27:11,440 --> 00:27:14,139 Implementations for both both deals 755 00:27:14,140 --> 00:27:16,119 and a sales just appeared to the 756 00:27:16,120 --> 00:27:17,589 standards at the time. 757 00:27:17,590 --> 00:27:19,029 But they will talk a lot about this 758 00:27:19,030 --> 00:27:21,499 because I found it easier to introduce 759 00:27:21,500 --> 00:27:23,229 say yes as a cipher. 760 00:27:23,230 --> 00:27:25,539 So their idea was to obfuscate 761 00:27:25,540 --> 00:27:27,669 its implementation with the key 762 00:27:27,670 --> 00:27:29,889 insight to publish, 763 00:27:29,890 --> 00:27:33,069 algorithm and use mainly 764 00:27:33,070 --> 00:27:34,469 small lookup tables. 765 00:27:36,160 --> 00:27:38,679 As algorithms, logic and published 766 00:27:38,680 --> 00:27:40,689 as a sequence, the algorithm itself has a 767 00:27:40,690 --> 00:27:43,059 simple sequence of smaller 768 00:27:43,060 --> 00:27:45,159 table lookups where 769 00:27:45,160 --> 00:27:47,529 input for each table is carefully 770 00:27:47,530 --> 00:27:49,839 composed of the outputs of 771 00:27:49,840 --> 00:27:51,669 previous table lookups. 772 00:27:51,670 --> 00:27:53,920 And their goal was 773 00:27:55,600 --> 00:27:57,879 the security goal was to make the key 774 00:27:57,880 --> 00:27:59,769 recovery difficult. 775 00:27:59,770 --> 00:28:01,659 So the recovery of the internal key 776 00:28:01,660 --> 00:28:02,979 that's used in the. 777 00:28:02,980 --> 00:28:05,499 So their goal was to hide the key so 778 00:28:05,500 --> 00:28:07,989 that their goal was not 779 00:28:07,990 --> 00:28:10,539 to make the cipher a non-negotiable 780 00:28:10,540 --> 00:28:12,759 to prevent decryption given encryption. 781 00:28:12,760 --> 00:28:14,829 It was possible, but the goal 782 00:28:14,830 --> 00:28:16,389 was rather limited to make the key 783 00:28:16,390 --> 00:28:17,469 recovery difficult. 784 00:28:18,790 --> 00:28:20,529 How did did that? 785 00:28:20,530 --> 00:28:22,300 So here comes the bit of 786 00:28:24,610 --> 00:28:26,319 technical details. 787 00:28:26,320 --> 00:28:28,689 So this is a so-called 788 00:28:28,690 --> 00:28:30,999 block cipher, so it's versus 789 00:28:31,000 --> 00:28:33,489 16 byte blocks 790 00:28:33,490 --> 00:28:34,599 of data. 791 00:28:34,600 --> 00:28:35,739 Well, as follows. 792 00:28:35,740 --> 00:28:38,129 So this 16 bytes are split 793 00:28:38,130 --> 00:28:40,269 it into four 794 00:28:40,270 --> 00:28:42,489 blocks of size 32 795 00:28:42,490 --> 00:28:43,719 bits. 796 00:28:43,720 --> 00:28:45,939 Well, here are the denote as boxes as 797 00:28:45,940 --> 00:28:48,279 the D2 and ACE 798 00:28:48,280 --> 00:28:50,739 has structure of so-called 10 rounds, 799 00:28:50,740 --> 00:28:53,559 10 almost identical transformations, 800 00:28:53,560 --> 00:28:55,629 and each transformation works 801 00:28:55,630 --> 00:28:56,589 as follows. 802 00:28:56,590 --> 00:28:57,970 So first, the key 803 00:28:59,140 --> 00:29:01,479 is taken. It's just sort 804 00:29:01,480 --> 00:29:04,119 into the internal state into every 805 00:29:04,120 --> 00:29:06,519 well. It's also has four 806 00:29:06,520 --> 00:29:08,739 16 byte long, and it's just 807 00:29:08,740 --> 00:29:10,459 sort of every bite. 808 00:29:10,460 --> 00:29:12,849 Then every bite undergoes 809 00:29:12,850 --> 00:29:15,579 some nonlinear transformation called 810 00:29:15,580 --> 00:29:18,459 sub bites, and then 811 00:29:18,460 --> 00:29:20,769 a linear transformation is applied 812 00:29:20,770 --> 00:29:23,229 to this to every block of four bytes 813 00:29:23,230 --> 00:29:24,230 wide. 814 00:29:24,880 --> 00:29:26,829 And after this, the sequence of three 815 00:29:26,830 --> 00:29:29,139 iterations of this six and bytes 816 00:29:29,140 --> 00:29:30,140 are permeated. 817 00:29:32,370 --> 00:29:34,649 And this is this is done for 818 00:29:34,650 --> 00:29:36,029 this done 10 times. 819 00:29:36,030 --> 00:29:38,369 So pretty much the same 10 times. 820 00:29:38,370 --> 00:29:40,619 So the key is to be different every time 821 00:29:40,620 --> 00:29:42,809 to prevent some very specific 822 00:29:42,810 --> 00:29:43,769 sort of attacks. 823 00:29:43,770 --> 00:29:45,509 But the main feature is like this. 824 00:29:45,510 --> 00:29:47,609 So the 825 00:29:47,610 --> 00:29:49,889 main point of this description is that 826 00:29:49,890 --> 00:29:52,319 A splits its input into four 827 00:29:52,320 --> 00:29:54,629 blocks, so four blocks undergo 828 00:29:54,630 --> 00:29:56,159 each undergoes some specific 829 00:29:56,160 --> 00:29:57,899 transformation. And then there's the 830 00:29:57,900 --> 00:29:59,669 bicep muted. 831 00:29:59,670 --> 00:30:00,899 That's the thing. 832 00:30:00,900 --> 00:30:03,149 And having this picture in mind, 833 00:30:03,150 --> 00:30:05,249 the designers of the first 834 00:30:05,250 --> 00:30:07,409 white box implementation, they press it. 835 00:30:07,410 --> 00:30:10,049 This follows. So their goal was to hide 836 00:30:10,050 --> 00:30:12,509 the key key in the scheme, 837 00:30:12,510 --> 00:30:14,609 and they had to do this at 838 00:30:14,610 --> 00:30:16,649 every round. We'll consider only one 839 00:30:16,650 --> 00:30:18,749 round, but the procedure 840 00:30:18,750 --> 00:30:20,309 is pretty much the same in other ones. 841 00:30:21,600 --> 00:30:23,699 So now I will describe a white 842 00:30:23,700 --> 00:30:26,669 box and cordoned off a round. 843 00:30:26,670 --> 00:30:28,859 I will. Well, the original 844 00:30:28,860 --> 00:30:31,169 idea was much more complicated 845 00:30:31,170 --> 00:30:33,359 than I describe here, and 846 00:30:33,360 --> 00:30:34,799 it was much more optimized. 847 00:30:34,800 --> 00:30:36,959 So what I describe here is first a 848 00:30:36,960 --> 00:30:38,729 stronger version. 849 00:30:38,730 --> 00:30:40,979 And second, it's requires 850 00:30:40,980 --> 00:30:42,419 much more memory. 851 00:30:42,420 --> 00:30:44,669 And even though this version that 852 00:30:44,670 --> 00:30:46,979 I described here is stronger, it still 853 00:30:46,980 --> 00:30:49,439 can be broken and badly broken. 854 00:30:49,440 --> 00:30:51,569 So you don't lose anything 855 00:30:51,570 --> 00:30:54,179 in listening to 856 00:30:54,180 --> 00:30:55,889 my view of what they've done. 857 00:30:55,890 --> 00:30:58,289 So the original version was just 858 00:30:58,290 --> 00:31:00,389 a bit weaker, but also smaller. 859 00:31:00,390 --> 00:31:03,059 So the designers 860 00:31:03,060 --> 00:31:05,759 worked mainly with this 32 bit blocks, 861 00:31:05,760 --> 00:31:07,919 so they left this byte 862 00:31:07,920 --> 00:31:09,209 permutation apart. 863 00:31:09,210 --> 00:31:11,189 And their goal was to hide the key. 864 00:31:11,190 --> 00:31:13,349 So what they did, they 865 00:31:13,350 --> 00:31:14,580 secretly generated 866 00:31:15,810 --> 00:31:16,949 linear transformations. 867 00:31:16,950 --> 00:31:19,049 P and Q made them 868 00:31:19,050 --> 00:31:21,359 some sort of mutually exclusive 869 00:31:21,360 --> 00:31:23,429 compensating so that if 870 00:31:23,430 --> 00:31:25,499 you put P 871 00:31:25,500 --> 00:31:27,449 right after Q, they would compensate each 872 00:31:27,450 --> 00:31:28,450 other 873 00:31:29,700 --> 00:31:31,799 so that the encryption process 874 00:31:31,800 --> 00:31:33,299 would still be the same. 875 00:31:33,300 --> 00:31:35,700 But this 32 bit block? 876 00:31:36,730 --> 00:31:38,859 It will operate a bit differently, and 877 00:31:38,860 --> 00:31:40,929 the idea was to hide this 878 00:31:40,930 --> 00:31:43,269 secret key between 879 00:31:43,270 --> 00:31:45,549 the two secret lunar 880 00:31:45,550 --> 00:31:46,550 transformations. 881 00:31:48,760 --> 00:31:49,760 So 882 00:31:50,860 --> 00:31:52,689 they generate a distance formations for 883 00:31:52,690 --> 00:31:56,079 every round and for every block and 884 00:31:56,080 --> 00:31:58,509 the resultant 32 bit block. 885 00:31:58,510 --> 00:32:00,579 They just computed 886 00:32:00,580 --> 00:32:03,309 a full lookup table, which is 887 00:32:03,310 --> 00:32:05,379 again key dependent and has two 888 00:32:05,380 --> 00:32:06,739 to the thirty two entries. 889 00:32:06,740 --> 00:32:08,949 Well, originally less, but we'll 890 00:32:08,950 --> 00:32:10,629 assume that it's just like this. 891 00:32:10,630 --> 00:32:13,839 So to the thirty two entries 892 00:32:13,840 --> 00:32:16,809 and they start all this tables in memory 893 00:32:16,810 --> 00:32:19,599 and having like this, so 894 00:32:19,600 --> 00:32:21,549 the ten rounds of layoffs were just 895 00:32:21,550 --> 00:32:23,529 sequences of this tables and byte 896 00:32:23,530 --> 00:32:25,669 permutations tables and by table 897 00:32:25,670 --> 00:32:27,399 look ups and by permutations. 898 00:32:27,400 --> 00:32:29,859 And this worked pretty much the same 899 00:32:29,860 --> 00:32:31,480 as the original is. 900 00:32:33,330 --> 00:32:35,549 And, well, the same idea was 901 00:32:35,550 --> 00:32:37,920 used for the DEA Cipher. 902 00:32:40,750 --> 00:32:42,729 But the problem of all this 903 00:32:42,730 --> 00:32:44,349 implementation is that they can be badly 904 00:32:44,350 --> 00:32:45,279 broken. 905 00:32:45,280 --> 00:32:47,529 So the well known methods of differential 906 00:32:47,530 --> 00:32:49,659 cryptanalysis applies to all 907 00:32:49,660 --> 00:32:51,609 of this proposed implementations. 908 00:32:51,610 --> 00:32:53,979 So the idea of differential cryptanalysis 909 00:32:53,980 --> 00:32:56,319 is that we can see their differences 910 00:32:56,320 --> 00:32:58,689 will be the difference between 911 00:32:58,690 --> 00:32:59,739 pairs of inputs. 912 00:32:59,740 --> 00:33:01,479 So I recall that 913 00:33:02,740 --> 00:33:04,929 the full lookup table is available to 914 00:33:04,930 --> 00:33:07,089 the adversary and 915 00:33:07,090 --> 00:33:09,459 looking at inputs, you can compute 916 00:33:09,460 --> 00:33:11,349 the difference of inputs and difference 917 00:33:11,350 --> 00:33:13,629 of outputs, and 918 00:33:13,630 --> 00:33:15,729 that worked briefly 919 00:33:15,730 --> 00:33:16,749 as follows. 920 00:33:16,750 --> 00:33:19,089 So we consider multiple inputs 921 00:33:19,090 --> 00:33:21,459 and we look we consider the evolution 922 00:33:21,460 --> 00:33:22,869 of difference between them. 923 00:33:22,870 --> 00:33:24,939 And we just guess that for some 924 00:33:24,940 --> 00:33:27,249 pair of inputs, the difference 925 00:33:27,250 --> 00:33:29,379 becomes after it goes through linear 926 00:33:29,380 --> 00:33:31,869 transformations, it becomes non-zero 927 00:33:31,870 --> 00:33:34,059 only in one as box well, 928 00:33:34,060 --> 00:33:35,559 possibly in two as boxes. 929 00:33:35,560 --> 00:33:37,269 Well, suppose they're in one. 930 00:33:37,270 --> 00:33:39,489 And the next important thing is that 931 00:33:39,490 --> 00:33:41,079 this input pairs. 932 00:33:41,080 --> 00:33:43,149 They form some sort of linear 933 00:33:43,150 --> 00:33:44,109 space. 934 00:33:44,110 --> 00:33:47,079 This linear space can be detected and 935 00:33:47,080 --> 00:33:49,509 it can be detected because the output 936 00:33:49,510 --> 00:33:51,849 difference they form a metrics and 937 00:33:51,850 --> 00:33:53,109 this matrix. 938 00:33:53,110 --> 00:33:55,299 It has low rent because all 939 00:33:55,300 --> 00:33:57,489 this out for differences 940 00:33:57,490 --> 00:34:00,729 of size 32 bits they were generated 941 00:34:00,730 --> 00:34:03,049 of out of 942 00:34:03,050 --> 00:34:05,229 a difference in only one byte in 943 00:34:05,230 --> 00:34:06,669 eight bit. 944 00:34:06,670 --> 00:34:08,769 So some very simple algebraic 945 00:34:08,770 --> 00:34:10,928 properties are used, and 946 00:34:10,929 --> 00:34:13,059 this is enough to detect 947 00:34:13,060 --> 00:34:15,279 the case when there's differences 948 00:34:15,280 --> 00:34:17,769 shrink to only one byte to recover 949 00:34:17,770 --> 00:34:21,339 P and Q, and subsequently 950 00:34:21,340 --> 00:34:22,869 to recover 951 00:34:23,920 --> 00:34:26,109 well being recovered up to some linear 952 00:34:26,110 --> 00:34:28,249 equivalence. And then the key can be a 953 00:34:28,250 --> 00:34:29,408 simple as well. 954 00:34:29,409 --> 00:34:31,209 This layers are removed and then the key 955 00:34:31,210 --> 00:34:33,339 can be simply guessed from this lookup 956 00:34:33,340 --> 00:34:34,718 tables. It's very simple. 957 00:34:34,719 --> 00:34:36,609 And with other optimizations, the entire 958 00:34:36,610 --> 00:34:38,049 key from the whole wide box 959 00:34:38,050 --> 00:34:40,359 implementations can mean that in just 960 00:34:40,360 --> 00:34:42,349 two to three operations, which is on 961 00:34:42,350 --> 00:34:44,859 modern desktop with just seconds 962 00:34:46,030 --> 00:34:48,099 and all the subsequent 963 00:34:48,100 --> 00:34:50,619 ideas and proposals for refinements 964 00:34:50,620 --> 00:34:52,209 of this simple principle. 965 00:34:52,210 --> 00:34:54,189 And they all were broken. 966 00:34:57,840 --> 00:35:00,119 Part of problem, why they were broken 967 00:35:00,120 --> 00:35:02,579 because, well, heaven on the two 968 00:35:04,110 --> 00:35:06,329 linear transformations and one nonlinear 969 00:35:06,330 --> 00:35:08,879 layer is not enough. 970 00:35:08,880 --> 00:35:11,219 There is a paper more than 10 years 971 00:35:11,220 --> 00:35:13,519 old that shows that even if we had three 972 00:35:13,520 --> 00:35:15,839 nonlinear layers here, then they 973 00:35:15,840 --> 00:35:17,249 can still be attacked. 974 00:35:17,250 --> 00:35:19,829 And when we consider a yes, 975 00:35:19,830 --> 00:35:22,019 there is only one nonlinear layer 976 00:35:22,020 --> 00:35:24,449 in a round and this scheme, 977 00:35:24,450 --> 00:35:26,999 even if we surrounded with unknown 978 00:35:27,000 --> 00:35:29,310 B and Q, it can still be easily attacked 979 00:35:30,450 --> 00:35:32,849 and generally the table based 980 00:35:32,850 --> 00:35:34,439 approach the approach based on lookup 981 00:35:34,440 --> 00:35:36,449 tables, it fails for a yes. 982 00:35:36,450 --> 00:35:38,579 It also fails from any other ciphers 983 00:35:38,580 --> 00:35:40,829 just because of structural failures, 984 00:35:40,830 --> 00:35:43,739 because if we consider smaller 985 00:35:43,740 --> 00:35:45,630 part of a cipher for which. 986 00:35:48,060 --> 00:35:50,129 For which a look up table 987 00:35:50,130 --> 00:35:52,589 can be constructed for smaller ones, 988 00:35:52,590 --> 00:35:54,719 then only a small part of the key 989 00:35:54,720 --> 00:35:55,859 is hidden here. 990 00:35:55,860 --> 00:35:57,359 Only 32 bits. 991 00:35:57,360 --> 00:35:59,489 And if we consider a larger part 992 00:35:59,490 --> 00:36:01,589 of a yes, then the 993 00:36:01,590 --> 00:36:03,089 tables becomes too large. 994 00:36:03,090 --> 00:36:05,339 So hiding in turkey 995 00:36:05,340 --> 00:36:07,439 would require enormously large 996 00:36:07,440 --> 00:36:09,449 tables, which you cannot allow. 997 00:36:09,450 --> 00:36:11,549 And all this table based approach 998 00:36:11,550 --> 00:36:13,769 that failed for years 999 00:36:13,770 --> 00:36:16,199 and other ciphers. So some different 1000 00:36:16,200 --> 00:36:18,300 design is required to 1001 00:36:19,740 --> 00:36:21,749 sew. A cipher must have completely 1002 00:36:21,750 --> 00:36:23,849 different design, and 1003 00:36:23,850 --> 00:36:25,769 the key must be injected in different 1004 00:36:25,770 --> 00:36:27,929 ways to be suitable 1005 00:36:27,930 --> 00:36:29,789 for a wide box implementation. 1006 00:36:29,790 --> 00:36:32,009 So here is just an overview of other 1007 00:36:32,010 --> 00:36:34,229 proposals, so all that 1008 00:36:34,230 --> 00:36:36,509 a white box and 1009 00:36:36,510 --> 00:36:38,129 implementation have been broken. 1010 00:36:38,130 --> 00:36:40,259 All the DS wide box implementations have 1011 00:36:40,260 --> 00:36:43,139 been broken quite 1012 00:36:43,140 --> 00:36:44,429 many years ago. 1013 00:36:44,430 --> 00:36:45,689 All the attacks have practical 1014 00:36:45,690 --> 00:36:48,179 complexity, and indeed, if an adversary 1015 00:36:48,180 --> 00:36:50,459 ever gets their full entire record 1016 00:36:50,460 --> 00:36:51,959 with this tables, it can be easily 1017 00:36:51,960 --> 00:36:52,889 broken. 1018 00:36:52,890 --> 00:36:55,199 But to my 1019 00:36:55,200 --> 00:36:57,689 great surprise, well, 1020 00:36:57,690 --> 00:36:59,069 everything it is broken. 1021 00:36:59,070 --> 00:37:01,079 To my great surprise, there are quite 1022 00:37:01,080 --> 00:37:03,389 minor proprietary solutions on the market 1023 00:37:04,950 --> 00:37:07,529 from different companies, including 1024 00:37:07,530 --> 00:37:09,389 companies started by people who 1025 00:37:10,410 --> 00:37:12,389 made the first white box implementations, 1026 00:37:12,390 --> 00:37:14,999 and they are certainly aware of 1027 00:37:15,000 --> 00:37:16,199 the existing attacks. 1028 00:37:16,200 --> 00:37:18,419 So this solutions probably combine 1029 00:37:18,420 --> 00:37:20,609 well this week academic proposals with 1030 00:37:20,610 --> 00:37:22,919 some additional obfuscation techniques, 1031 00:37:22,920 --> 00:37:25,079 and we do not know anything 1032 00:37:25,080 --> 00:37:26,099 about their security. 1033 00:37:26,100 --> 00:37:27,629 Well, there are no public attacks on the 1034 00:37:27,630 --> 00:37:29,909 schemes. Maybe they have been 1035 00:37:29,910 --> 00:37:31,619 there, Vertex, but they are not 1036 00:37:31,620 --> 00:37:33,749 published. So I recommend you not 1037 00:37:33,750 --> 00:37:36,149 to trust these schemes at all because 1038 00:37:36,150 --> 00:37:38,279 academically, there is no strong white 1039 00:37:38,280 --> 00:37:39,280 box scheme. 1040 00:37:40,660 --> 00:37:41,660 So 1041 00:37:42,850 --> 00:37:45,069 the previous parts of the previous 1042 00:37:45,070 --> 00:37:46,839 five books implementations there are 1043 00:37:46,840 --> 00:37:49,089 devoted to recovery, but what about other 1044 00:37:49,090 --> 00:37:50,439 security goals? 1045 00:37:50,440 --> 00:37:53,289 So can we use 1046 00:37:53,290 --> 00:37:55,149 this principle fireworks implementation 1047 00:37:55,150 --> 00:37:56,150 for something else? 1048 00:37:57,180 --> 00:37:59,609 So one definition, 1049 00:37:59,610 --> 00:38:01,109 which we do know to the so-called 1050 00:38:01,110 --> 00:38:03,359 required books, cryptography deals 1051 00:38:03,360 --> 00:38:05,639 with the key very secure 1052 00:38:05,640 --> 00:38:07,769 to so-called is the goal that 1053 00:38:07,770 --> 00:38:09,929 an adversary cannot extract the key 1054 00:38:09,930 --> 00:38:11,069 from the code. 1055 00:38:11,070 --> 00:38:12,689 Well, this definition was chronological 1056 00:38:12,690 --> 00:38:14,849 at first, and it's apparently easier 1057 00:38:14,850 --> 00:38:17,249 to achieve, even though this 1058 00:38:17,250 --> 00:38:19,919 previous implementations were broken. 1059 00:38:19,920 --> 00:38:22,049 But when indeed the code lifting 1060 00:38:22,050 --> 00:38:24,539 was used, then this definition 1061 00:38:24,540 --> 00:38:26,819 is irrelevant because when you can use 1062 00:38:26,820 --> 00:38:29,580 your white box in implementation 1063 00:38:30,690 --> 00:38:32,789 as a decryption routine, then the 1064 00:38:32,790 --> 00:38:35,429 white to care about recovery, 1065 00:38:35,430 --> 00:38:36,689 it's useless. 1066 00:38:36,690 --> 00:38:37,690 So. 1067 00:38:39,680 --> 00:38:42,289 People introduced in other definition 1068 00:38:42,290 --> 00:38:43,579 of so-called Strunk White box 1069 00:38:43,580 --> 00:38:46,219 cryptography, where 1070 00:38:46,220 --> 00:38:48,309 we require that even though 1071 00:38:48,310 --> 00:38:50,659 their implementation 1072 00:38:50,660 --> 00:38:52,579 is published, that verse there cannot 1073 00:38:52,580 --> 00:38:54,739 invert the cipher so it cannot 1074 00:38:54,740 --> 00:38:56,959 get a decryption routine 1075 00:38:56,960 --> 00:38:59,179 from a publicly available encryption 1076 00:38:59,180 --> 00:39:00,779 routine and encryption routine is 1077 00:39:00,780 --> 00:39:03,529 available together with embedded key. 1078 00:39:03,530 --> 00:39:05,689 It applies in the case of code 1079 00:39:05,690 --> 00:39:08,269 lifting and but also it's 1080 00:39:08,270 --> 00:39:09,739 almost identical to public key 1081 00:39:09,740 --> 00:39:10,729 cryptography. 1082 00:39:10,730 --> 00:39:12,949 And the problem is that 1083 00:39:12,950 --> 00:39:15,169 it's as difficult to design 1084 00:39:15,170 --> 00:39:17,809 as public key cryptographic schemes 1085 00:39:17,810 --> 00:39:20,089 and all the existing proposals for wide 1086 00:39:20,090 --> 00:39:21,799 box implementation that don't comply to 1087 00:39:21,800 --> 00:39:22,999 this definition at all. 1088 00:39:23,000 --> 00:39:24,619 They are all easily in virtual. 1089 00:39:26,150 --> 00:39:28,579 And when we started 1090 00:39:28,580 --> 00:39:31,339 our research on weight loss cryptography, 1091 00:39:31,340 --> 00:39:33,709 so we started thinking that 1092 00:39:33,710 --> 00:39:35,989 indeed. So if 1093 00:39:35,990 --> 00:39:38,419 current ciphers are not so 1094 00:39:38,420 --> 00:39:39,769 much suitable for white box 1095 00:39:39,770 --> 00:39:41,899 implementations, even 1096 00:39:41,900 --> 00:39:43,939 recover security is difficult to achieve. 1097 00:39:43,940 --> 00:39:45,949 So does the station change if we make a 1098 00:39:45,950 --> 00:39:47,660 white box suitable cipher from scratch? 1099 00:39:49,190 --> 00:39:51,739 Well, apparently it does, 1100 00:39:51,740 --> 00:39:53,689 at least for a quick recovery security, 1101 00:39:53,690 --> 00:39:55,789 so we can claim that 1102 00:39:55,790 --> 00:39:57,739 we can achieve good recovery, secure a 1103 00:39:57,740 --> 00:39:59,179 weak white box orthography. 1104 00:40:00,320 --> 00:40:01,519 In our proposal. 1105 00:40:01,520 --> 00:40:03,589 And the idea is so if 1106 00:40:03,590 --> 00:40:05,749 we have the goal of just hire the 1107 00:40:05,750 --> 00:40:08,029 key in a table, then 1108 00:40:08,030 --> 00:40:09,769 it's super easy. 1109 00:40:09,770 --> 00:40:12,079 So you just 1110 00:40:12,080 --> 00:40:14,779 take an iOS like Cipher, for example, 1111 00:40:14,780 --> 00:40:17,449 consider a 32 bit cipher 1112 00:40:17,450 --> 00:40:18,530 and then just take 1113 00:40:19,550 --> 00:40:22,309 128 bit key and 1114 00:40:22,310 --> 00:40:24,839 apply a 32 bit block, 1115 00:40:24,840 --> 00:40:26,689 then some lean years information and then 1116 00:40:26,690 --> 00:40:28,459 get the key. Apply a 1117 00:40:30,200 --> 00:40:33,409 32 bit transformation and then make 1118 00:40:33,410 --> 00:40:35,479 a linear transformation and eject the key 1119 00:40:35,480 --> 00:40:38,359 and do this say 20 times. 1120 00:40:38,360 --> 00:40:40,489 So the every bit of the key 1121 00:40:40,490 --> 00:40:41,600 is used five times. 1122 00:40:42,970 --> 00:40:45,079 And make it a huge 1123 00:40:45,080 --> 00:40:47,289 a lookup table out of it, 1124 00:40:47,290 --> 00:40:48,909 if you want a cipher with the larger 1125 00:40:48,910 --> 00:40:50,050 block. You can. 1126 00:40:51,550 --> 00:40:53,739 Make this in Berlin, mixed outputs, 1127 00:40:53,740 --> 00:40:56,529 so the cake will be perfectly hidden, 1128 00:40:56,530 --> 00:40:59,019 security margin is even larger than in 1129 00:40:59,020 --> 00:41:00,189 regular is. 1130 00:41:00,190 --> 00:41:01,879 But the problem, of course, it's trivial 1131 00:41:01,880 --> 00:41:03,519 and vertical because given this lookup 1132 00:41:03,520 --> 00:41:05,529 table, it's rather easy to obtain the 1133 00:41:05,530 --> 00:41:07,869 plain text from a cipher text. 1134 00:41:07,870 --> 00:41:10,419 And this is the problem of every table 1135 00:41:10,420 --> 00:41:12,549 based white box 1136 00:41:12,550 --> 00:41:14,949 cryptography since, well, 1137 00:41:14,950 --> 00:41:17,259 because of their of the implementation 1138 00:41:17,260 --> 00:41:19,119 size lookup tables, allowing inputs only 1139 00:41:19,120 --> 00:41:21,009 up to 32 bits. 1140 00:41:21,010 --> 00:41:23,139 Sort of. And we 1141 00:41:23,140 --> 00:41:24,039 just don't know. 1142 00:41:24,040 --> 00:41:25,509 It's really an open problem how to 1143 00:41:25,510 --> 00:41:27,999 compose lookup tables 1144 00:41:28,000 --> 00:41:30,159 so that they 1145 00:41:30,160 --> 00:41:32,229 cannot be invisible easily by an 1146 00:41:32,230 --> 00:41:34,389 adversary. So we might allow that 1147 00:41:34,390 --> 00:41:36,039 they can be invisible. 1148 00:41:36,040 --> 00:41:38,079 If you know the key, if you know how 1149 00:41:38,080 --> 00:41:39,969 these tables are structured. 1150 00:41:39,970 --> 00:41:40,970 But if 1151 00:41:42,520 --> 00:41:45,159 that works to just know the key he 1152 00:41:45,160 --> 00:41:47,229 cannot invert and 1153 00:41:47,230 --> 00:41:48,399 we don't know how to do it. 1154 00:41:48,400 --> 00:41:50,979 So doing this would solve a pretty 1155 00:41:50,980 --> 00:41:52,239 good problem in cryptography. 1156 00:41:53,600 --> 00:41:55,429 It's pretty much similar to what we know 1157 00:41:55,430 --> 00:41:57,050 as one way permutations. 1158 00:41:59,220 --> 00:42:01,169 So-called Ted, there are permutations 1159 00:42:01,170 --> 00:42:02,369 were introduced in the beginning of 1160 00:42:02,370 --> 00:42:04,679 public key cryptography, and 1161 00:42:06,900 --> 00:42:09,389 things like RSA has functions 1162 00:42:09,390 --> 00:42:11,459 are seeing encryption function is an 1163 00:42:11,460 --> 00:42:13,649 example of a trapdoor permutation, and 1164 00:42:13,650 --> 00:42:15,789 they are believed the only problem is 1165 00:42:15,790 --> 00:42:18,149 that believed to be secure, you 1166 00:42:18,150 --> 00:42:21,419 consider a secure for really large 1167 00:42:21,420 --> 00:42:23,940 and for which the performance is usually 1168 00:42:25,200 --> 00:42:26,729 not attractive. 1169 00:42:26,730 --> 00:42:28,349 And for smaller end, for example, 1170 00:42:28,350 --> 00:42:29,729 performance, this is still an open 1171 00:42:29,730 --> 00:42:30,730 problem. 1172 00:42:31,570 --> 00:42:33,789 We also consider some algebraic 1173 00:42:33,790 --> 00:42:36,219 constructions because we know that 1174 00:42:36,220 --> 00:42:38,349 inversion vector functions, 1175 00:42:38,350 --> 00:42:40,419 which are even degree to 1176 00:42:40,420 --> 00:42:42,789 polynomials of our finite fields, 1177 00:42:42,790 --> 00:42:44,019 is difficult. 1178 00:42:44,020 --> 00:42:46,359 And the problem is you cannot 1179 00:42:46,360 --> 00:42:48,579 make such a polynomial at random 1180 00:42:48,580 --> 00:42:51,039 enough to hide this trapdoor 1181 00:42:51,040 --> 00:42:53,349 sight. And there are quite many proposals 1182 00:42:53,350 --> 00:42:55,929 in this area called multivariate 1183 00:42:55,930 --> 00:42:58,089 cryptography, and they were 1184 00:42:58,090 --> 00:43:00,580 all broken up. 1185 00:43:03,510 --> 00:43:06,329 Unfortunately, outsold the whole scheme, 1186 00:43:06,330 --> 00:43:08,010 it looks like there is. 1187 00:43:09,820 --> 00:43:11,919 Publicly available Polynomial A. 1188 00:43:11,920 --> 00:43:14,079 It's surrounded by 1189 00:43:14,080 --> 00:43:16,659 a fine transformations S.A., 1190 00:43:16,660 --> 00:43:19,119 and while it's inevitable 1191 00:43:19,120 --> 00:43:21,159 because of properties of a as 1192 00:43:21,160 --> 00:43:22,449 unfortunate, unfortunately, the families 1193 00:43:22,450 --> 00:43:24,429 of convertible polynomials are pretty 1194 00:43:24,430 --> 00:43:26,529 small and all 1195 00:43:26,530 --> 00:43:28,149 this schemes have been attacked pretty 1196 00:43:28,150 --> 00:43:29,150 many of them. 1197 00:43:29,830 --> 00:43:32,619 Some work in progress and our direction 1198 00:43:32,620 --> 00:43:35,019 is to consider two layer 1199 00:43:35,020 --> 00:43:37,419 schemes where 1200 00:43:37,420 --> 00:43:39,699 we would have to nonlinear 1201 00:43:39,700 --> 00:43:42,099 layers A1, A2 and some 1202 00:43:42,100 --> 00:43:43,359 supplementary level 1203 00:43:44,470 --> 00:43:45,670 multi-level A3, 1204 00:43:46,750 --> 00:43:48,849 where we eventually get polynomial 1205 00:43:48,850 --> 00:43:50,679 of degree for and 1206 00:43:51,770 --> 00:43:52,719 esteemed you. 1207 00:43:52,720 --> 00:43:54,609 Here are a fine inverse to both 1208 00:43:54,610 --> 00:43:55,899 transformations. 1209 00:43:55,900 --> 00:43:58,029 But this is still pretty much work 1210 00:43:58,030 --> 00:43:59,030 in progress. 1211 00:43:59,710 --> 00:44:01,779 So there is some hope to build white 1212 00:44:01,780 --> 00:44:04,119 box good wide blocks of thoroughfare 1213 00:44:04,120 --> 00:44:06,819 on the algebraic basis, but it's far from 1214 00:44:06,820 --> 00:44:08,889 being explored and finished. 1215 00:44:08,890 --> 00:44:11,109 And so 1216 00:44:11,110 --> 00:44:13,839 short summary that 1217 00:44:13,840 --> 00:44:15,399 white box approach, if initially was 1218 00:44:15,400 --> 00:44:17,319 aimed to obfuscate encryption or 1219 00:44:17,320 --> 00:44:19,659 decryption the rotis with keys inside. 1220 00:44:19,660 --> 00:44:21,579 Isn't it quite similar to public key 1221 00:44:21,580 --> 00:44:23,679 cryptography and the 1222 00:44:23,680 --> 00:44:25,809 main feature of existing 1223 00:44:25,810 --> 00:44:27,909 proposals that they are all 1224 00:44:27,910 --> 00:44:29,799 week and they have been broken? 1225 00:44:29,800 --> 00:44:31,899 So use every solution 1226 00:44:31,900 --> 00:44:33,369 why books are part of solution that is 1227 00:44:33,370 --> 00:44:35,739 offered on the market with a great care 1228 00:44:35,740 --> 00:44:38,079 and we we are afraid that just 1229 00:44:38,080 --> 00:44:40,179 good file box solutions do not exist. 1230 00:44:40,180 --> 00:44:42,039 But if they exist, it would be a really 1231 00:44:42,040 --> 00:44:44,139 good solution to an 1232 00:44:44,140 --> 00:44:46,059 open problem, though. 1233 00:44:46,060 --> 00:44:47,060 Thank you for your attention. 1234 00:44:55,340 --> 00:44:56,780 Thank you very much, Dimitri. 1235 00:44:57,860 --> 00:45:00,259 I expect after this talk 1236 00:45:00,260 --> 00:45:02,149 a lot of questions, if you have 1237 00:45:02,150 --> 00:45:04,069 questions, could you line up at the 1238 00:45:04,070 --> 00:45:06,379 microphones put up appear 1239 00:45:06,380 --> 00:45:07,549 in the room? 1240 00:45:07,550 --> 00:45:09,829 And I want to ask our signal 1241 00:45:09,830 --> 00:45:11,269 angel up there. 1242 00:45:11,270 --> 00:45:12,709 Do you have any questions from the 1243 00:45:12,710 --> 00:45:13,759 internet? 1244 00:45:13,760 --> 00:45:16,129 No, no questions 1245 00:45:16,130 --> 00:45:17,449 from the internet. 1246 00:45:17,450 --> 00:45:19,579 How about questions from 1247 00:45:19,580 --> 00:45:20,580 inside the room? 1248 00:45:25,310 --> 00:45:26,909 OK, go ahead, please. 1249 00:45:26,910 --> 00:45:29,299 Um, it's more of an practical 1250 00:45:29,300 --> 00:45:31,579 application question, 1251 00:45:31,580 --> 00:45:34,129 um, from the tax taxi have shown 1252 00:45:34,130 --> 00:45:36,199 and are referring to that as a 1253 00:45:36,200 --> 00:45:38,359 metric for encryption is too slow to be 1254 00:45:38,360 --> 00:45:40,070 feasible in the practical context. 1255 00:45:41,100 --> 00:45:42,100 What? 1256 00:45:42,850 --> 00:45:45,130 What improvement would I get from using 1257 00:45:46,600 --> 00:45:48,429 as a metric encryption, because the 1258 00:45:48,430 --> 00:45:50,499 problem is the 1259 00:45:50,500 --> 00:45:52,779 user or its antivirus, which isn't, 1260 00:45:52,780 --> 00:45:54,999 you know, AutoZone obviously 1261 00:45:55,000 --> 00:45:56,499 has to do the decryption. 1262 00:45:56,500 --> 00:45:58,389 So the interesting part in the first 1263 00:45:58,390 --> 00:45:59,559 place is the description key. 1264 00:46:01,500 --> 00:46:04,859 So using asymmetric encryption, 1265 00:46:04,860 --> 00:46:07,769 it would keep me from after extracting 1266 00:46:07,770 --> 00:46:10,139 the decryption key in several 1267 00:46:10,140 --> 00:46:11,140 ways you described. 1268 00:46:11,970 --> 00:46:14,039 Asymmetric encryption would keep me from 1269 00:46:14,040 --> 00:46:16,589 obtaining the encryption key. 1270 00:46:16,590 --> 00:46:17,669 No, it wouldn't. 1271 00:46:17,670 --> 00:46:20,279 So what would what to bring 1272 00:46:20,280 --> 00:46:22,049 and what what's the good part about? 1273 00:46:22,050 --> 00:46:23,099 Yeah. 1274 00:46:23,100 --> 00:46:25,499 Well, let me scrub it to 1275 00:46:26,760 --> 00:46:27,760 the first example. 1276 00:46:30,380 --> 00:46:32,449 So as you 1277 00:46:32,450 --> 00:46:35,299 might see here, so you have a 1278 00:46:35,300 --> 00:46:37,129 pretty much large content. 1279 00:46:37,130 --> 00:46:39,439 So if you encrypt it just with 1280 00:46:39,440 --> 00:46:41,449 a symmetrically atrophy, it will be just 1281 00:46:41,450 --> 00:46:42,979 very slow. 1282 00:46:42,980 --> 00:46:45,019 You can have an encrypted with a warfare 1283 00:46:45,020 --> 00:46:47,419 if you're encrypt only 1284 00:46:47,420 --> 00:46:49,039 with symmetrical photography. 1285 00:46:49,040 --> 00:46:51,199 And the key to this as the 1286 00:46:51,200 --> 00:46:53,029 symmetric scheme encrypted with 1287 00:46:53,030 --> 00:46:55,129 asymmetric cryptography, then it becomes 1288 00:46:55,130 --> 00:46:56,209 vulnerable. 1289 00:46:56,210 --> 00:46:58,309 While this semester key is 1290 00:46:58,310 --> 00:47:00,619 used, and if you 1291 00:47:00,620 --> 00:47:03,049 have a good white box scheme here 1292 00:47:03,050 --> 00:47:05,389 that you can replace both encryption 1293 00:47:05,390 --> 00:47:07,699 and this scheme with just one white 1294 00:47:07,700 --> 00:47:10,099 box scheme. So if its performance 1295 00:47:10,100 --> 00:47:12,239 is good enough, then the key cannot be 1296 00:47:12,240 --> 00:47:14,989 recovered in this scheme, and 1297 00:47:14,990 --> 00:47:17,209 performance loss would 1298 00:47:17,210 --> 00:47:19,639 be a much smaller compared to 1299 00:47:19,640 --> 00:47:22,389 the total use of asymmetric cryptography. 1300 00:47:22,390 --> 00:47:24,019 So just answer the question. 1301 00:47:26,880 --> 00:47:28,559 Mm hmm. 1302 00:47:28,560 --> 00:47:29,560 And. 1303 00:47:33,500 --> 00:47:35,629 And perhaps I just missed the 1304 00:47:35,630 --> 00:47:37,519 point of the complete speech a bit, 1305 00:47:37,520 --> 00:47:39,739 because in the end, all 1306 00:47:39,740 --> 00:47:41,239 the white box encryption schemes look a 1307 00:47:41,240 --> 00:47:43,909 bit like, what's up obfuscation to me, 1308 00:47:43,910 --> 00:47:46,039 it's not good, not a really different 1309 00:47:46,040 --> 00:47:47,300 quality than obfuscation, is it? 1310 00:47:48,470 --> 00:47:49,729 They are not much different from 1311 00:47:49,730 --> 00:47:51,809 obfuscation. And yes, it can be 1312 00:47:51,810 --> 00:47:53,749 simply stated that the just application 1313 00:47:53,750 --> 00:47:55,159 of symmetric schemes. 1314 00:47:55,160 --> 00:47:57,289 But this obfuscation they 1315 00:47:57,290 --> 00:47:58,999 it really brings us to the world of 1316 00:47:59,000 --> 00:48:00,079 public cryptography. 1317 00:48:00,080 --> 00:48:02,359 So they're just crazy creatures 1318 00:48:02,360 --> 00:48:03,360 in between. 1319 00:48:04,220 --> 00:48:05,839 OK, thank you. 1320 00:48:05,840 --> 00:48:08,149 OK, then microphone number 1321 00:48:08,150 --> 00:48:10,879 four in the center of the room, please. 1322 00:48:10,880 --> 00:48:12,769 Thank you for your talk. 1323 00:48:12,770 --> 00:48:15,109 I had a question because you mentioned 1324 00:48:15,110 --> 00:48:17,269 these lookup tables and making them hard 1325 00:48:17,270 --> 00:48:18,529 to inferred. 1326 00:48:18,530 --> 00:48:21,589 And then you said that you tried 1327 00:48:21,590 --> 00:48:23,239 trapdoor functions or someone tried to 1328 00:48:23,240 --> 00:48:25,699 get Chapter 14 and that was performance 1329 00:48:25,700 --> 00:48:26,839 wise, really difficult. 1330 00:48:26,840 --> 00:48:27,979 And I can imagine that 1331 00:48:29,000 --> 00:48:30,769 you can't do any better than trapdoor 1332 00:48:30,770 --> 00:48:33,289 functions so that you 1333 00:48:33,290 --> 00:48:35,029 can prove that if a central function is 1334 00:48:35,030 --> 00:48:37,459 just too hard to use, then 1335 00:48:37,460 --> 00:48:39,289 you won't find anything better. 1336 00:48:39,290 --> 00:48:41,029 Have you looked at impossibility proofs 1337 00:48:41,030 --> 00:48:41,899 there? 1338 00:48:41,900 --> 00:48:44,119 Well, the fact that we 1339 00:48:44,120 --> 00:48:46,099 would not like impossibility proves 1340 00:48:46,100 --> 00:48:48,199 because we can't possibly 1341 00:48:48,200 --> 00:48:49,200 prove that 1342 00:48:50,390 --> 00:48:53,179 some sort of trapdoor are impossible, 1343 00:48:53,180 --> 00:48:55,489 but maybe we don't need something 1344 00:48:55,490 --> 00:48:57,709 that is provably 1345 00:48:57,710 --> 00:48:59,209 non-convertible here. 1346 00:48:59,210 --> 00:49:01,369 Maybe we can hope for something 1347 00:49:01,370 --> 00:49:03,619 like for a yes, that is just seemingly 1348 00:49:03,620 --> 00:49:04,939 non-convertible. 1349 00:49:04,940 --> 00:49:07,579 We it's a key to not having 1350 00:49:07,580 --> 00:49:09,679 a formal integer as proof that it is 1351 00:49:09,680 --> 00:49:11,869 a good trapdoor, but it could be key 1352 00:49:11,870 --> 00:49:13,519 if that's just many people try to 1353 00:49:13,520 --> 00:49:15,349 inverted and didn't succeed. 1354 00:49:15,350 --> 00:49:17,629 So that's our hope to get away from 1355 00:49:18,740 --> 00:49:19,849 rigorous proofs here. 1356 00:49:19,850 --> 00:49:22,129 So this possibility is not what we 1357 00:49:22,130 --> 00:49:23,399 would really like. 1358 00:49:23,400 --> 00:49:25,189 Okay, thank you very much. 1359 00:49:25,190 --> 00:49:27,379 OK, microphone number two, please. 1360 00:49:27,380 --> 00:49:29,569 So I'm not an expert on cryptography, 1361 00:49:29,570 --> 00:49:30,570 but 1362 00:49:31,670 --> 00:49:33,529 my understanding is that in symmetric 1363 00:49:33,530 --> 00:49:35,119 cryptography, you have the same key for 1364 00:49:35,120 --> 00:49:36,379 both encryption and encryption. 1365 00:49:36,380 --> 00:49:37,879 So isn't it? 1366 00:49:37,880 --> 00:49:39,799 Why do you care so much about 1367 00:49:39,800 --> 00:49:41,749 inevitability? Isn't it an important 1368 00:49:41,750 --> 00:49:43,849 attack vector to if the 1369 00:49:43,850 --> 00:49:45,949 attacker is able to basically rerun the 1370 00:49:45,950 --> 00:49:48,319 ciphertext for whatever method you use 1371 00:49:48,320 --> 00:49:51,109 and then to get the plain text again? 1372 00:49:51,110 --> 00:49:52,879 It doesn't matter how you implement it, 1373 00:49:52,880 --> 00:49:55,009 even if you just created, he just 1374 00:49:55,010 --> 00:49:56,239 gets the plain text again by just 1375 00:49:56,240 --> 00:49:57,889 rerunning whatever you have implemented. 1376 00:49:57,890 --> 00:50:00,589 Isn't that an important factor of attack? 1377 00:50:00,590 --> 00:50:01,590 Well. 1378 00:50:06,770 --> 00:50:09,589 So in semantic cryptography, you have 1379 00:50:09,590 --> 00:50:11,779 a cipher, so if you have an algorithm 1380 00:50:11,780 --> 00:50:14,179 and if you are given a key that 1381 00:50:14,180 --> 00:50:16,390 you can easily run it in both directions, 1382 00:50:17,840 --> 00:50:20,149 if you're given a table of so-called 1383 00:50:20,150 --> 00:50:21,979 full code book table, you can again 1384 00:50:21,980 --> 00:50:24,499 inverted and use it in both directions. 1385 00:50:24,500 --> 00:50:26,899 But the idea is to 1386 00:50:26,900 --> 00:50:29,179 give you some sort of an 1387 00:50:29,180 --> 00:50:31,309 algorithm with key and with embedded 1388 00:50:31,310 --> 00:50:33,079 keys so that you cannot invert that 1389 00:50:33,080 --> 00:50:35,869 easily to give you some sort of function 1390 00:50:35,870 --> 00:50:37,939 that you know how to run the tin forward 1391 00:50:37,940 --> 00:50:40,069 direction. But it's obfuscated 1392 00:50:40,070 --> 00:50:42,259 in a way that you cannot run 1393 00:50:42,260 --> 00:50:43,489 into the benkler direction. 1394 00:50:45,690 --> 00:50:47,759 You can imagine it, like supposed to 1395 00:50:47,760 --> 00:50:49,499 have two functions of the same input that 1396 00:50:49,500 --> 00:50:51,329 you just sort of outputs. 1397 00:50:51,330 --> 00:50:52,590 Of course, how would you inverted? 1398 00:50:53,700 --> 00:50:55,979 But but I mean, my point was that 1399 00:50:55,980 --> 00:50:57,839 you couldn't you just rerun it on the 1400 00:50:57,840 --> 00:50:59,729 ciphertext to get the plain text again, 1401 00:50:59,730 --> 00:51:00,539 basically. 1402 00:51:00,540 --> 00:51:03,029 No. So decryption algorithm is 1403 00:51:03,030 --> 00:51:03,479 not. 1404 00:51:03,480 --> 00:51:04,559 Maybe not. 1405 00:51:04,560 --> 00:51:05,639 Obviously, not that easily. 1406 00:51:05,640 --> 00:51:07,709 But I mean, isn't it some some possible 1407 00:51:07,710 --> 00:51:09,479 way of attacking that? 1408 00:51:09,480 --> 00:51:10,589 No, not really. 1409 00:51:10,590 --> 00:51:12,359 Sold the decryption algorithm is not the 1410 00:51:12,360 --> 00:51:14,909 same one, so it's easily obtainable 1411 00:51:14,910 --> 00:51:16,829 from the encryption one, but usually it's 1412 00:51:16,830 --> 00:51:18,389 a different one. 1413 00:51:18,390 --> 00:51:19,390 OK. 1414 00:51:20,100 --> 00:51:22,319 OK, then we can have one question 1415 00:51:22,320 --> 00:51:24,539 for microphone breakdown down number 1416 00:51:24,540 --> 00:51:26,339 three, please. 1417 00:51:26,340 --> 00:51:28,409 So. So if I 1418 00:51:28,410 --> 00:51:29,489 understand it correctly, 1419 00:51:31,500 --> 00:51:32,500 if you have 1420 00:51:34,080 --> 00:51:36,149 the classical problem of DRM 1421 00:51:36,150 --> 00:51:39,059 is that you have the algorithm 1422 00:51:39,060 --> 00:51:41,099 that decrypted because you have it. 1423 00:51:41,100 --> 00:51:43,919 You have to have it to play the movie, 1424 00:51:43,920 --> 00:51:46,169 to play the music 1425 00:51:46,170 --> 00:51:48,449 or whatever. So, yeah, I 1426 00:51:48,450 --> 00:51:50,009 understand it. 1427 00:51:50,010 --> 00:51:52,979 I think the key would be somehow 1428 00:51:52,980 --> 00:51:55,469 somehow good for the for the implementers 1429 00:51:55,470 --> 00:51:57,599 of DRM because it makes 1430 00:51:57,600 --> 00:51:59,969 it slightly harder 1431 00:51:59,970 --> 00:52:01,559 to to implement 1432 00:52:03,210 --> 00:52:04,859 the attack. 1433 00:52:04,860 --> 00:52:07,139 But if you 1434 00:52:08,910 --> 00:52:10,829 basically I can see how it would be 1435 00:52:10,830 --> 00:52:13,949 possible to break 1436 00:52:13,950 --> 00:52:16,349 through to not allow the 1437 00:52:16,350 --> 00:52:18,659 attack that 1438 00:52:18,660 --> 00:52:20,729 uses the code that you have for 1439 00:52:20,730 --> 00:52:21,599 playing, oh, 1440 00:52:21,600 --> 00:52:23,639 it's full formal, it's impossible. 1441 00:52:23,640 --> 00:52:25,709 So and the main implementations that 1442 00:52:25,710 --> 00:52:28,169 can indeed easily extract the code 1443 00:52:28,170 --> 00:52:30,299 and use it as your 1444 00:52:30,300 --> 00:52:31,379 own routine. 1445 00:52:31,380 --> 00:52:33,479 But ah, well, this is some sort of 1446 00:52:33,480 --> 00:52:35,729 solution for the kids when this is not 1447 00:52:35,730 --> 00:52:37,889 easily. So this if you 1448 00:52:37,890 --> 00:52:40,169 have this white box implementation 1449 00:52:40,170 --> 00:52:42,449 that it immediately increases 1450 00:52:42,450 --> 00:52:44,579 their tech costs, it 1451 00:52:44,580 --> 00:52:46,919 will require that nursery to use 1452 00:52:46,920 --> 00:52:49,079 just the code that it was given 1453 00:52:49,080 --> 00:52:50,999 that not anything else. 1454 00:52:51,000 --> 00:52:53,969 So it limits their daughter's 1455 00:52:53,970 --> 00:52:56,099 capabilities somehow, and that's at 1456 00:52:56,100 --> 00:52:57,239 least some partial 1457 00:52:58,320 --> 00:52:59,320 achievement. 1458 00:53:00,640 --> 00:53:02,499 OK, microphone number one. 1459 00:53:02,500 --> 00:53:03,939 Yeah, hey. 1460 00:53:03,940 --> 00:53:05,409 So first, I want to thank you for the 1461 00:53:05,410 --> 00:53:07,149 presentation because it helps shedding 1462 00:53:07,150 --> 00:53:09,429 some light on the mysterious topic of 1463 00:53:09,430 --> 00:53:12,279 white box cryptography, and it helped me 1464 00:53:12,280 --> 00:53:13,989 calling out bullshit on the whole idea. 1465 00:53:13,990 --> 00:53:15,159 And I think somebody should make this 1466 00:53:15,160 --> 00:53:17,259 critical comment because the whole 1467 00:53:17,260 --> 00:53:19,749 concept breaks with one of the 1468 00:53:19,750 --> 00:53:21,909 principles of cryptography that an 1469 00:53:21,910 --> 00:53:23,949 algorithm should be verifiable, right? 1470 00:53:23,950 --> 00:53:26,199 So if you obfuscated to hide 1471 00:53:26,200 --> 00:53:28,299 something, you know, if 1472 00:53:28,300 --> 00:53:29,799 it's only hiding the key, it's no use 1473 00:53:29,800 --> 00:53:31,029 because I can. 1474 00:53:31,030 --> 00:53:32,859 I wouldn't go after the implementation at 1475 00:53:32,860 --> 00:53:34,449 all. I would have other ways to attack 1476 00:53:34,450 --> 00:53:36,039 and recover the key. Everybody knows how 1477 00:53:36,040 --> 00:53:36,969 easy that is. 1478 00:53:36,970 --> 00:53:39,309 And if it obfuscates more or even changes 1479 00:53:39,310 --> 00:53:41,889 it, then it breaks with the principle of 1480 00:53:41,890 --> 00:53:42,999 being verifiable. 1481 00:53:43,000 --> 00:53:44,919 Right. So I think the whole thing is 1482 00:53:44,920 --> 00:53:46,599 snake oil and shouldn't be used by 1483 00:53:46,600 --> 00:53:47,600 anybody. 1484 00:53:50,280 --> 00:53:51,280 Thank you for the comments. 1485 00:53:52,860 --> 00:53:54,989 OK, last question for microphone number 1486 00:53:54,990 --> 00:53:56,729 four over there, please 1487 00:53:56,730 --> 00:53:58,380 just have a two part question. 1488 00:53:59,790 --> 00:54:01,919 Can you achieve white box properties 1489 00:54:01,920 --> 00:54:03,389 with homomorphic encryption? 1490 00:54:03,390 --> 00:54:05,189 Theoretically, and the second part is, 1491 00:54:05,190 --> 00:54:06,450 can you do that practically? 1492 00:54:08,220 --> 00:54:10,779 Are he? 1493 00:54:10,780 --> 00:54:11,939 Yes, well, 1494 00:54:13,050 --> 00:54:15,419 I think with most of the public 1495 00:54:15,420 --> 00:54:17,219 key schemes, well. 1496 00:54:19,390 --> 00:54:20,390 You can. 1497 00:54:21,680 --> 00:54:22,760 You can achieve this. 1498 00:54:23,810 --> 00:54:25,940 The problem is, again, performance. 1499 00:54:29,570 --> 00:54:31,099 I would say so, I think the performance 1500 00:54:31,100 --> 00:54:33,139 of the main problem that prevents us from 1501 00:54:33,140 --> 00:54:35,929 using candidates from 1502 00:54:35,930 --> 00:54:37,909 things like homomorphic encryption or the 1503 00:54:37,910 --> 00:54:40,400 latest that they're based on, so. 1504 00:54:42,160 --> 00:54:43,599 Things like that, there have been some 1505 00:54:43,600 --> 00:54:46,059 recent recent improvements, 2012 1506 00:54:46,060 --> 00:54:48,129 2013 in fully 1507 00:54:48,130 --> 00:54:49,150 homomorphic schemes, 1508 00:54:50,290 --> 00:54:53,019 do they bring the 1509 00:54:53,020 --> 00:54:55,089 sort of level down to 1510 00:54:55,090 --> 00:54:57,279 where this may be practical for for white 1511 00:54:57,280 --> 00:54:59,169 box properties? Or have you have you not 1512 00:54:59,170 --> 00:55:00,170 looked into this? 1513 00:55:01,210 --> 00:55:02,210 Well. 1514 00:55:02,590 --> 00:55:05,649 Uh, you know, I didn't really think 1515 00:55:05,650 --> 00:55:07,629 in this direction of for the morphine 1516 00:55:07,630 --> 00:55:09,699 version, if you give this just some time 1517 00:55:09,700 --> 00:55:11,439 off line, they have to think about it, 1518 00:55:11,440 --> 00:55:13,269 probably give you a better but transfer. 1519 00:55:15,550 --> 00:55:17,499 OK. Dimitri, well, thank you very much 1520 00:55:17,500 --> 00:55:19,299 for your talk. 1521 00:55:19,300 --> 00:55:20,300 Thank you, John.