A cryptographic hash allows you to take any amount of data--
it can be a small bit of text, or it can be an entire book--
and you can represent that bit of data
as a short string of text.
We refer to this short string of hashed text
as a message digest.
A hash is not an encrypted version of the original text.
It's really a one-way trip.
There's no way to recover the original text by simply
looking at the hashed value.
It's because of this unique characteristic
that we commonly use hashes to store passwords.
That way, we can compare a stored hash
against another hash that's given to us later,
but we'll still have no idea what the original password was
from the user.
We might also use hashes to confirm
that a file that we've downloaded
is identical to the original version of that file.
And we use hashing during the creation of a digital signature
that allows us to provide authentication,
non-repudiation, and integrity to a particular document.
A fundamental characteristic of hashing algorithms
is that two different messages will not
have the exact same hash.
We call this a hash collision, and it's important
that we don't have two documents that
somehow manage to represent exactly the same hash.
Let's look at the process of creating a hash.
For this, we're going to use the SHA256 hashing algorithm.
This creates a hash that is 256 bits in length,
and we usually represent this as something human-readable
by using 64 hexadecimal characters.
For this hash, we'll take a simple sentence
which says, "my name is Professor
Messer" with a period.
If we were to perform the SHA256 hash of that text,
we receive this particular hash value.
We can also perform the same function
with another bit of text.
This one looks almost identical.
But instead of having a period at the end,
I put an exclamation mark, and I performed
exactly the same SHA256 hash.
And you can see that the hash value for these
is completely different, even though the only thing that
is different between the two messages
is that single piece of information at the end--
a period or an exclamation mark.
If we were to compare these two, you
can see that they are very different from each other,
even though the original message was very similar.
The only difference was really the punctuation at the end.
But because this hashing algorithm
is designed to create very different hashes,
we can see that there is a remarkable difference
between one hash and the other.
This hashing method can be used with any type of message.
It could be a large graphics file, it could be a disk image,
or it can be a sentence like the one
I used in the previous slide.
We use that hashing algorithm to create that fixed size string,
which is our message digest.
This message digest-- the hash that
is created from this hashing algorithm-- should be unique.
If we have two different kinds of input,
they should never create exactly the same hash.
If we do have an instance where that occurs, it's a collision.
We had an example of this with the MD5 hashing algorithm,
where a collision was found in 1996.
And because of that, we don't tend
to use MD5 to do our hashing these days.
Here is an example of this collision
that occurred with MD5.
These are two different pieces of information.
They're almost identical, except for the items
that are highlighted in red.
Those are the only differences between these two messages.
But if I use MD5 to hash these messages,
I get exactly the same MD5 hash, and that is our collision.
One common use of hashing is to verify a file
that you may have downloaded.
You might go to a website and find a number of files
posted that have along with them a particular hash value.
When you download this file, you can perform the same hash
locally on your machine and then compare your results
of that hash to the version that is posted on the website
to verify that the file you've received
is identical to the one that's posted on the website.
And as we mentioned earlier, it's
common to use hashes when you're storing passwords.
Instead of storing the original plaintext password,
you can combine the password with a little bit
of extra information that's called the salt,
hash that information, and store that information instead
of something that could be seen by anyone.
During the authentication process,
the user would input their password.
The same hashing function would occur,
and that hash would be compared to the one that is stored.
If those two match, then you know
the authentication was successful,
and you were able to do that without storing the user's
plaintext password.
We can also combine hashes with asymmetric encryption
to create digital signatures.
Digital signatures can be used to provide integrity
so you can be sure that the message that you've received
is exactly the message that was originally sent.
Digital signatures can also provide authentication
so you know that the message that you received
was really sent by the sender.
And digital signatures can provide non-repudiation,
which means that we know that the digital signature was not
faked or provided by a third party.
To create a digital signature, we
need to be able to sign the paper with something
that no one else has.
And with asymmetric encryption, we
know that our private key is something
that no one else has access to.
That means then, obviously, that no one but us
can provide that digital signature.
And since we're using asymmetric encryption,
the recipient of this digitally signed document
can verify my signature by verifying it
with my public key.
Visually, here's how this would work.
We would start with Alice, who wants
to digitally sign a document that she's sending to Bob.
This plaintext document says, you're hired, Bob,
and she'll hash this document to create
a hash of that plaintext.
Alice will then encrypt this hash with her private key,
and obviously, no one else would have access
to Alice's private key but Alice.
The result is this digital signature.
This is not an encrypted version of the plaintext.
In fact, it's common to create a digital signature
and simply attach the digital signature
to the original plaintext that you're
sending to the third party.
And that's exactly what Alice has done here.
She's taken the original plaintext
with the digital signature and sent it to Bob.
Bob will take the digital signature off of the plaintext,
and he will decrypt it using Alice's public key.
That will provide the original hash
that Alice originally created.
Now Bob can use exactly the same plaintext,
perform the same hashing function that Alice originally
did, and come up with a hash of that plaintext.
Now Bob's able to compare the hash of the plaintext that
was created from the digital signature and the hash
of the plaintext that he performed himself.
And if those two match, then he knows
that this digital signature is valid.