WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 00:00:00.000 --> 00:00:02.856 [MUSIC PLAYING] 00:00:06.670 --> 00:00:09.160 CONNOR DOYLE: Welcome back to Cooking with Connor. 00:00:09.160 --> 00:00:13.390 I'm your host, Connor, and today we're going to be talking about one 00:00:13.390 --> 00:00:16.810 of my favorite recipes, hash browns. 00:00:16.810 --> 00:00:20.200 To start, you'll need, boop, boop, boop-- 00:00:20.200 --> 00:00:21.370 three potatoes. 00:00:21.370 --> 00:00:24.809 And we're going to cut sharply down-- 00:00:24.809 --> 00:00:25.600 what are you doing? 00:00:31.480 --> 00:00:34.120 DAVID J. MALAN: Hello world, this is CS50LIVE. 00:00:34.120 --> 00:00:37.510 Now CS50'S team recently had an opportunity to cross the pond 00:00:37.510 --> 00:00:41.050 and head over to the United Kingdom where we reunited with our friends from 00:00:41.050 --> 00:00:43.090 [INAUDIBLE], an undergraduate organization 00:00:43.090 --> 00:00:46.480 of students interested in technology at University College London, 00:00:46.480 --> 00:00:50.449 or UCL, where we held the second ever CS50 hackathon. 00:00:50.449 --> 00:00:52.240 Thereafter, we hopped on a train and headed 00:00:52.240 --> 00:00:55.239 to Manchester, where we were met with [INAUDIBLE], another student 00:00:55.239 --> 00:00:57.280 group, this time at the University of Manchester, 00:00:57.280 --> 00:01:00.572 with which we hosted our first ever CS50 hackathon. 00:01:00.572 --> 00:01:02.780 Now not only were quite a few students in attendance, 00:01:02.780 --> 00:01:07.300 so were quite a few pizzas, as captured here in this photo of our receipt. 00:01:07.300 --> 00:01:10.990 But also in attendance was CS50's own Dan Armendariz 00:01:10.990 --> 00:01:15.260 whom you might recall is one of the authors behind CS50's own IDE. 00:01:15.260 --> 00:01:18.730 In fact, we happened to catch a little bit of Dan on camera. 00:01:18.730 --> 00:01:20.479 Shall we roll film? 00:01:20.479 --> 00:01:22.475 DAN ARMENDARIZ: Oh god. 00:01:22.475 --> 00:01:25.968 [MUSIC PLAYING] 00:01:39.940 --> 00:01:42.750 DAVID J. MALAN: Now Dan Armendariz used to work for CS50 00:01:42.750 --> 00:01:45.060 but is now actually at Cloud9, the startup 00:01:45.060 --> 00:01:48.630 based in Amsterdam that created Cloud9's IDE itself. 00:01:48.630 --> 00:01:51.120 Cloud9 happens to be owned by Amazon now, 00:01:51.120 --> 00:01:56.730 but it turns out, fun story, CS50 IDE wasn't working earlier this week. 00:01:56.730 --> 00:01:59.700 In fact, we started receiving just a couple of days ago reports 00:01:59.700 --> 00:02:01.530 like this on the course's subreddit. 00:02:01.530 --> 00:02:05.400 Is it just me, or is this CS50.io IDE down? 00:02:05.400 --> 00:02:07.260 And sure enough, over the subsequent hours 00:02:07.260 --> 00:02:10.080 did we start to see a few posts on Facebook and beyond where 00:02:10.080 --> 00:02:13.890 some but not all students were reporting that the IDE wasn't working. 00:02:13.890 --> 00:02:17.250 And yet, curiously, here on campus all was perfectly fine. 00:02:17.250 --> 00:02:20.460 And around the world all seemed to be fine, but not so much 00:02:20.460 --> 00:02:22.560 in certain pockets of the United States. 00:02:22.560 --> 00:02:27.840 Now finally did Cloud9 isolate the issue and realize that the c9.io domain was 00:02:27.840 --> 00:02:32.940 being blocked by Comcast, c9.io being the official domain for Cloud9's IDE, 00:02:32.940 --> 00:02:36.885 and Comcast being a really big internet service provider or ISP 00:02:36.885 --> 00:02:38.520 here in the United States. 00:02:38.520 --> 00:02:40.710 Now as it turns out, and it took a few hours 00:02:40.710 --> 00:02:44.130 to ascertain exactly what was going on, Comcast had essentially 00:02:44.130 --> 00:02:47.370 blacklisted, or banned, some of Cloud9's IP 00:02:47.370 --> 00:02:52.140 addresses, the result of a bad customer having used the Cloud9 service 00:02:52.140 --> 00:02:55.650 to wage a sort of phishing attack against some Comcast customers. 00:02:55.650 --> 00:03:00.210 And so, Comcast simply shut off that IP, but unfortunately, any other workspaces 00:03:00.210 --> 00:03:02.880 that were hosted at that same IP address. 00:03:02.880 --> 00:03:06.900 Fortunately, our friends at Cloud9 did in fact resolve the issue ultimately. 00:03:06.900 --> 00:03:08.970 And everything should be now back online. 00:03:08.970 --> 00:03:12.930 But this was indeed a bit of a puzzler since it was only affecting 00:03:12.930 --> 00:03:15.630 just a subset of CS50's users. 00:03:15.630 --> 00:03:18.960 Now, on CS50LIVE today do we look at something else that's been in the news. 00:03:18.960 --> 00:03:22.050 Namely, this frightening quote here. 00:03:22.050 --> 00:03:25.740 "We have broken SHA-1 in practice." 00:03:25.740 --> 00:03:26.850 But what does that mean? 00:03:26.850 --> 00:03:30.180 Well SHA-1, it turns out, is what's called a hash function, which 00:03:30.180 --> 00:03:33.240 is a special algorithm that takes input and produces output, 00:03:33.240 --> 00:03:34.472 as all algorithms do. 00:03:34.472 --> 00:03:36.180 And what it's generally designed to do is 00:03:36.180 --> 00:03:39.150 take pretty large inputs, or pretty important inputs, 00:03:39.150 --> 00:03:42.420 and reduce them to a number, or a short string that 00:03:42.420 --> 00:03:45.180 represents that original input. 00:03:45.180 --> 00:03:47.250 And SHA-1, like a lot of other algorithms 00:03:47.250 --> 00:03:49.770 too, are used in any number of different contexts. 00:03:49.770 --> 00:03:53.460 For instance, SHA-1 is used in what are called digital certificates, which 00:03:53.460 --> 00:03:57.330 is a digital mechanism whereby you can prove with high probability 00:03:57.330 --> 00:04:00.120 that some document, or some credit card transaction, 00:04:00.120 --> 00:04:04.200 or some bank transaction, or more was indeed performed by, or signed 00:04:04.200 --> 00:04:05.747 by a specific person. 00:04:05.747 --> 00:04:07.830 They're also used in software updates so that when 00:04:07.830 --> 00:04:10.290 you download new software from Apple or Microsoft, 00:04:10.290 --> 00:04:13.170 you can confirm with high probability that that update indeed 00:04:13.170 --> 00:04:17.160 came from one of those players, and not, for instance, from some malicious user 00:04:17.160 --> 00:04:18.120 online. 00:04:18.120 --> 00:04:19.050 Backup systems. 00:04:19.050 --> 00:04:22.890 If you're in the habit, as you should be, of backing up all of your files, 00:04:22.890 --> 00:04:25.770 your software might be using SHA-1 in order 00:04:25.770 --> 00:04:29.070 to ensure that your file is indeed correctly backed up 00:04:29.070 --> 00:04:32.340 and it wasn't corrupted, for instance, when being uploaded or copied. 00:04:32.340 --> 00:04:35.430 And it's also used by GIT, the version control system with which you might 00:04:35.430 --> 00:04:38.130 be familiar on a website like GitHub. 00:04:38.130 --> 00:04:41.460 Now it wasn't all that long ago that a well-known security 00:04:41.460 --> 00:04:43.710 researcher, Bruce Schneier, wrote this. 00:04:43.710 --> 00:04:47.730 "It's time for us all to migrate away from SHA-1." 00:04:47.730 --> 00:04:49.350 Actually, it was a long time ago. 00:04:49.350 --> 00:04:52.620 That was said in 2005, at which time it was 00:04:52.620 --> 00:04:57.330 noted that cryptographers had showed that SHA-1 is not collision free. 00:04:57.330 --> 00:05:02.580 Specifically, that is they developed an algorithm for finding collisions faster 00:05:02.580 --> 00:05:03.840 than brute force. 00:05:03.840 --> 00:05:06.460 Now what does collision free mean, and what are collisions? 00:05:06.460 --> 00:05:08.660 Well, let's take a closer look now at SHA-1 itself. 00:05:08.660 --> 00:05:10.410 It's indeed an algorithm, which you recall 00:05:10.410 --> 00:05:14.460 can be thought of as this black box that takes inputs and produces outputs-- 00:05:14.460 --> 00:05:16.839 takes problems and produces solutions. 00:05:16.839 --> 00:05:20.130 And indeed, we generalize that black box as algorithms, but a type of algorithm 00:05:20.130 --> 00:05:23.280 is a hash function, of which SHA-1 is one. 00:05:23.280 --> 00:05:27.690 Now, a hash function generally takes as input a string or some other value 00:05:27.690 --> 00:05:30.672 and produces as output another string or a number. 00:05:30.672 --> 00:05:32.880 You can think of it more generally as the input being 00:05:32.880 --> 00:05:36.630 x and the output being f of x, a function of x, if you think back 00:05:36.630 --> 00:05:37.860 to some of your math days. 00:05:37.860 --> 00:05:39.910 Now let's take a specific example. 00:05:39.910 --> 00:05:43.530 Suppose that we want to hash foo to some value. 00:05:43.530 --> 00:05:46.900 That is, we want to take a string like foo as input and produce as output 00:05:46.900 --> 00:05:49.860 some number that uniquely, or with high probability, 00:05:49.860 --> 00:05:54.450 uniquely represents foo, perhaps so that we can use fewer bits or fewer bytes 00:05:54.450 --> 00:05:56.110 to represent that same value. 00:05:56.110 --> 00:05:58.980 Now quite simply, if you're familiar with hash tables, which 00:05:58.980 --> 00:06:02.790 use hash functions, we might start simply by looking at f and thinking, 00:06:02.790 --> 00:06:06.010 oh, well this is 0, 1, 2, 3, 4, 5. 00:06:06.010 --> 00:06:09.445 This is the fifth zero-indexed letter of the alphabet A through Z. 00:06:09.445 --> 00:06:10.320 And so you know what? 00:06:10.320 --> 00:06:15.220 We're going to represent the word foo with a hash value, or integer, of 5. 00:06:15.220 --> 00:06:15.720 Great. 00:06:15.720 --> 00:06:16.500 How about bar? 00:06:16.500 --> 00:06:18.660 Let's take a look at b, the first letter there. 00:06:18.660 --> 00:06:23.610 A is 0, B might be 1, and so we would represent bar's hash value as 1. 00:06:23.610 --> 00:06:26.040 And then, what about a value like baz, B-A-Z? 00:06:26.040 --> 00:06:28.490 Let's again take a look at its first character. 00:06:28.490 --> 00:06:30.930 And oh-oh, it produces the same value. 00:06:30.930 --> 00:06:32.340 So this is a collision. 00:06:32.340 --> 00:06:35.580 If you are using a hash function, like this very simple one we're 00:06:35.580 --> 00:06:37.950 using here looking only at the first character, 00:06:37.950 --> 00:06:42.197 you get collisions if two inputs happen to produce the same output. 00:06:42.197 --> 00:06:44.280 All right, well that's clearly my fault for having 00:06:44.280 --> 00:06:46.470 proposed such a silly naive algorithm. 00:06:46.470 --> 00:06:48.810 Let's do something a little better with the same inputs. 00:06:48.810 --> 00:06:52.140 Foo, again, could be viewed not just as a single character, its first, 00:06:52.140 --> 00:06:53.630 but let's look at all three. 00:06:53.630 --> 00:06:56.850 And let's convert all three of those to some integer representation 00:06:56.850 --> 00:06:59.700 where a again is 0 and z would be 25. 00:06:59.700 --> 00:07:02.910 And therefore, foo is 5, 14, 14. 00:07:02.910 --> 00:07:03.730 And you know what? 00:07:03.730 --> 00:07:06.360 Why don't we mathematically just add these together so 00:07:06.360 --> 00:07:08.940 that we're taking into account more information than just 00:07:08.940 --> 00:07:09.930 the first characters? 00:07:09.930 --> 00:07:13.350 So 5 plus 14 plus 14 is going to give me 33. 00:07:13.350 --> 00:07:17.310 So in this algorithm, 33 shall be my hash value. 00:07:17.310 --> 00:07:21.600 Bar, meanwhile, is going to become, of course, B-A-R, or 1, 0, and 17. 00:07:21.600 --> 00:07:25.050 Add those together and we get 18, another distinct value. 00:07:25.050 --> 00:07:27.720 And baz, and remember this was the problem before, 00:07:27.720 --> 00:07:31.800 is going to be B-A- and Z, or 1, and 0, and 25, 00:07:31.800 --> 00:07:34.620 which of course is 26 when added together. 00:07:34.620 --> 00:07:36.450 So all seems to be well. 00:07:36.450 --> 00:07:40.080 Now a hash function like SHA-1 is actually much more sophisticated 00:07:40.080 --> 00:07:43.980 than looking at a single character, or adding even the number of characters 00:07:43.980 --> 00:07:44.610 together. 00:07:44.610 --> 00:07:48.520 It actually produces much larger hash values like this one here. 00:07:48.520 --> 00:07:52.140 In fact, if you were to hash, so to speak, the string CS50, 00:07:52.140 --> 00:07:54.510 you'd actually see this as output. 00:07:54.510 --> 00:07:57.924 But there's a problem with this general principle of hashing. 00:07:57.924 --> 00:07:59.340 In fact, notice what happens here. 00:07:59.340 --> 00:08:02.580 Foo, again, has a hash value of 33. 00:08:02.580 --> 00:08:06.731 But so does another word like oof, because it's the same letters 00:08:06.731 --> 00:08:07.980 if we're adding them together. 00:08:07.980 --> 00:08:11.229 So simplistically, we're still going to get 33, so that's a collision. 00:08:11.229 --> 00:08:13.020 And what that means is we can't necessarily 00:08:13.020 --> 00:08:15.450 figure out from the output what the input was 00:08:15.450 --> 00:08:18.550 because there might be multiple inputs that produce that value. 00:08:18.550 --> 00:08:21.590 Moreover, if we're just doing addition with this algorithm, 00:08:21.590 --> 00:08:24.390 our hash values are just going to grow, and grow, and grow. 00:08:24.390 --> 00:08:28.260 And surely we can't count to infinity if our computers on earth 00:08:28.260 --> 00:08:30.010 only have a finite amount of memory. 00:08:30.010 --> 00:08:32.250 So if we're hashing qux, we might get 59, 00:08:32.250 --> 00:08:35.190 or double quux, 79, or triple quuux, or even more 00:08:35.190 --> 00:08:38.610 than that we might just keep counting higher, and higher, and higher. 00:08:38.610 --> 00:08:42.350 And we probably want to cap the number of possible hash values 00:08:42.350 --> 00:08:45.305 so we can actually store stuff in real computers in their memory. 00:08:45.305 --> 00:08:47.430 So of course, in programming we might use something 00:08:47.430 --> 00:08:50.110 like this, the modulo, or remainder operator, 00:08:50.110 --> 00:08:52.231 which you recall allows us to wrap values around. 00:08:52.231 --> 00:08:54.480 And indeed, if you're familiar with hash tables, which 00:08:54.480 --> 00:08:56.580 you might think of pictorially as this, this 00:08:56.580 --> 00:09:00.270 is one of the ways we actually ensure that we don't run out 00:09:00.270 --> 00:09:02.520 of index beyond the boundaries of an array 00:09:02.520 --> 00:09:05.010 by making sure we wrap back around. 00:09:05.010 --> 00:09:06.810 So what is the problem then at hand? 00:09:06.810 --> 00:09:08.430 And why is this so worrisome? 00:09:08.430 --> 00:09:12.480 Well, hash functions, SHA-1 included, are supposed to be one way. 00:09:12.480 --> 00:09:15.487 Given an input, you should be able to get an output. 00:09:15.487 --> 00:09:17.820 And you should not be able to go in the other direction. 00:09:17.820 --> 00:09:19.945 You shouldn't be able to reverse engineer things so 00:09:19.945 --> 00:09:22.830 that given the hash value you can figure out what that value was. 00:09:22.830 --> 00:09:24.690 For instance, if you saw this on the screen, 00:09:24.690 --> 00:09:27.960 you should not be able to figure out that this once upon a time 00:09:27.960 --> 00:09:30.000 was CS50 as input. 00:09:30.000 --> 00:09:33.030 Now SHA-1 is still OK in that regard, but it's not OK 00:09:33.030 --> 00:09:34.860 when it comes to these collisions. 00:09:34.860 --> 00:09:37.560 Because security researchers have originally 00:09:37.560 --> 00:09:42.026 claimed that two objects colliding accidentally is exceedingly unlikely. 00:09:42.026 --> 00:09:44.400 That is a mathematical tenet of this and many algorithms. 00:09:44.400 --> 00:09:47.010 And in fact, and don't get scared, this would 00:09:47.010 --> 00:09:48.780 be the formula with which you can compute 00:09:48.780 --> 00:09:52.230 the probability of a collision using not our simple arithmetic, 00:09:52.230 --> 00:09:54.040 but SHA-1 itself. 00:09:54.040 --> 00:09:57.690 This yields really, really, really, really low probabilities 00:09:57.690 --> 00:09:59.970 that should be quite reassuring enough. 00:09:59.970 --> 00:10:03.030 In fact, the probability of a collision with the SHA-1 algorithm 00:10:03.030 --> 00:10:08.010 should be 1 divided by 2 raised to the 160th power. 00:10:08.010 --> 00:10:11.070 If we do that math, that's 1 divided by this big number 00:10:11.070 --> 00:10:14.560 here, which is one quindecillion, a number so big 00:10:14.560 --> 00:10:18.750 I had to Google how to pronounce it in anticipation of saying it just now. 00:10:18.750 --> 00:10:23.640 If we actually do that math, the probability is so, so close to 0 you 00:10:23.640 --> 00:10:28.980 can see that 0.0000 all the way down to those digits there is the probability 00:10:28.980 --> 00:10:29.784 of a collision. 00:10:29.784 --> 00:10:31.200 Now, this seems all very abstract. 00:10:31.200 --> 00:10:33.880 How can we wrap our minds around this a little more effectively? 00:10:33.880 --> 00:10:35.370 Well, consider the planet Earth. 00:10:35.370 --> 00:10:39.480 There's a whole lot of sand on Earth, and indeed according to NPR 00:10:39.480 --> 00:10:45.930 there should be seven quintillion grains of sand, give or take, on planet Earth. 00:10:45.930 --> 00:10:48.270 Now that's a lot of grains of sand. 00:10:48.270 --> 00:10:51.960 So the probability of a collision in the SHA-1 algorithm, 00:10:51.960 --> 00:10:58.210 theoretically, would be like looking on Earth for a specific grain of sand out 00:10:58.210 --> 00:11:00.850 of all of the grains of sand on Earth. 00:11:00.850 --> 00:11:02.597 And actually, I'm oversimplifying. 00:11:02.597 --> 00:11:04.680 You wouldn't have to just check this Earth looking 00:11:04.680 --> 00:11:06.240 for a specific grain of sand. 00:11:06.240 --> 00:11:10.890 You would have to search 194 octillion planet 00:11:10.890 --> 00:11:15.030 Earths identical to this one, each of them with their own deserts of sand, 00:11:15.030 --> 00:11:17.670 in order to find that one possible collision. 00:11:17.670 --> 00:11:21.510 Suffice it to say that should be super, super unlikely. 00:11:21.510 --> 00:11:24.180 And yet, computers are a lot faster than us humans. 00:11:24.180 --> 00:11:29.610 In fact, in 2015 was The SHAppening, not to be confused with the hit series B 00:11:29.610 --> 00:11:31.830 Happening starring Mark Wahlberg, at which point 00:11:31.830 --> 00:11:34.800 security researchers announced, we just successfully broke 00:11:34.800 --> 00:11:37.070 the full inner layer of SHA-1. 00:11:37.070 --> 00:11:40.210 So a portion of the algorithm used for hashing 00:11:40.210 --> 00:11:45.310 was cracked using, frankly, quite a few GPUs, or Graphical Processing Units. 00:11:45.310 --> 00:11:52.030 64 GPU cluster was used to essentially crack the hash function in order 00:11:52.030 --> 00:11:54.640 to figure out a possible form of collision. 00:11:54.640 --> 00:11:57.640 And choosing hardware that looks a little something like this-- in fact, 00:11:57.640 --> 00:12:00.098 you might have these in your PC if you're quite the gamer-- 00:12:00.098 --> 00:12:03.230 GPUs are highly specialized for lots of parallel processing. 00:12:03.230 --> 00:12:05.980 So this is increasingly what CS researchers are using. 00:12:05.980 --> 00:12:09.640 They estimated ultimately, this team, that the SHA-1 collision cost today 00:12:09.640 --> 00:12:15.040 in 2015 should be between 75,000 US dollars and a $120,000 00:12:15.040 --> 00:12:18.962 if you rent Amazon EC2 cloud computing over a few months. 00:12:18.962 --> 00:12:20.170 And this is the key takeaway. 00:12:20.170 --> 00:12:22.090 And this is why it's so worrisome. 00:12:22.090 --> 00:12:27.310 That financial amount is within the resources of a criminal syndicate. 00:12:27.310 --> 00:12:30.760 In other words, by investing that much money in a hack or an exploit, 00:12:30.760 --> 00:12:34.346 could bad guys theoretically compromise the systems out 00:12:34.346 --> 00:12:36.970 there in the world-- credit cards, passwords, and the like that 00:12:36.970 --> 00:12:39.400 rely on SHA-1 at least in part? 00:12:39.400 --> 00:12:42.220 For more on this particular attack, take a look at this URL here. 00:12:42.220 --> 00:12:44.380 But in conclusion today, unfortunately, it 00:12:44.380 --> 00:12:49.570 was just days earlier that SHAttered now followed The SHAppening, wherein 00:12:49.570 --> 00:12:52.090 researchers from Google in the Netherlands 00:12:52.090 --> 00:12:55.100 announced that we have broken SHA-1 in practice. 00:12:55.100 --> 00:12:57.760 So not just a portion of the algorithm but the algorithm 00:12:57.760 --> 00:13:00.820 itself, by finding a collision and demonstrating a mechanism 00:13:00.820 --> 00:13:02.710 for generating such collisions. 00:13:02.710 --> 00:13:07.180 This research result is so significant that it even has its own logo. 00:13:07.180 --> 00:13:10.405 And ultimately, what the researchers put forth was this. 00:13:10.405 --> 00:13:16.870 This attack required over nine quintillion SHA-1 computations. 00:13:16.870 --> 00:13:18.730 This took the equivalent processing power 00:13:18.730 --> 00:13:22.840 as 6,500 years of single CPU computations, 00:13:22.840 --> 00:13:26.540 and a 110 years of single GPU computations. 00:13:26.540 --> 00:13:29.020 Now of course, they didn't use single CPUs or single GPUs. 00:13:29.020 --> 00:13:33.010 They too had a rack of servers and more using the so-called cloud in order 00:13:33.010 --> 00:13:34.930 to perform these calculations. 00:13:34.930 --> 00:13:37.870 Which is to say that with enough money, and with enough computers, 00:13:37.870 --> 00:13:41.620 and CPUs use and GPUs, is this attack now possible? 00:13:41.620 --> 00:13:43.960 Now thankfully, browser manufacturers have at least 00:13:43.960 --> 00:13:45.670 been aware of this for some time. 00:13:45.670 --> 00:13:48.970 And Google, for instance, has been defending against this in recent months 00:13:48.970 --> 00:13:52.960 already by displaying a screen like this if a website you are visiting 00:13:52.960 --> 00:13:57.460 is using encryption that uses this older version of SHA, SHA-1. 00:13:57.460 --> 00:13:59.920 In fact, if we zoom in here, you'll see that Google 00:13:59.920 --> 00:14:03.820 is complaining, a bit arcanely, of a weak signature algorithm. 00:14:03.820 --> 00:14:05.560 Now Firefox has been planning to do this, 00:14:05.560 --> 00:14:07.476 and just days after this announcement did they 00:14:07.476 --> 00:14:09.790 further their plans to do this quickly. 00:14:09.790 --> 00:14:14.050 And Mozilla, the company behind Firefox, announced that SHA-1 on the public web 00:14:14.050 --> 00:14:14.960 is now over. 00:14:14.960 --> 00:14:17.710 And there are indeed solutions, and there have been for some time. 00:14:17.710 --> 00:14:22.540 So the real result here is humans really expediting their transition away 00:14:22.540 --> 00:14:23.170 from SHA-1. 00:14:23.170 --> 00:14:26.020 There's algorithms like SHA-256, SHA-3 and others, 00:14:26.020 --> 00:14:30.190 which not only are different algorithms, but also use many, many more bits 00:14:30.190 --> 00:14:31.880 to actually produce those hash values. 00:14:31.880 --> 00:14:34.420 So collisions are even less likely. 00:14:34.420 --> 00:14:37.690 Indeed, if I may say so myself, CS50's own website 00:14:37.690 --> 00:14:40.510 here is secure, according to Google Chrome, because we have indeed 00:14:40.510 --> 00:14:43.420 been using SHA-256 for some time. 00:14:43.420 --> 00:14:45.740 Now for more on this, head to this URL here. 00:14:45.740 --> 00:14:49.030 And indeed yes, this research result is so significant it even 00:14:49.030 --> 00:14:51.100 has its own website. 00:14:51.100 --> 00:14:51.790 Now that's it. 00:14:51.790 --> 00:14:56.380 For CS50LIVE, thanks so much to the whole team Ramon, Dan, Skully, Ian, 00:14:56.380 --> 00:15:02.590 Marinda, Arturo Christian, Dough, and of course, Chef Connor. 00:15:02.590 --> 00:15:04.530 This was CS50. 00:15:04.530 --> 00:15:07.880 [MUSIC PLAYING]