Uses Uses of cryptography Lab today on RSA It’s not just to thwart eavesdroppers Data Integrity Authenticating people or data Non-repudiation Examples in chapter 9 Lab today on RSA

Hash functions Many applications in CS An efficient way to store lots of data, for easy retrieval later Quickly determine whether data has become corrupted Provide password security It’s a 1-way function: used to encrypt passwords When you enter your password, p, the system computes value of e(p) Your correct password, c, is already stored in encrypted form e(c) If e(p) == e(c), then you are “authenticated”

Hash functions (2) Why do it this way? One way to do it: If password file is compromised, thief really has no information If you lose your password, no one can retrieve it  very secure. In this case, a new password is generated One way to do it: Multiply first letter value by 3 Add 2nd letter value. Multiply answer by 3. Add 3rd letter value. Multiply answer by 3. Continue… At each point, take mod by a large prime ~ 1 billion

Hash functions (3) Another purpose: provide digital fingerprint to a file Associate with each file a single numerical value, like a serial number For example, the file size There is a slim chance that 2 files will map to the same number. Quick way to determine if your files have been altered or damaged. Saves space.

Breakability Cryptanalysis often relies on “exhaustive key search.” What does this mean? How does Moore’s Law relate? What can an attacker do to speed up a search? RSA & Diffie-Hellman rely on unsolvability of certain number theory problems (we have faith in them) But will someone discover short cuts? We should be seeking out better 1-way functions just in case! Learn from history.

Data integrity A hacker might not care what your message says Wants to modify / corrupt it Just encrypting your data won’t help Need to Recognize genuine data, unchanged from the source Detect unauthorized access or change (security) Preventing the attack might not be necessary We have backups of the data

Digital signature Proof of origin Sender can’t later deny sending message! In ordinary authentication, an imposter could have used Diffie-Hellman to pretend being A. DS relies on sender’s public and private keys The two keys are mathematically related Sender must use private key to compute the message’s digital signature (analogous to authentication value) Receiver uses sender’s public key to verify origin

Digital signature Similar to RSA Purpose: verify sender & integrity of message Useful when resolving disputes: non-repudiation When A sends message to B Message  private key  D.S. Append D.S. to the message B receives message (with D.S.) from A Separate the D.S. from body of the message. D.S.  public key  output Verify that the output matches the message. (To save time, the message is usually “hashed”)

E-commerce What are the relationships among: Other things to consider: Client (i.e. you) Server Bank Certification authority Other things to consider: How to set up your own online business The steps of a secure session Authentication Digital signature

Setting it up You have products to sell Create a Web site Subscribe for Web hosting, acquire HW/SW as needed Need accounts with a bank, and individual credit card merchant accounts, PayPal, etc. Subscribe to SSL service E.g. Verisign is now owned by Symantec Maintain database of transactions E.g. individual purchases

Secure Web session Here’s one way to do it. Client wants to buy goods on server’s secure site. Server sends its public key & authentication certificate to client. Client’s Web browser verifies certificate with CA Client uses RSA with server’s public key to encrypt DES key. Send to server. Server uses own RSA-private key to decrypt DES key. Now, both parties can communicate with DES.

Notes Why not just use RSA for everything? DES is much faster. We just use RSA to communicate the DES key. Client & server have “agreed” on a key, but we did not use Diffie-Hellman. DES key was chosen by the client, sent to server securely. Diffie-Hellman by itself can’t authenticate. Authentication goes both ways CA verifies server identity to client (you). Bank verifies client (you) to the server.