Now we talk about the benefits of symmetric cryptography. Mainly that it's fast. But we said it's got the limitations of not being scalable. It, ah requires out of manky exchange. Ah, it doesn't give me. The other service is that I'm interested in and we talk about asymmetric fixing those problems.
But the truth of the matter is we want to combine them
both so that we get the best of both worlds. And I think that's best seen in SSL which of course, we're really looking at T. L s transport layer security more, but the principles are the same.
So the bottom line is, let's say I want a secure connection to my banking server
Bank of America. Okay, so I'm gonna connect to Bank of America with https and remember, that s says I want a secure connection. What that means is, I want the server to send me back. It's public key,
right? So I now have Bank of America's public key, and I can send data to it confidentially.
However, what I really want to do is communicate with Bank of America using symmetric cryptography because symmetric cryptography so much faster.
So what? I'm gonna do is a client is I'm gonna generate a symmetric key.
I'm gonna encrypt the symmetric key
with Bank of America's public key. So I'm encrypting a key within a key, right? I've got Bank of America's public key. I'm on Lee using that to encrypt a symmetric key. Why? Because now I can transmit that symmetric key across an unsecured network knowing on Lee, Bank of America can decrypt it.
It was encrypted with Bank of America's public only Bank of America's private comm decrypt.
And what have I just done? I've done secured key distribution across an unsecured line or an unsecured connection.
Now, I generated the symmetric key. So I know it. I've gotten it securely, the Bank of America. So Bank of America knows it. And now I set up what we call a secure channel, which basically just means all communication is gonna be encrypted with that secure symmetric key. And that's the hybrid technology. That S S L T l s.
use now we haven't talked very much about integrity and integrity means that I need to find a way to detect modification if a file if I If you've ever downloaded the file from the Internet, and then you go to open it up, and it says This file's been damaged or corrupted.
Well, there has to be some mechanism that my system can use to determine that
otherwise it would go undetected. Also, we've got to think about malicious modification. What if an attacker intercepts an email message from me and changes the body of that message of the content of that message? That could be a real concern.
So what we look for to mitigate those sorts of situations is some sort of guarantee of integrity, and one of the most common guarantees of integrity would be using a hash.
So what a hash does is it essentially takes a snapshot, if you will, or creates a digital representation of the file. So basically it runs an algorithm on the entire contents of the file and comes up with a message digest, which could also be referred to as a hash.
It might be 100 28 minute message digest if you're using an algorithm. Cult Indy five
Shah one uses 160 bit algorithm, but what's important is depending on the algorithm. The size of your hash will not change. Okay, that's important. Because if you had a very short hash for a short message and a long hash for long message, maybe I could figure out something about the length and and perhaps the content of your message.
before I send you a message, my application will hash the document, and along with the document or the message I send you will be the hash.
So I performed math Come up with the hash on your end. You perform the exact same math. If you come up with the same hash they both match, you've determined that there's not been a change. There's not been a modification, and that's the whole purpose of hashing.
there's only one problem with that.
Okay, let's say I create a message and I send it to you,
okay? And I put the hash on it right, and I send it to you.
But it gets intercepted somewhere along the way, and it gets intentionally changed
Woods to keep an attacker from simply adding a new hash or changing the hash,
and the answer is nothing.
There's nothing that would prevent a hat. An attacker from doing that. So just plain hashing is on Lee Good to detect accidental corruption. If somebody's gonna maliciously modify message, they'll just modify the hash as well. And then you'll get it on your end and the hashes will match, and you won't be any the wiser. Okay,
so we can only use hash is to detect accidental modification.
But if I really want to detect malicious modification
instead of my application just hashing my message,
my application will go one step further, and it will encrypt that hash with my private key.
Okay, I'm the sender. So before I send you this message, it gets hashed, and it gets encrypted with my private key.
If it's encrypted with my private key,
it will be decrypted with my public.
So when I send that to you and your application uses Kelly's hander hands public key
and is able to successfully decrypt the hash,
you know it came from me because it only could have been created with my private key. Okay, so when a sender hash is a document and encrypts that hash with the sender's private key that becomes known as a digital signature, and it's a digital signature that gives me non repudiation.
I get integrity through hashing by encrypting the hash with my private key. I get authenticity because you'll decrypted with my public and know it came from my private. And that gives us authenticity. The two of those combined give us non repudiation. Okay, so for the ultimate security, I'd encrypt the message. But then I'd also digitally sign
encryption gives me privacy,
a digital signature. Give me integrity, authenticity and non repudiation. Of course, that gives us all the surfaces of cryptography.