Speaker 1: Get in touch with technology with tech Stuff from how
Speaker 1: stuff Works dot com. Hey there, and welcome to tech Stuff.
Speaker 1: I'm your host, Jonathan Strickland. I'm an executive producer with
Speaker 1: How Stuff Works and the Love all Things Tech Today.
Speaker 1: Probably sounds a little different from my normal episodes because
Speaker 1: I'm actually recording this while I'm in a hotel room
Speaker 1: in Las Vegas. I'm attending yet another tech conference. But
Speaker 1: this episode is more in line with our normally scheduled episodes.
Speaker 1: This one is from a listener request, and the listener
Speaker 1: in this case wished to remain anonymous, and so I
Speaker 1: am going to to completely comply with his or her wishes,
Speaker 1: but wanted to know more about end to end encryption,
Speaker 1: which has been the news a lot, particularly in the UK.
Speaker 1: End to end encryption is a means of sending information securely,
Speaker 1: and it has positive aspects and depending upon who you are,
Speaker 1: negative aspects. We're going to cover all of that, explain
Speaker 1: what end and encryption is and how it works. It's
Speaker 1: been the news for a couple of years for multiple reasons.
Speaker 1: One is that some folks and government agencies have made
Speaker 1: a stink about the technology because they say it gives
Speaker 1: bad actors like criminals and terrorists, the ability to communicate
Speaker 1: secretly with one another. That, in a sense is true,
Speaker 1: but I think it oversimplifies the issue. The tech actually
Speaker 1: allows any two people to communicate secretly with one another. So,
Speaker 1: in other words, it's a tool that can be used
Speaker 1: by people who are bad, but in itself is not
Speaker 1: a bad tool. It's a tool that has tons of
Speaker 1: legitimate uses that have nothing to do with terrorism or crime.
Speaker 1: So as an example, let's say you are running a
Speaker 1: record label and it's your job to sign new acts
Speaker 1: to this record label. In the old days, you would
Speaker 1: do all this in person, but today you can do
Speaker 1: a lot of your business, practically all of your business
Speaker 1: over the internet. So you can negotiate with the act.
Speaker 1: You can come to an agreement on terms. You can
Speaker 1: draw up a contract, and you can send it over
Speaker 1: for them to sign, and then send it back for
Speaker 1: you to countersign. But you want all this information to
Speaker 1: remain confidential. The terms of one agreement with one act
Speaker 1: could be very different from the terms you set with
Speaker 1: another act. To lure a really big act to your label,
Speaker 1: you might have to include more attractive terms for that act,
Speaker 1: like better percentages, But you don't necessarily want to do
Speaker 1: that with every act you're signing. It might not merit it.
Speaker 1: In some cases, the amount of investment a label might
Speaker 1: make in an unproven act could end up being unrewarded downeline.
Speaker 1: So you would rather have the details of contracts remain
Speaker 1: secure and not get leaked to the general public, because
Speaker 1: then your negotiation tools are made plain for everyone to see.
Speaker 1: It opens up the opportunity for various acts to say, hey,
Speaker 1: how come they got such a sweet deal and we didn't. Uh,
Speaker 1: you know, it's all part of business. So you would
Speaker 1: rather have a means to send all this information in
Speaker 1: a way so that even if someone were to intercept
Speaker 1: the messages, no one who didn't you know, didn't have authority,
Speaker 1: would ever understand what it actually says. Now that particular
Speaker 1: idea has been around for as long as we have
Speaker 1: had secrets, How do you communicate a secret to someone
Speaker 1: else without anyone else finding out about it, particularly if
Speaker 1: you can't whisper it quietly to that person. You have
Speaker 1: to come up with a means to hide the meaning
Speaker 1: of your message in some way, and there are a
Speaker 1: lot of different ways to do this. So, for example,
Speaker 1: steganography is a way, and I covered that in a
Speaker 1: previous episode of Tech Stuff with my friend Ariel who
Speaker 1: joined me for that episode. Steganography is the practice of
Speaker 1: hiding a message within some other form of non secret data,
Speaker 1: like uh an image or a music file. You could
Speaker 1: literally high the message inside the image, meaning that unless
Speaker 1: you know what to look for, you're not likely to
Speaker 1: discover the message. That's not the most secure way of
Speaker 1: doing it, obviously, but it is something you can do.
Speaker 1: I remember collecting old Grow the Wanderer comic books by
Speaker 1: Sergio Ariganez, who would hide a secret message in every
Speaker 1: single issue. Typically it would read this is the hidden message.
Speaker 1: So not super duper helpful, but that would be one
Speaker 1: way of doing it. However, you could also hide the
Speaker 1: information within the actual text or or the the the
Speaker 1: file information of the image itself, so instead of like
Speaker 1: hiding it physically inside the image, you're hiding it in
Speaker 1: the code that represents the image. And it's only if
Speaker 1: you know to look at that code that you would
Speaker 1: even see that there was a message there. The whole
Speaker 1: point is you're concealing that secret message inside some other
Speaker 1: non secret information that you can freely distribute, so you
Speaker 1: can send that photo out being reasonably confident that people
Speaker 1: are not going to see that there's a secret message there.
Speaker 1: You only know that it's there if you know to
Speaker 1: look for it. At least that's the theory or the hope. Obviously,
Speaker 1: if someone is super nosy and just curious and they
Speaker 1: start looking at these things more closely, they might uncover
Speaker 1: that message, So it's not always the most secure methodology. Cryptography,
Speaker 1: which means to make communication secret, is a very broad category,
Speaker 1: and encryption falls into that category. Encryption is the specific
Speaker 1: process to make hidden or secret. The two terms are
Speaker 1: often used interchangeably, but technically they are distinct, though I
Speaker 1: guess if enough people use them interchangeably for long enough,
Speaker 1: the meaning itself will change, because that's how language works.
Speaker 1: But that's a bonus episode, I guess. So with encryption,
Speaker 1: you would use some sort of process too encrypt the data.
Speaker 1: You would use a cipher to take a plane message
Speaker 1: the secret that you wish to can municate, and you
Speaker 1: would turn it into something that the average person would
Speaker 1: not be able to understand, but your intended recipient would
Speaker 1: have the knowledge of how to reverse this process to
Speaker 1: decipher the mixed up message, so that he or she
Speaker 1: could read the original secret. So let's take a super
Speaker 1: simple example, one that would never be used in modern
Speaker 1: day encryption. Let's take a basic substitution cipher, in which
Speaker 1: we swap out letters for other letters. In a super
Speaker 1: simple version of this, are two communicators have agreed that,
Speaker 1: for the purposes of their messaging, they will shift all
Speaker 1: letters over by one so that an A will be
Speaker 1: represented by the letter B, A B will be represented
Speaker 1: by the letter C, and so forth until you get
Speaker 1: to Z, which will be represented by the letter A.
Speaker 1: So if I wanted to write out uh j O
Speaker 1: n as my sign off, shortening my name to John,
Speaker 1: I would actually use the letters k P O. My
Speaker 1: recipient would receive this message and say, ah, I must
Speaker 1: decipher it by cleverly stepping back each letter by one position,
Speaker 1: and I get j O N Oh it was Jonathan
Speaker 1: who sent me this message. Now, clearly anyone could crack
Speaker 1: that code. It would not take any sort of master
Speaker 1: code breaker to do it. You don't need a computer
Speaker 1: to do it. Is the simplest of substitution ciphers, and
Speaker 1: obviously that would never stand. However, more much more complicated
Speaker 1: ciphers have been used throughout history, and in fact, one
Speaker 1: of the earliest uses for computers was in decoding encrypted messages.
Speaker 1: During World War Two, computers were dedicated to cracking codes
Speaker 1: made by physical devices like the Enigma machine. But I've
Speaker 1: talked about that in previous episodes, so I'm gonna move
Speaker 1: on rather than dwell on it here now. In cryptology,
Speaker 1: people often use examples to explain specific implementations and strategies.
Speaker 1: This has led to two fictional care is becoming placeholders
Speaker 1: for these examples. So when you want to say person
Speaker 1: A in person B, that gets really cumbersome. So those
Speaker 1: characters are Alice and Bob. If you've ever heard examples
Speaker 1: using Alice and Bob, it comes from this branch of cryptology.
Speaker 1: The characters were actually created by three researchers named Ron Revest,
Speaker 1: Audi Schamir, and Leonard Alderman, who came up with the
Speaker 1: r S A encryption strategy. R s A for the
Speaker 1: first initial uh of each of their last names, so Revest, Schamir,
Speaker 1: and Ottoman you get r S A. And when they
Speaker 1: came up with that, they decided they needed to have
Speaker 1: examples to describe what their whole procedure was, and they
Speaker 1: invented these characters of Alice and Bob. More on R
Speaker 1: s A in just a minute. Alice and Bob have
Speaker 1: become the arc types for cryptological discussions and beyond that. Actually,
Speaker 1: Alie and Bob are used in lots of different examples
Speaker 1: for tech, not just cryptology, but basically, the premise spoils
Speaker 1: down to Bob and Alice both wished to commune dicate
Speaker 1: with one another without other people being able to intercept
Speaker 1: and understand those messages. All right, So Alice and Bob
Speaker 1: they want to send messages to each other using some
Speaker 1: sort of computer device. It could be an actual computer
Speaker 1: like a desktop or a laptop. It could be a smartphone.
Speaker 1: It could be a laptop, tablet, computer, could be any
Speaker 1: of these things. It doesn't really matter that the point
Speaker 1: is that they want to be able to send electronic
Speaker 1: messages in some meaningful way. And when Alice and Bob
Speaker 1: send messages back and forth, their devices aren't doing so directly. Right,
Speaker 1: there's no direct connection between Alice's device and Bob's device
Speaker 1: unless they happen to be very close together and able
Speaker 1: to use some sort of technology like near field communication
Speaker 1: or NFC. Apart from that, where you're so close you
Speaker 1: could just whisper it to each other. Let's say that
Speaker 1: you are across the country from one. Alice is over
Speaker 1: in California, Bob is in New York. The messages they
Speaker 1: send to each other are going to go through routers
Speaker 1: and switches and servers, and eventually they're going to pass
Speaker 1: through some sort of central server system before going through
Speaker 1: even more routers and switches and servers and eventually ending
Speaker 1: up on the other person's phone. So whatever service Alice
Speaker 1: and Bob are using, that centralized server, which is the
Speaker 1: the you know, kind of like the the Great uh
Speaker 1: Post service for that particular app it the message has
Speaker 1: to pass through there because this is a specific app
Speaker 1: being used offered by a specific company. So Alice sends
Speaker 1: Bob a message on their agreed upon messaging app. Alice's
Speaker 1: message is going to head out over the Internet, hit
Speaker 1: the server in charge of handling the messaging service that
Speaker 1: they are both using, and then continue on until it
Speaker 1: hits Bob. Now, if the message is in plain text,
Speaker 1: meaning it's unencrypted, anyone along that pathway could potentially read
Speaker 1: the contents of that message. That includes hackers who could
Speaker 1: have compromised a system somewhere along that pathway, and they're
Speaker 1: trying to pull a man in the middle attack. The message,
Speaker 1: in other words, is not safe. One way to fix
Speaker 1: that is through a simple encryption method in which Alice
Speaker 1: and Bob each have their own private encryption and decryption
Speaker 1: keys with the server. So let's say Alice and Bob
Speaker 1: are using a messaging app. Let's call the app x
Speaker 1: y Z, and x y Z has its server systems.
Speaker 1: When Alice wants to send Bob a message, she uses
Speaker 1: her own personal x y Z encryption key to do
Speaker 1: so and sends it along. No one else other than
Speaker 1: x y Z has that encryption key, so Alice and
Speaker 1: x y Z share it, but nobody else does. Her
Speaker 1: message will get to the server, which sees that Alice
Speaker 1: wants to send a message to Bob. So the service says,
Speaker 1: all right, I'll send this to Bob, except Bob can't
Speaker 1: read it because it's been encrypted with Alice's key, so
Speaker 1: Bob doesn't have Alice's key. So what the server then
Speaker 1: does will decrypt the message because it has Alice's key
Speaker 1: and it also has Bob's key, so it then re
Speaker 1: encrypts the message using Bob's key and then sends that
Speaker 1: along to Bob, so the message has been encrypted twice. Technically,
Speaker 1: it was encrypted, decrypted at the server level, encrypted again
Speaker 1: sent to Bob. Whenever the message is passing over the Internet,
Speaker 1: it is encrypted, which is pretty safe. But you may say, well,
Speaker 1: what about the time that it's spending on the server.
Speaker 1: That's the rub. See, this is not end to end encryption.
Speaker 1: I'll explain that a little bit later. The server is
Speaker 1: able to decrypt all incoming messages, no matter who is
Speaker 1: sending them, and then encrypt them with the respective keys
Speaker 1: belonging to whoever was the intended recipients. But this creates
Speaker 1: a few different problematic scenarios. One is that governments they
Speaker 1: love this strategy because it opens up the possibility that
Speaker 1: the server could release message is on a court order
Speaker 1: or some other means, Like if the government orders the
Speaker 1: service to share those messages and the services compelled to
Speaker 1: agree to it, then potentially the government could get hold
Speaker 1: of unencrypted plane text messages because at the server level
Speaker 1: everything gets unlocked. So the government agency can go to
Speaker 1: X Y Z and say, we suspect Alice and Bob
Speaker 1: are plotting something dangerous. We have some evidence, but we
Speaker 1: want access to the messages they're sending to each other.
Speaker 1: Lives could be at stake, and then they flash a
Speaker 1: Warren or something, and because X y Z is following
Speaker 1: this strategy, it could hand over such information if ordered to,
Speaker 1: revealing all the messages between Alice and Bob. And maybe
Speaker 1: Alice and Bob really were plotting something terrible and it's
Speaker 1: prevented as a result, or maybe they're just happy people
Speaker 1: and their private messages have now been compromised and they
Speaker 1: were completely innocent, and yet there otherwise private communication has
Speaker 1: now been made at least semi public. The strategy also
Speaker 1: creates an incredibly attractive target for hackers, obviously, because if
Speaker 1: you can compromise that central server, you can get at
Speaker 1: all the data that's going across it because it gets
Speaker 1: decrypted there. In fact, this has happened a few times
Speaker 1: in the past where hackers have managed to get access
Speaker 1: to such systems and mind them for data and dump
Speaker 1: all the information onto various places on the web, or
Speaker 1: more likely on the dark web. This is where stuff
Speaker 1: like credit card information or compromising photos can come into play,
Speaker 1: where hackers have managed to get into a server and
Speaker 1: and get all that information. Sure the messages were encrypted
Speaker 1: as they went over the Internet, but that one central
Speaker 1: point everything was unlocked and ready for exploitation and to
Speaker 1: end Encryption aims to defeat this by creating a strategy
Speaker 1: in which only Alice and Bob know how to decrypt
Speaker 1: messages from the other. They have a private means of
Speaker 1: decrypting information. The central server does not have access to
Speaker 1: that it decryption key, and so the messages sent across
Speaker 1: the server are meaningless to the server, is just gobbledygook.
Speaker 1: The server could confirm that messages had passed between Alice
Speaker 1: and Bob, you could say, well, yes, we know that
Speaker 1: the two have communicated with each other, but they the
Speaker 1: company wouldn't be able to speak to what was actually
Speaker 1: in those messages. So if a government agency served up
Speaker 1: a search warrant, all they would get is some garbled,
Speaker 1: seemingly random and meaningless data. They would need that private
Speaker 1: key to make any sense of it. Now, there are
Speaker 1: companies that absolutely love using the strategy because it really
Speaker 1: takes the heat off of them that not only are
Speaker 1: they able to offer their customers a secure way to communicate,
Speaker 1: there's no way for the company to know what sort
Speaker 1: of data is crossing its servers, so it cannot be
Speaker 1: complicit in anything illegal because it doesn't know what's happening.
Speaker 1: It provides a service one in which people may communicate
Speaker 1: with one another in a secure fashion, and that's it.
Speaker 1: But it raises a question how the heck are Alice
Speaker 1: and Bob is supposed to get a private key across
Speaker 1: to each other? Right? If Alice and Bob are apart
Speaker 1: from one another and their communication requires going through a
Speaker 1: centralized service, how do they establish a secret means of
Speaker 1: communication in the first place. If that first message is hey,
Speaker 1: let's use this secret code, but it's decrypted by the
Speaker 1: centralized server, then the centralized server knows the secret code,
Speaker 1: it doesn't help. Well. The answer comes down to what
Speaker 1: was called an asymmetric cryptographic algorithm that uses public key cryptography.
Speaker 1: And in this method, there are two keys that are
Speaker 1: used for each message. One of them is a public key,
Speaker 1: which is unique to each user that can be freely
Speaker 1: distributed across the internet. The other is a private key,
Speaker 1: which is a jealously guarded secret that allows only one
Speaker 1: entity the chance to decrypt information. I'll speak about more
Speaker 1: of this in just a minute, but first let's take
Speaker 1: a quick break to thank our sponsor. Alright, So how
Speaker 1: does public key cryptography work. Each person using the system,
Speaker 1: let's call it ABC. For this case, we're talking about
Speaker 1: different service from x y Z. Every single person using
Speaker 1: ABC gets too encryption keys, or well, one encryption key
Speaker 1: and one decryption key. Technically, one key is the person's
Speaker 1: private key, So Alice has a private key that's unique
Speaker 1: to her, and Bob has a private key it's unique
Speaker 1: to him. They they also each have a public key,
Speaker 1: so Alice has a public key, Bob has another public key.
Speaker 1: These are also unique to Alice and Bob, but those
Speaker 1: keys are published publicly on the service across the Internet.
Speaker 1: Anyone who wants to send an encrypted message to Alice
Speaker 1: or Bob must use their respective public keys. In other words,
Speaker 1: if I want to send Alice a message, I have
Speaker 1: to use Alice's public to encrypt it. To decode a message,
Speaker 1: you have to have the private key. So if you
Speaker 1: know both keys for a specific message, you can transform
Speaker 1: that garbled mess into meaningful communication. And because you keep
Speaker 1: your own private key to yourself, at least ideally, the
Speaker 1: only person who can decode messages meant for you is you.
Speaker 1: So Alice takes Bob's public key and uses it to
Speaker 1: encode her message to Bob. She then sends the encoded
Speaker 1: message to Bob across the messaging service. The encoded message
Speaker 1: passes through ABC's server, which cannot read the message because
Speaker 1: ABC does not have Bob's private key. Only Bob has
Speaker 1: that the message gets to Bob, he uses his private
Speaker 1: key and it decodes the message and then he can
Speaker 1: read it in plain text. But what is actually going
Speaker 1: on here? How is this happening? Well that that depends
Speaker 1: heavily on the specific cryptographic strategy used, But we can
Speaker 1: go with one of the earliest proposed methods of doing this,
Speaker 1: the RSA algorithm, the one I mentioned earlier that was
Speaker 1: proposed by the guys who used Alice and Bob as
Speaker 1: examples in the first place. This one relies on prime numbers,
Speaker 1: and just a quick refresher, a prime number is only
Speaker 1: equal to one times the prime number itself. There are
Speaker 1: no other multiple multiple factors. There are no other numbers
Speaker 1: you can multiply together to get the prime number. So
Speaker 1: if you can get to the value of a number
Speaker 1: by by multiplying any other two numbers, it's what we
Speaker 1: call a composite number. And is not a prime number.
Speaker 1: So the numbers one, two, and three are all prime numbers.
Speaker 1: They are only divisible by themselves and by one that
Speaker 1: there are no other factors, right That our whole numbers anyway,
Speaker 1: because the only multiplication you can do to arrive at
Speaker 1: them is one times one is one, one times two
Speaker 1: is two, and one times three is three, respectively. Four
Speaker 1: is the smallest composite number because you can multiply two
Speaker 1: times two to get four. So it's one times four
Speaker 1: is four and two times two is four. That means
Speaker 1: it is not a prime number. It's a posit number.
Speaker 1: So the number is only divisible by one or itself,
Speaker 1: then it's a prime number. The r s a algorithm
Speaker 1: takes two really really really big prime numbers, like hundreds
Speaker 1: of digits long. You might find systems that use a
Speaker 1: five twelve bit prime number, though a lot of security
Speaker 1: experts would say a thousand twenty four bit prime number
Speaker 1: would be better than It takes those two already huge numbers. Remember,
Speaker 1: it has to identify two different prime numbers that are
Speaker 1: enormous and then multiplies those two enormous prime numbers together
Speaker 1: to get a new number. This number is called the modulus.
Speaker 1: It then requires the calculation of the totient of that product.
Speaker 1: And this is where you say, wait a minute, hang on,
Speaker 1: what the heck is a totient? At least if you
Speaker 1: are like me, I was an English lit major, I
Speaker 1: never got to totients in my studies in math. But
Speaker 1: a totient is a number um that describes the number
Speaker 1: of integers smaller than a given number that are co
Speaker 1: prime with that number. Oh, that's a lot of numbers.
Speaker 1: Let me try that again. Let's say you've got a
Speaker 1: really big number, and the totient is all of the
Speaker 1: integers that are smaller than this really big number that
Speaker 1: are co prime with that really big number, which means
Speaker 1: they share no factors except one with that really big number.
Speaker 1: So let's use an example, because this sounds really really vague. Right.
Speaker 1: Let's say that we have the number fourteen. We we
Speaker 1: got to fourteen, uh, and we took prime numbers. We
Speaker 1: took the number two and the number seven and we
Speaker 1: multiplied those together. Those are our prime numbers we started with.
Speaker 1: So again, this is just an example. You would never
Speaker 1: use numbers this small. You multiply two times seven, you
Speaker 1: get fourteen. Fourteen is your modulus. Then you say what
Speaker 1: is the totient of fourteen? The answer is six, and
Speaker 1: here is why. First, you take all the integers that
Speaker 1: are less than four team, which is one through thirteen. Right,
Speaker 1: you can't use fourteen. You have to use all the
Speaker 1: ones that are all the whole numbers that are lower
Speaker 1: than fourteen, so one through thirteen. But the numbers also
Speaker 1: have to be co prime with fourteen. That means they
Speaker 1: cannot share any factors that fourteen has. Now, the factors
Speaker 1: of fourteen are two and seven, so we get those
Speaker 1: off the list those those get removed, So two and
Speaker 1: seven are gone. But you also have to eliminate the
Speaker 1: numbers four, six, eight, ten, and twelve. All of those
Speaker 1: numbers have two as a factor, and fourteen also has
Speaker 1: two as a factor, so those numbers are not co prime,
Speaker 1: so you strike those. Once you've gotten rid of those,
Speaker 1: the numbers you have left that are lower than fourteen
Speaker 1: are one, three, five, nine, eleven, and thirteen. Now nine
Speaker 1: is not a prime number, right, You can multiply three
Speaker 1: times three and get nine, but it is co prime
Speaker 1: with fourteen because the two numbers share no common factor
Speaker 1: except for the number one. So when you count up
Speaker 1: all the co primes that are left. After you've eliminated
Speaker 1: the numbers that are not co primes, you find out
Speaker 1: you've got six numbers total one, three, five, nteen. That's
Speaker 1: six numbers. So the totient for fourteen is six. By
Speaker 1: the way, there's actually a formula for calculating the totent
Speaker 1: of your huge number that's really really easy. And what
Speaker 1: you do is you take your first prime number, the
Speaker 1: one that you want. You know, in our case we
Speaker 1: use two and seven. Let's say you take your first
Speaker 1: prime number, you subtract one from that. You take your
Speaker 1: second big prime number, you subtract one from that, and
Speaker 1: you multiply those two new numbers together, and that is
Speaker 1: your totent. So in our example, we take our two
Speaker 1: prime numbers of two and seven, we subtract one from each.
Speaker 1: That means we have a one and a six. We
Speaker 1: multiply these two new numbers together one time, six is six.
Speaker 1: That's the totent for fourteen. It's the fastest way to
Speaker 1: calculate the totent. Next, because we're not done yet, you
Speaker 1: have to select an integer, but not just any integer.
Speaker 1: The integer you select has to be larger than the
Speaker 1: number one, but smaller than the totient of your big
Speaker 1: old number that you generated earlier by multiplying those two
Speaker 1: prime numbers together and then taking the totient from it.
Speaker 1: In fact, it has to be a co prime with
Speaker 1: the totient and the modulus itself, so it cannot share
Speaker 1: a factor with the totient or with the modulus. So again,
Speaker 1: in my example, where I had fourteen as our modulus,
Speaker 1: the totient was six, we need an integer between one
Speaker 1: and six that is co prime with both six and fourteen.
Speaker 1: So we cannot use one because the number has to
Speaker 1: be bigger than one. We can't use two or three
Speaker 1: or four because all of those share factors with six. Right,
Speaker 1: it has to be co prime, so you cannot use those.
Speaker 1: The only number available to us is five. This becomes
Speaker 1: our encryption key. Figuring out the decryption key is a
Speaker 1: little more complicated, and that's probably making some of you
Speaker 1: scratch your heads, because what I just went through is
Speaker 1: fairly complicated for those of us who are not very
Speaker 1: mathematically inclined. I include myself in that number. By the way,
Speaker 1: the prime number we arrived at for the encryption key
Speaker 1: has the greatest common divisor or g c D of
Speaker 1: one with the totient of that number. So we take
Speaker 1: the multiplicative inverse of this number with respect to the
Speaker 1: totient using the extended Euclidean algorithm. Yeah, I get super
Speaker 1: duper complicated, and I'm pretty sure I can't explain it,
Speaker 1: especially not in audio alone, so the well will skip ahead.
Speaker 1: You just imagine you do some more complicated math and
Speaker 1: you denote this result with the letter D, and that
Speaker 1: represents the private key. Now. I use the prime numbers
Speaker 1: two and seven in my example only because they were
Speaker 1: easy to work with, But that's precisely why no one
Speaker 1: in the right mind would ever use those to encrypt anything.
Speaker 1: You want to have a pretty large number to work with,
Speaker 1: and even your public key should be pretty big. A
Speaker 1: standard public key is sixty five thousand, five seven, which
Speaker 1: is a prime number, and as long as it has
Speaker 1: no common factors with the modulus, you're good to go.
Speaker 1: And the only way it could have a common factor
Speaker 1: with a modulus is if it was itself a factor
Speaker 1: of your big number, but that's not likely to happen.
Speaker 1: So you want a big key, but you don't want
Speaker 1: it to be too big, and the reason for that
Speaker 1: is encryption is more efficient if you're using smaller numbers
Speaker 1: as your keys. Remember, like essentially encryption involves doing lots
Speaker 1: of math problems. The bigger the numbers are for your
Speaker 1: math problems, the bigger the results are going to be,
Speaker 1: and the larger it's going to make your message. So
Speaker 1: if you're trying to encrypt a very long message to someone,
Speaker 1: then ends up being a much larger amount of data,
Speaker 1: like sometimes several times larger than the original amount of data.
Speaker 1: And if you get too big, you may not even
Speaker 1: be able to send it if the service you're using
Speaker 1: has a limit on the size of messages. So if
Speaker 1: you go too big, it gets inefficient and clunky and
Speaker 1: sometimes too big for you to even hand. But if
Speaker 1: you go too small, you risk the possibility of someone
Speaker 1: being able to suss out the private key given enough
Speaker 1: time and processing powers, So it's a balancing act. One
Speaker 1: thing you could do to make things move more quickly
Speaker 1: is to use this public and private key approach to
Speaker 1: establish a new encryption key between the two communicators. This
Speaker 1: would be called a session key. So Alice would send
Speaker 1: Bob a message, she would use Bob's public encryption key
Speaker 1: that's and she would encrypt a message that says, hey,
Speaker 1: got a second and she sends it to Bob, and
Speaker 1: Bob receives the message. He uses his private key, he
Speaker 1: decodes the message and sends a message back to Alice
Speaker 1: using her public encryption key that says, sure I do.
Speaker 1: And here's a brand new private key that we can
Speaker 1: use for each other for the purposes of this conversation session.
Speaker 1: And then Alice would decrypt this message, and they would
Speaker 1: each have a private key that they could use to
Speaker 1: each other, a symmetric key. All subsequent messages between Bob
Speaker 1: and Alice would use this new private encryption methodology. And
Speaker 1: we call this symmetric because you're using the same key
Speaker 1: to encrypt and decrypt and UH. Otherwise, you wouldn't be
Speaker 1: able to send this to each other because it would
Speaker 1: be public information and everyone would have a copy of
Speaker 1: the key. Using the public private key message to first
Speaker 1: send this is clever because the first message, anyone could
Speaker 1: intercept it, but they're not gonna know what's in it.
Speaker 1: And then all subsequent messages would be using a totally
Speaker 1: different UH encryption methodology. So even if someone were to
Speaker 1: monitor this communication, the communications they would see would be
Speaker 1: encrypted in different ways, and that would make it practically
Speaker 1: impossible to figure out what was going on. You could
Speaker 1: even go a step further and have a new key
Speaker 1: generated with essentially every single message, so it's essentially a
Speaker 1: one ahead. Each message gets a new key to be
Speaker 1: encrypted by, and since it keeps changing each time someone
Speaker 1: sends a message, like Bob sends Alice a new message
Speaker 1: and says uh uh secret, secret, secret, brand new key,
Speaker 1: Alice uses the brand new key to part her message
Speaker 1: in too, Bob, and it says more secrets, more secrets,
Speaker 1: more secrets, new, brand new key. Bob uses the uh
Speaker 1: the the key from one session earlier to unlock Alice's
Speaker 1: message reads it then uses the brand new key to
Speaker 1: send the next message. You could keep doing this forever.
Speaker 1: You could keep sending a brand new key with every
Speaker 1: single message, and it would make your communications very secure.
Speaker 1: It would be a little slow because you would have
Speaker 1: to do this decryption encryption thing every single step, and
Speaker 1: you wouldn't be able to repeat the steps because they'll
Speaker 1: be using a new key every time, but it would
Speaker 1: be really secure, and in fact, there are some messaging
Speaker 1: apps that use this kind of methodology. So the really
Speaker 1: big benefit of symmetric encryption is that. Well, one, it's
Speaker 1: faster than using public and private key approach, but another
Speaker 1: is that limits the number of times that you use
Speaker 1: the public key, and that can be a good thing. Now,
Speaker 1: it's not easy with today's computers, but at least there
Speaker 1: it's at least theoretically possible that hackers could suss out
Speaker 1: a public encryption key and work backward to figure out
Speaker 1: the private encryption key. It's a non trivial problem. It
Speaker 1: requires a ton of computer processing power, and it's not
Speaker 1: likely to happen if you're using really secure encryption. But
Speaker 1: the more frequently use the same public key, the more
Speaker 1: data hackers have to work with, and they can start
Speaker 1: looking for patterns. Patterns are the bane of encryption. When
Speaker 1: you have patterns, then you can start to establish rules.
Speaker 1: And when you start to establish rules, you can start
Speaker 1: working backward and figuring out what generates those rules, and
Speaker 1: eventually you figure out the methodology for encoding the information.
Speaker 1: So you don't want to have patterns in your encoded information.
Speaker 1: If possible, if you keep using the public private key
Speaker 1: method and it's all you're using, then hackers eventually can
Speaker 1: gather enough information that if they have a sufficiently powerful
Speaker 1: computer and enough time on their hands, they can decrypt it. Uh.
Speaker 1: That if is a big one though, because if you're
Speaker 1: using pretty strong encryption, it would take weeks or months
Speaker 1: or more likely years to decrypt the messages. Now, in
Speaker 1: a recent episode, I talked about quantum computers. With a
Speaker 1: classical computer, like I said, figuring out prime numbers for
Speaker 1: a really large number takes an incredibly long time. Depending
Speaker 1: on the size of the number, it could take like
Speaker 1: I said, years for a classical computer to sort it out.
Speaker 1: But a quantum computer, if it's sufficiently powerful, could solve
Speaker 1: those problems much more quickly using a process called Shore's algorithm.
Speaker 1: So if you have a quantum computer with a sufficient
Speaker 1: number of cubits, you could crack this type of encryption
Speaker 1: relatively quickly and pretty reliably. So it's therefore imperative to
Speaker 1: look at new methods of encrypt in order to avoid
Speaker 1: a situation in which the first really powerful quantum computer
Speaker 1: effectively gets a skeleton key to all encrypted messages that
Speaker 1: have been sent across the Internet. Now, let's talk a
Speaker 1: second about the history of end to end encryption, and
Speaker 1: then a bit more about the apps and services that
Speaker 1: use it and some that do not use it. In nine, Whitfield,
Speaker 1: Diffy and Martin Hellman proposed the concept of using public
Speaker 1: and private key combinations in order to distribute symmetric encryption keys.
Speaker 1: It's possible they weren't the first to consider this too.
Speaker 1: There's been some evidence to suggest the British Secret Service
Speaker 1: had come up with a similar approach but never really
Speaker 1: did anything with it. Their idea was the basis not
Speaker 1: just for the r s A algorithm, but a few
Speaker 1: others as well, like the el Camal crypto system, which
Speaker 1: was named after Tahir el Camal, or the d s
Speaker 1: A system also known as the Digital Signature algorithm, invented
Speaker 1: by a guy named David Kravitz, as well as the
Speaker 1: Diffie Hellman cryptosystem, which obviously was created by Whitfield, Diffie
Speaker 1: and Martin Hellman. Then along came p g P, which
Speaker 1: stands for Pretty Good Privacy. The cryptosystem is a hybrid system.
Speaker 1: It was proposed by Phil Zimmerman in n Zimmerman graduated
Speaker 1: from Florida Atlantic University with a degree in computer science,
Speaker 1: and he was active in a project called the Freeze,
Speaker 1: also known as the Nuclear Weapons Freeze campaign. The purpose
Speaker 1: of this organization was to try and curtail nuclear arms
Speaker 1: production in an effort to de escalate mounting global tensions
Speaker 1: and to remove a A an existential threat to the
Speaker 1: human race, and Zimmerman created p g P to allow
Speaker 1: for secure email communications among various parties to make their
Speaker 1: efforts more effective and less likely to get snooped on. Now,
Speaker 1: when you use p g P, the first thing it
Speaker 1: does is it takes your plain text message and impresses it,
Speaker 1: and so it makes it smaller, which is one benefit,
Speaker 1: but it also helps to make it more secure because
Speaker 1: it reduces patterns that might otherwise be useful to hackers
Speaker 1: who want to decrypt messages. It also generates a session key,
Speaker 1: that's that symmetric encryption key I was just talking about
Speaker 1: that would be used throughout the length of any particular
Speaker 1: communication session. The way PGP does this is pretty cool.
Speaker 1: It actually generates the data for the session key based
Speaker 1: on your mouse movements and key strokes you've typed, so
Speaker 1: it's based upon physical interactions you've had with your computer,
Speaker 1: not with any other just random prime number. All of this,
Speaker 1: the compressed plane text message and the unique session key
Speaker 1: generated from your physical interactions with your computer then get
Speaker 1: encoded using this public private key strategy. If Alice sends
Speaker 1: a message using PGP too Bob, first, Alice's computer will
Speaker 1: compress your message, it will append a session key based
Speaker 1: on Alice's typing and mouse movements, and then encrypt all
Speaker 1: of that mess using Bob's public key. Then the message
Speaker 1: travels to Bob. Bob uses his private key to decode
Speaker 1: the message and he can see the session key Alice
Speaker 1: has set up and then use that to communicate back
Speaker 1: with her securely for the rest of the session. Zimmerman's
Speaker 1: p GP was more than just pretty good. It was
Speaker 1: actually a brilliant approach to encryption. It became adopted by
Speaker 1: many organizations and people across the United States and then
Speaker 1: the world, and that caused a huge amount of trouble
Speaker 1: for Zimmerman. For one thing, r s A Security wished
Speaker 1: to question Zimmerman about the use of the r s
Speaker 1: A algorithm within p GP. There was some disputes about
Speaker 1: the licensing. Then the United States Custom Services decided to
Speaker 1: investigate Zimmerman because of the distribution of p GP beyond
Speaker 1: the US borders. Because in the United States there was
Speaker 1: the Arms Control Act and it listed cryptographics software as
Speaker 1: a type of munitions, which would mean if Zimmerman had
Speaker 1: allowed his work to go outside the US, he would
Speaker 1: be in very big trouble because it was similar to
Speaker 1: shipping prohibited weapons outside the country. And if you think
Speaker 1: that sounds a little crazy that software could be considered
Speaker 1: a weapon, Welcome to the twenty first century. Zimmerman was
Speaker 1: never officially charged with any crime, but the investigation did
Speaker 1: last several years. Eventually, the courts determined that p GP
Speaker 1: did not fall into a category that would be considered munitions,
Speaker 1: and today his PGP technology is the property of the
Speaker 1: security firm Symantec, which purchased the PGP Corporation back in
Speaker 1: Now I've got a little bit more I want to
Speaker 1: say about end to end encryption, but before I get
Speaker 1: to that, let's take another quick break to thank our sponsor.
Speaker 1: So the PGP strategy also allows for digital signatures, which
Speaker 1: are a way for you to make sure the message
Speaker 1: being sent to you hasn't been intercepted and altered in
Speaker 1: any way. Plus you can be sure that the message
Speaker 1: came from the person it claims to have come from.
Speaker 1: Digital signatures and p g P use what is called
Speaker 1: a one way hash function. The implementation p g P
Speaker 1: uses is to take the message, which can be of
Speaker 1: any length. So let's say it's a really really long message.
Speaker 1: Then it does a mathematical process on it to arrive
Speaker 1: at a fixed length output, such as one sixty bits.
Speaker 1: So the one sixty bits does not contain the entire message.
Speaker 1: It represents the entire message. It's fine distinction. It doesn't
Speaker 1: matter how long that original message was. The goal is
Speaker 1: to create this shorter hash that speeds things up. It
Speaker 1: doesn't make file sizes balloon from the encryption process. The
Speaker 1: hash function depends entirely on the message itself, So if
Speaker 1: someone were to change even one single bit as in one,
Speaker 1: zero or one of information in that message, the hash
Speaker 1: value would also change because it depends upon the nature
Speaker 1: of the rest of the message. So if you send
Speaker 1: a message to someone and they know what the hash
Speaker 1: value is supposed to be, they can verify that the
Speaker 1: associated message was never altered. So they've got essentially the
Speaker 1: the hash value it's supposed to be and the hash
Speaker 1: value it actually is. If those two numbers are different,
Speaker 1: then they know that something has happened to the message
Speaker 1: in transit. The way PGP does this is to generate
Speaker 1: a hash called the message digest. It uses the message
Speaker 1: digest and the private key to create a signature. Then
Speaker 1: p GP sends the plain text in signature together to
Speaker 1: the recipient. The recipient uses PGP to recompute the message
Speaker 1: digest to verify it is from the supposed center and
Speaker 1: then it hasn't been altered. And if the recomputed message
Speaker 1: digest is the same as the original that was in
Speaker 1: the message, everything's good. If the recomputed one is not
Speaker 1: the same, then something has happened, and you know that
Speaker 1: the the trail between the two has been compromised in
Speaker 1: some way. By the way, this does not reveal the
Speaker 1: private key to the other person. The private key remains
Speaker 1: private um P. G P is able to protect that,
Speaker 1: which is kind of cool. Alright. So who uses end
Speaker 1: to end encryption and who does not? Well? Among the
Speaker 1: messaging apps that use end to end encryption, there is
Speaker 1: the Big Daddy What's App. That's an incredibly popular messaging app.
Speaker 1: It is owned by Facebook. Now what didn't start off
Speaker 1: as a Facebook project. It was purchased by Facebook. The
Speaker 1: original messaging app was co founded by Jan Kom who
Speaker 1: grew up in the Ukraine. And wanted to create a
Speaker 1: way in which people could send messages safely without the
Speaker 1: fear of an oppressive presence, like a totalitarian government agency,
Speaker 1: for example, that could read all of them. Now, he
Speaker 1: had moved to America when he was sixteen, and years
Speaker 1: later he met with a guy named Brian Acton and
Speaker 1: Acting became the other co founder of WhatsApp. They created
Speaker 1: the messaging service, and they used end to end encryption
Speaker 1: to protect users privacy. When Faceboo Public purchased WhatsApp rather,
Speaker 1: many security experts express concern because they were worried that
Speaker 1: Facebook might chip away at the messaging apps security and
Speaker 1: allow Facebook the chance to mind these messages and then
Speaker 1: sell that data to advertisers, and there have been accusations
Speaker 1: levied at Facebook claiming as much. To Bias Bolter, a
Speaker 1: security researcher, told reporters at The Guardian that Facebook had
Speaker 1: the ability to generate new encryption keys for offline users
Speaker 1: and thus access messages that would be sent to them.
Speaker 1: Whether that's true or not, I don't know. Facebook has
Speaker 1: denied that they have the ability to read any messages
Speaker 1: from their users, but there's still a lot of concern
Speaker 1: about WhatsApp in general. Another app that uses end to
Speaker 1: end encryption is Signal. Signal started out as text secure
Speaker 1: private messenger, and you can also use Signal to make
Speaker 1: encrypted voice and video calls to other users. These follow
Speaker 1: a similar approach to messages and email els um. They
Speaker 1: protocols are obviously a little different because they're different media
Speaker 1: or different forms of messaging, but the general principle remains
Speaker 1: the same, the idea that all the information being sent
Speaker 1: across these channels is encrypted all the way until it
Speaker 1: gets to the destination device. Whire is a another popular app,
Speaker 1: particularly in countries belonging to the European Union. It's also
Speaker 1: free and open source. The app does store a record
Speaker 1: of the people you've communicated with. That's a little problematic
Speaker 1: from a security standpoint. Now, the purpose of storing this
Speaker 1: information is to make it easier to synchronize and experience
Speaker 1: across devices, because one of the big drawbacks of the
Speaker 1: public private key approach is that ideally you have that
Speaker 1: private key on one and only one device. If you
Speaker 1: share a private key across multiple devices, then you have
Speaker 1: increased the possibility of someone getting access to your private key.
Speaker 1: But if you lose the device pace that the private
Speaker 1: key is on, you lose all your messaging history as well,
Speaker 1: because remember, no one else can see what that encrypted
Speaker 1: stuff is because it all used your public key that
Speaker 1: could only be decoded by your private key. So if
Speaker 1: you lose your private key, all you have is gobbledygook.
Speaker 1: You can't read it. That is, of course, if if
Speaker 1: you haven't been storing messages in some other fashion, uh
Speaker 1: like in plain text some services, you could, as a
Speaker 1: user opt to store your messages using a third party application.
Speaker 1: This would be like you receive the message, you decrypt
Speaker 1: the message when you receive it, you have the message
Speaker 1: in plain text because you have to in order to
Speaker 1: read it or or view it or whatever it may be.
Speaker 1: And then you decide you want to save that message. Well,
Speaker 1: when you're saving that message, you may be saving that
Speaker 1: in plain text using a third party app, in which
Speaker 1: case all that secrecy for the communication is undone by
Speaker 1: your storage. It becomes a security vulnerabile. So you could
Speaker 1: be super careful about messages as they speed to and
Speaker 1: from your device, But if you're then storing everything on
Speaker 1: a cloud server somewhere, you could still technically be allowing
Speaker 1: some other company access to that information. After the fact,
Speaker 1: but if you don't do that, if you lose your phone,
Speaker 1: then you could lose all those messages, all the histories,
Speaker 1: all the communications, So it's a tough situation. Also, by
Speaker 1: the way, this means that the hackers will sometimes concentrate
Speaker 1: not on trying to intercept a message in the middle,
Speaker 1: because if it's encrypted, it could be more trouble than
Speaker 1: what it's worth to try and decrypt it. Or instead
Speaker 1: of doing that, they'll they'll try and target the end device.
Speaker 1: So in other words, they're actually trying to get physical
Speaker 1: access to your computer or phone or somehow be able
Speaker 1: to look at your screen remotely once the decryption process
Speaker 1: has happened, So they want to compromise your device at
Speaker 1: that point because it's relatively easier than trying to do
Speaker 1: crypt one of these heavily encrypted messages on the Internet. Anyway,
Speaker 1: Wire has said that a user once a user deactivates
Speaker 1: deletes his or her account, then the service deletes all
Speaker 1: the associated information with that account, all the stored connections,
Speaker 1: everything is gone once you delete your account with Wire,
Speaker 1: according to the service, there's also a multi platform app
Speaker 1: that's popular that's called Telegram. Telegram, you can search for
Speaker 1: people by user name rather than by phone number. A
Speaker 1: lot of apps require that you know the phone number
Speaker 1: of the person you're trying to contact, but Telegram, when
Speaker 1: you create a profile, in addition to creating a profile
Speaker 1: based on a telephone number, you can create a user name,
Speaker 1: and so people can search for you on that. It
Speaker 1: makes it a little easier to communicate with people. There's
Speaker 1: also another app called wicker w i c k R,
Speaker 1: which is really popular in enterprises, so in business, not
Speaker 1: necessarily as much with individual users. But as for email,
Speaker 1: their services like tour Guard, Hushmail, Mail, fence to to,
Speaker 1: Not to run Box, proton Mail, all of these use
Speaker 1: various encryption strategies to keep messages safe. Not all of
Speaker 1: them necessarily use end to end encryption, some of them
Speaker 1: use other methods for encryption than in too end, but
Speaker 1: they all do some form of encryption on their messages,
Speaker 1: whereas popular email services like Gmail do not support end
Speaker 1: to end encryption, and one reason they might not I
Speaker 1: can't say this is for sure sure, but one reason
Speaker 1: they may not do that is that it's possible that
Speaker 1: they want to mine all that information for the possibility
Speaker 1: of advertising against it. So in other words, you send
Speaker 1: a message. Alison's a message to Bob, Alice talks about
Speaker 1: all these nice flowers that she saw on a recent trip.
Speaker 1: And then Alice starts seeing ads mysteriously whenever she's using
Speaker 1: a Google service that is talking about flowers. Well, that
Speaker 1: raises some very tricky ethical questions. Now, whether or not
Speaker 1: that's actually going on, that's a that's a matter of
Speaker 1: investigation on a case by case basis. You know, not
Speaker 1: all emails are necessarily being mined for information, but they
Speaker 1: all could be if they're not being encrypted end to end.
Speaker 1: So there are a lot of advocates for privacy out
Speaker 1: there who some of them will say, Hey, don't even
Speaker 1: bother sending me any email if it's not encrypted. I'm
Speaker 1: not interested you. If you're not using an encryption service
Speaker 1: of some sort, then I do not want to communicate
Speaker 1: with you because I prefer to keep my privacy private.
Speaker 1: And that's a legitimate argument, I think. I don't think
Speaker 1: it's not necessarily the indication that someone is up to something,
Speaker 1: you know, suspicious, But it's important to remember that without
Speaker 1: that end to end encryption, it is a possibility that
Speaker 1: someone along the way is reading your messages. Besides the
Speaker 1: person you're sending them too. I would like to thank
Speaker 1: our anonymous listener for asking for us to cover this topic.
Speaker 1: It is very fascinating. In the UK in particular, this
Speaker 1: is an ongoing issue where the UK government would love
Speaker 1: to see end to end encryption go away because they
Speaker 1: worry that it's a methodology of UH, that that terrorists
Speaker 1: are using to communicate with one another, and that this
Speaker 1: creates a problem because you can't really investigate those terrorists
Speaker 1: cells at least not through the means of their communication,
Speaker 1: because you can't decrypt it. There have been people who
Speaker 1: have called for a back door of some sort to
Speaker 1: end to end encryption services, which defeats the purpose. Backdoor
Speaker 1: is essentially a vulnerability you introduce on purpose so that
Speaker 1: a party apart from the intended recipient can decode a message,
Speaker 1: and that that raises enormous security problems. Like you don't
Speaker 1: create a backdoor because that means you're introducing the possibility
Speaker 1: of a hacker getting access to this information. You don't
Speaker 1: want to do that. That's that's bad security. So there,
Speaker 1: that's not a great UH strategy moving forward. Is trying
Speaker 1: to force services to create a backdoor. It pretty much
Speaker 1: breaks the whole service in the first place. So I
Speaker 1: don't know what the solution here is. I don't think
Speaker 1: that that getting rid of a technology because some people
Speaker 1: use it improperly is necessarily going to work. Um that
Speaker 1: is uh, it is, it is. It raises a lot
Speaker 1: of questions, and it also means that you have to
Speaker 1: put an awful lot of trust in the governing agency,
Speaker 1: and that can be difficult to do. And also, any
Speaker 1: time you have a back door, anytime you have any
Speaker 1: sort of vulnerability, if people know it exists, then you've
Speaker 1: just given hackers a target to shoot for. And even
Speaker 1: if it works as it's supposed to, where everyone is
Speaker 1: behaving themselves from the good guys standpoint, let's say that
Speaker 1: the government is a good guy in this. In this
Speaker 1: scenario that both Alice and Bob are behaving themselves, the
Speaker 1: government is behaving itself. It's not investigating Alison Bob. It
Speaker 1: has no reason to suspect them. So they're able to
Speaker 1: send their messages securely. But there is this back door
Speaker 1: option that is available, then hackers could target that and
Speaker 1: then they compromise the system, and then Alice and Bob's
Speaker 1: messages are laid bare for the hackers because you've just
Speaker 1: painted a huge target on the service. It's not great,
Speaker 1: and not every end to end encryption service is infallible. Uh.
Speaker 1: There have been security experts who have accused Apple in
Speaker 1: particular of implementing a poor end to end encryption strategy
Speaker 1: for their Eye Message app and have stated that there
Speaker 1: are ways that that could be defeated using classical computer systems.
Speaker 1: So it is possible to do this in a way
Speaker 1: that isn't effective, but the actual idea itself is incredibly
Speaker 1: effective if you implement it properly and you're using classical
Speaker 1: computers as your potential threat. Once quantum computers actually become
Speaker 1: on part of the scene for real z s, when
Speaker 1: they're sufficiently powerful, it'll be a totally different story because
Speaker 1: a sufficiently powerful quantum computer will completely lay bare all
Speaker 1: these encryption schemes, So you have to come up with
Speaker 1: something new. But I talked a little bit about that
Speaker 1: in one of the IBM Think episodes, so you can
Speaker 1: go back and listen to that if you want to
Speaker 1: learn more. As for you, guys, if you have any
Speaker 1: suggestions for future episodes of Tech Stuff, I I welcome
Speaker 1: you to send those suggestions to me. You can email
Speaker 1: the show that addresses tech stuff at how stuff Works
Speaker 1: dot com, or you can drop me a line on
Speaker 1: Twitter or Facebook. The handle at both of those is
Speaker 1: tech stuff hs W. Remember to follow us on Instagram,
Speaker 1: and remember typically I record these episodes live on twitch
Speaker 1: dot tv slash tech stuff on Wednesdays and Fridays. This
Speaker 1: particular episode I'm recording right now was an exception because
Speaker 1: again I'm in a hotel, a music hotel WiFi, which
Speaker 1: is not the greatest thing to use for streaming, but
Speaker 1: usually I stream live from the studio on Wednesdays and Fridays.
Speaker 1: Go to Twitch dot tv slash tech Stuff. You'll see
Speaker 1: the schedule there. I hope to see you in the
Speaker 1: chat room and you can chat with me as I'm recording.
Speaker 1: You can have a grand old time and I'll talk
Speaker 1: to you again really soon. For more on this and
Speaker 1: bathands of other topics. Is that how stuff Works dot com.