End to End Encryption Services

This one is from a listener request, and the listener in this case wished to remain anonymous, and so I am going to to completely comply with his or her wishes, but wanted to know more about end to end encryption, which has been the news a lot, particularly in the UK. End to end encryption is a means of sending information securely, and it has positive aspects and depending upon who you are, negative aspects. We're going to cover all of that, explain

what end and encryption is and how it works. It's been the news for a couple of years for multiple reasons. One is that some folks and government agencies have made a stink about the technology because they say it gives bad actors like criminals and terrorists, the ability to communicate secretly with one another. That, in a sense is true, but I think it oversimplifies the issue. The tech actually

allows any two people to communicate secretly with one another. So, in other words, it's a tool that can be used by people who are bad, but in itself is not a bad tool. It's a tool that has tons of legitimate uses that have nothing to do with terrorism or crime. So as an example, let's say you are running a record label and it's your job to sign new acts

to this record label. In the old days, you would do all this in person, but today you can do a lot of your business, practically all of your business over the internet. So you can negotiate with the act. You can come to an agreement on terms. You can draw up a contract, and you can send it over for them to sign, and then send it back for you to countersign. But you want all this information to

remain confidential. The terms of one agreement with one act could be very different from the terms you set with another act. To lure a really big act to your label, you might have to include more attractive terms for that act, like better percentages, But you don't necessarily want to do that with every act you're signing. It might not merit it. In some cases, the amount of investment a label might make in an unproven act could end up being unrewarded downeline.

So you would rather have the details of contracts remain secure and not get leaked to the general public, because then your negotiation tools are made plain for everyone to see. It opens up the opportunity for various acts to say, hey, how come they got such a sweet deal and we didn't. Uh,

you know, it's all part of business. So you would rather have a means to send all this information in a way so that even if someone were to intercept the messages, no one who didn't you know, didn't have authority, would ever understand what it actually says. Now that particular idea has been around for as long as we have had secrets, How do you communicate a secret to someone else without anyone else finding out about it, particularly if

you can't whisper it quietly to that person. You have to come up with a means to hide the meaning of your message in some way, and there are a lot of different ways to do this. So, for example, steganography is a way, and I covered that in a previous episode of Tech Stuff with my friend Ariel who joined me for that episode. Steganography is the practice of hiding a message within some other form of non secret data,

like uh an image or a music file. You could literally high the message inside the image, meaning that unless you know what to look for, you're not likely to discover the message. That's not the most secure way of doing it, obviously, but it is something you can do. I remember collecting old Grow the Wanderer comic books by Sergio Ariganez, who would hide a secret message in every single issue. Typically it would read this is the hidden message. So not super duper helpful, but that would be one

way of doing it. However, you could also hide the information within the actual text or or the the the file information of the image itself, so instead of like hiding it physically inside the image, you're hiding it in the code that represents the image. And it's only if you know to look at that code that you would

even see that there was a message there. The whole point is you're concealing that secret message inside some other non secret information that you can freely distribute, so you can send that photo out being reasonably confident that people are not going to see that there's a secret message there. You only know that it's there if you know to

look for it. At least that's the theory or the hope. Obviously, if someone is super nosy and just curious and they start looking at these things more closely, they might uncover that message, So it's not always the most secure methodology. Cryptography, which means to make communication secret, is a very broad category, and encryption falls into that category. Encryption is the specific

process to make hidden or secret. The two terms are often used interchangeably, but technically they are distinct, though I guess if enough people use them interchangeably for long enough, the meaning itself will change, because that's how language works. But that's a bonus episode, I guess. So with encryption, you would use some sort of process too encrypt the data.

You would use a cipher to take a plane message the secret that you wish to can municate, and you would turn it into something that the average person would not be able to understand, but your intended recipient would have the knowledge of how to reverse this process to decipher the mixed up message, so that he or she could read the original secret. So let's take a super simple example, one that would never be used in modern day encryption. Let's take a basic substitution cipher, in which

we swap out letters for other letters. In a super simple version of this, are two communicators have agreed that, for the purposes of their messaging, they will shift all letters over by one so that an A will be represented by the letter B, A B will be represented by the letter C, and so forth until you get to Z, which will be represented by the letter A. So if I wanted to write out uh j O n as my sign off, shortening my name to John, I would actually use the letters k P O. My

recipient would receive this message and say, ah, I must decipher it by cleverly stepping back each letter by one position, and I get j O N Oh it was Jonathan who sent me this message. Now, clearly anyone could crack that code. It would not take any sort of master code breaker to do it. You don't need a computer to do it. Is the simplest of substitution ciphers, and

obviously that would never stand. However, more much more complicated ciphers have been used throughout history, and in fact, one of the earliest uses for computers was in decoding encrypted messages. During World War Two, computers were dedicated to cracking codes made by physical devices like the Enigma machine. But I've talked about that in previous episodes, so I'm gonna move

on rather than dwell on it here now. In cryptology, people often use examples to explain specific implementations and strategies. This has led to two fictional care is becoming placeholders for these examples. So when you want to say person A in person B, that gets really cumbersome. So those characters are Alice and Bob. If you've ever heard examples using Alice and Bob, it comes from this branch of cryptology.

The characters were actually created by three researchers named Ron Revest, Audi Schamir, and Leonard Alderman, who came up with the r S A encryption strategy. R s A for the first initial uh of each of their last names, so Revest, Schamir, and Ottoman you get r S A. And when they came up with that, they decided they needed to have examples to describe what their whole procedure was, and they invented these characters of Alice and Bob. More on R s A in just a minute. Alice and Bob have

become the arc types for cryptological discussions and beyond that. Actually, Alie and Bob are used in lots of different examples for tech, not just cryptology, but basically, the premise spoils down to Bob and Alice both wished to commune dicate with one another without other people being able to intercept and understand those messages. All right, So Alice and Bob they want to send messages to each other using some sort of computer device. It could be an actual computer

like a desktop or a laptop. It could be a smartphone. It could be a laptop, tablet, computer, could be any of these things. It doesn't really matter that the point is that they want to be able to send electronic messages in some meaningful way. And when Alice and Bob

send messages back and forth, their devices aren't doing so directly. Right, there's no direct connection between Alice's device and Bob's device unless they happen to be very close together and able to use some sort of technology like near field communication or NFC. Apart from that, where you're so close you could just whisper it to each other. Let's say that you are across the country from one. Alice is over

in California, Bob is in New York. The messages they send to each other are going to go through routers and switches and servers, and eventually they're going to pass through some sort of central server system before going through even more routers and switches and servers and eventually ending

up on the other person's phone. So whatever service Alice and Bob are using, that centralized server, which is the the you know, kind of like the the Great uh Post service for that particular app it the message has to pass through there because this is a specific app being used offered by a specific company. So Alice sends

Bob a message on their agreed upon messaging app. Alice's message is going to head out over the Internet, hit the server in charge of handling the messaging service that they are both using, and then continue on until it hits Bob. Now, if the message is in plain text, meaning it's unencrypted, anyone along that pathway could potentially read the contents of that message. That includes hackers who could have compromised a system somewhere along that pathway, and they're

trying to pull a man in the middle attack. The message, in other words, is not safe. One way to fix that is through a simple encryption method in which Alice and Bob each have their own private encryption and decryption keys with the server. So let's say Alice and Bob are using a messaging app. Let's call the app x y Z, and x y Z has its server systems. When Alice wants to send Bob a message, she uses her own personal x y Z encryption key to do

so and sends it along. No one else other than x y Z has that encryption key, so Alice and x y Z share it, but nobody else does. Her message will get to the server, which sees that Alice wants to send a message to Bob. So the service says, all right, I'll send this to Bob, except Bob can't read it because it's been encrypted with Alice's key, so

Bob doesn't have Alice's key. So what the server then does will decrypt the message because it has Alice's key and it also has Bob's key, so it then re encrypts the message using Bob's key and then sends that along to Bob, so the message has been encrypted twice. Technically, it was encrypted, decrypted at the server level, encrypted again sent to Bob. Whenever the message is passing over the Internet,

it is encrypted, which is pretty safe. But you may say, well, what about the time that it's spending on the server. That's the rub. See, this is not end to end encryption. I'll explain that a little bit later. The server is able to decrypt all incoming messages, no matter who is sending them, and then encrypt them with the respective keys belonging to whoever was the intended recipients. But this creates

a few different problematic scenarios. One is that governments they love this strategy because it opens up the possibility that the server could release message is on a court order or some other means, Like if the government orders the service to share those messages and the services compelled to agree to it, then potentially the government could get hold of unencrypted plane text messages because at the server level

everything gets unlocked. So the government agency can go to X Y Z and say, we suspect Alice and Bob are plotting something dangerous. We have some evidence, but we want access to the messages they're sending to each other. Lives could be at stake, and then they flash a Warren or something, and because X y Z is following this strategy, it could hand over such information if ordered to,

revealing all the messages between Alice and Bob. And maybe Alice and Bob really were plotting something terrible and it's prevented as a result, or maybe they're just happy people and their private messages have now been compromised and they were completely innocent, and yet there otherwise private communication has

now been made at least semi public. The strategy also creates an incredibly attractive target for hackers, obviously, because if you can compromise that central server, you can get at all the data that's going across it because it gets decrypted there. In fact, this has happened a few times in the past where hackers have managed to get access to such systems and mind them for data and dump all the information onto various places on the web, or

more likely on the dark web. This is where stuff like credit card information or compromising photos can come into play, where hackers have managed to get into a server and and get all that information. Sure the messages were encrypted as they went over the Internet, but that one central point everything was unlocked and ready for exploitation and to end Encryption aims to defeat this by creating a strategy in which only Alice and Bob know how to decrypt

messages from the other. They have a private means of decrypting information. The central server does not have access to that it decryption key, and so the messages sent across the server are meaningless to the server, is just gobbledygook. The server could confirm that messages had passed between Alice and Bob, you could say, well, yes, we know that the two have communicated with each other, but they the company wouldn't be able to speak to what was actually

in those messages. So if a government agency served up a search warrant, all they would get is some garbled, seemingly random and meaningless data. They would need that private

key to make any sense of it. Now, there are companies that absolutely love using the strategy because it really takes the heat off of them that not only are they able to offer their customers a secure way to communicate, there's no way for the company to know what sort of data is crossing its servers, so it cannot be complicit in anything illegal because it doesn't know what's happening.

It provides a service one in which people may communicate with one another in a secure fashion, and that's it. But it raises a question how the heck are Alice and Bob is supposed to get a private key across to each other? Right? If Alice and Bob are apart from one another and their communication requires going through a centralized service, how do they establish a secret means of

communication in the first place. If that first message is hey, let's use this secret code, but it's decrypted by the centralized server, then the centralized server knows the secret code, it doesn't help. Well. The answer comes down to what was called an asymmetric cryptographic algorithm that uses public key cryptography. And in this method, there are two keys that are used for each message. One of them is a public key, which is unique to each user that can be freely

distributed across the internet. The other is a private key, which is a jealously guarded secret that allows only one entity the chance to decrypt information. I'll speak about more of this in just a minute, but first let's take a quick break to thank our sponsor. Alright, So how does public key cryptography work. Each person using the system,

let's call it ABC. For this case, we're talking about different service from x y Z. Every single person using ABC gets too encryption keys, or well, one encryption key and one decryption key. Technically, one key is the person's private key, So Alice has a private key that's unique to her, and Bob has a private key it's unique to him. They they also each have a public key, so Alice has a public key, Bob has another public key.

These are also unique to Alice and Bob, but those keys are published publicly on the service across the Internet. Anyone who wants to send an encrypted message to Alice or Bob must use their respective public keys. In other words, if I want to send Alice a message, I have to use Alice's public to encrypt it. To decode a message, you have to have the private key. So if you know both keys for a specific message, you can transform

that garbled mess into meaningful communication. And because you keep your own private key to yourself, at least ideally, the only person who can decode messages meant for you is you. So Alice takes Bob's public key and uses it to encode her message to Bob. She then sends the encoded message to Bob across the messaging service. The encoded message passes through ABC's server, which cannot read the message because

ABC does not have Bob's private key. Only Bob has that the message gets to Bob, he uses his private key and it decodes the message and then he can read it in plain text. But what is actually going on here? How is this happening? Well that that depends heavily on the specific cryptographic strategy used, But we can go with one of the earliest proposed methods of doing this, the RSA algorithm, the one I mentioned earlier that was proposed by the guys who used Alice and Bob as

examples in the first place. This one relies on prime numbers, and just a quick refresher, a prime number is only equal to one times the prime number itself. There are no other multiple multiple factors. There are no other numbers you can multiply together to get the prime number. So if you can get to the value of a number by by multiplying any other two numbers, it's what we call a composite number. And is not a prime number. So the numbers one, two, and three are all prime numbers.

They are only divisible by themselves and by one that there are no other factors, right That our whole numbers anyway, because the only multiplication you can do to arrive at them is one times one is one, one times two is two, and one times three is three, respectively. Four is the smallest composite number because you can multiply two times two to get four. So it's one times four is four and two times two is four. That means it is not a prime number. It's a posit number.

So the number is only divisible by one or itself, then it's a prime number. The r s a algorithm takes two really really really big prime numbers, like hundreds of digits long. You might find systems that use a five twelve bit prime number, though a lot of security experts would say a thousand twenty four bit prime number

would be better than It takes those two already huge numbers. Remember, it has to identify two different prime numbers that are enormous and then multiplies those two enormous prime numbers together to get a new number. This number is called the modulus. It then requires the calculation of the totient of that product. And this is where you say, wait a minute, hang on, what the heck is a totient? At least if you are like me, I was an English lit major, I

never got to totients in my studies in math. But a totient is a number um that describes the number of integers smaller than a given number that are co prime with that number. Oh, that's a lot of numbers. Let me try that again. Let's say you've got a really big number, and the totient is all of the integers that are smaller than this really big number that are co prime with that really big number, which means they share no factors except one with that really big number.

So let's use an example, because this sounds really really vague. Right. Let's say that we have the number fourteen. We we got to fourteen, uh, and we took prime numbers. We took the number two and the number seven and we multiplied those together. Those are our prime numbers we started with. So again, this is just an example. You would never use numbers this small. You multiply two times seven, you get fourteen. Fourteen is your modulus. Then you say what

is the totient of fourteen? The answer is six, and here is why. First, you take all the integers that are less than four team, which is one through thirteen. Right, you can't use fourteen. You have to use all the ones that are all the whole numbers that are lower than fourteen, so one through thirteen. But the numbers also have to be co prime with fourteen. That means they

cannot share any factors that fourteen has. Now, the factors of fourteen are two and seven, so we get those off the list those those get removed, So two and seven are gone. But you also have to eliminate the numbers four, six, eight, ten, and twelve. All of those numbers have two as a factor, and fourteen also has two as a factor, so those numbers are not co prime, so you strike those. Once you've gotten rid of those, the numbers you have left that are lower than fourteen

are one, three, five, nine, eleven, and thirteen. Now nine is not a prime number, right, You can multiply three times three and get nine, but it is co prime with fourteen because the two numbers share no common factor except for the number one. So when you count up all the co primes that are left. After you've eliminated the numbers that are not co primes, you find out you've got six numbers total one, three, five, nteen. That's

six numbers. So the totient for fourteen is six. By the way, there's actually a formula for calculating the totent of your huge number that's really really easy. And what you do is you take your first prime number, the one that you want. You know, in our case we use two and seven. Let's say you take your first prime number, you subtract one from that. You take your second big prime number, you subtract one from that, and you multiply those two new numbers together, and that is

your totent. So in our example, we take our two prime numbers of two and seven, we subtract one from each. That means we have a one and a six. We multiply these two new numbers together one time, six is six. That's the totent for fourteen. It's the fastest way to calculate the totent. Next, because we're not done yet, you have to select an integer, but not just any integer.

The integer you select has to be larger than the number one, but smaller than the totient of your big old number that you generated earlier by multiplying those two prime numbers together and then taking the totient from it. In fact, it has to be a co prime with the totient and the modulus itself, so it cannot share

a factor with the totient or with the modulus. So again, in my example, where I had fourteen as our modulus, the totient was six, we need an integer between one and six that is co prime with both six and fourteen. So we cannot use one because the number has to be bigger than one. We can't use two or three or four because all of those share factors with six. Right, it has to be co prime, so you cannot use those. The only number available to us is five. This becomes

our encryption key. Figuring out the decryption key is a little more complicated, and that's probably making some of you scratch your heads, because what I just went through is fairly complicated for those of us who are not very mathematically inclined. I include myself in that number. By the way, the prime number we arrived at for the encryption key has the greatest common divisor or g c D of

one with the totient of that number. So we take the multiplicative inverse of this number with respect to the totient using the extended Euclidean algorithm. Yeah, I get super duper complicated, and I'm pretty sure I can't explain it, especially not in audio alone, so the well will skip ahead. You just imagine you do some more complicated math and you denote this result with the letter D, and that

represents the private key. Now. I use the prime numbers two and seven in my example only because they were easy to work with, But that's precisely why no one in the right mind would ever use those to encrypt anything. You want to have a pretty large number to work with, and even your public key should be pretty big. A standard public key is sixty five thousand, five seven, which is a prime number, and as long as it has no common factors with the modulus, you're good to go.

And the only way it could have a common factor with a modulus is if it was itself a factor of your big number, but that's not likely to happen. So you want a big key, but you don't want it to be too big, and the reason for that is encryption is more efficient if you're using smaller numbers as your keys. Remember, like essentially encryption involves doing lots of math problems. The bigger the numbers are for your math problems, the bigger the results are going to be,

and the larger it's going to make your message. So if you're trying to encrypt a very long message to someone, then ends up being a much larger amount of data, like sometimes several times larger than the original amount of data. And if you get too big, you may not even be able to send it if the service you're using has a limit on the size of messages. So if you go too big, it gets inefficient and clunky and

sometimes too big for you to even hand. But if you go too small, you risk the possibility of someone being able to suss out the private key given enough time and processing powers, So it's a balancing act. One thing you could do to make things move more quickly is to use this public and private key approach to establish a new encryption key between the two communicators. This

would be called a session key. So Alice would send Bob a message, she would use Bob's public encryption key that's and she would encrypt a message that says, hey, got a second and she sends it to Bob, and Bob receives the message. He uses his private key, he decodes the message and sends a message back to Alice using her public encryption key that says, sure I do. And here's a brand new private key that we can use for each other for the purposes of this conversation session.

And then Alice would decrypt this message, and they would each have a private key that they could use to each other, a symmetric key. All subsequent messages between Bob and Alice would use this new private encryption methodology. And we call this symmetric because you're using the same key to encrypt and decrypt and UH. Otherwise, you wouldn't be able to send this to each other because it would be public information and everyone would have a copy of

the key. Using the public private key message to first send this is clever because the first message, anyone could intercept it, but they're not gonna know what's in it. And then all subsequent messages would be using a totally different UH encryption methodology. So even if someone were to monitor this communication, the communications they would see would be encrypted in different ways, and that would make it practically

impossible to figure out what was going on. You could even go a step further and have a new key generated with essentially every single message, so it's essentially a one ahead. Each message gets a new key to be encrypted by, and since it keeps changing each time someone sends a message, like Bob sends Alice a new message and says uh uh secret, secret, secret, brand new key, Alice uses the brand new key to part her message in too, Bob, and it says more secrets, more secrets,

more secrets, new, brand new key. Bob uses the uh the the key from one session earlier to unlock Alice's message reads it then uses the brand new key to send the next message. You could keep doing this forever. You could keep sending a brand new key with every single message, and it would make your communications very secure.

It would be a little slow because you would have to do this decryption encryption thing every single step, and you wouldn't be able to repeat the steps because they'll be using a new key every time, but it would be really secure, and in fact, there are some messaging apps that use this kind of methodology. So the really big benefit of symmetric encryption is that. Well, one, it's faster than using public and private key approach, but another is that limits the number of times that you use

the public key, and that can be a good thing. Now, it's not easy with today's computers, but at least there it's at least theoretically possible that hackers could suss out a public encryption key and work backward to figure out the private encryption key. It's a non trivial problem. It requires a ton of computer processing power, and it's not

likely to happen if you're using really secure encryption. But the more frequently use the same public key, the more data hackers have to work with, and they can start looking for patterns. Patterns are the bane of encryption. When you have patterns, then you can start to establish rules. And when you start to establish rules, you can start working backward and figuring out what generates those rules, and eventually you figure out the methodology for encoding the information.

So you don't want to have patterns in your encoded information. If possible, if you keep using the public private key method and it's all you're using, then hackers eventually can gather enough information that if they have a sufficiently powerful computer and enough time on their hands, they can decrypt it. Uh. That if is a big one though, because if you're using pretty strong encryption, it would take weeks or months or more likely years to decrypt the messages. Now, in

a recent episode, I talked about quantum computers. With a classical computer, like I said, figuring out prime numbers for a really large number takes an incredibly long time. Depending on the size of the number, it could take like I said, years for a classical computer to sort it out. But a quantum computer, if it's sufficiently powerful, could solve those problems much more quickly using a process called Shore's algorithm.

So if you have a quantum computer with a sufficient number of cubits, you could crack this type of encryption relatively quickly and pretty reliably. So it's therefore imperative to look at new methods of encrypt in order to avoid a situation in which the first really powerful quantum computer effectively gets a skeleton key to all encrypted messages that

have been sent across the Internet. Now, let's talk a second about the history of end to end encryption, and then a bit more about the apps and services that use it and some that do not use it. In nine, Whitfield, Diffy and Martin Hellman proposed the concept of using public and private key combinations in order to distribute symmetric encryption keys. It's possible they weren't the first to consider this too.

There's been some evidence to suggest the British Secret Service had come up with a similar approach but never really did anything with it. Their idea was the basis not just for the r s A algorithm, but a few others as well, like the el Camal crypto system, which was named after Tahir el Camal, or the d s A system also known as the Digital Signature algorithm, invented by a guy named David Kravitz, as well as the Diffie Hellman cryptosystem, which obviously was created by Whitfield, Diffie

and Martin Hellman. Then along came p g P, which stands for Pretty Good Privacy. The cryptosystem is a hybrid system. It was proposed by Phil Zimmerman in n Zimmerman graduated from Florida Atlantic University with a degree in computer science, and he was active in a project called the Freeze,

also known as the Nuclear Weapons Freeze campaign. The purpose of this organization was to try and curtail nuclear arms production in an effort to de escalate mounting global tensions and to remove a A an existential threat to the human race, and Zimmerman created p g P to allow for secure email communications among various parties to make their

efforts more effective and less likely to get snooped on. Now, when you use p g P, the first thing it does is it takes your plain text message and impresses it, and so it makes it smaller, which is one benefit, but it also helps to make it more secure because it reduces patterns that might otherwise be useful to hackers

who want to decrypt messages. It also generates a session key, that's that symmetric encryption key I was just talking about that would be used throughout the length of any particular communication session. The way PGP does this is pretty cool. It actually generates the data for the session key based on your mouse movements and key strokes you've typed, so it's based upon physical interactions you've had with your computer,

not with any other just random prime number. All of this, the compressed plane text message and the unique session key generated from your physical interactions with your computer then get encoded using this public private key strategy. If Alice sends a message using PGP too Bob, first, Alice's computer will compress your message, it will append a session key based on Alice's typing and mouse movements, and then encrypt all of that mess using Bob's public key. Then the message

travels to Bob. Bob uses his private key to decode the message and he can see the session key Alice has set up and then use that to communicate back with her securely for the rest of the session. Zimmerman's p GP was more than just pretty good. It was actually a brilliant approach to encryption. It became adopted by many organizations and people across the United States and then the world, and that caused a huge amount of trouble

for Zimmerman. For one thing, r s A Security wished to question Zimmerman about the use of the r s A algorithm within p GP. There was some disputes about the licensing. Then the United States Custom Services decided to investigate Zimmerman because of the distribution of p GP beyond

the US borders. Because in the United States there was the Arms Control Act and it listed cryptographics software as a type of munitions, which would mean if Zimmerman had allowed his work to go outside the US, he would be in very big trouble because it was similar to shipping prohibited weapons outside the country. And if you think that sounds a little crazy that software could be considered

a weapon, Welcome to the twenty first century. Zimmerman was never officially charged with any crime, but the investigation did

last several years. Eventually, the courts determined that p GP did not fall into a category that would be considered munitions, and today his PGP technology is the property of the security firm Symantec, which purchased the PGP Corporation back in Now I've got a little bit more I want to say about end to end encryption, but before I get to that, let's take another quick break to thank our sponsor.

So the PGP strategy also allows for digital signatures, which are a way for you to make sure the message being sent to you hasn't been intercepted and altered in any way. Plus you can be sure that the message came from the person it claims to have come from. Digital signatures and p g P use what is called a one way hash function. The implementation p g P uses is to take the message, which can be of any length. So let's say it's a really really long message.

Then it does a mathematical process on it to arrive at a fixed length output, such as one sixty bits. So the one sixty bits does not contain the entire message. It represents the entire message. It's fine distinction. It doesn't matter how long that original message was. The goal is to create this shorter hash that speeds things up. It

doesn't make file sizes balloon from the encryption process. The hash function depends entirely on the message itself, So if someone were to change even one single bit as in one, zero or one of information in that message, the hash value would also change because it depends upon the nature of the rest of the message. So if you send a message to someone and they know what the hash value is supposed to be, they can verify that the

associated message was never altered. So they've got essentially the the hash value it's supposed to be and the hash value it actually is. If those two numbers are different, then they know that something has happened to the message in transit. The way PGP does this is to generate a hash called the message digest. It uses the message digest and the private key to create a signature. Then p GP sends the plain text in signature together to

the recipient. The recipient uses PGP to recompute the message digest to verify it is from the supposed center and then it hasn't been altered. And if the recomputed message digest is the same as the original that was in the message, everything's good. If the recomputed one is not the same, then something has happened, and you know that the the trail between the two has been compromised in some way. By the way, this does not reveal the

private key to the other person. The private key remains private um P. G P is able to protect that, which is kind of cool. Alright. So who uses end to end encryption and who does not? Well? Among the messaging apps that use end to end encryption, there is the Big Daddy What's App. That's an incredibly popular messaging app. It is owned by Facebook. Now what didn't start off as a Facebook project. It was purchased by Facebook. The original messaging app was co founded by Jan Kom who

grew up in the Ukraine. And wanted to create a way in which people could send messages safely without the fear of an oppressive presence, like a totalitarian government agency, for example, that could read all of them. Now, he had moved to America when he was sixteen, and years later he met with a guy named Brian Acton and Acting became the other co founder of WhatsApp. They created the messaging service, and they used end to end encryption

to protect users privacy. When Faceboo Public purchased WhatsApp rather, many security experts express concern because they were worried that Facebook might chip away at the messaging apps security and allow Facebook the chance to mind these messages and then sell that data to advertisers, and there have been accusations

levied at Facebook claiming as much. To Bias Bolter, a security researcher, told reporters at The Guardian that Facebook had the ability to generate new encryption keys for offline users and thus access messages that would be sent to them. Whether that's true or not, I don't know. Facebook has denied that they have the ability to read any messages from their users, but there's still a lot of concern about WhatsApp in general. Another app that uses end to

end encryption is Signal. Signal started out as text secure private messenger, and you can also use Signal to make encrypted voice and video calls to other users. These follow a similar approach to messages and email els um. They protocols are obviously a little different because they're different media or different forms of messaging, but the general principle remains the same, the idea that all the information being sent across these channels is encrypted all the way until it

gets to the destination device. Whire is a another popular app, particularly in countries belonging to the European Union. It's also free and open source. The app does store a record of the people you've communicated with. That's a little problematic from a security standpoint. Now, the purpose of storing this information is to make it easier to synchronize and experience across devices, because one of the big drawbacks of the public private key approach is that ideally you have that

private key on one and only one device. If you share a private key across multiple devices, then you have increased the possibility of someone getting access to your private key. But if you lose the device pace that the private key is on, you lose all your messaging history as well, because remember, no one else can see what that encrypted stuff is because it all used your public key that could only be decoded by your private key. So if you lose your private key, all you have is gobbledygook.

You can't read it. That is, of course, if if you haven't been storing messages in some other fashion, uh like in plain text some services, you could, as a user opt to store your messages using a third party application. This would be like you receive the message, you decrypt the message when you receive it, you have the message in plain text because you have to in order to read it or or view it or whatever it may be.

And then you decide you want to save that message. Well, when you're saving that message, you may be saving that in plain text using a third party app, in which case all that secrecy for the communication is undone by your storage. It becomes a security vulnerabile. So you could be super careful about messages as they speed to and from your device, But if you're then storing everything on a cloud server somewhere, you could still technically be allowing

some other company access to that information. After the fact, but if you don't do that, if you lose your phone, then you could lose all those messages, all the histories, all the communications, So it's a tough situation. Also, by the way, this means that the hackers will sometimes concentrate not on trying to intercept a message in the middle, because if it's encrypted, it could be more trouble than

what it's worth to try and decrypt it. Or instead of doing that, they'll they'll try and target the end device. So in other words, they're actually trying to get physical access to your computer or phone or somehow be able to look at your screen remotely once the decryption process has happened, So they want to compromise your device at that point because it's relatively easier than trying to do

crypt one of these heavily encrypted messages on the Internet. Anyway, Wire has said that a user once a user deactivates deletes his or her account, then the service deletes all the associated information with that account, all the stored connections, everything is gone once you delete your account with Wire, according to the service, there's also a multi platform app that's popular that's called Telegram. Telegram, you can search for

people by user name rather than by phone number. A lot of apps require that you know the phone number of the person you're trying to contact, but Telegram, when you create a profile, in addition to creating a profile based on a telephone number, you can create a user name, and so people can search for you on that. It makes it a little easier to communicate with people. There's also another app called wicker w i c k R, which is really popular in enterprises, so in business, not

necessarily as much with individual users. But as for email, their services like tour Guard, Hushmail, Mail, fence to to, Not to run Box, proton Mail, all of these use

various encryption strategies to keep messages safe. Not all of them necessarily use end to end encryption, some of them use other methods for encryption than in too end, but they all do some form of encryption on their messages, whereas popular email services like Gmail do not support end to end encryption, and one reason they might not I can't say this is for sure sure, but one reason they may not do that is that it's possible that they want to mine all that information for the possibility

of advertising against it. So in other words, you send a message. Alison's a message to Bob, Alice talks about all these nice flowers that she saw on a recent trip. And then Alice starts seeing ads mysteriously whenever she's using a Google service that is talking about flowers. Well, that raises some very tricky ethical questions. Now, whether or not that's actually going on, that's a that's a matter of

investigation on a case by case basis. You know, not all emails are necessarily being mined for information, but they all could be if they're not being encrypted end to end. So there are a lot of advocates for privacy out there who some of them will say, Hey, don't even bother sending me any email if it's not encrypted. I'm not interested you. If you're not using an encryption service of some sort, then I do not want to communicate with you because I prefer to keep my privacy private.

And that's a legitimate argument, I think. I don't think it's not necessarily the indication that someone is up to something, you know, suspicious, But it's important to remember that without that end to end encryption, it is a possibility that someone along the way is reading your messages. Besides the person you're sending them too. I would like to thank our anonymous listener for asking for us to cover this topic.

It is very fascinating. In the UK in particular, this is an ongoing issue where the UK government would love to see end to end encryption go away because they worry that it's a methodology of UH, that that terrorists are using to communicate with one another, and that this creates a problem because you can't really investigate those terrorists cells at least not through the means of their communication,

because you can't decrypt it. There have been people who have called for a back door of some sort to end to end encryption services, which defeats the purpose. Backdoor is essentially a vulnerability you introduce on purpose so that a party apart from the intended recipient can decode a message, and that that raises enormous security problems. Like you don't create a backdoor because that means you're introducing the possibility of a hacker getting access to this information. You don't

want to do that. That's that's bad security. So there, that's not a great UH strategy moving forward. Is trying to force services to create a backdoor. It pretty much breaks the whole service in the first place. So I don't know what the solution here is. I don't think that that getting rid of a technology because some people use it improperly is necessarily going to work. Um that

is uh, it is, it is. It raises a lot of questions, and it also means that you have to put an awful lot of trust in the governing agency, and that can be difficult to do. And also, any time you have a back door, anytime you have any sort of vulnerability, if people know it exists, then you've just given hackers a target to shoot for. And even if it works as it's supposed to, where everyone is behaving themselves from the good guys standpoint, let's say that

the government is a good guy in this. In this scenario that both Alice and Bob are behaving themselves, the government is behaving itself. It's not investigating Alison Bob. It has no reason to suspect them. So they're able to send their messages securely. But there is this back door option that is available, then hackers could target that and then they compromise the system, and then Alice and Bob's messages are laid bare for the hackers because you've just

painted a huge target on the service. It's not great, and not every end to end encryption service is infallible. Uh. There have been security experts who have accused Apple in particular of implementing a poor end to end encryption strategy for their Eye Message app and have stated that there are ways that that could be defeated using classical computer systems.

So it is possible to do this in a way that isn't effective, but the actual idea itself is incredibly effective if you implement it properly and you're using classical computers as your potential threat. Once quantum computers actually become on part of the scene for real z s, when they're sufficiently powerful, it'll be a totally different story because a sufficiently powerful quantum computer will completely lay bare all these encryption schemes, So you have to come up with

something new. But I talked a little bit about that in one of the IBM Think episodes, so you can go back and listen to that if you want to learn more. As for you, guys, if you have any suggestions for future episodes of Tech Stuff, I I welcome you to send those suggestions to me. You can email the show that addresses tech stuff at how stuff Works dot com, or you can drop me a line on

Twitter or Facebook. The handle at both of those is tech stuff hs W. Remember to follow us on Instagram, and remember typically I record these episodes live on twitch dot tv slash tech stuff on Wednesdays and Fridays. This particular episode I'm recording right now was an exception because again I'm in a hotel, a music hotel WiFi, which is not the greatest thing to use for streaming, but usually I stream live from the studio on Wednesdays and Fridays.

Go to Twitch dot tv slash tech Stuff. You'll see the schedule there. I hope to see you in the chat room and you can chat with me as I'm recording. You can have a grand old time and I'll talk to you again really soon. For more on this and bathands of other topics. Is that how stuff Works dot com.