By the end of today, you should:

- understand digital signatures and message digests

We all know that identity theft is a big modern problem. How can you
prove you are who you are? How does the thief prove they are you?
Usually it's by having certain magic

numbers that only you are
supposed to have, like your Social Security Number (SSN) and
such. Unfortunately, in day to day life, we don't usually have anything
much better than that. Computer scientists have invented something
better, namely *digital signatures.*

First, digital signatures have *nothing* to do with privacy
and security. Just the opposite. You may want to prove to
the *world* that you signed something. Don't confuse these.

- Alice wants to sign a public message. She already has a public key pair (S,P) and everyone has P.
- She composes the message to be signed, M.
- She posts M and E
_{S}(M). That is, she posts the message*and*its encryption using her*secret*key. - Anyone can compute D
_{P}(E_{S}(M)) and check that it matches M. - Since
*only*Alice could have created such an encrypted form of that message, it*must*have been from Alice.

The same idea can be used for Alice to prove her identity! All she has to do is sign a message and anyone can verify that the message was signed by her.

Because digital signatures take significant computing time, in
practice Alice doesn't sign M, but rather a *message digest*. A
message digest algorithm puts M through a kind of deterministic
cuisinart that reduces it to just a small number of bits, say 128 or
256. However, the digest is (essentially) *unique*, like
fingerprints.

Just as your fingerprint is much smaller than you, but just as unique as you are, message digests are smaller but uniquely identify a message.

They have some really cool properties:

- They're relatively
*quick*to compute. - They're essentially
*unique*to a message. (There's only a 1 in 2^{128}chance that two different messages would have the same digest.) - They depend on the entire message. Change just a single
character, and the digest changes. So it's like a
*fingerprint*. - You can't run them backwards to get the message back. They are
*one-way*functions.

This makes message digests useful for a host of cryptographic techniques. We'll just explore them a little.

Something built in to all your Macs is *md5*. I'll demo using that.

When Bob signs a message he's sending to Alice, he uses:

Bob's secret key

Bob's public key

Alice's secret key

Alice's public key

Which of the following is FALSE about message digests:

it is infeasible to find two different messages with the same digest

it is infeasible to modify a message without changing the digest

it is infeasible to recreate a message knowing its digest

it is infeasible to compute the digest for any given message

Let's make this a bit more realistic. Use the same partner as you
used before in the RSA exercise, so your partner already knows your
public key. One of you will be the *sender* and the other
the *receiver*. The receiver is the one who knows the sender's
public key. If both of you know the other's public key, either can be
the receiver.

I'll do this on the instructor station while you follow along.

- The sender creates a message of some sort.
- She uses the SHA-2 page to create a digest of the message.
- She generates a digital signature of the digest using her secret, private key
- She sends all three of these to the receiver. In our demo, though, we'll just send the MD and the signed MD.
- The receiver checks the digital signature of the digest using the sender's public key by copying those two values in to the bottom two fields and clicking the check signature button.

The public key that your browser downloads is *signed* by
a *certificate authority*.

This gives you some assurance:

- that the website is who it says it is, like checking someone's ID card.
- It doesn't say they are honest and trustworthy
- only that they aren't someone else.
- It's a little like
a
*notary public*, who checks someone's ID when they sign a document.

Let's look at this page via https!

We'll break up into groups and discuss:

- Who should prevail: Apple or the government?
- What's the dividing line between individual privacy and collective security?
- What about
*ransomware*? How can encryption be used against innocent people? - Practical issues for use of strong encryption?

We hope that after these activities you can:

- understand how encryption and decryption work
- undertand the difference between private and publick key cryptography
- the uses of private and public key cryptography

Will be posted later, visit again after .