Hello and welcome back. My name is Tyler McMinn, and this is the Aruba Networks Security Basics course, part two, where we're going to be looking at securing our communication with regards to asymmetric encryption. [MUSIC] So asymmetric public key as it sometimes refer to encryption. We have an example with Bob and Alice wanting to exchange information and ultimately authenticate each other as well. Bob could come up with a shared key or asymmetric key to encrypt and decrypt across to Alice, but that would require that they use some mechanism to transport the key or drive the key. For example, using Diffie Hellman with asymmetric, you generate a key pair at the same time. So a public private key pair much larger keys than symmetric, but equally as strong if you have a large enough key. So for Bob to send encrypted information that only Alice could understand rather than trying to somehow get the key across to her. What Bob could do is get Alice's public key beforehand, and Bob, with his own public private key pair, could share his public key with Alice. The strength of asymmetric encryption what we call public key infrastructure is sending everyone's public key to each other, making that available. And if you work in a company, you have a laptop on the domain or part of active directory or whatever. These mechanisms are in place and they've been used for more than a decade or two. So for Bob to send that message here, that's plain text and encrypted. All Bob would need to do is use Alice's public key to encrypt the message. And you might think, well, if everybody has a public key, can everybody decrypted? No, the way that public and private key pairs work and this is crazy. Only something encrypted with a private key can decrypt something that's been encrypted by the matching public key, and vice versa. So if Alice derived a public and private key pair ahead of time, so there's her private key, which she keeps private and kept locked away on a chip on her laptop called a trusted platform module chip, never ever shares it. Then there's a matching public key that belongs to Alice that she then sends to everybody or posts it or sends or emails with it or makes it available. And ultimately, Bob gets a hold of Alice's public key. With her public key, anything that is encrypted and sent to Alice, Alice is the only one that can decrypt it as long as she keeps her private key private. Now she loses her private key, whole system falls apart and the certain needs to be pulled and new keys need to be generated. But assuming she keeps it private, the system stays strong. So once Bob validates that this is indeed Alice's public key and that someone pretending to be Alice sending us their key like Mallory, he can encrypt the message with the public key from Alice. And only Alice could be the one to decrypt it. Pretty cool. With symmetric keys, anybody who has the symmetric key can encrypt or decrypt as they see fit. But with public private keys and this weird relationship that they have mathematically speaking, we can leverage that and enjoy authenticity and authentication when it comes to encryption and decryption. So we can encrypt this small message or piece of information with Alice's public key, you end up with your ciphertext that can only be decrypted by Alice's private key. Mallory in the middle here is out of luck. While Mallory, we would assume she has a copy of Alice's public key that does her no good. Something encrypted with the public key cannot be decrypted with the public key, only the private key pair. So different keys generated as a pair private cannot be derived from the public. In fact, that's the reason why we use such large key sizes. With symmetric keys we could have gotten away with 128 bits, even 256 if we were especially paranoid for the equivalent protection on the asymmetric side, you would look at something like 1024 bits, or for 256 you might bump that up to 4096 or 2048. Larger key size is much slower than to do the encryption and decryption. But what you lose in speed you gain in this newfound ability to do authenticity, to do authentication checks that is asymmetric, not the same asymmetry versus symmetry. So encryption for signing. How would that work? Well, let's say Alice wants to send an email. She doesn't care if it's encrypted. She just wants to sign it so that anybody who receives the email knows it came from her. You can validate that she, in fact, sent it. So you have authenticity. And if she does an integrity check of the email, she hashes it and then encrypts the hash with her private key. Now that she's not sending her private key because again, private key stay private. What she is doing is she's taking the hash of the email and sending the email in clear text or plain text along with the hash value. And then she's encrypting the hash value with her private key. So what that means is that anybody who intercepts this email like Mallory can read the email because it's not encrypted and can decrypt the hash to see what the hash was to validate that it was indeed Alice who encrypted it, because if anybody receives it and has Alice's public key, they know it came from her. Only Alice's public key can decrypt this, and then they could check their own hash value against the one that was in the email encrypted, and they know two things. The message has not been altered. If it had been altered, the hash would look completely different. And the fact that you could decrypt the hash with Alice's public key tells me or tells Mallory that it came from Alice. This is not protection in the sense of encryption with confidentiality. But you are getting integrity and you are getting non repudiation and you're getting authenticity. You're getting everything except encryption. And you could add that if you wanted the quick brown fox goes through a hashing algorithm, there's the hash result. Alice then takes the hash and encrypts the hash, not the email with her private key and produces this encrypted bit of garbage. When this arrives on Bob's computer, he can easily read the email without having to decrypt anything. But if he wants to validate that it came from Alice, what does he need to do? He needs to take Alice's public key that he trusts belongs to Alice, attempt to decrypt the hash, producing the result, which would be the 01 ad hash or whatever it is. He himself runs his own hash and gets the result that Alice did when she received it. And what does that tell Bob? That tells him that even though he doesn't trust the medium that the email went through to get to his computer, he knows that the message has not been altered because who could have altered the text and still produce the same result? Nobody, only Alice, only somebody that could re encrypt this with Alice's private key could have altered the hash. And since that wasn't done since Alice's public key was the one that decrypted, not Mallory's. And we trust that Alice didn't lose her private key that her private key is still private, the system works. It seems a bit complicated when you first go through this, and it took me a few times of going over and over this before he started to sink in. because there's so many moving parts, have a little trust in the system given that has been used for decades, and it's been well established pretty much every Enterprise Secure Network uses this method of keys tied to identities. So there you go. Alice's public key decrypt the hash, matching valid signatures, the signature now being trusted that it did indeed come from Alice. And because the hash is the same, the message has not been altered. So while it's still readable by everybody, we know it was Alice, and we know that it was what she originally stated. So asymmetric encryption considerations, the advantage of asymmetry. No need to communicate keys securely. We don't have to rely on the strength of Diffie Hellman, Elliptic we don't, we can more importantly, encrypt and sign data for anyone who receives the public key. The disadvantage. And there's a big one here is that yeah, it's slow. I guess that's bad. But you have to go through the labor of linking an identity of who somebody is to the key and then manage those keys. Somebody has to generate the keys and tie them to the users. Someone has to distribute the keys. Someone has to maintain a repository, a public keys. We need some way to trust that Alice's public key is actually from Alice. We need to sign the key in order to make sure that, okay, this is valid. This is good to go. And we're going to get into that in the next series of videos here. But it's the equivalent of me holding up like a driver's license or a passport or something like that. And because it's got the watermark of the state, I'm in Washington or whatever this is considered signed by the state. So if I hand this to the police or use this to buy alcohol or something like that, anybody can validate that this is indeed the Washington valid driver's license, and therefore the information on it is valid as well. Same thing with Alice's public key. We need something that we trust to sign off on it and a little bit of a spoiler alert here. That thing is going to be called the certificate authority to server. We run on Windows or you can use clear pass for it. So this use of certificates is what we're going to get into next. Hopefully, this establishes a bit of a baseline for you. All right, let's stop there for this one. In the next video, we'll go on to do a quick little question answer here. I'll give you the question in this video. I'll give you the answer to begin the next one. So Alice hashes or message encrypt the hash with her private key and sends the message plus the hash to Bob. What key should Bob used to validate the message? His own private, his own public, Alice's private key or Alice's public key? I think you know the answer. Check yourself in the next video. Thanks again. I'll see you in the next one where we're going to jump into certs.
