An Encryption Deep Dive - Part Two

Chris Hickman and Jon Christensen of Kelsus and Rich Staats of Secret Stache continue their series on encryption to discuss transport layer security (TLS) in practice. 

(Read Part I)

Some of the highlights of the show include:

Episode 73, Part 1 Recap: Essential encryption pieces (hashing) and categories (symmetric vs. public keys)TLS (a.k.a. https) Components: Authentication, encryption, and integritySecure Sockets Layer (SSL) Certificate: Identify and authenticate who is communicating with you on the Internet Public key encryption involves public and private parts, plus a middleman:Web server handling security traffic generates separate digital SSL certificate Certificate authority issues certificates and confirms identities of Web serversCertificates: Verify account/billing information and domain ownership; simplified and streamlined process makes it easier to create fraudulent certificatesTLS Handshake: Session initiated for server to prove its identity through SSL certificate and establish a shared encryption keyWhy create shared secret for a session? Performance and revocationBig Ideas of Symmetric Key Encryption: Confusion, diffusion, and secrecy in the keyVirgil Software Development Kit (SDK): End-to-end encryption where two parties establish secure communication link with a server

Links and Resources

Managing Humans by Michael Lopp 

Bitcoin Billionaires by Ben Mezrich

The Accidental Billionaires by Ben Mezrich

The Social Network

Network Solutions

Verisign

A Stick Figure Guide to the Advanced Encryption Standard (AES) from Moserware

Rubik's Cube

VirgilSecurity SDK

WhatsApp

Kelsus

Secret Stache Media

Transcription

Rich: In episode 74 of Mobycast, we continue with part two of our series on encryption. In particular, we'll discuss Transport Layer Security in practice. 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.

Chris: Hey, guys. It's good to be back.

Jon: Yeah, good to have you back. Rich, what have you been up to?

Rich: You had recommended a book called Managing Humans. I was asking you about how to start that learning process of becoming more of a manager and a practitioner. That book came today, so I'll be planning to read that this week in the weekend, hopefully.

Jon: Great. Let me know what you think. It's definitely a slacker [...] part of called Rands Slack. It's a popular read. Everybody recommends it. 

How about you, Chris? What are you up to?

Chris: Speaking about books, I am working through a book called Bitcoin Billionaires. Very appropriate considering the topics we've been discussing here on Mobycast the last [...]. Definitely in line with encryption; bitcoin. 

It's a fascinating story. It's like the Revenge of the [...] in a way. The book is written by Ben Mezrich who wrote the Accidental Billionaires which is the book that the movie The Social Network was based on. It's all about how Facebook started; it's genesis story.

Jon: [...]

Chris: The movie is too. Jesse Eisenberg just nails it. To me, that's the true Mark Zuckerberg. Coming away from that book and that movie, the Winklevoss twins didn't really come off looking so great. This book is, again, by the same author. It sees what happens after the fallout from that. They did have a settlement with Facebook, so they received an amount of financial settlement. They really got in early into bitcoin around 2011–2012. Before anyone else really jumped on that bandwagon, they ended up buying a lot. They really went it and ruin it bigtime. They saw this as a big opportunity. They really believed that this is the future for currency and for financial models. 

Parts of it being a bit like a spy novel. The measures that they go to protect the bitcoin that they've purchased is pretty impressive. With bitcoin, you pick a private key to basically protect your coin and that's all you need to say, "This bitcoin is mine." That private key is really, really important.

They talk about how they went and generated this private key, and really make sure it's completely random. By the way, they didn’t even trust computers. They went out and bought a 20 set of die from Dungeons and Dragons game, then rolled that to come up with something that they felt was random enough.

Then, that private key that they did generate, they broke it up into three separate pieces, printed it out on pieces of paper, made four copies of that, got on planes, just jetted around the US, put these pieces of paper inside safe deposit boxes in various different banks and locations. They've felt that this was the best way to keep it safe. Pretty interesting story, definitely recommended.

Jon: Very cool. They're talking about keeping their key safe and we’re talking about encryption. Maybe you can talk a little bit about what we discussed last week because this week we're going to go to encryption in practice. It's going to be based on everything we learned from last week. We're going to get into the details of how those things we learned last week are used in practice and the stuff that we as software developers do everyday.

Chris: Right. This is a multi part series on encryption. Last week was about the essentials. We went through the essential pieces of encryption, being hashing. Then, the two main categories of encryption, symmetric encryption and public key encryption. Hashing is that one way function that given an input, generates an output. Given the outputs, it's really not possible to go backwards from that. That is the basis for things like signing things, verifying identity, authentication, if you will. It's also the backbone of some of the cryptography algorithms from a math standpoint.

The symmetric involves a single key. That key needs to be known for both encrypting and decrypting. Both parties involved in the secured communications need to have that key. A lot of the challenges around that is how do you securely share that key and ensure that no else has it. 

Public key encryption is also known as asymmetric key encryption. This involves two keys. It's a key pair. There's a public part of it and there's a private part of it. This gets around the problem of having to share a secret between two parties. Instead, it's a party that wants to allow other people and other parties to communicate to it securely, publishes a public key. That's a key that other parties use to encrypt the message that they want to send. It has the private key. The private key is only known to that party. The private key is required in order to decrypt the message.The only part that they can actually do the decryption is one with the private key. Then, you can have the byway of communication just by reversing that. 

Those are the three main things we talked about last time. Today, we're going to dive a little deeper and say, "How does this encryption work in real life? What are some of the actual examples of it?" We'll go into two particular examples today, one being TLS, another one is an end-to-end encryption SDK that allows for a secure point-to-point messaging between two or more parties and not just the one-to-one communication. What happens when you want to go to one-to-many or many-to-many communication, how does that work? We'll be doing that today.

Jon: Great. I guess we'll start with TLS. Just to help everyone, most people may still say HTTPS, but when you say HTTPS, you're talking about TLS. So, go ahead and talk about TLS. 

Chris: It's actually a part of that networking layer stack. TLS stands for Transport Layer Security. It's actually built into the OSI network model. HTTPS is in the application level, so that's layer seven. TLS is down at the transport layer, so it's level four.

Jon: I mean, let's just get the thing out there, the theme really in general nomenclature. There are a few people that will hold your head over a barrel if you get those wrong, but those people are not cool.

Chris: Maybe the other thing, maybe the point that's a little confusing too is SSL. People will confuse TLS with SSL. SSL was the one that has been deprecated. We don't use SSL anymore. TLS has superseded it, which was at the same level as TLS—Secure Sockets Layer—versus TLS—Transport Layer Security.

TLS basically is the backbone for how do we have secure communications over the internet. Specifically, how do we trust other parties, and make sure that that whole communication is indeed secure without really knowing who they are and whatnot.

There are three components to TLS. One is authentication. Authentication is I need to be able to make sure that who I am talking to is who I think it is. That's really important because you could go ahead and setup a secure channel between yourself and some other party, but if they're pretending to be someone else, now you just sent all your private secured data to some actor or some spoof site or whatnot. Authentication is a key part of this.

Then, of course, encryption. Once that channel is set up, we want to make sure that the messages are encrypted and can only be read by two parties. 

Then, the third part of it is integrity. Integrity is all about making sure that the message that's been sent hasn't been tampered with. There hasn't been someone in the middle that's altered that message as well. 

These are the three components that we're going to talk about. We've been talking about encryption and we'll spend the bulk of the time with that. For completeness, it is interesting to talk about the other parts of TLS, especially the authentication part. This is really a key part of how the web and HTTPS works just from your browser. 

Jon: This is the part that I don't know about, so keep going. I got this confused look on my face like, "What is he going to say here?" Go ahead.

Chris: Right. This was back in the day why you have to pay $400 a year for an SSL certificate. Nowadays, it's much, much easier. Folks like Amazon do it for free as long as you run them on their services. These SSL certs are the way the web does identity and authentication to verify who is it you're talking to. 

It itself relies on public key encryption. Like what we've talked about public key encryption, there's a public part of that key and there's a private part of that key. There's a middleman between these digital certificates. A web server that wants to serve out security traffic, it needs to generate its own SSL certificate. It's a digital certificate. Essentially, it's a unique ID that indicates that server. There's a middleman which is the certificate authority. The certificate authority is the one that’s responsible for issuing these certificates and it's the one that's going to guarantee the identity of those certificates. The certificate authority is going to confirm the identity of that web servers.

Jon: In the case of AWS, really, they're just verifying that you have a billing relationship with them. You sign up for an account, you give them a credit card, and they're like, "Okay, you're at least known enough to me that we're taking money from you. I'm going to give you the certificate based on that."

Chris: That's definitely a big part of it. The other big part of it is verifying that you actually own the domain. They'll have you do things.

Jon: But again, [...] domain from AWS is still the one thing, right?

Chris: Yeah. They'll do the steps automatically for you. A way a lot of these certificate authorities do is they’ll use DNS, so they’ll require you to go update your DNS records, to put in a text record for some specific secret or just unique ID that they're going to use for that particular identity verification process. Amazon really makes it easy because they have their own DNS—Route 53—so, when you go and create one of these certs, there's a little thing that says, "Hey, would you like us to go ahead and do this for you automatically?" so, they may update your Route 53. They can do all that very quickly.

Jon: I'm not really getting the technology behind it. I'm actually getting more the policy behind it. By verifying that you have a billing relationship with them, AWS is offloading the "know who you are" part of identity management to your credit card company. Your credit card company is responsible for vetting you as a business or as a person. Then, if you can produce a credit card number that works with AWS, then AWS is like, “Great. Somebody out there has vetted you and also your domain. I'll let you hook it up in Route 53. I'll then sell you a certificate and all of that, all your holes, identity checking is just based on the fact that I've established a billing relationship with you.” This is me, guessing. 

It's that easy. There's nobody calling you. There's nobody giving you an interview to make sure you have the number of employees you said. That's what it used to be and at this point, I don’t think it's anything beyond that billing relationship.

Chris: Yeah. Specifically for AWS, it's much easier now to do that, that identity process. I know in the past, what I did with folks like Network Solutions or Verisign, it would be a multiday process for you. You would have to have a phone bill with the company address on it. It was a more manual process for checking this. AWS has definitely streamlined the process. They probably have other ways of automating identity verification. Who knows what databases they're tapping into as well?

Jon: Right, and if I were to speculate, I guess I would say, "Wow! It seems like it'd be really easy to create a fraudulent certificate." You're a bad actor and you want a TLS certificate. You can get one pretty easily, maybe more easily than it used to be able to, but it doesn't matter. All the things that you need to do to protect your security, protect your assets and things on the internet are just getting harder and harder. It doesn't matter that there used to be a big human process involved and now it's just quick. There were so many ways around the human process that you might as well not even waste people’s time with it. I guess that's what I'm saying. That's my speculation. Now, all of these are easy, but protecting yourself has just gotten harder.

Chris: Yeah. All of this doesn't preclude someone from going and registering the domain. Yahoo! spelled Y-O-U instead of Y-O-O, right? That's all legit, but if you're just stealing people's money, then, that's not a TLS problem. That's another problem, just so you know. Phishing and all the other ways people can do crime on the intertubes.

Jon: Do some crimes.

Chris: Yeah, with the Z. 

Jon: All right. Keep talking [...] this handshake.

Chris: So, we have the certificate authority, they're the middleman, they're the ones that are the trusted party. When a server wants to build these secured communications, it's going through this certificate authority, and say, "Hey, I want you to issue this certificate." It keeps it as the public key and the private key to it. The public key goes with the certificate that's available through the certificate authority and the server itself. The private key stays obviously private with it. This way, when a client wants to talk to that server securely, one of the things they're going to have to figure out is, "Hey, what's the public key?"

It's going to go and look at that certificate. There's some steps there that it needs to do to verify that that certificate is trusted. It's going to verify that the certificate authorities it's coming from is a trusted CA. It's going to make sure that that certificate is valid, so it's not expired. It's also going to make sure that the certificate matches the domain of the web server. 

We've all seen the message in the browser when you go somewhere and get the big warning message saying, "The certificate doesn't match this site. As developers, we tried to do this. We're trying to test something in our dev environment or staging environment. We're trying to use an SSL certificate and it just doesn't match up with the domain that it's being surfed from." That's another check that the client's going to do. 

Once it does that and says, "Yeah, I'm going to trust this certificate," that certificate has the public key part of the certificate. It can now start doing this public key encryption to implement TLS between it and the web server. This is all part of the TLS handshake. This TLS handshake happens at the very beginning, the initiation of a session. It's doing these two things. The server's proving its identity through the SSL certificate and then after that, the two parties are establishing a shared encryption key.

This ends what it is. It's a combination of both symmetric cryptography encryption as well as public key. What it will do is it's going to use the public key encryption so that the two parties—the client and the web server—can create a shared secret to be used for the symmetric encryption. We talked about before, this is a big problem with the symmetric key encryption is that both parties have to know the secret. Well, how do you share that secret? What if you need to revoke it? How do you make sure that no one else has it?

Jon: Chris, would you believe me if I told you that I've never had this thought before? But at the beginning of this episode when you were talking about public key encryption and the difficulty of sharing keys with symmetric key encryption is like that sharing in the keys and I was like, “Oh, I wonder if you could use public key encryption to share that key.” Now you're saying that's exactly how TLS works, would you believe me?

Chris: Sure.

Jon: I just had an aha moment earlier in the episode and now you're telling me that's actually how it works. How cool. I'm so excited.

Chris: Too bad you didn't have that, we couldn't go back 30 years and you could patent that and [...] on the beach.

Jon: Yeah, boat trips every weekend.

Chris: Yeah. That's exactly what happened. The other thing to think about here is that the public key encryption is much more computationally expensive than symmetric encryption. The other question was why don't we just use a public key encryption for the whole thing? Why do we even worry about symmetric encryption? We already solved the problem. We already had to do this setting up the secure channel without having a shared secret so why create a shared secret for this session? The reason is literally for performance.

Jon: It takes a little while, you got to be patient. But then once you get that symmetric key encryption going, you're blazing, you're going so fast.

Chris: Actually, it's not just performance as well, you're creating a level of indirection. This way, it gives you the freedom to revoke who you're talking to and whatnot. Intermediate key is that you decide what lifetime they have.

Jon: I was even wondering if the TLS protocol makes it so that as part of creating that shared secret, if it's different for every handshake, [...] handshake, and then a new one, and make another handshake, and make another new one. Just every time new, it could be.

Chris: That's what the handshake does. Every handshake is one, verify the identity, make sure that we trust that certificate, and then two, we're going to create a new encryption key, a new symmetric encryption key, and set that up and share it. Then for the remainder of that session, we don't need to do any of that anymore. We're going to use that same symmetric key. But for any new sessions, brand new symmetric key. It’s going to all be done again. Lots and lots of these symmetric keys are basically just disposable keys.

Jon: Right on. Last week, we had talked about symmetric key encryption and I was asking you if you had any way of describing it in an intuitive way, what's happening in the math, not the math of why it works, but the math of how the encryption happens. We didn't know off the top of our heads and so I promised that I would go figure that out and tell everybody this week. This is a good opportunity to do that because we just said that TLS creates a symmetric encryption conversation between two parties.

I looked it up. We'll put this in the show notes. There's this moserware.com, I've never heard of it before, but there's a stick figure guide to the AES encryption protocol and it's really good. It's really long, but it makes it fairly simple to understand what's happening in AES. There's just a couple things that I want to talk about from it because I can't get into every single detail. There's literally like 200 boxes of stick figures, so it's going to take you an afternoon to read it. But there's a few principles that are worth sharing in Mobycast.

First is that there are three big ideas in symmetric key encryption. One is the idea of confusion. That's the secret decoder ring classic thing of, I'm going to change every letter by increasing it by three. A becomes D, T becomes W, and C becomes F. That's confusion. If you can imagine there's more than one way to do that, you don't just have to move up or down the alphabet by a certain number. There are lots of things.

In fact, since every character or every part of a computer message is not necessarily an English letter. In fact, it's definitely not. It's actually a byte or a pair of bytes. You can do the math on the bytes. Maybe a byte is like AE or 0F or C1. You can do some math with those bytes to turn that byte into a different byte that you can then reverse later. C1 might become AF and then you reverse it, AF goes back to being C1. That's one part of it, that's the confusion.

The other part of it is diffusion. You can imagine a string like ‘attack at dawn’ and you could write that all out in one line or you could write it out in three lines. The three lines could be line one ATTA, line two, CKAT, and line three DAWN. If you wrote out in three lines, then all of a sudden instead of reading it as rows—ATTA is row one—you could be like, “I'm going to actually encrypt it by doing the columns instead.”

The first column is ACD and the next column is TKA. By doing things as columns, you just switched the message from saying ‘attack at dawn’ to ACD, TKA, TAW, ATN. That's completely different than the original message. That's called diffusion. That's like scrambling things up in terms of scrambling the order of the letters in the message.

Then the last big idea of symmetric key cryptography is that the secrecy is only in the key. The secrecy can't be in the method. It can't be something like nobody can know that on step three we're going to switch around the order by doing this, this, and this. That can't be the core of a secret because if the core of the secret is in the method, somebody's going to find out your method someday and then they'll be able to decode everything.

The secret has to be in the key because then all you have to do is change the key. Everybody can know the method. If they don't know the key, there's no way that they can figure out the message. If all of your secret is in the key, then that's good. That's why AES keys are 256 bytes, they're really long. That makes them unguessable.

Finally, how does AES actually work? I'm not going to get into the details here, but you can just imagine it's like a game of moving stuff around. I'm going to put the message into a square. One step is going to be I'm going to switch the quarter of the columns. In another step is going to be I'm going to take each byte from the square and multiply it or actually not multiply it by another byte, but this other operation called XOR, there's a lot of XOR happening and XOR is like an operation that a transistor can do.

Why would you do a bunch of XOR-ing? The reason is because on transistors inside of computer chips, XOR is so fast. That goes back to what you were just saying, Chris, switching from public key encryption which requires lots of actual multiplication and things that are slow on chips to AES encryption which involves a lot of XOR-ing which is unbelievably fast on chips. I'm talking you can probably do on a modern chip multiple billion, like three, four, or five billion XORs per second. It means you can just go so fast through messages, you can just encrypt and decrypt at lightning speed.

Then the AES protocol involves a bunch XOR-ing, a bunch of shifting bits around, a bunch of rearranging columns, a bunch of sliding rows over and doing that a whole bunch of times and then undoing it a whole bunch of times, enough times that the math people out there have essentially proven that to do this with brute force is harder than is really possible with today's computer chips. That is what I wanted to talk about. Do you have any questions for me about that, Chris?

Chris: No. The way that I wrap my head around it is it's like a Rubik's Cube. You start off with the Rubik's cube that’s solved and you just start not only just making turns to change the rows and the columns of those squares, but then you start actually taking the stickers off and putting them on different squares. Removing the stickers and put them on other ones, that's the confusion. The rotating the cube, the rows and the columns of the cube, that's diffusion. You can see how the input was like the solved cube and then the output it looks like just a bunch of random colored squares, and that's your encrypted data.

Jon: To keep our analogy working though, like the confusion part, you can't just be switching stickers that random, you have to use the key to figure out how you're going to switch the stickers. If that’s the yellow, I'm going to turn it into a white because the key is telling me I need to turn it to white and that's what the key is for, is telling you what color to change your sticker to.

Chris: Yeah. Now the key informs what exact steps you do to reverse that, to get back to the solved state.

Jon: Yeah, great. That was the question that I felt like we didn't answer well last week. Hopefully, the encryption hardcore people out there that listen to us and rolled their eyes last week will be like, “Okay, these guys did their homework.”

Chris: Yeah. One small thing, it's 256 bit, not 256 byte, 256 byte would be pretty intense, maybe we're going to need that in 10 years. So, for now it's bit. Just to finish up then with TLS, we've used this public key encryption to create a unique per session symmetric key. Now, that's what the two parties are going to use for encrypting. What they're going to do is each one of these messages that goes across is going to be encrypted using symmetric encryption, using that shared secret. Because they've shared that secret using public key and encryption, now they can just safely go ahead and encrypt and decrypt these messages for as long as the session lasts. Again, as you mentioned, very, very fast and that's why we do symmetric encryption for the actual bulk of the messages and we use public encryption for sharing the secret that's going to be used for that.

The third part of this TLS was in the integrity. That's verifying that these messages haven’t been tampered with, as well as authenticated that the message originated from who I thought it did. That's done by signing the messages with a message authentication code or MAC, even more specifically an HMAC. It's a hashed key message authentication code.

What this does is it's using hashing that we talked about previously. It hashes the message, it combines that hash with the secret key that was negotiated during the TLS handshake. The result is a short value that's sent alongside with the messages. That is what can now be used by the other party to verify that (1) that hasn't been changed, and that (2) it actually is coming from who I think it is because it also combined that hash with the key signing.

Jon: We're not going to get out of TLS today because I want to also add a little bit to what you just said about the signing. That was another thing last week that I felt that I stumbled around on. I was like, “Yeah, there's something that you're using the private key to add to your message and that's how signing works.” You just started down the road of explaining how signing works. I could just add a little bit more to it.

We have two sides of digital signature that happens and you talked about the sender side. The sender has a message that they're going to send over to the receiver and they send that message just directly, but they also take that message and they run it through a hash function—you just said that that was the HMAC function—and that creates that short little thing because hash functions just turn an arbitrary length input into a specified length output that’s much shorter usually. They run it through the hash function and the outcome is called a message digest. What did you call it though? You had a different name for it.

Chris: You'll see it called both a hashed value or a digest.

Jon: Okay. We have this message digest that's just the short outcome of the hash function and then the sender will encrypt that with their private key which means nobody can read it. This is actually something that's a little weird to me. I just never have really looked at it carefully, but I guess private keys and public keys, either one of them can be used to encrypt.

Typically, in asymmetric encryption, people use your public key to encrypt something to send to you, but I guess you can also encrypt and then use your own private key to decrypt. I guess you can also encrypt with a private key. I guess they're just a number so there's no reason you can't use it. I'll just use this number instead of that number to do my encryption.

Once the sender encrypts that message digest, that's now called a signed digest and they stack that on to the front of the message and send it to the receiver. Now the receiver has a signed digest and a message. Then the receiver takes the message, runs it through a hash function, and now they also have a message digest. It should be the same as the message digest that the sender created. Then they take the sign digest and then decrypt it with the sender's public key. I guess these keys can be used either direction, which I did not know that. They decrypt with the public key and now they should have that same message digest. They compare the message digest to the message digest and if they're the same, boom, you trust that the sender has the private key that they say they do.

I have to be so specific about that. Somebody, along the way one time, made a big deal about private keys not identifying a person, but just being private keys like just because Rich says, “I'm Rich because I have this private key,” if Steve got Rich’s private key, then Steve can pretend to be Rich. Private key is not proof of identity, it's only proof of private key.

Chris: Right. Again, it’s part of that key pair secret. What you just described is definitely like code signing in general. Just a nuance is like with TLS, it's a little bit modified there. The term that you were wondering about, it's a message authentication code MAC. It's a little bit different with TLS, but in general, it's the same principle where it's using some secret, not just the hash function, but some secret, and by using the secret, you can then also verify who it's coming from and that you can trust it. That goes into part of it.

In TLS, the client is not sharing a public key-private key pair, it doesn't have a public key-private key pair that it's using with the server. It's just the server public key-private key pair. This MAC thing, I believe it uses the symmetric key as the secret. When it hashes, the hash is used to verify that the message hasn't been tampered with and then it uses a secret saying like, “Hey, the secret is only known between us. If you throw the secret in there, it’s basically solved, then I know that it came from you.” But it's not encrypting it necessarily, but it's the same principle.

Jon: That makes sense since you've already established that connection and you've got a symmetric key encryption going. If you can just prove that you've got that symmetric key as part of your message, then that whole thing goes faster. You don't have to do that. Because I think, what I just described which is digital signatures in general, it's probably not a fast thing.

Chris: You have to have the infrastructure in place for publishing the public key part of it and managing that. That's where I caught something on the web, we get quite onerous.

Jon: What I like about it though, what is cool and the thing that's worth remembering is that digital signatures work the same way as passwords do. There's this secret that the person verifying the signature can't know and is not allowed to know and that's that private key, but they can make use of it to do a comparison just like a password.

A password like the server that receives your password is not supposed to know your password, the server only knows the thing that you're using as a password matches this other thing that the server has in its database. That's a cool thing and it's another use of hashing as part of this whole world of encryption.

Chris: Indeed.

Jon: Chris, is there anything else you wanted to say about TLS to wrap it up?

Chris: No, that definitely covers TLS. We’d planned to talk about the Virgil SDK which is an SDK for end-to-end encryption. This is where two parties can establish a secure communication link with a server between them and the server never sees unencrypted messages. This is like WhatsApp, secure messaging with WhatsApp. With WhatsApp, the messages go through their servers, but as it goes through the servers, it's completely encrypted and Whatsapp can't read it. That's a key part of their value proposition.

Virgil SDK is a code library that allows developers to build this into it and we can walk through this and understand how that works, how you can keep this encrypted all the way end-to-end, and then also the multi-party aspect to it, how do you do this with one-to-many. Maybe we can talk about that next time.

Jon: Okay. That would be great. Thank you. This was really informative. I knew that this week was going to be more fun than last week because last week, there's just some ground that we had to tread to lay this framework out, but now we can really use it and get into it deeply. Super fun and we'll talk next week.

Chris: All right. See you then.

Jon: Thanks.

Rich: Later.

Jon: Later, Rich. Bye.

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/74. 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.