WEBVTT - End to End Encryption Services 0:00:04.160 --> 0:00:07.160 Get in touch with technology with tech Stuff from how 0:00:07.240 --> 0:00:14.160 stuff Works dot com. Hey there, and welcome to tech Stuff. 0:00:14.200 --> 0:00:17.560 I'm your host, Jonathan Strickland. I'm an executive producer with 0:00:17.600 --> 0:00:20.160 How Stuff Works and the Love all Things Tech Today. 0:00:20.200 --> 0:00:22.880 Probably sounds a little different from my normal episodes because 0:00:22.880 --> 0:00:25.639 I'm actually recording this while I'm in a hotel room 0:00:25.680 --> 0:00:28.639 in Las Vegas. I'm attending yet another tech conference. But 0:00:28.760 --> 0:00:33.000 this episode is more in line with our normally scheduled episodes. 0:00:33.320 --> 0:00:37.440 This one is from a listener request, and the listener 0:00:37.479 --> 0:00:41.279 in this case wished to remain anonymous, and so I 0:00:41.360 --> 0:00:46.640 am going to to completely comply with his or her wishes, 0:00:47.200 --> 0:00:51.400 but wanted to know more about end to end encryption, 0:00:51.680 --> 0:00:53.960 which has been the news a lot, particularly in the UK. 0:00:54.960 --> 0:00:59.360 End to end encryption is a means of sending information securely, 0:00:59.440 --> 0:01:03.880 and it has positive aspects and depending upon who you are, 0:01:03.960 --> 0:01:06.440 negative aspects. We're going to cover all of that, explain 0:01:06.520 --> 0:01:09.280 what end and encryption is and how it works. It's 0:01:09.280 --> 0:01:11.440 been the news for a couple of years for multiple reasons. 0:01:11.520 --> 0:01:14.000 One is that some folks and government agencies have made 0:01:14.000 --> 0:01:16.399 a stink about the technology because they say it gives 0:01:16.480 --> 0:01:20.520 bad actors like criminals and terrorists, the ability to communicate 0:01:20.560 --> 0:01:24.200 secretly with one another. That, in a sense is true, 0:01:24.400 --> 0:01:28.120 but I think it oversimplifies the issue. The tech actually 0:01:28.160 --> 0:01:32.800 allows any two people to communicate secretly with one another. So, 0:01:32.840 --> 0:01:34.440 in other words, it's a tool that can be used 0:01:34.440 --> 0:01:38.360 by people who are bad, but in itself is not 0:01:38.440 --> 0:01:41.080 a bad tool. It's a tool that has tons of 0:01:41.200 --> 0:01:45.679 legitimate uses that have nothing to do with terrorism or crime. 0:01:45.840 --> 0:01:48.560 So as an example, let's say you are running a 0:01:48.640 --> 0:01:52.000 record label and it's your job to sign new acts 0:01:52.040 --> 0:01:54.520 to this record label. In the old days, you would 0:01:54.520 --> 0:01:57.200 do all this in person, but today you can do 0:01:57.440 --> 0:01:59.640 a lot of your business, practically all of your business 0:01:59.640 --> 0:02:02.240 over the internet. So you can negotiate with the act. 0:02:02.320 --> 0:02:04.240 You can come to an agreement on terms. You can 0:02:04.320 --> 0:02:06.480 draw up a contract, and you can send it over 0:02:06.520 --> 0:02:08.680 for them to sign, and then send it back for 0:02:08.720 --> 0:02:11.560 you to countersign. But you want all this information to 0:02:11.600 --> 0:02:15.960 remain confidential. The terms of one agreement with one act 0:02:16.120 --> 0:02:18.800 could be very different from the terms you set with 0:02:18.840 --> 0:02:21.959 another act. To lure a really big act to your label, 0:02:22.440 --> 0:02:26.240 you might have to include more attractive terms for that act, 0:02:26.320 --> 0:02:30.280 like better percentages, But you don't necessarily want to do 0:02:30.360 --> 0:02:33.720 that with every act you're signing. It might not merit it. 0:02:33.919 --> 0:02:37.679 In some cases, the amount of investment a label might 0:02:37.720 --> 0:02:42.000 make in an unproven act could end up being unrewarded downeline. 0:02:42.080 --> 0:02:46.560 So you would rather have the details of contracts remain 0:02:46.919 --> 0:02:50.040 secure and not get leaked to the general public, because 0:02:50.080 --> 0:02:53.440 then your negotiation tools are made plain for everyone to see. 0:02:53.760 --> 0:02:56.639 It opens up the opportunity for various acts to say, hey, 0:02:56.639 --> 0:02:59.800 how come they got such a sweet deal and we didn't. Uh, 0:03:00.040 --> 0:03:01.960 you know, it's all part of business. So you would 0:03:02.040 --> 0:03:04.360 rather have a means to send all this information in 0:03:04.360 --> 0:03:07.280 a way so that even if someone were to intercept 0:03:07.320 --> 0:03:12.680 the messages, no one who didn't you know, didn't have authority, 0:03:12.760 --> 0:03:16.280 would ever understand what it actually says. Now that particular 0:03:16.320 --> 0:03:19.880 idea has been around for as long as we have 0:03:20.040 --> 0:03:23.799 had secrets, How do you communicate a secret to someone 0:03:23.840 --> 0:03:27.280 else without anyone else finding out about it, particularly if 0:03:27.320 --> 0:03:30.480 you can't whisper it quietly to that person. You have 0:03:30.600 --> 0:03:33.120 to come up with a means to hide the meaning 0:03:33.360 --> 0:03:35.760 of your message in some way, and there are a 0:03:35.800 --> 0:03:38.640 lot of different ways to do this. So, for example, 0:03:38.680 --> 0:03:41.520 steganography is a way, and I covered that in a 0:03:41.600 --> 0:03:44.000 previous episode of Tech Stuff with my friend Ariel who 0:03:44.080 --> 0:03:48.120 joined me for that episode. Steganography is the practice of 0:03:48.200 --> 0:03:53.040 hiding a message within some other form of non secret data, 0:03:53.400 --> 0:03:58.400 like uh an image or a music file. You could 0:03:58.680 --> 0:04:03.600 literally high the message inside the image, meaning that unless 0:04:03.640 --> 0:04:06.160 you know what to look for, you're not likely to 0:04:06.280 --> 0:04:08.960 discover the message. That's not the most secure way of 0:04:09.000 --> 0:04:11.280 doing it, obviously, but it is something you can do. 0:04:11.400 --> 0:04:15.440 I remember collecting old Grow the Wanderer comic books by 0:04:15.440 --> 0:04:19.920 Sergio Ariganez, who would hide a secret message in every 0:04:19.920 --> 0:04:24.200 single issue. Typically it would read this is the hidden message. 0:04:24.839 --> 0:04:29.760 So not super duper helpful, but that would be one 0:04:29.800 --> 0:04:32.279 way of doing it. However, you could also hide the 0:04:32.279 --> 0:04:37.520 information within the actual text or or the the the 0:04:37.560 --> 0:04:41.080 file information of the image itself, so instead of like 0:04:41.160 --> 0:04:44.200 hiding it physically inside the image, you're hiding it in 0:04:44.240 --> 0:04:47.200 the code that represents the image. And it's only if 0:04:47.240 --> 0:04:49.000 you know to look at that code that you would 0:04:49.000 --> 0:04:51.479 even see that there was a message there. The whole 0:04:51.520 --> 0:04:54.719 point is you're concealing that secret message inside some other 0:04:54.839 --> 0:04:58.400 non secret information that you can freely distribute, so you 0:04:58.440 --> 0:05:01.920 can send that photo out being reasonably confident that people 0:05:01.960 --> 0:05:05.120 are not going to see that there's a secret message there. 0:05:05.160 --> 0:05:06.839 You only know that it's there if you know to 0:05:06.880 --> 0:05:10.919 look for it. At least that's the theory or the hope. Obviously, 0:05:10.960 --> 0:05:14.240 if someone is super nosy and just curious and they 0:05:14.279 --> 0:05:17.520 start looking at these things more closely, they might uncover 0:05:17.640 --> 0:05:22.440 that message, So it's not always the most secure methodology. Cryptography, 0:05:22.480 --> 0:05:27.159 which means to make communication secret, is a very broad category, 0:05:27.360 --> 0:05:31.279 and encryption falls into that category. Encryption is the specific 0:05:31.360 --> 0:05:35.520 process to make hidden or secret. The two terms are 0:05:35.560 --> 0:05:39.440 often used interchangeably, but technically they are distinct, though I 0:05:39.440 --> 0:05:42.159 guess if enough people use them interchangeably for long enough, 0:05:42.560 --> 0:05:45.320 the meaning itself will change, because that's how language works. 0:05:45.360 --> 0:05:49.400 But that's a bonus episode, I guess. So with encryption, 0:05:49.720 --> 0:05:54.480 you would use some sort of process too encrypt the data. 0:05:54.520 --> 0:05:57.720 You would use a cipher to take a plane message 0:05:58.400 --> 0:06:00.960 the secret that you wish to can municate, and you 0:06:00.960 --> 0:06:03.440 would turn it into something that the average person would 0:06:03.440 --> 0:06:07.640 not be able to understand, but your intended recipient would 0:06:07.640 --> 0:06:10.160 have the knowledge of how to reverse this process to 0:06:10.520 --> 0:06:13.560 decipher the mixed up message, so that he or she 0:06:13.680 --> 0:06:17.440 could read the original secret. So let's take a super 0:06:17.480 --> 0:06:21.720 simple example, one that would never be used in modern 0:06:21.760 --> 0:06:26.520 day encryption. Let's take a basic substitution cipher, in which 0:06:26.560 --> 0:06:30.000 we swap out letters for other letters. In a super 0:06:30.040 --> 0:06:33.080 simple version of this, are two communicators have agreed that, 0:06:33.120 --> 0:06:36.360 for the purposes of their messaging, they will shift all 0:06:36.480 --> 0:06:40.640 letters over by one so that an A will be 0:06:40.680 --> 0:06:44.440 represented by the letter B, A B will be represented 0:06:44.440 --> 0:06:47.120 by the letter C, and so forth until you get 0:06:47.160 --> 0:06:49.320 to Z, which will be represented by the letter A. 0:06:49.720 --> 0:06:52.720 So if I wanted to write out uh j O 0:06:52.960 --> 0:06:55.960 n as my sign off, shortening my name to John, 0:06:56.400 --> 0:06:59.279 I would actually use the letters k P O. My 0:06:59.360 --> 0:07:02.400 recipient would receive this message and say, ah, I must 0:07:02.640 --> 0:07:07.919 decipher it by cleverly stepping back each letter by one position, 0:07:08.040 --> 0:07:10.440 and I get j O N Oh it was Jonathan 0:07:10.440 --> 0:07:13.960 who sent me this message. Now, clearly anyone could crack 0:07:14.040 --> 0:07:17.040 that code. It would not take any sort of master 0:07:17.360 --> 0:07:19.440 code breaker to do it. You don't need a computer 0:07:19.520 --> 0:07:24.440 to do it. Is the simplest of substitution ciphers, and 0:07:25.680 --> 0:07:29.720 obviously that would never stand. However, more much more complicated 0:07:29.720 --> 0:07:32.800 ciphers have been used throughout history, and in fact, one 0:07:32.840 --> 0:07:37.600 of the earliest uses for computers was in decoding encrypted messages. 0:07:37.680 --> 0:07:41.200 During World War Two, computers were dedicated to cracking codes 0:07:41.240 --> 0:07:45.160 made by physical devices like the Enigma machine. But I've 0:07:45.160 --> 0:07:47.480 talked about that in previous episodes, so I'm gonna move 0:07:47.520 --> 0:07:51.640 on rather than dwell on it here now. In cryptology, 0:07:51.800 --> 0:07:57.320 people often use examples to explain specific implementations and strategies. 0:07:57.960 --> 0:08:01.480 This has led to two fictional care is becoming placeholders 0:08:01.520 --> 0:08:03.920 for these examples. So when you want to say person 0:08:04.000 --> 0:08:07.760 A in person B, that gets really cumbersome. So those 0:08:07.840 --> 0:08:11.520 characters are Alice and Bob. If you've ever heard examples 0:08:11.640 --> 0:08:16.160 using Alice and Bob, it comes from this branch of cryptology. 0:08:16.280 --> 0:08:20.640 The characters were actually created by three researchers named Ron Revest, 0:08:20.960 --> 0:08:24.760 Audi Schamir, and Leonard Alderman, who came up with the 0:08:24.960 --> 0:08:28.160 r S A encryption strategy. R s A for the 0:08:28.200 --> 0:08:33.400 first initial uh of each of their last names, so Revest, Schamir, 0:08:33.520 --> 0:08:36.160 and Ottoman you get r S A. And when they 0:08:36.160 --> 0:08:38.080 came up with that, they decided they needed to have 0:08:38.280 --> 0:08:42.520 examples to describe what their whole procedure was, and they 0:08:42.800 --> 0:08:45.400 invented these characters of Alice and Bob. More on R 0:08:45.520 --> 0:08:47.680 s A in just a minute. Alice and Bob have 0:08:47.800 --> 0:08:51.560 become the arc types for cryptological discussions and beyond that. Actually, 0:08:51.559 --> 0:08:53.800 Alie and Bob are used in lots of different examples 0:08:53.800 --> 0:08:57.440 for tech, not just cryptology, but basically, the premise spoils 0:08:57.480 --> 0:09:00.319 down to Bob and Alice both wished to commune dicate 0:09:00.360 --> 0:09:03.600 with one another without other people being able to intercept 0:09:03.640 --> 0:09:07.200 and understand those messages. All right, So Alice and Bob 0:09:07.760 --> 0:09:09.960 they want to send messages to each other using some 0:09:10.000 --> 0:09:12.880 sort of computer device. It could be an actual computer 0:09:13.000 --> 0:09:15.360 like a desktop or a laptop. It could be a smartphone. 0:09:15.400 --> 0:09:18.200 It could be a laptop, tablet, computer, could be any 0:09:18.200 --> 0:09:23.320 of these things. It doesn't really matter that the point 0:09:23.400 --> 0:09:25.559 is that they want to be able to send electronic 0:09:25.640 --> 0:09:29.000 messages in some meaningful way. And when Alice and Bob 0:09:29.040 --> 0:09:33.360 send messages back and forth, their devices aren't doing so directly. Right, 0:09:33.400 --> 0:09:38.200 there's no direct connection between Alice's device and Bob's device 0:09:38.280 --> 0:09:41.000 unless they happen to be very close together and able 0:09:41.000 --> 0:09:43.840 to use some sort of technology like near field communication 0:09:43.960 --> 0:09:47.160 or NFC. Apart from that, where you're so close you 0:09:47.160 --> 0:09:49.760 could just whisper it to each other. Let's say that 0:09:49.840 --> 0:09:52.480 you are across the country from one. Alice is over 0:09:52.520 --> 0:09:55.400 in California, Bob is in New York. The messages they 0:09:55.440 --> 0:09:59.080 send to each other are going to go through routers 0:09:59.080 --> 0:10:02.480 and switches and servers, and eventually they're going to pass 0:10:02.520 --> 0:10:06.160 through some sort of central server system before going through 0:10:06.320 --> 0:10:09.320 even more routers and switches and servers and eventually ending 0:10:09.400 --> 0:10:12.760 up on the other person's phone. So whatever service Alice 0:10:12.760 --> 0:10:18.360 and Bob are using, that centralized server, which is the 0:10:18.360 --> 0:10:21.359 the you know, kind of like the the Great uh 0:10:21.480 --> 0:10:25.560 Post service for that particular app it the message has 0:10:25.600 --> 0:10:28.440 to pass through there because this is a specific app 0:10:28.520 --> 0:10:32.679 being used offered by a specific company. So Alice sends 0:10:32.720 --> 0:10:36.960 Bob a message on their agreed upon messaging app. Alice's 0:10:36.960 --> 0:10:39.440 message is going to head out over the Internet, hit 0:10:39.480 --> 0:10:42.080 the server in charge of handling the messaging service that 0:10:42.160 --> 0:10:44.720 they are both using, and then continue on until it 0:10:44.760 --> 0:10:47.360 hits Bob. Now, if the message is in plain text, 0:10:47.559 --> 0:10:52.120 meaning it's unencrypted, anyone along that pathway could potentially read 0:10:52.160 --> 0:10:55.720 the contents of that message. That includes hackers who could 0:10:55.720 --> 0:10:59.360 have compromised a system somewhere along that pathway, and they're 0:10:59.360 --> 0:11:01.800 trying to pull a man in the middle attack. The message, 0:11:01.800 --> 0:11:04.880 in other words, is not safe. One way to fix 0:11:04.920 --> 0:11:08.440 that is through a simple encryption method in which Alice 0:11:08.480 --> 0:11:12.640 and Bob each have their own private encryption and decryption 0:11:12.720 --> 0:11:16.560 keys with the server. So let's say Alice and Bob 0:11:16.840 --> 0:11:19.760 are using a messaging app. Let's call the app x 0:11:19.880 --> 0:11:23.040 y Z, and x y Z has its server systems. 0:11:23.520 --> 0:11:26.440 When Alice wants to send Bob a message, she uses 0:11:26.520 --> 0:11:29.679 her own personal x y Z encryption key to do 0:11:29.760 --> 0:11:33.520 so and sends it along. No one else other than 0:11:33.720 --> 0:11:37.000 x y Z has that encryption key, so Alice and 0:11:37.160 --> 0:11:40.280 x y Z share it, but nobody else does. Her 0:11:40.360 --> 0:11:44.400 message will get to the server, which sees that Alice 0:11:44.440 --> 0:11:47.520 wants to send a message to Bob. So the service says, 0:11:47.559 --> 0:11:50.480 all right, I'll send this to Bob, except Bob can't 0:11:50.520 --> 0:11:54.400 read it because it's been encrypted with Alice's key, so 0:11:54.720 --> 0:11:57.679 Bob doesn't have Alice's key. So what the server then 0:11:57.720 --> 0:12:01.880 does will decrypt the message because it has Alice's key 0:12:01.920 --> 0:12:05.120 and it also has Bob's key, so it then re 0:12:05.360 --> 0:12:09.320 encrypts the message using Bob's key and then sends that 0:12:09.480 --> 0:12:14.640 along to Bob, so the message has been encrypted twice. Technically, 0:12:14.679 --> 0:12:18.640 it was encrypted, decrypted at the server level, encrypted again 0:12:18.800 --> 0:12:22.760 sent to Bob. Whenever the message is passing over the Internet, 0:12:23.200 --> 0:12:27.600 it is encrypted, which is pretty safe. But you may say, well, 0:12:27.640 --> 0:12:31.240 what about the time that it's spending on the server. 0:12:32.280 --> 0:12:35.680 That's the rub. See, this is not end to end encryption. 0:12:35.720 --> 0:12:38.840 I'll explain that a little bit later. The server is 0:12:38.880 --> 0:12:42.559 able to decrypt all incoming messages, no matter who is 0:12:42.600 --> 0:12:45.679 sending them, and then encrypt them with the respective keys 0:12:45.720 --> 0:12:49.240 belonging to whoever was the intended recipients. But this creates 0:12:49.240 --> 0:12:53.880 a few different problematic scenarios. One is that governments they 0:12:54.080 --> 0:12:58.040 love this strategy because it opens up the possibility that 0:12:58.080 --> 0:13:01.440 the server could release message is on a court order 0:13:01.640 --> 0:13:05.600 or some other means, Like if the government orders the 0:13:05.800 --> 0:13:09.600 service to share those messages and the services compelled to 0:13:09.840 --> 0:13:14.920 agree to it, then potentially the government could get hold 0:13:15.040 --> 0:13:18.640 of unencrypted plane text messages because at the server level 0:13:18.679 --> 0:13:21.720 everything gets unlocked. So the government agency can go to 0:13:21.840 --> 0:13:24.559 X Y Z and say, we suspect Alice and Bob 0:13:24.600 --> 0:13:27.520 are plotting something dangerous. We have some evidence, but we 0:13:27.559 --> 0:13:30.280 want access to the messages they're sending to each other. 0:13:30.920 --> 0:13:33.480 Lives could be at stake, and then they flash a 0:13:33.480 --> 0:13:36.480 Warren or something, and because X y Z is following 0:13:36.480 --> 0:13:39.559 this strategy, it could hand over such information if ordered to, 0:13:39.760 --> 0:13:43.400 revealing all the messages between Alice and Bob. And maybe 0:13:43.440 --> 0:13:46.280 Alice and Bob really were plotting something terrible and it's 0:13:46.320 --> 0:13:49.920 prevented as a result, or maybe they're just happy people 0:13:50.080 --> 0:13:53.199 and their private messages have now been compromised and they 0:13:53.200 --> 0:13:57.880 were completely innocent, and yet there otherwise private communication has 0:13:57.920 --> 0:14:01.880 now been made at least semi public. The strategy also 0:14:01.920 --> 0:14:06.040 creates an incredibly attractive target for hackers, obviously, because if 0:14:06.080 --> 0:14:09.400 you can compromise that central server, you can get at 0:14:09.440 --> 0:14:11.880 all the data that's going across it because it gets 0:14:12.000 --> 0:14:15.160 decrypted there. In fact, this has happened a few times 0:14:15.160 --> 0:14:17.480 in the past where hackers have managed to get access 0:14:17.559 --> 0:14:20.880 to such systems and mind them for data and dump 0:14:20.920 --> 0:14:23.520 all the information onto various places on the web, or 0:14:23.880 --> 0:14:26.720 more likely on the dark web. This is where stuff 0:14:26.760 --> 0:14:30.600 like credit card information or compromising photos can come into play, 0:14:30.640 --> 0:14:34.160 where hackers have managed to get into a server and 0:14:34.160 --> 0:14:37.880 and get all that information. Sure the messages were encrypted 0:14:37.960 --> 0:14:40.120 as they went over the Internet, but that one central 0:14:40.160 --> 0:14:44.280 point everything was unlocked and ready for exploitation and to 0:14:44.600 --> 0:14:48.720 end Encryption aims to defeat this by creating a strategy 0:14:48.800 --> 0:14:51.840 in which only Alice and Bob know how to decrypt 0:14:51.920 --> 0:14:55.080 messages from the other. They have a private means of 0:14:55.120 --> 0:14:59.520 decrypting information. The central server does not have access to 0:14:59.600 --> 0:15:03.360 that it decryption key, and so the messages sent across 0:15:03.440 --> 0:15:07.320 the server are meaningless to the server, is just gobbledygook. 0:15:07.800 --> 0:15:11.680 The server could confirm that messages had passed between Alice 0:15:11.720 --> 0:15:13.760 and Bob, you could say, well, yes, we know that 0:15:13.880 --> 0:15:17.640 the two have communicated with each other, but they the 0:15:17.640 --> 0:15:19.840 company wouldn't be able to speak to what was actually 0:15:19.880 --> 0:15:22.960 in those messages. So if a government agency served up 0:15:22.960 --> 0:15:25.480 a search warrant, all they would get is some garbled, 0:15:25.480 --> 0:15:28.920 seemingly random and meaningless data. They would need that private 0:15:29.040 --> 0:15:31.600 key to make any sense of it. Now, there are 0:15:31.600 --> 0:15:35.560 companies that absolutely love using the strategy because it really 0:15:35.600 --> 0:15:37.880 takes the heat off of them that not only are 0:15:37.880 --> 0:15:41.320 they able to offer their customers a secure way to communicate, 0:15:41.840 --> 0:15:43.840 there's no way for the company to know what sort 0:15:43.880 --> 0:15:47.320 of data is crossing its servers, so it cannot be 0:15:47.440 --> 0:15:51.480 complicit in anything illegal because it doesn't know what's happening. 0:15:51.960 --> 0:15:54.680 It provides a service one in which people may communicate 0:15:54.720 --> 0:15:57.040 with one another in a secure fashion, and that's it. 0:15:57.520 --> 0:16:00.320 But it raises a question how the heck are Alice 0:16:00.360 --> 0:16:03.400 and Bob is supposed to get a private key across 0:16:03.440 --> 0:16:06.320 to each other? Right? If Alice and Bob are apart 0:16:06.400 --> 0:16:10.040 from one another and their communication requires going through a 0:16:10.080 --> 0:16:13.360 centralized service, how do they establish a secret means of 0:16:13.360 --> 0:16:17.400 communication in the first place. If that first message is hey, 0:16:17.600 --> 0:16:21.640 let's use this secret code, but it's decrypted by the 0:16:21.640 --> 0:16:25.360 centralized server, then the centralized server knows the secret code, 0:16:25.400 --> 0:16:27.760 it doesn't help. Well. The answer comes down to what 0:16:27.880 --> 0:16:34.080 was called an asymmetric cryptographic algorithm that uses public key cryptography. 0:16:34.120 --> 0:16:37.000 And in this method, there are two keys that are 0:16:37.160 --> 0:16:40.920 used for each message. One of them is a public key, 0:16:40.960 --> 0:16:44.040 which is unique to each user that can be freely 0:16:44.280 --> 0:16:47.840 distributed across the internet. The other is a private key, 0:16:47.880 --> 0:16:51.640 which is a jealously guarded secret that allows only one 0:16:51.800 --> 0:16:55.240 entity the chance to decrypt information. I'll speak about more 0:16:55.240 --> 0:16:57.880 of this in just a minute, but first let's take 0:16:57.880 --> 0:17:07.840 a quick break to thank our sponsor. Alright, So how 0:17:07.880 --> 0:17:12.160 does public key cryptography work. Each person using the system, 0:17:12.240 --> 0:17:15.240 let's call it ABC. For this case, we're talking about 0:17:15.240 --> 0:17:19.080 different service from x y Z. Every single person using 0:17:19.119 --> 0:17:24.199 ABC gets too encryption keys, or well, one encryption key 0:17:24.240 --> 0:17:28.440 and one decryption key. Technically, one key is the person's 0:17:28.480 --> 0:17:31.639 private key, So Alice has a private key that's unique 0:17:31.680 --> 0:17:34.280 to her, and Bob has a private key it's unique 0:17:34.320 --> 0:17:38.439 to him. They they also each have a public key, 0:17:38.640 --> 0:17:42.360 so Alice has a public key, Bob has another public key. 0:17:42.440 --> 0:17:45.400 These are also unique to Alice and Bob, but those 0:17:45.480 --> 0:17:49.040 keys are published publicly on the service across the Internet. 0:17:49.440 --> 0:17:52.600 Anyone who wants to send an encrypted message to Alice 0:17:52.720 --> 0:17:56.560 or Bob must use their respective public keys. In other words, 0:17:56.560 --> 0:17:58.359 if I want to send Alice a message, I have 0:17:58.400 --> 0:18:02.960 to use Alice's public to encrypt it. To decode a message, 0:18:03.320 --> 0:18:06.240 you have to have the private key. So if you 0:18:06.280 --> 0:18:09.240 know both keys for a specific message, you can transform 0:18:09.240 --> 0:18:12.320 that garbled mess into meaningful communication. And because you keep 0:18:12.359 --> 0:18:15.520 your own private key to yourself, at least ideally, the 0:18:15.560 --> 0:18:18.399 only person who can decode messages meant for you is you. 0:18:19.119 --> 0:18:23.280 So Alice takes Bob's public key and uses it to 0:18:23.400 --> 0:18:26.960 encode her message to Bob. She then sends the encoded 0:18:27.000 --> 0:18:31.080 message to Bob across the messaging service. The encoded message 0:18:31.080 --> 0:18:35.080 passes through ABC's server, which cannot read the message because 0:18:35.119 --> 0:18:39.080 ABC does not have Bob's private key. Only Bob has 0:18:39.119 --> 0:18:42.520 that the message gets to Bob, he uses his private 0:18:42.600 --> 0:18:45.400 key and it decodes the message and then he can 0:18:45.440 --> 0:18:48.040 read it in plain text. But what is actually going 0:18:48.080 --> 0:18:50.439 on here? How is this happening? Well that that depends 0:18:50.480 --> 0:18:54.480 heavily on the specific cryptographic strategy used, But we can 0:18:54.600 --> 0:18:58.399 go with one of the earliest proposed methods of doing this, 0:18:58.560 --> 0:19:01.600 the RSA algorithm, the one I mentioned earlier that was 0:19:01.760 --> 0:19:04.200 proposed by the guys who used Alice and Bob as 0:19:04.200 --> 0:19:08.320 examples in the first place. This one relies on prime numbers, 0:19:08.760 --> 0:19:12.200 and just a quick refresher, a prime number is only 0:19:12.280 --> 0:19:15.320 equal to one times the prime number itself. There are 0:19:15.320 --> 0:19:18.480 no other multiple multiple factors. There are no other numbers 0:19:18.520 --> 0:19:21.119 you can multiply together to get the prime number. So 0:19:21.160 --> 0:19:23.119 if you can get to the value of a number 0:19:23.240 --> 0:19:26.439 by by multiplying any other two numbers, it's what we 0:19:26.520 --> 0:19:30.080 call a composite number. And is not a prime number. 0:19:30.359 --> 0:19:34.840 So the numbers one, two, and three are all prime numbers. 0:19:34.880 --> 0:19:37.399 They are only divisible by themselves and by one that 0:19:37.520 --> 0:19:41.560 there are no other factors, right That our whole numbers anyway, 0:19:41.840 --> 0:19:44.119 because the only multiplication you can do to arrive at 0:19:44.160 --> 0:19:46.720 them is one times one is one, one times two 0:19:46.760 --> 0:19:49.879 is two, and one times three is three, respectively. Four 0:19:50.080 --> 0:19:53.680 is the smallest composite number because you can multiply two 0:19:53.720 --> 0:19:56.600 times two to get four. So it's one times four 0:19:56.680 --> 0:19:58.360 is four and two times two is four. That means 0:19:58.400 --> 0:20:00.680 it is not a prime number. It's a posit number. 0:20:00.840 --> 0:20:03.400 So the number is only divisible by one or itself, 0:20:03.600 --> 0:20:06.359 then it's a prime number. The r s a algorithm 0:20:06.400 --> 0:20:12.520 takes two really really really big prime numbers, like hundreds 0:20:12.520 --> 0:20:14.679 of digits long. You might find systems that use a 0:20:14.680 --> 0:20:17.760 five twelve bit prime number, though a lot of security 0:20:17.800 --> 0:20:20.359 experts would say a thousand twenty four bit prime number 0:20:20.359 --> 0:20:24.919 would be better than It takes those two already huge numbers. Remember, 0:20:24.960 --> 0:20:28.720 it has to identify two different prime numbers that are 0:20:28.920 --> 0:20:33.959 enormous and then multiplies those two enormous prime numbers together 0:20:34.240 --> 0:20:38.000 to get a new number. This number is called the modulus. 0:20:38.440 --> 0:20:42.240 It then requires the calculation of the totient of that product. 0:20:43.160 --> 0:20:45.080 And this is where you say, wait a minute, hang on, 0:20:45.200 --> 0:20:47.199 what the heck is a totient? At least if you 0:20:47.240 --> 0:20:49.600 are like me, I was an English lit major, I 0:20:49.680 --> 0:20:52.720 never got to totients in my studies in math. But 0:20:52.840 --> 0:20:57.520 a totient is a number um that describes the number 0:20:57.520 --> 0:21:01.919 of integers smaller than a given number that are co 0:21:02.040 --> 0:21:04.280 prime with that number. Oh, that's a lot of numbers. 0:21:04.359 --> 0:21:06.119 Let me try that again. Let's say you've got a 0:21:06.160 --> 0:21:12.160 really big number, and the totient is all of the 0:21:12.200 --> 0:21:15.720 integers that are smaller than this really big number that 0:21:15.760 --> 0:21:19.560 are co prime with that really big number, which means 0:21:19.600 --> 0:21:23.639 they share no factors except one with that really big number. 0:21:24.359 --> 0:21:28.119 So let's use an example, because this sounds really really vague. Right. 0:21:28.240 --> 0:21:31.439 Let's say that we have the number fourteen. We we 0:21:31.560 --> 0:21:35.280 got to fourteen, uh, and we took prime numbers. We 0:21:35.320 --> 0:21:37.680 took the number two and the number seven and we 0:21:37.800 --> 0:21:40.480 multiplied those together. Those are our prime numbers we started with. 0:21:40.560 --> 0:21:42.880 So again, this is just an example. You would never 0:21:43.000 --> 0:21:46.080 use numbers this small. You multiply two times seven, you 0:21:46.080 --> 0:21:49.520 get fourteen. Fourteen is your modulus. Then you say what 0:21:49.680 --> 0:21:54.399 is the totient of fourteen? The answer is six, and 0:21:54.480 --> 0:21:58.919 here is why. First, you take all the integers that 0:21:59.000 --> 0:22:02.960 are less than four team, which is one through thirteen. Right, 0:22:03.240 --> 0:22:05.560 you can't use fourteen. You have to use all the 0:22:05.600 --> 0:22:07.480 ones that are all the whole numbers that are lower 0:22:07.480 --> 0:22:10.640 than fourteen, so one through thirteen. But the numbers also 0:22:10.680 --> 0:22:13.280 have to be co prime with fourteen. That means they 0:22:13.400 --> 0:22:17.880 cannot share any factors that fourteen has. Now, the factors 0:22:17.920 --> 0:22:20.280 of fourteen are two and seven, so we get those 0:22:20.359 --> 0:22:23.159 off the list those those get removed, So two and 0:22:23.200 --> 0:22:25.600 seven are gone. But you also have to eliminate the 0:22:25.680 --> 0:22:30.440 numbers four, six, eight, ten, and twelve. All of those 0:22:30.520 --> 0:22:34.200 numbers have two as a factor, and fourteen also has 0:22:34.200 --> 0:22:37.159 two as a factor, so those numbers are not co prime, 0:22:37.600 --> 0:22:40.280 so you strike those. Once you've gotten rid of those, 0:22:40.600 --> 0:22:43.400 the numbers you have left that are lower than fourteen 0:22:43.480 --> 0:22:49.760 are one, three, five, nine, eleven, and thirteen. Now nine 0:22:49.840 --> 0:22:52.160 is not a prime number, right, You can multiply three 0:22:52.160 --> 0:22:55.760 times three and get nine, but it is co prime 0:22:56.119 --> 0:23:00.080 with fourteen because the two numbers share no common factor 0:23:00.240 --> 0:23:03.120 except for the number one. So when you count up 0:23:03.280 --> 0:23:06.439 all the co primes that are left. After you've eliminated 0:23:06.520 --> 0:23:09.080 the numbers that are not co primes, you find out 0:23:09.160 --> 0:23:14.760 you've got six numbers total one, three, five, nteen. That's 0:23:14.840 --> 0:23:18.960 six numbers. So the totient for fourteen is six. By 0:23:18.960 --> 0:23:21.320 the way, there's actually a formula for calculating the totent 0:23:21.400 --> 0:23:24.600 of your huge number that's really really easy. And what 0:23:24.720 --> 0:23:27.239 you do is you take your first prime number, the 0:23:27.240 --> 0:23:29.720