An Encryption Deep Dive - Part One

Chris Hickman and Jon Christensen of Kelsus and Rich Staats of Secret Stache begin a series of episodes focused on encryption - starting with the essentials. 

Some of the highlights of the show include:

Encryption: Everybody depends on it, but most don’t understand itTransmitting sensitive information, such as credit card and social security numbers, via the Internet is taken for grantedKey to Encryption: Plain text converted to ciphertext (no resemblance to original)Encrypt Everything: Most major browsers requiring Web traffic over secure port What’s the difference? End-to-end vs.at rest and in transit encryption Encryption Types: Hashing (one-way function) and Salting (added secret to hashed) Encryption Methods: Symmetric and asymmetric (public) keys, including DES, TripleDES, Blowfish, and TLS I am who I say I am: Trust, identify, share, and sign

Reddit

Encryption Deep Dive Part One

Links and Resources

ZooPix

To Salt or Not To Salt? Salting is not the only answer to securing passwords

Slack

WhatsApp

Werner Vogels of AWS

Blockchain

Bitcoin

Encryption Algorithms

Kelsus

Secret Stache Media

Transcription

Rich: In episode 73 of Mobycast, we start a new series on encryption and dive into the essentials. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. Let’s jump right in.

Jon: Welcome, Chris and Rich. It’s another episode of Mobycast.

Rich: Hey, it’s good to be back.

Jon: Yeah. Good to have you back. Chris, what have you been up to this week?

Chris: As I’ve mentioned several times on the podcast, I’m a cycling nut. 

Jon: No spoilers, please. I’m a couple days behind.

Chris: Come on. Okay, fine. So be it. Let me just say, it will not disappoint as far as drama. We’ll put it that way. It’s amazing the last few days. 

Jon: I’m almost done with [...]. They’re about to start up the [...].

Chris: July is definitely the month of Tour de France. My wife is equally a cycling nut following the pro peloton. During July, we joke that our kids become tour orphans. It’s quite a bit of commitment. It’s 4–5 hours of coverage everyday. We’re done except we’re actually behind on the final stage, on the [...].

By the way, we subscribed to DIRECTV to watch this, this year. You just do it all over the intertubes, don’t have to have cable installed or get a satellite dish, but the software is just absolutely horrible. They say it’s in beta but it was in beta last year when we got it. It’s just often terrible. We’ve had so many snafus this month. We’re trying to record it and it drops in recording and not recording things.

NBCSN for some reason on yesterday’s stage, the last stage is they decided to switch channels midway through. We said we’re DVR, right? We’re watching it. We think we have the whole stage and then, no, it’s missing the last hour. They’re like, “Alert, switch over to NBC to see the rest of it.” But we gave you [...]

Jon: That’s so terrible. It’s only available on [...] probably because a lot of DIRECTV developers are in Denver and there’s a new shiny thing in town for them to go work for named Slack. 

Chris: We’re done with it. I am cancelling today.

Jon: How about you, Rich? What are you up to?

Rich: We’ve been busier than we’ve ever been. The idea of project portfolio management is becoming pretty important. I really didn’t know what that was until a couple of months ago. It’s like the birds eye of a few of all projects. The idea of using Gantt charts and trying to figure out how you can jigsaw puzzle human resources so that you can layer projects in creative ways so you can get more done.

Trying to figure that out, which has been challenging since I don’t have any experience with project management, so I’m learning as I go. We’re not at a point where it’s already a problem. I’m doing this ahead of time, but nonetheless, it’s challenging to put that out on and be effective when you don’t know what you’re doing.

Jon: Yeah. You’re not talking a little bit about it and I’m excited to see your journey. 

Rich: Yeah.

Jon: I have a quick story to you. I had to get a new file cabinet. I had bought one on Amazon which don’t do it because I spent $250 and some freight company came and dump it like it’s a totally dented piece of trash on my lawn. I had it sit there for another month while waiting for the freight company to come back and get it. Do not do that.

Chris: You can take it to Whole Foods. 

Jon: Yeah. Simply drive over to Mount Pass to get to Whole Foods. Anyway, yesterday I saw one on classifieds. It was $75, I went down there, and I met the guy in this fancy neighborhood called [...] to pick it up and I was like, “This really seems like a good deal.” He’s at his driveway, I walk up to it proprietarily looking like, “Oh yeah, I’m definitely going to buy this.” Opening drawers and he’s like, “I don’t know why my wife put this up for sale. I asked her and she said, ‘Well, it doesn’t have any files in it.’” I was like, “But you’re putting it up for $75?” and he goes, “That things costs $1300.” I was like, “Oh, maybe I should be a little bit more polite and thankful and not just like, ‘Yup, I’m taking it.’”

Chris: Was it plated in 18 karat gold?

Jon: It’s pretty fancy. Honestly, it’s all wood, file cabinet is pretty fancy. I’m excited, I just got to move in to my office. But that’s not what we’re going to talk today. Let’s talk about encryption. Everybody depends on it, everybody talks about it all the time, and it’s one of those things that is not very well-understood.

I was having a conversation with one of our clients over ZooPix the other day, trying to talk about implementing a new direct messaging feature and we want to make sure it’s really lock down. We’re talking about the difference between end-to-end encryption, making sure things are encrypted at rest and in transit, and it was quite explained. There was a lot to talk about and make sure that my client who’s not a developer, who’s a business person, was able to understand and make a decision because it affects his budget and the company’s budget, and they want to spend their budget wisely.

The people listening to the podcast, you probably know a bit more about encryption maybe than my client, but there’s so much to it and it’s so fascinating that we should get into it and talk a little more in detail. You want to kick us off, Chris?

Chris: Yeah. Absolutely. Encryption is one of those things we take for granted. It’s there, it underpins so many things that we use like the web, things like https. It’s pretty important whenever we’re transmitting anything that’s sensitive information whether be credit card information, or security numbers⁠ or whatnot. Encryption definitely is important.

We know it needs to happen. It’s a little bit of a black box for most people. How does it really work? What are the different types of encryption? That’s what we’re going to talk about today. This is going to be a multipart episodes on encryption.

To start off, we’re going to talk about the essentials of the encryption. What is it? What does it mean? Encryption interest versus transit, the major types of encryption, and how they work. Hopefully, it’s going to be pretty interesting and fill in some of the gaps that folks have out there like what is encryption? How does it work? Which types should I use?

Jon: When I was in college, I remember there were a demand among my peers and our computer science classes, there’s a demand. Everybody was interested in it. I can’t remember which class it was where I was introduced. I remember John Regor, the professor was the one that taught us. He taught us public key encryption and how it worked. I remember he said stuff like, “Do not share what I’m putting in this board with anyone because I’ve just written down something that would be illegal if you’re going to share it with certain other people.” We’re like, “Woah. This is cool.” The reason was because it’s got this reputation of being hardcore. When you’re dealing encryption, that’s when you started to get hardcore with computer programming. Would you agree, Chris?

Chris: What I would agree is the actual cryptographic algorithms are intensely hardcore. It is a method, it is purist, and it’s incredibly complex. It is very, very difficult. You’re trying to come up with an algorithm that is going to be very, very difficult to reverse engineer, to crack. Given how fast computers are evolving, things like Moore’s law and transaction, how many operations per second computers can do, it’s up to the algorithms to become more complicated and to have more entropy in them. There are slight changes in data and you want your cryptographic algorithms to have big changes on the output. You don’t want to be able to climb patterns in it. Having a really good strong cryptographic algorithm is very hardcore. You need the PhD and math and teams of people.

This is like a weapon [...]. Governments put lots and lots of millions and millions of dollars behind this stuff. The good thing is we don’t have to. The normal people using encryption don’t have to know the exact details and the proofs behind them. We can pop up a level or two.

Jon: it maybe instructive especially for anybody that’s newer listening. I remember seeing an NSA catalog in the computer science office at my college. If I had seen that thing before I learned the cryptographic algorithms, I might have been like, “Cool. NSA’s super cool cryptography. Yes, I want that,” and I might have applied, but fortunately, I saw the magazine, the pamphlet after we learned the cryptographic algorithms. I just remember learning them to me like, “I don’t think I spend a lot of time thinking about that.”

Chris: It’s [...], that excitement, that shame, that super secret agent, 007 away from it, right?

Jon: Right, but using this stuff is not that hard as you just said and it’s so important. Let’s talk not about how algorithm systems work but rather the practical use of this stuff because that is not only not hard but absolutely expected and important.

Chris: Exactly. Maybe starting off with the definition. What is encryption? What is it? Really quite simply, it’s the process of taking some plain text and you convert it to something that looks like gibberish. It’s ciphertext. You’re just transforming your information that you want to be kept secret into something that has no resemblance to what it originally was. That’s what we called ciphertext.

Some of these encryption methods require a key and that’s key to the whole encryption algorithm. It’s a secret that’s known, that’s part of that transformation, function to change that plain text to ciphertext. Use cases for encryption are many. It boils down to you have information that’s sensitive to you don’t want other parties that should be able to see it, be able to understand it.

Cryptography has been going on for thousands of years in various forms, where people, governments, civilizations have secrets that they want to keep within their ranks and don’t want to share with others, whether it be a codex or like the example of World War 2, trying to send communications to the different armies. England trying to crack the transmissions from Germany and vice versa. It’s been going on for a really long time.

That core use case of,  “I need to easily make this message secret so that only the people that I want to be able to decode it can,” it’s at the core of it. Everything we do today has use cases whether be, again, like sending our credit card information over the internet, whether we’re storing sensitive data on a database server, we want to have secure communications from point-to-point between ourselves and someone else. Things like WhatsApp, that’s one of its big features, encrypted communication between users. The WhatsApp server don’t even know, can’t even read the messages, it’s only the recipients that can read it.

Jon: It’s better saying that even stuff that doesn’t seem to need to be encrypted really should be these days. It’s like encrypt all the things and the reason you should encrypt all the things is because bad actors, whoever they might be, are able to tell so much from contacts now, that if you just encrypt everything, then they can’t really tell anything. Even if all you’re doing is looking at cheese-making recipes, put them on https. That way, whatever bad actor might need to know something about you can’t use the fact that you’re looking at cheese-making recipes the day before, as a way of triangulating what you’re up to.

Chris: It sound silly, right? But with the machine learning and AI, that context can actually end up becoming useful. In the past, we didn’t necessarily encrypt all the things just because there was such a performance penalty to it and it was also a lot more difficult. But now, it’s so simple to do, it’s so easy, and there really is very negligible in the way of performance.

In fact, most of the major browser now are moving to the point where they’re requiring that communication, the web traffic is over TLS. It’s secure and they’re showing warnings if it’s not over a secure port. Encrypt all the things, Werner Vogels, CTO for AWS is famous for coining the phrase, “Dance like everyone. Dance like no one is watching but encrypt like everyone is,” which is a good one.

Jon: I guess we’re going to talk about three different types of encryption now starting with hashing.

Chris: Maybe before we get into that, why don’t we talk a little bit about where to encrypt. This is where things in terms of encrypt in transit and encryption at rest come in to play. It just makes sense to talk about those two things in general and it really boils down to what is it that you need to secure? And when are you going to use one or the other?

Encryption at rest, quite simply just means it’s data that’s encrypted at where it’s stored. It’s wherever it’s persisted, whether be in the database, or file system, or whatnot, it gets encrypted before it’s actually persisted. In its restful state, it’s encrypted and when something wants to read it, it reads the encrypted data and then decrypts it to be able to inspect data. That’s encryption at rest. Anything that you’re persisting, you’re storing in a database could be your credit card numbers in a PostgreSQL table, those need to be encrypted. 

Jon: Or it could be just encrypting cute pictures of pets and things that people say about them, which is what we do on ZooPix.

Chris: Absolutely. Again, encryption at rest is one of those things that, in the past it’s much more complicated and expensive. Now, in the quad-native world, it’s one of those things where literally it’s a check box option. It’s like, “Why not do it?”

Jon: People get Twitter-pile on if the check box isn’t automatically selected.

Chris: Yes. Then, we have encryption in transit. This is the data moving. It’s going from point A to point B and as it travels from point A to point B, it’s encrypted. This is really to protect against things like eavesdropping.

Anything over the internet, any kind of traffic, you do not have a direct pipe from your machine to whoever’s machine is you’re talking to. You’re going through many, many hops along the way. You’re going to many different servers, routers, and whatnot. There’s always a possibility for eavesdropping there. There’s also the possibility for folks to spoof on destinations and redirect traffic. Because of that, encryption becomes really important and you need to protect that.

Encryption in transit is just that data is moving, it’s going from point A and point B. Before it gets sent over the wire, it gets encrypted and then when the receiving end receives it, they can then decrypt it and read it. And make sure only the recipient has the ability to decrypt. So, that’s encryption in transit. 

Jon: Great. Now, we’re going to talk about types of encryption and you can tell us about that. 

Chris: Yes. We’ll talk about the three main topics here. The first would be hashing. Definitely, this is one of those core foundational aspects of encryption but it’s not encryption necessarily, in and of itself. Hashing is an algorithm that, given an input— the thing that you want to protect—you pass it through this hash algorithm and it gives outputs, some obfuscated hashed value or sometimes we call it a digest.

It’s a one-way function. The same input input to this function will always produce the same hash and because it is one-way, it is impossible to do the reverse. Given just the hash value, you can’t go back the opposite direction to get to the original data. It’s a one-way function.

Also, given the particular hash value or digest, a good hashing function is going to be infeasible to create another string that would produce the same hash value. That’s called collision. That’s a common term that people may have heard like hash collision. That’s really where you have two different keys or input strings that produce the same hash value, that would be a collision and that’s bad. A good hash function will make that very much infeasible that the likelihood of that happening is very low.

Jon: I guess that is important though. It definitely does happen and even the best hashing function have, for any given hash, there are infinitely many ways to make a collision, but it’s just really unlikely because there’s infinite potential data inputs. You can keep trying them and trying them until you get another one that produces the same value.

The values themselves are not infinite. There maybe 36 and 48 characters long, so there’s just so many of those. But there are infinite possible inputs. Therefore, for each one of the potential output, there are infinitely many ways of achieving it. 

Chris: The important thing with this hash is usually the way when these are used in practice. What ends up becoming important is the actual digest itself. That’s what’s used to figure it out whether or not this is the correct value that you want. That is the secret. The hash algorithm gets applied by two different parties and if they come in to the same result.

Jon: Yeah. That’s [...] for. Can I trust that this thing is the same as the other thing?

Chris: If you do have a collision, that’s a really bad thing because it means you don’t need to even know the secret to be now where the other side of things that you do know it. A good example would be a password. If you had really bad hash now, looking for your passwords, if I type in my password is foo and someone else guesses it and guesses bar. If it turns out that foo and bar both hash to the same thing, then the server is just going to just say you have the correct password. They don’t but the hash value is the same. That would be an example of a collision and that’s a really obviously simplistic thing.

Jon: When I think about hashes, I always think about the graph of the function. I think about the x-axis as it goes along, those are all the different potential inputs—from zero to infinity of inputs—and the y is just the hash that comes out of it. I just imagine this almost solid thick line because every time you move one increment down the x-axis, your output value is way different that the one was right before it. It’s just this up and down, up, down, all over the place.

Chris: You should not be able to plot a curve.

Jon: Right, exactly. So, that’s what I think about. I don’t know if that helps anybody that thinks in terms of math but I think about that.

Chris: Complete entropy is really what you’re going for here. Some examples of hash algorithms are SHA, MD5 and then bcrypt is a specific hash algorithm that’s specifically designed for password hashing. Most developers are pretty familiar with bcrypt, especially when you’re dealing with passwords and storing passwords and whatnot. That is a hashing function that is based on the Blowfish cipher and it also incorporates a salt into it. The salt is incorporated to protect against brute-force hacking. This is, again, interesting.

First of all, think about all the different security attacks and hacks that we’ve heard about in the last five years, so you have the really bad ones where services store passwords in clear text. That’s really hard to understand. But then, you have systems where they hash the passwords but they weren’t salted. I really think [...] is LinkedIn. The LinkedIn password hack, I think it’s in 2012, they stored their passwords as hashed values but they weren’t salted.

Jon: I want to just explain what that means. The input value, I guess you’ve been calling that the key, so say it’s duranium or pizza dough. To every single one of those input values before hashing it, they’ll add XYZ or 1234, just some salts, some few extra characters and then they’ll add those 1234 to the end of duranium and then hash it. When a person types in their password, they type in duranium. Again, to make sure it’s the right password, the system will add 1234, that same salt to it, hash it, and see if it’s the same as what was stored earlier. That’s what salt is.

Chris: Righ. Imagine we’re just using the bcrypt algorithm, we’re not giving it any salt. Let’s just say we’re not using salt for whatever reason. We think we’re doing the right thing, we’re using bcrypt for hashing these passwords and storing the hash values. They type in duranium, that generates the gobbledygook, we think we’re doing well.

The bcrypt algorithm is well known, anyone can use it. This is the rainbow table attack. Really what it is, is just a look-up table. You just go through and start picking passwords, run them through the bcrypt algorithm, you now have the hash value. Now, all you have to do is if you’ve got a dump of hash values that represent passwords, you just use up your look table. Once you find a match, now you know what the actual password is because it’s just the same algorithm, that is the rainbow table attack.

That’s what lead to the issue with the LinkedIn problem back in 2012. Salt is basically an extra secret that’s applied to the algorithm that’s very specific to that particular service or application and it has to guard that very closely. That ends up becoming the actual true secret here. It really is. For all intents and purposes, it is the key in that particular case. With that salt, it’s a new rainbow table. Unless you know that specific key, you’re not going to be able to do that same brute-force password attack. So, always salt with your hashing.

Jon: Excited as I am to go into it, I won’t but I’ll just leave listeners also with that hashing cryptography is what’s use for blockchain as well. This thing that we just explained is at the core of how blockchain works and that going and all that.

Chris: What’s really interested too with bcrypt and bcrypt actually, the standard allows for an adaptive function. As part of the algorithm, you can tell it how many iterations it needs to go through to compute the actual hash value. They do this so that you can make it slower as computers get faster. It makes it more resistive to the brute-force search. It is similar to how bitcoin works, you can just make the algorithm more computationally complex as needed as computers gets faster and faster.

Jon: Super interesting.

Chris: It was something I learned the other day as well. 

Jon: Cool. Shall we talk about symmetric key encryption?

Chris: Yes. Now, we can get on to the two main encryption mechanisms. There’s symmetric and then there’s public key which is also known as asymmetric. Let’s first talk with symmetric. With symmetric key encryption, you know a single key. It’s the same key that’s used to both encrypt and to decrypt the data which means that in order for secure communication to happen between two parties, both parties have to know that same key. Lots of different algorithms out there that use symmetric key encryption to things like AES, Triple DES, Blowfish, RC4.

Jon: Everything was symmetric. Everything that you could decrypt was symmetric key encryption before the invention of public key encryption like secret decoder rings, everything.

Chris: Going back in World War II, when the Germans are encoding their messages, they were creating a key. They rotated their key daily but it’s symmetric key. They have a way of all parties needing to know what that key was, and the [...] have that key, you couldn’t decrypt the message and then they would rotate it everyday. Symmetric key was the way to go; was the only thing really up until the early 70s. Then came up with a more secure way when you have to, so that you don’t have to share one single key which has its limitations and we can talk about that a little bit more.

Jon: Do you know anything that you can share? I don’t want to get too mathy, you mentioned 3DES, AES, Blowfish. Those are the ones we’ve heard of. Do you know anything about generally how high-level what the math is doing?

Chris: At the very highest level, it’s a function. You have an input, you have some algorithm that translates it to an output. It’s very similar to what we talked about with hashing so you want to have the most entropy possible, so there are no patterns there. You refer to these algorithms as being spongy, its sponginess of basically how much information can you soak up in your algorithm and hide it from the output. 

Jon: I guess the unique thing about them is you’ve got two functions, one that can produce this output and another one that can take the output and regenerate the input from it. 

Chris: Yeah, very low level math. Again, it really boils down to the harder the algorithm is to crack, the better the algorithm is written more complicated. You can have a really simple algorithm like the key and you shift the character by three or something like that, there are simple rotations there. Simple, not very complicated from a mass standpoint, but also really easy to break.

That’s where the complexity of these things come into play. Trying to increase that sponginess of it, they’re increasing the entropy of it, they are also getting to key lengths. Obviously, the more bits that are there, the more possibilities there are which makes it much harder to do from a brute force attack. That’s why, the original DES was 56-bit encryption and then, Triple DES is three times that. AES was 128-bit and now the standard is 256-bit.

Jon: I know it has something to do with prime numbers and I know there is some intuitive way of understanding what’s happening. We can come back to that on the next episode, just spend two or three minutes and the next episode explaining in a high level what’s happening in some of these algorithms because it would be interesting for people without getting into the details of the math.

The other question I want to answer, I imagine we are not quite ready for is I have not fully understood how we do things like make sure that something that short is just as impenetrable as something that is longer. If you have a tweet and you encrypt it, that’s only going to be 256 characters or 240 characters max. What we are doing is to make sure that it is really impenetrable because 240 doesn’t seem to be that many to be guessing or even fewer sometimes. If you have a chat transcript, somebody might answer with one word. What are we doing to make sure that if somebody keeps answering ,“Yep,” that we are not able to be like, “Oh, now I can see what yep is.” A couple of those I’m curious if we can have intuitive answers for in the next episode. 

Chris: Yeah, a lot of that boils down to how you use encryption. This is more up to the application itself and what’s important. In that particular case, you may decide that you do it in batches or something like that to add to some branding. The algorithm themselves, because you’re feeding them some input, are going to give you an output. If the input is always going to be, “Yup,” that’s all it is that you keep encrypting then that maybe information. It’s just going to be the same cryptographic output with the hash function. Some of these encryption schemes may involve randomness in the form of time or something as that as well that would feed into it which might help there.

Jon: Yeah, let’s revisit.

Chris: Cool. So, that’s symmetric key encryption. The important point there is that both parties have to have that key. The big limitation with symmetric key encryption is how you securely get that key to everyone that must be able to read it. That’s where it gets complicated with the management of it and then also worrying what happens when that get exposed.

Jon: It’s safe to say that it requires trust. In order to truly have symmetric key encryption, at some point in the transaction of handing keys to each other involves a little bit of trust. You have to trust somebody like there’s actual personal trust involved.

Chris: The probably good example is password. It’s like sharing your password with someone like better trust them.

Jon: In order for us to have a conversation, say you and I want to have a symmetric key conversation with each other, we have to exchange this key to each other, we have to, at some point, figure out a way to trust. “Yup, it’s really me, I’m really giving you the key, and now we can talk over it.” I’m bringing this up because it’s going to be our segue in the public key which gets rid of that requirement.

Chris: Yeah. Let’s talk about public key encryption, also known as asymmetric key encryption. In this particular schema is the common terms that people heard before⁠. You have a public key and then you have the private key. The public key is published, anyone can see that and that is generally used to encrypt messages. The private key is only known to the receiving party. Basically, the owner of the key pair. They’re the only ones that have the private key.

Someone wants to send a message to you. They go first and find out, “Hey, what’s your public key?” They get that, they now use that to encrypt the message and the message is sent to the user. Basically, that part is not secure. Anyone can see that message and the message [...] be secure because it’s a public key used for encryption which is known to everyone, but what happens is only the person with the private key can actually read the message. The decryption can only happen with the private key. This is the public key, private key, the math behind it is based on prime numbers. That’s how those two things work together. Where the math is involved, is how does it deal with prime numbers.

Jon: Right. That just makes it possible for people to be able to communicate with me without me knowing who they are and without even trusting that they are who they say they are. It lets them get me a message that only I can read and that’s so important. The best use case that’s happening all around us today is a whistleblower giving information to a journalist. Who knows who the whistleblower might be and what they’re working for, but they need to be protected and the journalists wants to tell that story. So the whistle blower will use that journalist’s public key to send a message that nobody else can read. Maybe they can tell that a message found sent, maybe they can see the gibberish, but nobody else can know that the whistleblower are saying, “This important secret meeting took place between these public figures.” Only the journalist will be able to tell that that’s what happened. 

Chris: Exactly. You hit some of the other issues like trust, identity, and making sure that the public key that you’re using is indeed who you want the recipient to be. That’s important. So, examples of public key encryption implementations are SSL, TLS. The key fundamental encryption that is for the web is this public key, other ones like RSA. PGP is probably one of the first implementations of these which stands for Pretty Good Privacy. That was back in the early 70s. So again, public key encryption, big improvement where you don’t want to share secrets amongst these parties, but you can still set up this guarantee that only the intended recipient can actually read the message.

Jon: There’s one even further thing that we don’t have in our outline and I can’t describe it very well but I can give basically the gist of it which is being able to assign something with public-private key cryptography. Essentially, if I wanted to talk to you and you don’t know who I am, I’m going to use your public key to encrypt some stuff and send it to you. But I also want to prove to you that I really am who I say I am or at least that I have the key that I said I do because somebody else could have got my key. I really do have that key and I can do that by signing the message that I sent to you with your public key.

I can’t remember exactly how that works but essentially, what it boils down to is there’s some way that I can use my private key and your public key in a way that only I could give. It’s basically, encrypting my own public key with my private key or something like that but basically, nobody else can do that but me because I’m the only one with my private key and on your side you can see, “Oh yeah. It must have been Jon that did that because when I decrypt this with my own private key, I can see that it turns into his public key which only he could have done.” It’s essentially giving you my public key in a way that only I can do. I don’t know exactly how that works but that’s the key to making sure that people cannot just have conversations without trusting each other but also identify themselves like I am who I say I am.

Chris: Yes. Signing of secure messages or plain messages basically is the reverse to that, what we just talked about. That’s a way to further check to say, this is coming from whoever it is that they expect generated this message did to it. What we just talk about with public key encryption where the sender uses the public key to use the encryption. When they sign it, they use their private key for the encryption. The recipient is using the public key to decrypt the signed portion of it and it’s using their own private key to decrypt, to get the actual message contents. 

Jon: The key here isn’t knowing exactly how the sausages made but knowing what the use cases are because obviously, listening to this you might be like, “Chris and Jon are certainly are encryption experts.” No, we never claimed that we are encryption experts but we know enough to keep ourselves out of trouble.

As a developer, if you’re making decisions on how to do something, how to implement something, there’s just an area where you need to know at least as much to make sure that things are safe and things are at the data, when you tell your clients, you tell your boss that this is safe, we’ve done the best practices, you need to get yourself above that.

As in everything, there’s diminishing returns so why haven’t Chris and I gone, why aren’t we able to tell you every detail about each algorithm is because it really isn’t relevant to our day job. It’s not something that we would make use of day-to-day. We’d rather spend that same time learning about new features of AWS or learning different aspects of business or what have you. It’s getting above that threshold and that’s we’re hoping to do is get you sorted to our level of understanding cryptography with these three episodes and then each will be all good.

Chris: Absolutely. It’s good stuff in point for this particular episode. Next time, something will be fun just to dive a little deeper into the practical implementations of encryption and just doing a walkthrough, like how do these things work. Things like TLS, SSL, what’s really going on there, how does that actually work, and generate secure web traffic. Look at how do you secure point-to-point communications where only servers don’t/can’t see the actual message because it is encrypted, that the encryption-decryption is between the recipients only, and how do you handle the case where you have multiple recipients which is an interesting situation.

We’ll also get into the practicalities, like what happens in the real world. It’s not symmetric key encryption versus public key encryption. Usually, you use both of these and there’s reasons for doing that. One, the public key encryption is very computationally expensive. Symmetric key is much less, so how can we use these two together in concert to have a really secure but also performant way of communicating.

Jon: Very cool. Looking forward to it.

Chris: Alright, guys.

Jon: Thanks so much. Talk to you next week, Chris and Rich.

Rich: See ya. 

Chris: Alright, see ya. 

Rich: Well dear listener, you made it to the end. We appreciate your time and invite you to continue the conversation with us online. This episode, along with show notes and other valuable resources is available at mobycast.fm/73. If you have any questions or additional insights, we encourage you to leave us a comment there. Thank you and we’ll see you again next week.