Cryptography ECT 582 – Winter 2004 Robin Burke

Discussion

Outline Background Symmetric encryption Cryptographic attacks Public-key encryption Protecting message integrity Digital signatures Cryptographic software

Why cryptography? Two roles confidentiality integrity Essential security properties especially important on a public network

Cryptography in History Very old probably as old as writing Hebrew ATBASH cipher BC Julius Caesar's substitution cipher BC

Basic idea Plaintext (P) message to send Alice sender Bob recipient Eve eavesdropper Ciphertext (C) scrambled version of the message Algorithm technique for turning P into C (and back)

How it works The algorithm f is a secret shared by A and B Process A computes f(P) = C Transmits C to B B computes f'(C) = P E doesn't know the secret

Problem Secret algorithms hard to develop Once disclosed all messages readable

Better solution f is a function of two values f(k, P) = C Usually reversible f' (k, C) = P k = the secret key

Symmetric encryption Alice and Bob perform the same operation same key k Benefits Algorithm doesn't have to be secret Disclosure of one key leaves other message still protected

New problem Shared secret Alice and Bob need to know k Why can't Alice encrypt k and send it to Bob?

Attacks confidentiality Brute force try every possible key Cryptanalysis use properties of encrypted message to narrow range of possible keys

Cryptographic algorithms Very difficult to develop Existing algorithms DES obsolete Triple DES RCx AES IDEA Blowfish

Differences Key size Variable Fixed size Proprietary vs open History Cryptographic strength

The Real Issue Plaintext contains information Ciphertext should "look random" no information for cryptanalysis How to do this spread the information around use the key as a seed for a complex pattern

Brute force effort We assume that keys are chosen randomly all bit patterns equally likely Three bit key 2 3 = 8 possibilities from 000 to 111 How long to guess? on average 4 guesses will be enough

Key Size Larger key protects against a brute force attack 56 bits = 72 quintillion keys But "Deep Crack" 90 billion keys / sec. distributed.net 250 billion keys / sec.

Key Space Whole key space isn't used? less space to search this can make a big difference Passwords = poor keyspace Can only use keyboard characters People often use only a fraction of that

Sharing Secret Data How do A and B agree on k? Need an alternative secure channel Solvable for spies Unsolvable for the Internet

Public-key encryption asymmetric one key to encipher another to decipher A pair of functions f 1 (k 1, P) = C f 2 (k 2, C) = P Public key = k 1 Private key = k 2

What's the big deal? Shared secret no longer needed k 1 can be divulged to the world All it can do is encrypt k 2 must be secret

Encryption mode Alice gets Bob's public key b 1 Alice computes f 1 (b 1, P) = C Bob receives C Bob computes f 2 (b 2, C) = P

Authentication mode Alice computes f 2 (a 2, P) = C Bob computes f 1 (a 1, C) = P anyone could do this No privacy but identifies origin only Alice could have encoded C

Public-key algorithms Very, very difficult to create Algorithms Diffie-Helman / ElGamal RSA Elliptic curve

RSA Select e Select p and q prime p-1 and e have no common divisors q-1 and e also public modulus n = pq private modulus d (de – 1) divisible by (p – 1) and (q – 1)

RSA continued public key n + e private key n + d P e mod n = C C d mod n = P

Example: key generation e = 5, p = 7, q = 17 n = 119 d = 77 de – 1 = 384. divisible by 6 and 16. k 1 = (5, 119) k 2 = (77, 119),

Example: encryption Encryption P = 65 (ASCII 'A') C = 65 5 mod 119 = 46 Decryption C = 46 P = mod 119 = 65

Example: authentication P = 65 Authenticate S = mod 119 = 39 Send S, k1 Verify P = 39 5 mod 119 = 65 Only the private key holder could have sent

ElGamal RSA depends on the mathematical properties of primes factoring of a large n into primes p and q ElGamal uses "discrete logarithm"

ElGamal Alice and Bob agree on prime number p generator a Generation step Alice generates a random number x Bob generates a random number y Exchange step Alice sends Bob a x mod p Bob sends Alice a y mod p Shared key Alice and Bob both compute K = a xy mod p

ElGamal Eve listening knows a and p learns a x mod p and a y mod p but cannot recover K Note Bob won't learn x either Not useful for encryption "One-way function"

Public key version Bob generates both x and y public key is a y mod p

Practical Cryptographic Implementation PGP Uses RSA for public-key crypto Problem too slow Solution Use IDEA Generate a symmetric key Share it using RSA

PGP Dataflow

Protecting integrity Message Authentication Code Process Alice writes P Alice computes m(P) = M Alice sends Bob P + M Bob computes m(P). Compares M Useful even if P is not encrypted

Attacks If Eve modifies P  P' Bob computes m(P'). Won't match M What if Eve modifies P  P' and also computes m(P') = M' sends P' + M' m also needs a shared secret m(k, P)

MAC Features should be much shorter than the original message small change in message should result in very different MAC difficult to reverse engineer

Digital Signatures MAC does not support non- repudiation Bob could receive P + M verify that it came from Alice But Bob could also alter P  P' recompute m(k, P') = M' Tell the judge that Alice sent P' + M' how to prove otherwise

Digital Signature Authentication Only Alice can compute f 2 (k 2, P) = C Combine with a message P + C Now anyone can check that P matches C Bob could not generate C

DSA Federal standard Uses a variant of ElGamal Three public values p = prime modulus q = prime divisor of p-1 g = j (p-1)/q mod p where j is a random integer < p

To sign Generate a hash h of P Pick a random number k Generate two values r = (g k mod p) mod q s = (k -1 (h + kr) mod q where (k -1 k) mod q = 1 Send message P + r + s

To verify (complicated) Receive message P' with r' and s' Compute hash h' of received P' w = s' -1 mod q u1 = h' w mod q u2 = r' w mod q v = (g u1 y u2 mod p) mod q r' should equal v

Attacker Knows p, q, and g Does not know k Infeasible to compute the r, s pair without knowing k

Elliptic curve Math is very complex But the basic idea is that we define a curve y 2 + xy = x 3 + ax 2 + b the parameters of the curve are the secret knowledge

Encryption P and Q are points on the curve P+Q is defined geometrically k*P = C

Encryption, cont'd A specific base point G is selected and published for use with the curve E(q). A private key k is selected as a random integer; the value P = k*G is published as the public key If Alice and Bob have private keys kA and kB, and public keys PA and PB, then Alice can calculate kA*PB = (kA*kB)*G; and Bob can compute the same value as kB*PA = (kB*kA)*G.

Elliptic curve Benefits Faster to compute than RSA or ElGamal Computationally "harder" inverse problem = better security for same key size Drawback still somewhat new maybe flaws not yet known

Attacking digital signatures Bob wants to send Alice a secure message P Eve wants to modify it Bob signs P with private key k b1, creating MAC M Bob sends P + M + k b2 to Alice Eve intercepts this message Eve creates a modified message P' Signs it with her private key k e1 Sends P' + M' + k e2 Alice gets P' Verifies the signature against the public key Eve wins

Man in the middle The "man in the middle" can masquerade as the sender DSA has no authentication defense We know the message was unchanged since signing whoever signed it used the private key that matches the supplied public key We don't know that the signer is actually the sender who does the public key belong to?

Answer: next two weeks Public key certificates Public key infrastructure Read Ford & Baum, Ch. 6

Assignment #2 Question 1 effectiveness of brute force Questions 2 & 3 running PGP use shrike Question page discussion of the results of 2 & 3