WEBVTT 1 00:00:00.160 --> 00:00:02.799 So I was actually just looking at my phone this morning, right, 2 00:00:02.879 --> 00:00:06.519 Oh yeah, yeah, just checking my bank balance, sending a text, 3 00:00:06.839 --> 00:00:08.679 doing a software update, and just kind of hit me. 4 00:00:08.880 --> 00:00:11.400 Let me guess you have no idea how any of 5 00:00:11.400 --> 00:00:12.720 it actually stays secure? 6 00:00:13.039 --> 00:00:16.000 Literally no idea. I mean, I know there's that little 7 00:00:16.000 --> 00:00:18.480 lock icon in the browser, and I hear the word 8 00:00:18.559 --> 00:00:21.879 encryption thrown around a lot, right, But if you actually 9 00:00:21.960 --> 00:00:24.839 ask me to explain how my credit card number doesn't 10 00:00:24.879 --> 00:00:27.199 just you know, float out into the ether for anyone 11 00:00:27.199 --> 00:00:29.399 to grab, I've got absolutely nothing. 12 00:00:29.440 --> 00:00:31.160 Well, you are definitely not alone there. I think for 13 00:00:31.239 --> 00:00:33.520 most of us, cryptography is basically just magic. 14 00:00:33.600 --> 00:00:34.679 It really feels like magic. 15 00:00:34.759 --> 00:00:37.359 It's a black box, you know, the a secret in 16 00:00:37.399 --> 00:00:39.920 one side and random noise comes out the other. But 17 00:00:40.399 --> 00:00:44.359 for the people actually building our digital world, treating it 18 00:00:44.479 --> 00:00:49.359 like magic is well, it's actually incredibly dangerous. 19 00:00:49.039 --> 00:00:52.759 Because magic isn't real. But the software bugs definitely are. 20 00:00:53.240 --> 00:00:56.640 Exactly when cryptography breaks, it doesn't just glitch out for 21 00:00:56.640 --> 00:01:00.600 a second. It fails spectacularly, and that is exactly what 22 00:01:00.640 --> 00:01:03.079 we are digging into today. We're doing a deep dive 23 00:01:03.119 --> 00:01:04.560 into serious cryptography. 24 00:01:04.680 --> 00:01:09.719 Second edition by Jean Feleete almissant. And this isn't just 25 00:01:09.760 --> 00:01:12.719 some dry textbook right, Like, he's not just writing from 26 00:01:12.719 --> 00:01:14.480 an ivory tower somewhere. 27 00:01:14.159 --> 00:01:17.519 Far from it. He's a principal research engineer who deals 28 00:01:17.560 --> 00:01:21.480 with the actual messy reality of digital asset protection. 29 00:01:21.640 --> 00:01:22.719 He's a builder, he is. 30 00:01:23.200 --> 00:01:26.040 If you've ever heard of Blake two or sci fash, 31 00:01:26.079 --> 00:01:29.920 which are algorithms running on millions of servers literally right now, 32 00:01:29.959 --> 00:01:32.159 he designed those. So when he talks about how these 33 00:01:32.159 --> 00:01:34.640 systems break, he really knows where the bodies are buried. 34 00:01:34.920 --> 00:01:36.959 I actually love the metaphor he uses right at the 35 00:01:36.959 --> 00:01:39.879 start of the source material. Yeah, he compares learning this 36 00:01:39.920 --> 00:01:41.120 stuff to mountaineering. 37 00:01:41.239 --> 00:01:43.280 It's such a great image, he says. The book can 38 00:01:43.319 --> 00:01:46.959 give you the ropes, the ice axes, the carabineros, right, 39 00:01:47.159 --> 00:01:50.040 the tools, but you, the reader, you actually have to 40 00:01:50.040 --> 00:01:53.159 make the ascent yourself. You can't just passively watch someone 41 00:01:53.200 --> 00:01:54.319 else climb a mountain. 42 00:01:54.640 --> 00:01:57.599 Well, consider us the surpis for this deep dive. We're 43 00:01:57.599 --> 00:01:59.680 going to point out the handhold so nobody falls off 44 00:01:59.680 --> 00:02:03.959 the cliff, because honestly, looking at the table of contents, 45 00:02:04.599 --> 00:02:06.200 there is some serious math in here. 46 00:02:06.439 --> 00:02:06.799 There is. 47 00:02:07.319 --> 00:02:10.199 But before we get to like the complex curves and 48 00:02:10.240 --> 00:02:12.800 the quantum physics. We really have to start at the 49 00:02:12.800 --> 00:02:17.759 bottom of the mountain. The foundation of everything randomness. 50 00:02:18.080 --> 00:02:20.479 Randomness is the fuel. I mean, if you don't have 51 00:02:20.639 --> 00:02:25.159 high quality randomness, the fanciest encryption algorithm in the entire 52 00:02:25.199 --> 00:02:26.759 world is completely worthless. 53 00:02:26.800 --> 00:02:29.520 It's like having a titanium vault door but leaving the 54 00:02:29.599 --> 00:02:32.520 key right under the doormat exactly And I Stories highlights 55 00:02:32.560 --> 00:02:35.840 something really interesting about this. Computers are literally designed to 56 00:02:35.840 --> 00:02:39.120 be logical and predictable, right, so they actually struggle to 57 00:02:39.120 --> 00:02:41.400 be random. And there was this specific update in the 58 00:02:41.400 --> 00:02:43.840 second edition about Linux that I found fascinating. 59 00:02:44.000 --> 00:02:47.360 Oh right, the classic developer debate between dev random and 60 00:02:47.360 --> 00:02:48.000 dev you random. 61 00:02:48.080 --> 00:02:49.080 Yeah, what was the deal with that? 62 00:02:49.560 --> 00:02:52.680 For a long time the advice was super complicated. One 63 00:02:52.719 --> 00:02:55.599 of them blocked your system until it had gathered enough 64 00:02:55.960 --> 00:02:59.479 quote unquote environmental noise, and the other one didn't block, 65 00:02:59.560 --> 00:03:02.159 but was seen as maybe less secure. 66 00:03:02.439 --> 00:03:04.280 Kind of a headache for engineer, huge headache. 67 00:03:04.800 --> 00:03:07.479 But Almison points out that in modern Linux kernels those 68 00:03:07.479 --> 00:03:10.960 two have largely converged. The engineering has just gotten so 69 00:03:11.120 --> 00:03:12.960 much better at scavenging entropy. 70 00:03:13.280 --> 00:03:15.240 Entropy being that pure chaos. 71 00:03:14.960 --> 00:03:17.960 Right, It stavenges it from your keystrokes, your mouse movements, 72 00:03:18.039 --> 00:03:20.000 even the thermal noise of the hardware itself. 73 00:03:20.080 --> 00:03:24.319 But when that scavenging fails, man, things go south fast. Yeah, 74 00:03:24.400 --> 00:03:26.240 there was this case study in the book that absolutely 75 00:03:26.319 --> 00:03:28.879 blew my mind. The satellite phones. 76 00:03:29.039 --> 00:03:32.439 Oh, the GMR standards, that is a wild story. 77 00:03:32.639 --> 00:03:35.639 Yeah, we are talking about phones used in active war 78 00:03:35.719 --> 00:03:39.280 zones on offshore oil rigs in the middle of the ocean. 79 00:03:39.439 --> 00:03:42.759 You would completely assume this is military grade Fort Knox 80 00:03:42.840 --> 00:03:43.400 level stuff. 81 00:03:43.439 --> 00:03:46.199 You would definitely assume that these are the communication standards 82 00:03:46.280 --> 00:03:49.560 used by massive vendors like Thria and in Marsot. But 83 00:03:49.680 --> 00:03:52.919 researchers finally took a hard look at the encryption, specifically 84 00:03:53.000 --> 00:03:56.319 the GMR one standard, and they found something pretty shocking. 85 00:03:56.840 --> 00:04:00.960 The algorithm wasn't some cutting edge proprietary sheel ih was it. 86 00:04:00.960 --> 00:04:03.319 It was basically just a clone of the old A 87 00:04:03.479 --> 00:04:04.400 fifty two cipher. 88 00:04:04.520 --> 00:04:06.639 And for those of us who don't have our cipher catalogs, 89 00:04:06.680 --> 00:04:08.680 memorize what exactly is A fifty two. 90 00:04:08.759 --> 00:04:11.159 It's the encryption that was used in old two G 91 00:04:11.319 --> 00:04:14.680 mobile phones. And the kicker is it was known to 92 00:04:14.719 --> 00:04:17.639 be fundamentally insecure years before this. 93 00:04:18.079 --> 00:04:21.399 So they literally took a broken lock from an ancient 94 00:04:21.439 --> 00:04:23.759 Nokia and just slapped it onto a satellite phone. 95 00:04:23.800 --> 00:04:28.839 Effectively, Yes, GMR one used four linear feedback shift registers 96 00:04:29.519 --> 00:04:30.399 or LFSRs. 97 00:04:30.439 --> 00:04:33.519 Okay, can we pause on that linear feedback shift register. 98 00:04:33.839 --> 00:04:36.279 It sounds like a piece of vintage office equipment. How 99 00:04:36.319 --> 00:04:37.399 does that actually work? 100 00:04:37.560 --> 00:04:40.279 Imagine a row of bits, just zeros and ones in 101 00:04:40.279 --> 00:04:42.439 a ship register. You take the bit at the very end, 102 00:04:42.560 --> 00:04:44.040 do a little bit of math with it, and feed 103 00:04:44.079 --> 00:04:46.480 it back into the front, okay, and that shifts everything 104 00:04:46.480 --> 00:04:48.879 else down the line. It creates this stream of numbers 105 00:04:48.879 --> 00:04:52.600 that looks random at a glance. But the critical keyword there. 106 00:04:52.600 --> 00:04:54.759 Is linear, meaning it's simple math. 107 00:04:54.800 --> 00:04:58.279 Exactly, it's mathematically simple. If an attacker sees enough of 108 00:04:58.319 --> 00:05:01.600 that output stream, they can and just use basic linear 109 00:05:01.639 --> 00:05:04.079 algebra to reverse the whole process and figure out the 110 00:05:04.079 --> 00:05:04.720 internal state. 111 00:05:04.800 --> 00:05:06.399 So it's totally predictable. 112 00:05:06.040 --> 00:05:08.879 Highly predictable. And the absolute worst part about the satellite 113 00:05:08.879 --> 00:05:13.519 phone situation. This wasn't software. This was baked directly into 114 00:05:13.560 --> 00:05:14.079 the hardware. 115 00:05:14.240 --> 00:05:18.000 Oh wow, that really ties into the illusion of randomness section, 116 00:05:18.519 --> 00:05:20.959 because if it's software like a messaging app on my phone, 117 00:05:21.680 --> 00:05:23.839 the developer can just push an update over Wi Fi 118 00:05:23.879 --> 00:05:24.560 in twenty. 119 00:05:24.319 --> 00:05:28.120 Minutes, right, But if it's hardware physically wired inside a 120 00:05:28.160 --> 00:05:31.879 satellite in orbit or a specialized handset in a war zone, 121 00:05:32.360 --> 00:05:35.399 you can't just send a patch. You have to physically replace. 122 00:05:35.079 --> 00:05:36.800 The equipment, which nobody is going to do. 123 00:05:37.000 --> 00:05:40.920 No. It is the perfect example of why security by obscurity. 124 00:05:41.079 --> 00:05:44.120 Just blindly trusting a company because they assure you its 125 00:05:44.160 --> 00:05:46.120 export grade is a massive trap. 126 00:05:46.240 --> 00:05:48.639 Okay, so LFSRs are kind of the quick and dirty 127 00:05:48.639 --> 00:05:51.040 way to make a stream of numbers, but the source 128 00:05:51.079 --> 00:05:53.480 material does mention a much better way to use them 129 00:05:53.480 --> 00:05:55.759 in the hardware world, right, Yeah. The Grain one to 130 00:05:55.839 --> 00:05:56.800 eight a algorithm. 131 00:05:57.000 --> 00:06:00.920 Yes, this is where the engineering actually gets clever. Grain 132 00:06:01.040 --> 00:06:04.680 one is a stream cipher that tries to safely balance 133 00:06:04.720 --> 00:06:08.639 speed and security. It uses an LFSR for the rhythm 134 00:06:08.639 --> 00:06:12.399 and speed because they're incredibly fast and hardware, but it 135 00:06:12.439 --> 00:06:14.279 pairs it with an NFSR. 136 00:06:14.040 --> 00:06:15.959 A nonlinear feedback shift register. 137 00:06:16.199 --> 00:06:19.839 Exactly. The nonlinear part is what adds the actual chaos. 138 00:06:20.240 --> 00:06:22.759 It mixes the bits back in using logic that isn't 139 00:06:22.800 --> 00:06:25.519 just simple addition. It breaks that predictability. 140 00:06:25.680 --> 00:06:28.000 So you have the linear part driving the engine and 141 00:06:28.040 --> 00:06:29.959 the nonlinear part scrambling the output. 142 00:06:30.040 --> 00:06:31.480 That's a good way to put it. It is a very 143 00:06:31.519 --> 00:06:34.439 delicate balance, though. If you get the mathematical mixed wrong, 144 00:06:34.560 --> 00:06:36.439 you are right back to being vulnerable. 145 00:06:36.800 --> 00:06:38.759 Okay, so we've got a randomness and we've got our 146 00:06:38.800 --> 00:06:42.439 stream ciphers. Now let's talk about organizing all that chaos. 147 00:06:42.560 --> 00:06:43.240 Let's get into. 148 00:06:43.160 --> 00:06:45.959 Hashing the workhourse of cryptography. 149 00:06:45.319 --> 00:06:48.839 And specifically this birthday paradox thing. I have to admit 150 00:06:49.000 --> 00:06:50.879 every single time I hear this concept, if it's to 151 00:06:50.920 --> 00:06:53.079 stop and literally count on my. 152 00:06:53.040 --> 00:06:56.639 Fingers, it is incredibly counterintuitive to how human brains work. 153 00:06:56.839 --> 00:06:58.639 The source says that in a group of just twenty 154 00:06:58.680 --> 00:07:01.800 three people is a fifty percent chance that two of 155 00:07:01.839 --> 00:07:05.759 them share the exact same birthday, and that just feels wrong. 156 00:07:06.399 --> 00:07:08.319 My brain immediately says, well, there are three hundred and 157 00:07:08.319 --> 00:07:10.199 sixty five days in a year, so I should need 158 00:07:10.240 --> 00:07:11.839 way more people in the room to get a match. 159 00:07:12.000 --> 00:07:14.519 It feels wrong because we default to thinking about our 160 00:07:14.560 --> 00:07:17.480 own specific birthday. We walk into a room and think, 161 00:07:17.639 --> 00:07:20.120 what are the odds someone in here matches my birthday? 162 00:07:20.240 --> 00:07:20.439 Right? 163 00:07:21.040 --> 00:07:23.240 But the math isn't looking for a match to you 164 00:07:23.360 --> 00:07:26.000 it's looking for any match between any two people in 165 00:07:26.040 --> 00:07:28.759 the entire group. When you have twenty three people, the 166 00:07:28.879 --> 00:07:31.879 number of possible pairs cross checking each other is actually 167 00:07:31.920 --> 00:07:32.920 surprisingly high. 168 00:07:32.959 --> 00:07:35.560 Okay, that makes sense. Yeah, but why does a cryptographer 169 00:07:35.639 --> 00:07:37.519 care about a party trick with birthdays? 170 00:07:37.560 --> 00:07:41.399 Because of collisions. In hashing, you take a file, it 171 00:07:41.439 --> 00:07:44.079 could be a tiny text document or a massive four 172 00:07:44.160 --> 00:07:47.639 K movie, and the algorithm crunches it down into a short, 173 00:07:47.680 --> 00:07:50.079 fixed length unique fingerprint a ESH. 174 00:07:50.199 --> 00:07:50.360 Right. 175 00:07:50.720 --> 00:07:54.439 A collision is when two completely different files accidentally produce 176 00:07:54.519 --> 00:07:56.439 the exact same fingerprint. 177 00:07:55.959 --> 00:07:57.279 Which I'm guessing is really bad. 178 00:07:57.480 --> 00:08:00.920 It's catastrophic for things like digital signatures. If I can 179 00:08:00.959 --> 00:08:04.920 figure out how to create a malicious, virus laden software 180 00:08:05.000 --> 00:08:09.000 update that has the exact same hash as a legitimate. 181 00:08:08.560 --> 00:08:11.360 Update, then my computer accepts it as safe exactly. 182 00:08:11.560 --> 00:08:14.800 It tricks the system, and the birthday paradox tells us 183 00:08:14.839 --> 00:08:17.439 that finding that collision is so much easier than our 184 00:08:17.480 --> 00:08:22.519 intuition suggests. Mathematically, if your hash fingerprint is dollar bits long, 185 00:08:22.920 --> 00:08:24.879 you might think it takes two to the power of 186 00:08:24.920 --> 00:08:25.839 dollar tries to break it. 187 00:08:25.959 --> 00:08:28.360 This should be a huge number, right, But. 188 00:08:28.360 --> 00:08:31.040 To find a collision any collision. It actually only takes 189 00:08:31.160 --> 00:08:33.240 roughly two to the power of dollar divided by two. 190 00:08:33.480 --> 00:08:36.240 That is a massive shortcut for an attacker, it really is. 191 00:08:36.320 --> 00:08:39.519 It's a difference between blindly searching for a specific needle 192 00:08:39.559 --> 00:08:43.200 in a haystack versus just grabbing any two random pieces 193 00:08:43.200 --> 00:08:45.440 of hay and checking if they happen to look identical. 194 00:08:45.559 --> 00:08:47.840 So how do we actually build a hash that resists 195 00:08:47.879 --> 00:08:50.559 that kind of shortcut. The book spends a ton of 196 00:08:50.600 --> 00:08:53.519 time on this sponge construction, and I just love the visual. 197 00:08:53.559 --> 00:08:56.720 Here is it literally acting like a kitchen sponge. 198 00:08:56.879 --> 00:09:00.320 It really is an apt metaphor. Think about how you 199 00:09:00.440 --> 00:09:02.919 use a sponge in the sink. It operates in two 200 00:09:02.960 --> 00:09:06.720 distinct phases. First, you plunge it underwater and let it 201 00:09:07.639 --> 00:09:11.600 absorbs the liquid. Okay, in the cryptographic algorithm, this is 202 00:09:11.639 --> 00:09:15.080 called the absorbing phase. You take your blocks of message 203 00:09:15.159 --> 00:09:18.879 data and you mathematically mix them into the sponge's internal 204 00:09:18.879 --> 00:09:21.519 state using xor operations, XO. 205 00:09:21.399 --> 00:09:24.360 Being that fundamental logic gait that flips bits. 206 00:09:24.120 --> 00:09:27.639 Around correct so the mathematical sponge soaks up all the data. Then, 207 00:09:27.919 --> 00:09:30.720 once every single piece of your message is absorbed, you 208 00:09:30.799 --> 00:09:33.679 switch to the squeezing phase. You ring the sponge out 209 00:09:33.720 --> 00:09:35.080 to get your final hash output. 210 00:09:35.120 --> 00:09:37.080 And this is the structure that SAHA three. 211 00:09:37.000 --> 00:09:40.120 Uses, Yes, SAHA three, which is Kekak. And the reason 212 00:09:40.120 --> 00:09:43.080 the industry loves it is because it's so incredibly versatile 213 00:09:43.399 --> 00:09:46.039 because of this absorb and squeeze structure. You can use 214 00:09:46.039 --> 00:09:48.440 a sponge for basic harrying, sure, but you can also 215 00:09:48.519 --> 00:09:51.600 keep squeezing it to generate an endless stream of random. 216 00:09:51.360 --> 00:09:53.799 Numbers, or use it as a stream cipher exactly. 217 00:09:53.879 --> 00:09:55.960 It's like a Swiss army knife for cryptography. 218 00:09:56.279 --> 00:09:59.120 Now, speaking of hashing, we definitely have to talk about 219 00:09:59.200 --> 00:10:02.360 sci fash. We mentioned earlier that Amisan code designed it, 220 00:10:03.039 --> 00:10:06.120 but the sources it wasn't even originally designed for encryption, right. 221 00:10:06.279 --> 00:10:09.720 This is such a fascinating piece of modern Internet history. 222 00:10:10.159 --> 00:10:14.279 Sifash wasn't built to keep military secrets. It was designed 223 00:10:14.279 --> 00:10:17.840 to solve a very specific type of denial of service 224 00:10:17.879 --> 00:10:19.279 attack called hash flooding. 225 00:10:19.960 --> 00:10:21.759 How does a hash flooding attack work? 226 00:10:22.000 --> 00:10:25.039 Okay, so think about programming languages like Python or Ruby. 227 00:10:25.519 --> 00:10:28.360 Under the hood, they use something called hash tables to 228 00:10:28.399 --> 00:10:32.799 store data quickly. It's essentially a massive digital filing cabinet. 229 00:10:33.000 --> 00:10:36.720 The program hashes the incoming data to instantly know exactly 230 00:10:36.799 --> 00:10:40.039 which drawer to drop it into. Super efficient, very efficient, 231 00:10:40.120 --> 00:10:43.559 unless a hacker figures out your hashing algorithm and intentionally 232 00:10:43.600 --> 00:10:46.480 sends you a million pieces of junk data that are 233 00:10:46.519 --> 00:10:49.799 all mathematically calculated to hash to the exact same drawer. 234 00:10:49.840 --> 00:10:50.960 Oh a collision storm. 235 00:10:51.080 --> 00:10:54.840 Yes, suddenly your high speed server isn't quickly filing things 236 00:10:54.879 --> 00:10:58.960 away anymore. It's desperately digging through one massive, overflowing drawer 237 00:10:59.000 --> 00:11:01.879 trying to find things. It slows the entire server to 238 00:11:01.919 --> 00:11:03.039 an absolute crawl. 239 00:11:03.360 --> 00:11:05.919 So the server crashes, but not because it was hacked 240 00:11:06.360 --> 00:11:09.200 in the Hollywood sense of stealing passwords, but literally because 241 00:11:09.759 --> 00:11:12.320 it got confused by its own internal filing system. 242 00:11:12.480 --> 00:11:16.720 Precisely, sifash was specifically designed to be an incredibly fast, 243 00:11:16.799 --> 00:11:21.720 secure keyed hash function to prevent exactly this. It mixes 244 00:11:21.759 --> 00:11:24.919 in a secret key so the attacker cannot predict which 245 00:11:25.039 --> 00:11:27.720 drawer the data will go to. It protects the actual 246 00:11:27.720 --> 00:11:29.919 infrastructure itself, not just the secrets. 247 00:11:30.120 --> 00:11:34.399 It's engineering, plain and simple, keeping the pipes from bursting exactly. Okay, 248 00:11:34.480 --> 00:11:37.240 so we've covered the foothills. We did randomness, we did hashing. 249 00:11:37.679 --> 00:11:41.360 Now grab your ice axe, because we are tackling the 250 00:11:41.480 --> 00:11:45.480 big sheer cliff face of the book. Yeah, public key cryptography. 251 00:11:45.919 --> 00:11:47.799 This is the stuff that lets me send my credit 252 00:11:47.799 --> 00:11:50.200 card number to a website without a guy in a 253 00:11:50.240 --> 00:11:51.720 coffee shop van listening in. 254 00:11:51.720 --> 00:11:54.440 Right, the absolute backbone of the modern Internet. 255 00:11:54.519 --> 00:11:56.720 And for a really long time, the undisputed king of 256 00:11:56.720 --> 00:11:57.799 this hill was RSA. 257 00:11:58.279 --> 00:12:02.080 RSA is the grandfather and its beautiful math. Really it 258 00:12:02.120 --> 00:12:04.919 relies entirely on the fact that it is very very 259 00:12:04.960 --> 00:12:08.399 easy for a computer to multiply two massive prime numbers together. 260 00:12:08.559 --> 00:12:12.679 But it is incredibly mind bogglingly hard to take that 261 00:12:12.799 --> 00:12:15.840 final massive number and work backward to figure out what 262 00:12:15.919 --> 00:12:19.879 those two original primes were. Factoring factoring large integers, and 263 00:12:20.000 --> 00:12:22.519 the book gives some great scale on just how hard 264 00:12:22.559 --> 00:12:25.159 this is. There's an algorithm called the general number field 265 00:12:25.240 --> 00:12:29.519 sieve or GNFS. It is currently the absolute fastest way 266 00:12:29.559 --> 00:12:31.519 we know of to factor these large numbers. 267 00:12:31.519 --> 00:12:33.639 But fast is a very relative term here, Isn't it 268 00:12:33.799 --> 00:12:34.480 very relative? 269 00:12:34.799 --> 00:12:37.960 The source material notes that successfully factoring just a seven 270 00:12:38.039 --> 00:12:41.480 hundred and sixty eight bit number using GNFS took the 271 00:12:41.559 --> 00:12:44.639 computational equivalent of two thousand processor years. 272 00:12:44.679 --> 00:12:46.200 Two thousand years yes, and. 273 00:12:46.200 --> 00:12:48.279 A seven hundred and sixty eight bit key is considered 274 00:12:48.320 --> 00:12:51.279 small by today's standards. That is exactly why your bank 275 00:12:51.320 --> 00:12:53.720 and your browser are using twenty forty eight bit keys 276 00:12:53.879 --> 00:12:57.519 or even larger. The raw computational power required to break 277 00:12:57.559 --> 00:13:00.799 that with current classical technology is just astra nomical. It 278 00:13:00.879 --> 00:13:03.480 is safe because the math is just too hard to reverse. 279 00:13:03.559 --> 00:13:05.320 But RSA is getting kind of old, isn't it? Like? 280 00:13:05.360 --> 00:13:08.440 It's clunky? The keys have to be massively huge to 281 00:13:08.440 --> 00:13:10.879 stay secure. The source says, the industry is moving or 282 00:13:10.919 --> 00:13:14.759 really has already moved, to elliptic curve cryptography or ECC. 283 00:13:15.080 --> 00:13:18.360 ECC is definitely the modern standard. It gives you the 284 00:13:18.440 --> 00:13:21.960 exact same level of security as RSA, but with significantly 285 00:13:21.960 --> 00:13:26.799 smaller keys, which makes everything faster. Instead of smashing giant 286 00:13:26.799 --> 00:13:29.759 prime numbers together, we look at the geometric properties of 287 00:13:29.799 --> 00:13:30.799 points on a curve. 288 00:13:31.039 --> 00:13:32.600 Now, this was the part of the book where I 289 00:13:32.679 --> 00:13:35.679 really had to slow down and reread a few times. 290 00:13:36.080 --> 00:13:38.639 Can you try to visualize this for us? The book 291 00:13:38.679 --> 00:13:41.279 describes it as a sort of geometric game. 292 00:13:41.600 --> 00:13:46.080 Let's try picture a standard graph with a smooth, sweeping 293 00:13:46.120 --> 00:13:49.919 line looping around it. That is your elliptic curve. The 294 00:13:49.919 --> 00:13:53.519 mathematical game goes like this. You take two distinct points 295 00:13:53.559 --> 00:13:55.960 on that curve, let's call them point P and point Q. 296 00:13:56.399 --> 00:13:57.879 Okay, P and Q on the curve. 297 00:13:58.000 --> 00:14:00.480 Now draw a perfectly straight line through both of them. 298 00:14:01.200 --> 00:14:03.960 Because of the specific shape of an elliptic curve, that 299 00:14:04.000 --> 00:14:06.759 straight line is guaranteed to intersect the curve at exactly 300 00:14:06.799 --> 00:14:07.440 one other place. 301 00:14:07.519 --> 00:14:08.440 Okay, I'm with you so far. 302 00:14:08.720 --> 00:14:11.799 You find that third intersection point, and then you reflect 303 00:14:11.879 --> 00:14:14.240 it straight across the x axis, like dropping a mirror 304 00:14:14.279 --> 00:14:18.360 image down. That new reflected point is the mathematical result 305 00:14:18.399 --> 00:14:20.960 of quote unquote adding point P and point Q together. 306 00:14:21.320 --> 00:14:23.679 It really feels like playing a weird game of billiards 307 00:14:23.679 --> 00:14:24.279 on a graph. 308 00:14:24.360 --> 00:14:27.440 It totally does. And if you keep playing that game 309 00:14:27.480 --> 00:14:30.879 repeatedly adding a point to itself over and over, you 310 00:14:30.879 --> 00:14:34.799 start bouncing around the curve in this wildly chaotic, seemingly 311 00:14:35.000 --> 00:14:38.399 unpredictable pattern. The security of ECC comes from what we 312 00:14:38.440 --> 00:14:39.519 call the discrete. 313 00:14:39.159 --> 00:14:42.080 Logarithm problem, which is what exactly. 314 00:14:41.720 --> 00:14:43.919 Basically, if I tell you the exact point where I 315 00:14:43.960 --> 00:14:46.240 started my game of billiards, and then I show you 316 00:14:46.279 --> 00:14:49.919 the final point where my ball ended up. You cannot 317 00:14:49.960 --> 00:14:52.159 easily figure out how many times I hit the ball 318 00:14:52.200 --> 00:14:54.799 to get there. You can't calculate the number. 319 00:14:54.559 --> 00:14:56.879 Of hops, and that number of hops is the secret. 320 00:14:57.039 --> 00:14:59.039 That number of hops is your private key. 321 00:14:59.200 --> 00:15:03.240 That is genius, really But and there's always a huge 322 00:15:03.279 --> 00:15:05.799 but when we talk about this stuff, the math can 323 00:15:05.840 --> 00:15:08.879 be absolutely flawless, and the climbers can still fall right 324 00:15:08.919 --> 00:15:10.840 off the mountain if they don't tie their knots correctly. 325 00:15:11.000 --> 00:15:12.639 Implementation is everything. 326 00:15:12.799 --> 00:15:15.759 We have to talk about the PlayStation three hack because 327 00:15:15.799 --> 00:15:16.480 this section. 328 00:15:16.320 --> 00:15:18.320 Was what oh the PS three hack. This is an 329 00:15:18.360 --> 00:15:20.200 absolute tragedy of implementation. 330 00:15:20.320 --> 00:15:22.679 I remember when in the Savity it was massive news everywhere. 331 00:15:22.799 --> 00:15:27.600 So Sony was using ECDSA, the Elliptic Curve Digital Signature algorithm. 332 00:15:27.720 --> 00:15:31.080 The algorithm itself is incredibly strong, it's the industry standard, 333 00:15:31.559 --> 00:15:35.679 but the underlying math requires a fresh, completely random number, 334 00:15:35.759 --> 00:15:38.360 usually referred to as the value K, to generate every 335 00:15:38.360 --> 00:15:42.679 single signature. And the golden rule of ECDSA is you 336 00:15:42.759 --> 00:15:46.480 must never ever use the exact same K value twice. 337 00:15:46.639 --> 00:15:48.399 Let me guess they used the same k. 338 00:15:48.639 --> 00:15:51.360 They did, and it wasn't just twice. They literally hard 339 00:15:51.399 --> 00:15:55.039 coded a single static K value into the system. The 340 00:15:55.080 --> 00:15:59.039 fails offer Flow team, the group of hackers who cracked it. 341 00:15:59.080 --> 00:16:01.720 They just analyzed a few different game signatures and immediately 342 00:16:01.759 --> 00:16:03.840 realized that the k value wasn't changing at all. 343 00:16:03.919 --> 00:16:05.799 And what did that actually allow an attacker to do? 344 00:16:06.000 --> 00:16:09.360 It takes this impossibly hard cryptographic math and turns it 345 00:16:09.399 --> 00:16:12.240 into basic high school algebra. Because they now had two 346 00:16:12.279 --> 00:16:15.960 mathematical equations with the exact same shared variable, they could 347 00:16:15.960 --> 00:16:18.440 literally just solve for X and X in this case 348 00:16:18.559 --> 00:16:20.759 was Sony's ultimate private master key. 349 00:16:21.120 --> 00:16:23.559 That is just wild. So because of one single bad 350 00:16:23.679 --> 00:16:27.360 random number implementation, these hackers could just sign their own code. 351 00:16:27.399 --> 00:16:30.480 They could sign anything they wanted. They could run alternative 352 00:16:30.480 --> 00:16:35.440 operating systems like Linux, pirate games, custom homebrew software. The 353 00:16:35.480 --> 00:16:38.519 PS three console accepted every bit of it as perfectly 354 00:16:38.639 --> 00:16:44.559 valid official Sony kind because the cryptographic signature was mathematically perfect. 355 00:16:44.879 --> 00:16:47.279 It really just drives home the author's point, doesn't It. 356 00:16:47.559 --> 00:16:52.399 A mathematically strong algorithm is totally useless if the engineering 357 00:16:52.440 --> 00:16:56.000 surrounding it is lazier weak, absolutely useless. There was one 358 00:16:56.000 --> 00:16:58.639 other failure mentioned in the book that felt honestly even 359 00:16:58.720 --> 00:17:02.360 more dangerous because it wasn't just a gaming console being cracked. 360 00:17:02.480 --> 00:17:06.039 It was the trust of the web itself. The Digito 361 00:17:06.160 --> 00:17:06.880 Tar disaster. 362 00:17:07.079 --> 00:17:09.359 Yeah, this is the one that still keeps security professionals 363 00:17:09.400 --> 00:17:13.400 up at night. The entire secure web HTTPS relies entirely 364 00:17:13.440 --> 00:17:15.799 on a chain of trust. When you type Google dot 365 00:17:15.839 --> 00:17:18.160 com into your browser, how does your computer actually know 366 00:17:18.200 --> 00:17:19.880 it's talking to Google and not some hacker? 367 00:17:20.119 --> 00:17:23.400 You trust? A Certificate authority a CAA exactly. 368 00:17:23.680 --> 00:17:27.480 They act as digital notaries. They cryptographically vouch for the 369 00:17:27.480 --> 00:17:32.000 website's identity. Digito Tar was a major Dutch CAA, but 370 00:17:32.079 --> 00:17:36.000 in twenty eleven their internal systems were totally compromised. Hackers 371 00:17:36.039 --> 00:17:40.039 got in and managed to silently issue fake, mathematically valid 372 00:17:40.039 --> 00:17:42.680 certificates for domains like Google dot com. 373 00:17:42.759 --> 00:17:45.400 So if I'm just a regular user and my browser 374 00:17:45.519 --> 00:17:47.559 receives this fake certificate. 375 00:17:47.079 --> 00:17:50.359 Your browser sees the green padlock icon it says verified 376 00:17:50.359 --> 00:17:53.480 by Digito Tar. Everything looks one hundred percent secure and normal. 377 00:17:53.759 --> 00:17:57.119 But it's a trap. The hackers actually use these fraudulent 378 00:17:57.160 --> 00:18:00.440 certificates to launch massive man in the middle attack against 379 00:18:00.440 --> 00:18:01.680 Gmail users in Iran. 380 00:18:01.920 --> 00:18:02.359 Oh wow. 381 00:18:02.440 --> 00:18:05.920 They were silently intercepting and reading communications that people completely 382 00:18:05.920 --> 00:18:07.759 believed were securely encrypted. 383 00:18:07.880 --> 00:18:09.720 It just shows that the chain of trust we all 384 00:18:09.759 --> 00:18:13.559 rely on is extremely fragile. If just one link breaks, 385 00:18:13.599 --> 00:18:16.480 if one single notary company gets Lazier gets hacked, the 386 00:18:16.480 --> 00:18:18.440 whole global system wabbles. 387 00:18:18.160 --> 00:18:20.599 And once that trust is lost in cryptography, it is 388 00:18:20.680 --> 00:18:24.680 almost impossible to earn it back. Dignatar went completely bankrupt 389 00:18:24.839 --> 00:18:26.119 very shortly after that incident. 390 00:18:26.359 --> 00:18:29.759 Okay, so we've seen how things break in today's world, 391 00:18:29.880 --> 00:18:32.759 But the book ends by looking at how everything might 392 00:18:32.799 --> 00:18:38.480 break tomorrow. The ultimate system smasher quantum computing. 393 00:18:38.119 --> 00:18:40.839 The quantum threat it is looming now. 394 00:18:40.960 --> 00:18:44.079 Normally, when tech people talk about faster computers, we just 395 00:18:44.119 --> 00:18:47.079 mean they can guess our passwords faster, right, But the 396 00:18:47.160 --> 00:18:50.640 book explains that Shor's algorithm, which is designed to run 397 00:18:50.680 --> 00:18:54.599 on these future quantum computers, is fundamentally different than just 398 00:18:54.640 --> 00:18:55.279 being fast. 399 00:18:55.519 --> 00:18:58.079 It is entirely different. It's not just a speed boost. 400 00:18:58.200 --> 00:19:02.240 Shore's algorithm actually changes the mathematical complexity class the problem. 401 00:19:02.319 --> 00:19:05.160