>> Now we'll talk about hashing,
checksums and message digests.
We've just talked about how we get
privacy through asymmetric cryptography.
We said that if we encrypt data
with the receivers public key,
we'll be able to send the message across the network,
and that private key is
the only thing that can be decrypt it.
But we also said that we need things like
authenticity and integrity and non-repudiation.
Here we'll talk a little bit
about how we can get integrity.
One way we can do that is through hashing.
Hashes can also be referred to as
checksums or message digests.
Any of those terms can be used interchangeably.
Let's say I'm sending you a message
across the network, or the Internet,
or across a private line,
and let's say that connection is really unreliable.
It has a lot of interference and drop
packets and a lot of issues.
I want to make sure that you know,
what I sent you across the network hasn't
>> been corrupted.
>> That's exactly the purpose of hashing,
to detect unintentional modification like corruption.
Before I send you the message,
let's say that I determined
the numeric value for every character in the message.
For example, in the word hello,
The H is the eighth letter of the alphabet,
and the E is the fifth letter,
and the L is the 12th letter and so forth.
I'm going to take
all the numeric values and add them all together,
and then I'll put that value at the bottom of
the message, that's my hash.
In this case, if the message is hello,
then the value is 52.
I send the message to you,
your software does the same process,
adds up the numeric value
for every letter in the message,
and when you come up with the number 52,
then your software makes a reasonable assumption
that the message has not been modified.
Now, I realize that this is a weak idea of a hash,
but I'm just giving you this as an example so
you can understand how a hash works.
In reality, the hash would be more robust.
One thing to note about the hash and any hash,
is that it uses one-way math.
Hashes don't use keys
and they aren't symmetric or asymmetric.
The only reason I've included hashing here with
asymmetric cryptography is that we're
going to combine it with asymmetric cryptography
in a few minutes to get an additional service.
But I want you to know that a hash's magic
is a one-way nature of the math.
It's easy to take all these
numbers and add them together.
But if you look at the result,
you can't use that to reverse it.
If the message is encrypted
and all you saw was the number 52,
you couldn't say for sure that the message was Hello.
Again, my hash is nowhere near
the sophistication of a real hash.
Real hashes have a fixed length
>> for the hash themselves.
>> For example, MD-5 always creates a 128-bit hash,
regardless of how long your message is.
SHA-1 creates a 160 bit hash
and SHA-2 can create a 256-bit,
384-bit, 512-bit, 1024-bit hashes.
Make sure you know those hash bit links for the test,
SHA Secure Hashing Algorithm.
There are also other hashes called
HAVAL, TIGER and RIPEMD.
I don't think they will be on the test,
but at least know that they are hashes.
These days SHA-2 with
a 256-bit hash is the one people use the most.
Now with hashes, I'm going to get
a guarantee that the message has
not changed since it was sent.
But one problem can occur,
which is called a collision.
Its possible for two different documents
to produce the same hash.
When we see a collision,
we see that the hashing algorithm is broken.
But its very rare for a hash to cause a collision.
We look for hashes to be collision-resistant.
Now, a birthday attack
is an attempt to cause collisions.
Its based on the idea that it's going to
be incredibly difficult for you to
look at a hash and produce
a document that matches that hash.
You shouldn't be able to reverse a hash,
but the birthday attack says if you have
enough documents that you are comparing,
you might just find two documents
whose hashes happen to match,
its like saying, I'd rather be lucky than smart.
Just a quick wrap up with the hashes,
they're here to protect integrity and confirm that
a message hasn't been modified after being sent.
However, there is the possibility of
a collision where two documents produce the same hash,
but those are incredibly unlikely.