WEBVTT 1 00:00:00.000 --> 00:00:03.120 All right, let's unlock some secrets. Today. We're diving deep 2 00:00:03.240 --> 00:00:07.960 into cryptography. With Serious Cryptography A Practical Introduction to Modern Encryption. 3 00:00:08.919 --> 00:00:11.679 We really wanted to understand how modern encryption works in 4 00:00:11.679 --> 00:00:14.599 the real world, and this book, with all its focus 5 00:00:14.640 --> 00:00:17.480 on cutting edge tech like TLS one point three and 6 00:00:17.559 --> 00:00:20.920 post quantum cryptography, seems like the perfect place to start. 7 00:00:21.399 --> 00:00:24.000 It even has like the stamp of approval from some 8 00:00:24.079 --> 00:00:25.359 real security experts. 9 00:00:25.440 --> 00:00:28.079 Yeah. Absolutely, you can tell the author was really focused 10 00:00:28.079 --> 00:00:30.120 on practical application just reading through it. 11 00:00:30.440 --> 00:00:32.560 So one thing that really caught my eye was how 12 00:00:32.600 --> 00:00:36.079 the book challenged this idea that cryptography is always the 13 00:00:36.119 --> 00:00:40.079 strongest link in security. That got me thinking, is it 14 00:00:40.119 --> 00:00:41.439 really all it's cracked up to be? 15 00:00:41.799 --> 00:00:44.960 Well, it's interesting, right, Like cryptography can be super strong 16 00:00:45.000 --> 00:00:50.280 in theory, but real world implementations, m that's where things 17 00:00:50.320 --> 00:00:53.399 can go wrong, especially with human error and how complex 18 00:00:53.439 --> 00:00:54.359 these systems can get. 19 00:00:54.439 --> 00:00:56.799 So you're saying, even with strong cryptography, things can still 20 00:00:56.840 --> 00:00:57.560 go wrong. 21 00:00:57.719 --> 00:01:01.479 Exactly Like the book uses this example of certain smart cards. 22 00:01:01.880 --> 00:01:05.040 The underlying cipher itself might be secure, but attackers can 23 00:01:05.079 --> 00:01:09.560 find ways to exploit how the card interacts with other systems. Actually, 24 00:01:09.599 --> 00:01:12.159 research has shown that attackers can pull keys from these 25 00:01:12.159 --> 00:01:16.319 smart cards in like ten minutes using equipment anyone can 26 00:01:16.359 --> 00:01:17.400 buy ten minutes. 27 00:01:17.480 --> 00:01:20.120 Wow, that's a real reminder that it's not just about 28 00:01:20.159 --> 00:01:23.040 strong algorithms but the whole ecosystem. 29 00:01:23.120 --> 00:01:25.760 Right, really, And another thing the book digs into is 30 00:01:26.040 --> 00:01:27.840 randomness in cryptography. 31 00:01:28.400 --> 00:01:32.079 Randomness that sounds pretty straightforward, but I feel like there's 32 00:01:32.079 --> 00:01:32.640 more to it. 33 00:01:32.799 --> 00:01:35.280 Oh, you're right. True randomness the kind you get from 34 00:01:35.359 --> 00:01:39.959 unpredictable physical sources. That's ideal, but it's not always practical. 35 00:01:40.680 --> 00:01:44.519 That's where those pseudorandom number generators come in PRNGs. They 36 00:01:44.640 --> 00:01:47.519 make sequences of numbers that look random, but they're actually 37 00:01:47.560 --> 00:01:48.879 made with algorithms, so. 38 00:01:48.760 --> 00:01:52.120 It's like a really carefully crafted illusion of randomness. Why 39 00:01:52.159 --> 00:01:53.560 does this even matter for encryption? 40 00:01:53.680 --> 00:01:56.959 Though? Quality of that illusion is key. Predictable patterns in 41 00:01:57.000 --> 00:02:00.959 a prng's output. That's a weakness attackers can exploit. The 42 00:02:00.959 --> 00:02:04.239 book talks about the Mersen twister. It was widely used, 43 00:02:04.319 --> 00:02:06.799 but it was found to have vulnerabilities because it's linear. 44 00:02:07.319 --> 00:02:09.960 If an attacker could see enough of its output, they 45 00:02:10.000 --> 00:02:13.240 could maybe predict future outputs and mess with the encryption. 46 00:02:13.639 --> 00:02:16.919 That's wild seemingly small details can have a big impact. 47 00:02:17.240 --> 00:02:19.759 So how do we even measure how strong a cryptographic 48 00:02:19.800 --> 00:02:20.479 algorithm is? 49 00:02:20.639 --> 00:02:24.199 Ah, that's where bit security comes in. It's basically how 50 00:02:24.240 --> 00:02:27.000 difficult it is to break an algorithm like one hundred 51 00:02:27.039 --> 00:02:29.639 and twenty eight bits. Cipher would need an attacker to 52 00:02:29.680 --> 00:02:31.560 do something like two to the one hundred and twenty 53 00:02:31.599 --> 00:02:33.280 eighth power operations to crack it. 54 00:02:33.879 --> 00:02:36.800 So more bits equals more security? Is that the gist. 55 00:02:37.000 --> 00:02:39.479 It's a good starting point. But remember the smart cards 56 00:02:39.479 --> 00:02:41.919 from earlier. A huge key figs wouldn't have helped if 57 00:02:41.919 --> 00:02:43.240 the implementation was flawed. 58 00:02:43.360 --> 00:02:46.919 Hmmm, I see. But how do those theoretical bits of 59 00:02:46.919 --> 00:02:49.919 security translate to real world costs for attackers? 60 00:02:50.240 --> 00:02:54.199 Good question. The book talks about parallelism, where attackers can 61 00:02:54.280 --> 00:02:57.759 use multiple processors to speed up attacks a lot. Imagine 62 00:02:57.800 --> 00:03:01.919 trying to brute force a forty eight big key sounds tough, right, Yeah, 63 00:03:01.960 --> 00:03:05.080 But with enough processing power, an attacker could crack it 64 00:03:05.400 --> 00:03:06.680 in a reasonable timeframe. 65 00:03:06.800 --> 00:03:08.199 It's like a race against time. 66 00:03:08.360 --> 00:03:12.080 Yeah. And beyond just that, factors like memory, precomputation, how 67 00:03:12.080 --> 00:03:15.439 many targets there are? Those all matter? Like think about 68 00:03:15.439 --> 00:03:18.840 PayTV systems. They often use forty eight or sixty four 69 00:03:18.840 --> 00:03:20.039 bit encryption keys. 70 00:03:20.280 --> 00:03:22.439 That's low. How is that secure at all? 71 00:03:22.639 --> 00:03:26.159 Well, those systems refresh their keys every few seconds. To 72 00:03:26.240 --> 00:03:28.479 crack it, an attacker would have to brute force a 73 00:03:28.479 --> 00:03:31.879 brand new key super fast, making it basically impossible. 74 00:03:32.039 --> 00:03:34.759 Wow, context really mattered totally. 75 00:03:35.120 --> 00:03:37.319 And something else the book dives into is the idea 76 00:03:37.479 --> 00:03:40.520 of proofs in cryptography. You might think that means an 77 00:03:40.520 --> 00:03:42.400 algorithm security is totally proven. 78 00:03:42.159 --> 00:03:44.240 So you're saying it's not that simple. A proof is 79 00:03:44.240 --> 00:03:45.360 a proof, right Well. 80 00:03:45.240 --> 00:03:48.800 In cryptography it's different. Proofs often show that an algorithm 81 00:03:48.879 --> 00:03:52.439 is as secure as some well known hard problem, like 82 00:03:52.520 --> 00:03:56.240 factoring big numbers, but that doesn't guarantee it's one hundred 83 00:03:56.280 --> 00:03:59.520 percent secure. You never know if new attack methods or 84 00:03:59.560 --> 00:04:00.800 weakness might come up. 85 00:04:00.960 --> 00:04:05.199 So proofs are good for confidence, but not fool proof exactly. 86 00:04:05.680 --> 00:04:08.159 And then there's key management, which is all about protecting 87 00:04:08.159 --> 00:04:11.000 the heart of encryption, the keys themselves. 88 00:04:11.120 --> 00:04:14.280 Key management that sounds pretty self explanatory. You make a 89 00:04:14.360 --> 00:04:15.879 key and keep it safe, right. 90 00:04:16.160 --> 00:04:18.560 Well, the book talks about how keys are generated lots 91 00:04:18.600 --> 00:04:21.240 of different ways, each with its own trade offs. You 92 00:04:21.279 --> 00:04:24.680 can randomly generate keys using those PRNGs we talked about, 93 00:04:24.879 --> 00:04:28.240 or use something called key derivation functions, which make keys 94 00:04:28.240 --> 00:04:31.000 from other secret data. And then there's making keys on 95 00:04:31.000 --> 00:04:34.480 the fly from passwords, which is easy but risky if 96 00:04:34.480 --> 00:04:35.399 the password is weak. 97 00:04:35.879 --> 00:04:38.199 So many choices. What are some of the things to 98 00:04:38.240 --> 00:04:39.920 think about when making these decisions. 99 00:04:40.319 --> 00:04:43.279 It all comes down to your specific security needs. How 100 00:04:43.360 --> 00:04:46.639 much risk you're willing to take. Like key wrapping where 101 00:04:46.639 --> 00:04:49.480 you encrypt a key with another key as protection, but 102 00:04:49.519 --> 00:04:52.519 then you have to store that wrapped key securely makes sense. 103 00:04:52.759 --> 00:04:54.879 Every choice has its own impact, for sure. 104 00:04:55.360 --> 00:04:58.160 Now let's move on to block ciphers, the billing blocks 105 00:04:58.160 --> 00:05:00.399 of a lot of secure systems. 106 00:05:00.439 --> 00:05:02.040 I've heard the term, but I'm a little fuzzy on 107 00:05:02.079 --> 00:05:02.879 what they actually are. 108 00:05:03.000 --> 00:05:05.920 Basically, they work on blocks of data with a fixed size, 109 00:05:06.279 --> 00:05:09.399 using a key to turn it into ciphertext. Their security 110 00:05:09.439 --> 00:05:11.399 is affected by both the size of the block and 111 00:05:11.439 --> 00:05:12.480 the side of the key. 112 00:05:12.480 --> 00:05:15.120 So bigger blocks, bigger keys, stronger encryption. 113 00:05:15.439 --> 00:05:18.199 That's part of it. Larger blocks are better against certain 114 00:05:18.240 --> 00:05:21.800 attacks like codebook attacks, where someone tries to build a 115 00:05:21.839 --> 00:05:25.439 giant lookup table mapping plaintext blocks to ciphertext. 116 00:05:25.639 --> 00:05:27.720 A lookup table for every possible block. 117 00:05:27.759 --> 00:05:31.279 That sounds tedious, it is, and with bigger block sizes, 118 00:05:31.600 --> 00:05:35.160 the number of possible blocks gets huge, making it pretty 119 00:05:35.199 --> 00:05:37.759 much impossible to make and store such a table. 120 00:05:37.959 --> 00:05:39.319 Like memorizing the whole phone book. 121 00:05:39.439 --> 00:05:42.920 Not practical exactly. A great real world example of a 122 00:05:42.920 --> 00:05:47.600 block cipher is the Advanced Encryption Standard or AES. It's 123 00:05:47.639 --> 00:05:51.560 used everywhere from making websites secure with HTTPS to encrypting 124 00:05:51.560 --> 00:05:52.519 stuff on your hard drive. 125 00:05:52.680 --> 00:05:54.120 Hey yes, yeah, I've seen that one. 126 00:05:54.160 --> 00:05:56.600 What makes it so popular, Well, it's been tested and 127 00:05:56.639 --> 00:05:59.439 analyzed a ton and it's proven to be very secure, 128 00:06:00.040 --> 00:06:03.839 and it's got a good balance of security, performance, and flexibility. 129 00:06:03.959 --> 00:06:06.720 So HBS is like the gold standard. But what about 130 00:06:06.759 --> 00:06:10.480 stream sofers? The book describes them as encrypting data like 131 00:06:10.519 --> 00:06:11.319 a flowing river. 132 00:06:11.519 --> 00:06:14.800 Oh yeah, they're really interesting. Stream ciphers encrypt data bit 133 00:06:14.879 --> 00:06:18.000 by bit using a continuous stream of key stream bits. 134 00:06:18.399 --> 00:06:20.879 They're great when you're processing data in real time, like 135 00:06:20.920 --> 00:06:22.319 streaming video or calls. 136 00:06:22.480 --> 00:06:25.360 So block ciphers are like encrypting a book, and stream 137 00:06:25.399 --> 00:06:27.959 ciphers are like encrypting a live broadcast. 138 00:06:28.120 --> 00:06:31.399 Perfect analogy. The book talks about two main types of 139 00:06:31.439 --> 00:06:36.120 stream ciphers, stateful and counter based stateful ciphers like SALCID 140 00:06:36.199 --> 00:06:39.399 twenty keep a secret state that changes as data is encrypted. 141 00:06:39.839 --> 00:06:42.560 Counter based ciphers make keystream bits based on a key, 142 00:06:42.680 --> 00:06:44.560 a nonce, and a counter that goes up with each 143 00:06:44.639 --> 00:06:45.399 bit nons. 144 00:06:45.439 --> 00:06:46.319 What's that all about? 145 00:06:46.560 --> 00:06:49.720 The nons is crucial. It makes sure the same keystream 146 00:06:49.800 --> 00:06:52.120 isn't used to encrypt different messages, which would be bad. 147 00:06:52.600 --> 00:06:54.519 Think if the same code was used to lock your 148 00:06:54.519 --> 00:06:56.000 house in your car, that's. 149 00:06:55.839 --> 00:06:59.279 A recipe for disaster. So the nonce adds uniqueness. 150 00:06:59.000 --> 00:07:02.000 Exactly, but you know, not all stream ciphers are created equal. 151 00:07:02.879 --> 00:07:05.600 The book has this cautionary tale about RC four. It 152 00:07:05.680 --> 00:07:08.439 was really popular, but now it's considered insecure because of 153 00:07:08.480 --> 00:07:12.399 statistical biases in its output. These biases made it vulnerable, 154 00:07:12.680 --> 00:07:16.240 especially in protocols like WEP the early Wi Fi encryption. 155 00:07:16.839 --> 00:07:19.199 So even with randomness, there's a right way and a 156 00:07:19.279 --> 00:07:20.519 wrong way, definitely. 157 00:07:21.040 --> 00:07:24.639 The book highlights SALSEA twenty, a modern stream cipher designed 158 00:07:24.639 --> 00:07:27.240 to be better than RC four. It's got this robust 159 00:07:27.399 --> 00:07:31.639 core permutation that generates those key stream bits with really 160 00:07:31.680 --> 00:07:33.040 good randomness properties. 161 00:07:33.120 --> 00:07:35.480 So it's like the more secure successor. 162 00:07:35.959 --> 00:07:38.480 You could say that now, how about we shift gears 163 00:07:38.480 --> 00:07:40.040 and talk about hash functions. 164 00:07:40.120 --> 00:07:42.759 Hash functions like digital fingerprints for data. 165 00:07:43.000 --> 00:07:46.680 Right, yes, hash functions take any length of input and 166 00:07:46.759 --> 00:07:49.800 spit out a fixed size output called a hash value. 167 00:07:49.920 --> 00:07:52.680 It acts just like a fingerprint. Practically impossible to find 168 00:07:52.680 --> 00:07:54.759 two different inputs that make the same hash value. 169 00:07:54.839 --> 00:07:57.600 Okay, I get the fingerprint analogy. How do hash functions 170 00:07:57.600 --> 00:07:59.439 help with security though, Let's say. 171 00:07:59.279 --> 00:08:01.800 You're downloading it huge file. How do you know it 172 00:08:01.800 --> 00:08:03.600 hasn't been messed with during the download? 173 00:08:03.759 --> 00:08:06.720 Hmmm, good point. You just trust the source, I guess well. 174 00:08:06.800 --> 00:08:09.639 Hash functions can help the website with the file can 175 00:08:09.720 --> 00:08:12.720 give you a hash value of the original file. After 176 00:08:12.720 --> 00:08:15.079 you download it, you run the file through the same 177 00:08:15.120 --> 00:08:18.600 hash function. If the hash values match, you know the 178 00:08:18.639 --> 00:08:20.319 file is identical to the original. 179 00:08:20.480 --> 00:08:22.160 So it's like a check to make sure nothing has 180 00:08:22.240 --> 00:08:23.519 been changed exactly. 181 00:08:23.959 --> 00:08:26.560 And the book talks about the core properties that make 182 00:08:26.600 --> 00:08:31.519 a hash function secure pre image resistance, second, pre image resistance, 183 00:08:31.800 --> 00:08:33.000 and collision resistance. 184 00:08:33.080 --> 00:08:35.919 Okay, that's some serious cryptographic jarg and break it down 185 00:08:35.919 --> 00:08:36.200 for me. 186 00:08:36.279 --> 00:08:39.399 Sure, pre image resistance means it's really hard to find 187 00:08:39.399 --> 00:08:42.600 an input that gives you a specific hash value. Second, 188 00:08:42.600 --> 00:08:44.840 pre image resistance means that if you have an input 189 00:08:44.840 --> 00:08:48.039 in its hash, it's almost impossible to find another input 190 00:08:48.080 --> 00:08:51.240 with the same hash, and collision resistance means it's super 191 00:08:51.240 --> 00:08:53.759 hard to find any two different inputs that make the 192 00:08:53.759 --> 00:08:54.360 same hash. 193 00:08:54.559 --> 00:08:57.519 So it's all about keeping those digital fingerprints unique and 194 00:08:57.639 --> 00:08:59.000 unforgeable exactly. 195 00:08:59.399 --> 00:09:01.879 One common way to make secure hash functions is the 196 00:09:01.919 --> 00:09:06.039 Merkel dam Gord construction. It uses a secure compression function 197 00:09:06.480 --> 00:09:09.320 and processes the input data block by block. 198 00:09:09.360 --> 00:09:11.799 Like a cryptographic assembly line exactly. 199 00:09:12.279 --> 00:09:14.799 And to make sure messages of different lengths give you 200 00:09:14.840 --> 00:09:17.519 different hash values, the use padding. It's like adding a 201 00:09:17.600 --> 00:09:20.279 unique ID to the end of each message. Befoeen processing. 202 00:09:20.799 --> 00:09:23.600 Wow. So much thought goes into these systems. What about 203 00:09:23.639 --> 00:09:27.320 real world examples of hash functions. I've heard of SAHA before, right. 204 00:09:27.360 --> 00:09:30.720 The SAHA family, or a secure hash algorithm is used 205 00:09:30.720 --> 00:09:33.840 a lot. You've probably heard of SAHA one, which was 206 00:09:33.879 --> 00:09:37.039 really popular but is now considered insecure. There are ways 207 00:09:37.080 --> 00:09:38.919 to find collisions. 208 00:09:38.440 --> 00:09:41.240 So SAHA one is like the RC four of hash functions. 209 00:09:41.320 --> 00:09:44.080 You could say that SAHA two, five, six, and SAHA 210 00:09:44.120 --> 00:09:46.399 five to twelve are better, but even they're getting old. 211 00:09:46.639 --> 00:09:49.559 SAHA three is the latest standard. It's designed to last 212 00:09:49.639 --> 00:09:50.799 and is super secure. 213 00:09:51.159 --> 00:09:53.519 SAHA three the next generation. What's different about it? 214 00:09:53.679 --> 00:09:57.159 SAHA three uses this unique sponge function structure. It works 215 00:09:57.159 --> 00:10:00.399 on a fixed size state and absorbs data instead like 216 00:10:00.440 --> 00:10:03.080 a sponge soaking up water. It's different from that Merkele 217 00:10:03.120 --> 00:10:05.720 damgoard thing and seems to be more resistant to attacks. 218 00:10:05.919 --> 00:10:08.000 So SAJ three is the new kit on the block, 219 00:10:08.120 --> 00:10:10.600 built with lessons learned from the past exactly. 220 00:10:11.120 --> 00:10:14.399 But there are other contenders like BLAKE two, which was 221 00:10:14.440 --> 00:10:17.679 a finalist in the competition that picked SAHA three. It's 222 00:10:17.679 --> 00:10:20.440 known for being fast and simple, which makes it popular. 223 00:10:20.919 --> 00:10:23.840 So SAJ three and Blake two are the top dogs 224 00:10:23.840 --> 00:10:27.200 in the hash function world. But even with them, I 225 00:10:27.240 --> 00:10:30.559 bet things can still go wrong. The book talked about 226 00:10:30.639 --> 00:10:33.360 length extension attacks. What are those all about? 227 00:10:33.480 --> 00:10:36.159 Oh? Those are clever. They exploit a weakness in the 228 00:10:36.200 --> 00:10:39.799 Merkele damboard construction. If an attacker knows the hash of 229 00:10:39.840 --> 00:10:42.279 a message, they can add data to it and get 230 00:10:42.279 --> 00:10:45.000 a new hash without even knowing the original message. 231 00:10:45.000 --> 00:10:47.279 Wait, so they can tamper with data without knowing what 232 00:10:47.320 --> 00:10:47.679 it was. 233 00:10:48.080 --> 00:10:50.840 That's the basic idea. The book gives an example of 234 00:10:50.840 --> 00:10:53.879 cloud storage protocols, where these attacks could have let an 235 00:10:53.879 --> 00:10:56.519 attacker change data in the cloud without anyone noticing. 236 00:10:56.919 --> 00:11:01.720 That's scary. Even with secure algorithms, implementation flaws can cause problems. 237 00:11:01.759 --> 00:11:03.879 You got it, and it shows why it's so important 238 00:11:03.879 --> 00:11:06.360 to really understand these algorithms and use them correctly. 239 00:11:06.919 --> 00:11:09.519 So we've covered hash functions, but the book also talks 240 00:11:09.559 --> 00:11:14.080 about Maggie's message authentication codes are those related to hash functions. 241 00:11:14.360 --> 00:11:17.840 They are max make sure data is both correct and authentic, 242 00:11:18.120 --> 00:11:21.440 adding a security layer on top of just plane hash functions. 243 00:11:21.559 --> 00:11:22.639 Okay, how do they work? 244 00:11:22.759 --> 00:11:25.879 They combine a hash function with a secret key. This 245 00:11:26.000 --> 00:11:28.639 key is used when you create and verify the m ass, 246 00:11:29.039 --> 00:11:31.720 ensuring that only someone with the key can make a 247 00:11:31.799 --> 00:11:33.799 valid m ASS for a given message. 248 00:11:33.879 --> 00:11:37.320 So it's like a hash function with a secret handshake exactly. 249 00:11:37.639 --> 00:11:40.240 The book talks about a bunch of ways to build MSS, 250 00:11:40.600 --> 00:11:44.559 like HMAC which uses hash functions, and CMAC, which is 251 00:11:44.559 --> 00:11:45.679 made from block ciphers. 252 00:11:45.720 --> 00:11:48.000 So taking those building blocks we talked about earlier and 253 00:11:48.080 --> 00:11:50.720 using them to make even more secure system exactly. 254 00:11:50.960 --> 00:11:53.840 And then there's sci fash, a modern MAAA designed for 255 00:11:53.879 --> 00:11:57.919 speed and simplicity. It uses a structure similar to SAHA three, 256 00:11:57.960 --> 00:11:59.840 but it's specially designed for authentication. 257 00:12:00.279 --> 00:12:02.799 We've got hash functions and mashes. Are we missing anything? 258 00:12:02.919 --> 00:12:05.399 Well, what if we could combine the secrecy of encryption 259 00:12:05.879 --> 00:12:08.759 with the integrity and authenticity of a mavat. 260 00:12:08.480 --> 00:12:10.600 Sounds like the ultimate package? Is that possible? 261 00:12:10.679 --> 00:12:12.879 Yep, that's what all authenticated encryption does. 262 00:12:13.000 --> 00:12:16.600 I'm all ears. Tell me about this authenticated encryption magic. 263 00:12:16.600 --> 00:12:20.240 Not magic, but it's pretty cool. Authenticated encryption make sure 264 00:12:20.360 --> 00:12:24.320 data is both secret and trustworthy. One popular method is 265 00:12:24.360 --> 00:12:29.240 aesaas GCM, which combines the AES block cipher with a 266 00:12:29.279 --> 00:12:31.799 strong authentication function called ghash. 267 00:12:32.159 --> 00:12:35.000 So it's like AES with an extra authentication boost. 268 00:12:35.360 --> 00:12:38.360 You got it. AES GCM is used all over the place, 269 00:12:38.519 --> 00:12:42.440 from securing network traffic to protecting data that's just sitting there. 270 00:12:42.919 --> 00:12:46.159 But there are others too, like SIV mode, which fixes 271 00:12:46.159 --> 00:12:50.240 a potential problem in authenticated encryption called nonce reuse. 272 00:12:50.559 --> 00:12:53.639 Nonce reuse. We talked about nonces before, but remind me 273 00:12:53.720 --> 00:12:55.320 why reusing them as a problem. 274 00:12:55.440 --> 00:12:57.879 If you use the same nonce to encrypt two different 275 00:12:57.879 --> 00:13:01.720 messages with the same key, leak information about the plaintext. 276 00:13:02.200 --> 00:13:05.000 SIV mode gets around that by adding the plaintext data 277 00:13:05.080 --> 00:13:07.320 into the nons generation process, so it's like. 278 00:13:07.279 --> 00:13:10.039 A self destructing message, leaving no trace behind. 279 00:13:10.159 --> 00:13:12.960 That's a great way to think about it. And now 280 00:13:13.080 --> 00:13:14.399 for the big reveal. 281 00:13:14.159 --> 00:13:16.159 The big reveal. What are you talking about? 282 00:13:16.320 --> 00:13:18.720 Remember that looming threat we talked about earlier, the one 283 00:13:18.759 --> 00:13:20.600 that could change everything in cryptography? 284 00:13:20.720 --> 00:13:22.559 You mean quantum computers exactly. 285 00:13:22.639 --> 00:13:23.840 That's what we'll pick up next time. 286 00:13:24.000 --> 00:13:28.679 Welcome back. We're continuing our journey through serious cryptography. Last 287 00:13:28.679 --> 00:13:31.440 time we ended with quantum computers and how they could 288 00:13:31.519 --> 00:13:35.440 crack our current encryption. I'm ready to explore how we 289 00:13:35.480 --> 00:13:37.399 can prepare for this quantum era. 290 00:13:37.600 --> 00:13:40.399 That's a great place to start. The book goes deeper 291 00:13:40.440 --> 00:13:44.840 into the real world challenges of implementing cryptography when quantum 292 00:13:44.919 --> 00:13:45.799 computers are a thing. 293 00:13:45.919 --> 00:13:49.000 So it's not just about having those new post quantum algorithms, 294 00:13:49.039 --> 00:13:52.080 it's about making them actually work in real systems, right right. 295 00:13:52.120 --> 00:13:54.320 One of the first challenges is the chance of making 296 00:13:54.360 --> 00:13:58.120 mistakes in the implementation. Even a super secure algorithm can 297 00:13:58.159 --> 00:14:00.480 be broken if it's not implemented correctly. 298 00:14:00.559 --> 00:14:01.879 I can see how that would be a problem. Are 299 00:14:01.879 --> 00:14:03.080 there any examples that show this? 300 00:14:03.279 --> 00:14:06.720 Yeah, The book talks about the bell Core attack on RSA. 301 00:14:06.879 --> 00:14:09.799 It used a weakness that had to do with fault injections. 302 00:14:09.840 --> 00:14:11.240 Fault injections, what's that? 303 00:14:11.440 --> 00:14:14.879 Imagine someone messing with a cryptographic device, like changing the 304 00:14:14.879 --> 00:14:17.679 power supply or using electromagnetic interference. 305 00:14:17.759 --> 00:14:20.159 So they're messing with the actual hardware, making. 306 00:14:19.919 --> 00:14:24.320 It glitch yep, and even tiny glitches can make the 307 00:14:24.360 --> 00:14:28.080 device give wrong results. The bell core attack showed how 308 00:14:28.080 --> 00:14:30.399 those errors could be used to get the secret keys 309 00:14:30.480 --> 00:14:31.320 used in RSA. 310 00:14:31.799 --> 00:14:34.480 Wow, So it's like tricking the system into revealing its 311 00:14:34.519 --> 00:14:36.639 secrets by making it mess up exactly. 312 00:14:37.000 --> 00:14:39.240 The bell core attack was a big deal. It showed 313 00:14:39.279 --> 00:14:41.720 that we have to think about not just how strong 314 00:14:41.759 --> 00:14:44.799 the algorithms are, but also how they're actually implemented in 315 00:14:44.799 --> 00:14:45.360 the real world. 316 00:14:45.480 --> 00:14:47.519 Right, it's all connected. You can have the strongest lock, 317 00:14:47.639 --> 00:14:50.440 but if the door is weak, it doesn't really matter exactly. 318 00:14:50.960 --> 00:14:53.399 And since we're talking about different layers of security, let's 319 00:14:53.399 --> 00:14:56.919 talk about TLS. It's what makes Internet communications secure, and 320 00:14:56.960 --> 00:14:59.679 the book says its security depends on getting the cryptography 321 00:14:59.840 --> 00:15:01.480 in implementation and configuration. 322 00:15:01.519 --> 00:15:05.440 All Right, TLS like HTTPS, that little padlock we see 323 00:15:05.440 --> 00:15:06.799 in our browsers that's it. 324 00:15:07.000 --> 00:15:10.279 The book explains how TLS works using the latest version, 325 00:15:10.360 --> 00:15:13.279 TLS one point three. It's like a handshake between the client, 326 00:15:13.399 --> 00:15:16.159 your browser, and the server the website. 327 00:15:16.399 --> 00:15:19.600 So they exchanged secret greetings before sharing any sensitive info. 328 00:15:19.840 --> 00:15:23.799 Right, They exchanged digital certificates, agree on which encryption algorithms 329 00:15:23.840 --> 00:15:26.159 to use, and create a secure channel. 330 00:15:26.399 --> 00:15:29.080 Okay, but there have been attacks on TLS before, right, 331 00:15:29.159 --> 00:15:29.879 like heart bleed. 332 00:15:30.039 --> 00:15:32.639 Oh yeah, heartbeaed was a big one. The book uses 333 00:15:32.679 --> 00:15:36.039 it as an example of how implementation flaws can break 334 00:15:36.080 --> 00:15:37.559 even the strongest security. 335 00:15:37.759 --> 00:15:39.799 Can you remind me what heart bleed was all about? 336 00:15:39.840 --> 00:15:41.000 I vaguely remember it. 337 00:15:41.080 --> 00:15:44.399 Heart Bleed took advantage of a bug in open SSL, 338 00:15:44.720 --> 00:15:47.399 which is used a lot for cryptography. It was a 339 00:15:47.440 --> 00:15:52.360 buffer overflow vulnerability. Basically, the program was tricked into reading 340 00:15:52.399 --> 00:15:53.600 more data than it should have. 341 00:15:53.960 --> 00:15:56.879 So it's like accidentally spilling secrets because you tried to 342 00:15:56.919 --> 00:15:58.519 fit too much info in a container. 343 00:15:58.639 --> 00:16:01.919 Good analogy That extra data could have sensitive stuff like 344 00:16:02.039 --> 00:16:05.080 encryption keys or passwords, and an attacker could get it. 345 00:16:05.279 --> 00:16:08.679 That's not good. So even with something as important as TLS, 346 00:16:09.320 --> 00:16:11.960 there are still these implementation issues to worry about. 347 00:16:12.120 --> 00:16:15.600 Yep, it's a reminder to be careful, keep your software updated, 348 00:16:15.879 --> 00:16:18.480 and make sure developers are writing secure code right. 349 00:16:18.559 --> 00:16:22.200 Security is everyone's responsibility. What about the future of cryptography? Then, 350 00:16:22.240 --> 00:16:26.159 we've talked about quantum computers, new algorithms, implementation challenges. 351 00:16:26.320 --> 00:16:29.440 What's next, that's the big question. The book says the 352 00:16:29.440 --> 00:16:33.639 future of cryptography depends on how our relationship with technology changes. 353 00:16:33.759 --> 00:16:36.759 So it's more than just algorithms and protocols. It's about 354 00:16:36.759 --> 00:16:38.759 how we use technology exactly. 355 00:16:39.159 --> 00:16:41.960 As we depend more on digital systems, we'll need strong 356 00:16:42.000 --> 00:16:43.159 cryptography even more. 357 00:16:43.320 --> 00:16:46.519 We're already seeing it with self driving cars, smart homes, 358 00:16:46.639 --> 00:16:51.919 personalized medicine. All those rely on secure data, right, and. 359 00:16:51.840 --> 00:16:54.200 As we trust more of our lives to these systems, 360 00:16:54.639 --> 00:16:58.320 the consequences of failures get bigger. Imagine a self driving 361 00:16:58.360 --> 00:17:01.720 car getting hacked or met data being leaked because of 362 00:17:01.720 --> 00:17:02.440 bad encryption. 363 00:17:02.759 --> 00:17:06.039 That's a little scary, but it shows how important cryptography is, for. 364 00:17:06.039 --> 00:17:09.640 Sure, and the book reminds us that cryptography is always changing, 365 00:17:09.759 --> 00:17:11.920 new algorithms, new attacks, new challenges. 366 00:17:12.000 --> 00:17:14.119 So it's like a race between the people making the 367 00:17:14.119 --> 00:17:16.559 defenses and the attackers in a way, yes. 368 00:17:16.880 --> 00:17:18.880 But it's also about working together to make a more 369 00:17:18.920 --> 00:17:20.000 secure digital world. 370 00:17:20.279 --> 00:17:23.039 I like that. So how can we the people using 371 00:17:23.039 --> 00:17:25.880 this technology help? What can we do to keep our 372 00:17:25.960 --> 00:17:26.599 data safe? 373 00:17:26.720 --> 00:17:30.960 The book has some ideas. First, stay informed, keep up 374 00:17:31.000 --> 00:17:34.240 with what's happening in cryptography, what the threats are, and 375 00:17:34.279 --> 00:17:35.519 how to protect your data. 376 00:17:35.640 --> 00:17:38.160 So be aware and take steps to be safe. 377 00:17:38.599 --> 00:17:42.400 Yeah. Another thing is to be preactive support groups that 378 00:17:42.400 --> 00:17:46.279 are pushing cryptography forward, promoting secure coding and fighting for 379 00:17:46.319 --> 00:17:47.160 privacy right. 380 00:17:47.240 --> 00:17:49.599 Security is a team effort. We all have a part 381 00:17:49.599 --> 00:17:50.039 to play. 382 00:17:50.079 --> 00:17:54.119 Definitely. As we finish up this deep dive into serious cryptography, 383 00:17:54.599 --> 00:17:56.880 I hope you have a better understanding of how vital 384 00:17:56.880 --> 00:18:01.119 cryptography is, the challenges we face. It's possible in the future. 385 00:18:01.160 --> 00:18:03.880 I know I do. This book has been amazing. It's 386 00:18:04.039 --> 00:18:06.759 made me realize that cryptography is more than just technical stuff. 387 00:18:06.759 --> 00:18:10.599 It's about freedom, privacy, and being able to trust technology. 388 00:18:10.640 --> 00:18:13.799 Couldn't have said it better. So to everyone listening, stay curious, 389 00:18:14.000 --> 00:18:17.440 stay informed, and remember that even with those quantum threats, 390 00:18:17.680 --> 00:18:20.119 we can have secure communication as long as we all 391 00:18:20.160 --> 00:18:21.000 work to protect it. 392 00:18:21.240 --> 00:18:23.599 That's a great point. Thanks for joining us on this 393 00:18:23.680 --> 00:18:28.400 journey through serious cryptography. Remember, knowledge is power, especially when 394 00:18:28.440 --> 00:18:32.559 it comes to cybersecurity. Until next time, Stay safe, stay secure, 395 00:18:32.680 --> 00:18:33.559 and keep learning. 396 00:18:34.839 --> 00:18:37.480 Welcome back to the deep dive. We're wrapping up our 397 00:18:37.480 --> 00:18:40.559 look at serious cryptography, and I'm thinking about the future. 398 00:18:40.720 --> 00:18:44.039 We've covered so much, like the basics of encryption, the 399 00:18:44.160 --> 00:18:46.440 quantum threat, even a bit of algebra. 400 00:18:46.720 --> 00:18:48.559 It has been quite the journey, and the book says, 401 00:18:48.559 --> 00:18:50.960