Pertemuan-13Enkripsi and Authentication

Symmetric-key Cryptography

Data encrypted and decrypted with same key Classical examples: Caesar cipher, one-time pad,

Enigma Machine

Symmetric-key Cryptography: Drawbacks

How do the parties get the shared, secret key?  

• How do we transmit this or establish it securely?

• Must have some secret or ‘offline’ way of sending the secret.• This is really hard to do in some situations…• You could read it to them over the phone, but someone

could be tapping your phone in addition to your internet connection.

• How can we both get the shared secret?

Public Key Cryptography

Each user has a keypair, consisting of a public and private key

Anything encrypted with one key may only be decrypted by the other.

To make message readable only by B, encrypt message using B's public key

Where we are now… We can send coded messages without having to

establish any shared secret keys between us ahead of time.

There’s another exciting application of this technology from the fact that Public and Private keys can be used to decode one another (no matter which is used to encode in the first place).

But why would someone code a message with their private key. Anyone in the world could use their public key to decode it…

Digital Signatures I

Well, what would the receiver know about the sender of a message if Bob Smith’s public key can decode the message?

Whoever sent the message had Bob Smith’s private key… (So, it was probably Bob Smith.)

We’re no longer keeping the contents of a message secret. Now we have found a way to verify who was the sender of a message.

Also, we know that nobody but Bob Smith modified the contents of the message along the way. (So, it’s intact and how Bob last saw it.)

Digital Signatures II

Using Public-Key Crypto for Strong Authentication Switch the roles of the keys

• Encrypt with Private key ("signing") • Decrypt with Public key ("verifying" )

Anyone (B) can read the message, But only A could have generated it

Digital Signatures III

But there’s a problem… The Encoding/Decoding step for public/private key cryptography is really slow.

For secret agents and governments and people who really care about the secrecy of their message, this isn’t a big deal.

But for a lot of people who’d just like a digital signature, this slowness almost makes it not worthwhile to use the technology.

Digital Signatures IV What if we only encrypt a part of the message?

But then someone could go in and change the non-signed part, and we’d never know if Bob Smith really did that.

What if there was some good way to calculate some compressed or smaller form of the text and then encrypt/sign that?

But the smaller piece of text (or “digest”) would have to reflect the whole text in some way or else we have the same forgery problem as above.There are ways to do this…

Digital Signatures V

Remember our original digital signature picture?

Digital Signatures VI

Signature Generation:

Signature Verification:

A Digitally Signed Message (PGP)

-----BEGIN PGP SIGNED MESSAGE-----Dear Alice: I'm getting very tired of cryptographers talking

about us behind our back. Why can't they keep their nosesin their own affairs?!

Really, it's enough to make me paranoid. Sincerely,

Bob -----BEGIN PGP SIGNATURE-----Version: 2.6.2iQB1AwUBL4XFS2F2HFbSU7RpAQEqsQMAvo3mETurtUnLBL

zCj9/U8oOQg/T7iQcJvzMedbCfdR6ah8sErMV+3VRid64o2h2XwlKAWpfVcC+2v5pba+BPvd86KIP1xRFIe3ipmDnMaYP+iVbxxBPVELundZZw7IRE=Xvrc

-----END PGP SIGNATURE-----

But we’ve made an assumption here…

We’ve assumed that there’s an easy and accurate way to look up the public key for someone.

What if some imposter just makes a web page, claims to be Bob Smith, and publishes a public key that is supposedly for Bob Smith (but it’s really for them).

Now this imposter could send us e-mails, sign them as Bob Smith, and we might now know the difference.

Verify a Public Key… How can we know that the public key we look up

for someone really is the correct public key for that person. (And not just some key put up by an imposter who’s pretending to be Bob Smith.)

Well, there’s companies that make a big business out of this. They keep secure registries of listings of actual people and corporations and store a copy of their official public key.

You can go to this trusted company and know you’re getting the right public key for Bob Smith.

A lot of business for one company…

But there could be millions of times a day that people need to check digital signatures. This could just overwhelm some company.

So, the one company can also verify that a second company is also a trustworthy place to ask about people’s public keys.

So, now future requests for verification of public keys can go to these sub-companies.

Chain of Trust I

There’s a “Chain of Trust.” Start with a ‘root’ and grow the trust tree/chain until we find a company that is willing to verify Bob Smith’s public key.

VeriSign

Microsoft

MSN

Bob Smith

Chain of Trust II

There’s a “Chain of Trust.” Start with a ‘root’ and grow the trust tree/chain until we find a company that is willing to verify Bob Smith’s public key.

VeriSign

Microsoft

MSN

Bob Smith

Sheila Roy

That slowness problem…

So, we’ve seen:• Symmetric Cryptography – Fast.• Asymmetric (or Public Key) Cryptography – Slow.• Digital Signatures (which use Private/Public Keys)

—Chains of Trust of public key verification.

We also saw how to deal with the slowness issue for digital signatures. (Using a “digest.”)

Is there any way we can compensate for slowness in the general message encoding task?• Can we get the speed of symmetric cryptography?• With the convenience of public key cryptography?

What’s the problem with each?

Asymmetric is slower than symmetric.

Symmetric is hard to use because you need a secret/secure way to agree on your shared key.

What if we use the slow asymmetric cryptography to send a very short message: We send the secret shared key for symmetric.

Then we use symmetric crypto from then on.

“Secure Socket Layer” Coding.

Secure Socket Layer Used by most websites for secure connections

and for financial transactions to keep info safe.

Encrypts the info you send to the site and the info it sends to you. It also authenticates that the site you are connected to is really who you think it is.

You can tell that this is being used when you see the little yellow padlock icon in Internet Explorer.

SSL uses Symmetric crypto, Asymmetric crypto, and Digital Signatures.

How does SSL Work? (1)

Go to a website for a financial transaction. It sends you a ‘certificate’ claiming to be some

organization and claiming to have some public key.

Your browser uses a chain of trust until it finds a site you trust to will “vouch” for the accuracy of the certificate the website sent you.

Now, you know that the Amazon.com site you are looking at is really authentic. You also know the public key for Amazon; so, you can send it stuff.

How does SSL Work? (2)

Now you can send stuff to Amazon securely using asymmetric public/private key cryptography. But this is a bit slow.

What do you send them? SHARED SECRET KEY.

If you both have this shared secret key, you can now use symmetric cryptography to do the rest of the transaction and send info in both directions. Symmetric crypto is a lot faster than asymmetric.

Look at a web page with a certificate… Check out www.citizensbank.com.

Go to the Personal Banking Log-in Page.

File: Properties: Certificates.

This webpage is digitally signed by the bank so that you know it is the official bank web page and not some kind of imposter.

In this case, a ‘root’ has directly verified the bank’s public key.

Key length and security in real use

How could we break each part of this?

Factoring is the method to break public/private keys;  to break a 1024-bit private key, one would need to factor an integer of length 1024 bits (or over 300 decimal digits), which is well beyond what anybody has done to date (currently people can factor numbers of about 130 digits with lots of computing power and time ….)

(from RSA Security)

Key length and security in real use II

But one can also attack encryption by trying to break the symmetric key….  Here, there’s no math trick to break it. You just try all the possible keys.

But adding just one bit to the length of a symmetric key doubles the number of possible keys and the amount of time that is needed to find the right one. 

For example, the number of possible keys in a 56-bit encrypted message is about 72 quadrillion keys, or 72,057,594,037,927,936. 

Symmetric keys typically have lengths between 40 and 128 bits.  Public keys typically have lengths between 512 and 2048 bits. Both the symmetric and public keys need to be long enough to withstand an attack.

(from RSA Security)

So We’ve Seen…

Symmetric Crypto – Fast, but hard to share secret Asymmetric Crypto – Slow but easier to set up

Digital Signatures – Uses Asymmetric, Digests, Chains of Trust

Secure Socket Layer – Uses all three of the above techniques to allow people to authenticate the sender of a web page and conduct secure business with it without having to use a lot of slow asymmetric cryptography.