Welcome to the second video in our Introduction to Encryption, which is Part I of our series
designed to teach you the user how to secure your data.
If you haven't watched the first video, I urge you to do so, as it covers the basics
of what encryption is and why it's important.
We also covered the first type of encryption: symmetric or secret key encryption.
We also mentioned the concept of "entropy," which is the amount of uncertainty in a message.
Since you should never use the same key on the same data, entropy helps you scramble
things up so that the encrypted result resembles random noise.
We're going to continue with the next type of encryption: asymmetric, or private key
encryption.
Remember from Part I that the problem we kept having was how Alice can get the secret key
to Bob without Eve getting it.
One solution to this is to use asymmetric-key, or private key encryption.
With this concept, Alice can generate an encryption key and keep it to herself.
This is her private key, and no one else in the world needs to have it.
From this private key she generates a public key, which she sends to Bob.
This doesn't have to be secure; if Eve gets it, no problem!
The reason why is that the public key cannot be used to decrypt anything.
It can only encrypt, and Alice uses her private key to decrypt it.
Alice can post her public key on the internet, and anyone who wants to can find it and use
it to send her a private communication; the private key CANNOT be recovered using only
the public key.
So this is secure, and Alice is in complete control of the private key.
She doesn't have to trust anyone else, but Bob has to trust Alice.
Pretty much Eve's only hope at deciphering the message is to get Alice's private key,
but since Alice can keep it secret and all to herself, this will be very difficult.
The problem is, it's uni-directional.
Bob can now send encrypted data to Alice, but Alice cannot send anything encrypted to
Bob.
Bob would have to generate his own private key and send Alice the public key so that
she can send a secure message to him.
You can combine methods, however.
Remember that the problem with secret key encryption was the difficulty in getting the
key to the other person securely.
Now, since Bob has Alice's public key, he can generate a secret key and send that to
Alice, encrypted with her public key.
They can then communicate as usual with secret-key encryption, and Eve has no way of getting
the encryption keys.
Private key encryption also gives us the ability to verify that a message was written by the
person we want to be talking to.
Bob has Alice's public key, but he wants to make sure it's Alice and not Eve pretending
to be Alice.
So he has Alice send him a message--this doesn't have to be encrypted--that is digitally signed
using her private key.
Bob can then verify the signature using Alice's public key.
If everything matches up, then Bob knows that the message was written by someone with access
to Alice's private key.
As long as Eve hasn't managed to steal Alice's private key, then it must be Alice who sent
the message.
But if Eve ever does manage to steal the private key, she can read encrypted messages that
Bob intends for Alice, and even send messages to Bob pretending to be Alice and the digital
signature would match.
Our third type of encryption isn't technically encryption, although a lot of the concepts
still apply.
It's called "hashing," and you can think of it as a sort of one-way encryption.
You take a piece of data, run it through a hashing algorithm, and the output is scrambled
in a way that can never, ever be descrambled.
What's the point?
Well, if you take the same piece of data and run it through the same hashing algorithm,
you'll get the same hash.
You can do this whenever you need to verify a piece of information but don't need to decipher
it.
That's what hashes are for: some kind of verification.
One use for this is passwords.
If Alice connects to Bob's server, she creates her password, it gets hashed, and the hash--NOT
the original password--is stored in Bob's server.
Then, whenever Alice logs in, the password she types gets hashed the same way.
Bob's server then compares this hash to the hash stored in his database, and if they match,
Alice is logged in.
Knowing the original password isn't necessary; we only need to confirm that she typed in
the same password.
With a good hashing protocol, there will be no hints given as to whether the hacker has
gotten close to guessing the password.
The hash for the password RoughMilkPaintBattle1 should look as different from the hash for
RoughMilkPaintBattle2 as it does from FailedCourageSeldomPhysical.
The only way Eve can crack it is to try passwords over and over and over again, until she gets
lucky and hits the one that generates the hash on Bob's server.
We'll talk more about secure password storage in Part II.
Another way is if she wants to verify that a file she gets from Bob hasn't been tampered
with.
She downloads the file, and then Bob separately gives her the hash.
Once she has the file, she runs the hashing algorithm on it, and compares the result to
the hash she got from Bob.
If they match, she can safely assume the file hasn't been tampered with.
The hash acts as a signature that verifies she has the correct file.
The Bittorrent protocol uses hashing to verify the integrity of the files it sends.
Along with the metadata describing the torrent and what file or files it contains, there
is an info-hash which the client runs to verify that no one has monkeyed around with this.
Plus, Bittorrent divides its files into pieces, and each piece is given its own hash.
Once the client finishes downloading a piece, it verifies the hash, and if the hash is different,
it knows an error has occurred and it needs to download the piece again.
So that's our other two types of encryption: asymmetric key, or private key, a uni-directional
encryption that can also be used to create and verify digital signatures, and hashing,
which is a sort of one-way encryption, encryption that cannot be undone.
It's used for verification, whether it's verifying that a user typed in the correct password
or verifying that we've downloaded a file without error or tampering.
In the next video, we'll look at different ways of implementing these different kinds
of encryption to deal with certain problems, and we'll also look at issues surrounding
those all-important random numbers.