What did we talk about last time? Public key cryptography A little number theory

Week 4 - Friday

What did we talk about last time? Public key cryptography A little number theory

If p is prime and a is a positive integer not divisible by p, then: a p 1 1 (mod p)

Assume a is positive and less than p Consider the sequence a, 2a, 3a,, (p 1)a If these are taken mod p, we will get: 1, 2, 3,, p 1 This bit is the least obvious part of the proof However (because p is prime) if you add any non-zero element repeatedly, you will eventually get back to the starting point, covering all values (except 0) once Multiplying this sequence together gives: a 2a 3a (p 1)a 1 2 3 (p 1) (mod p) a p 1 (p 1)! (p 1)! (mod p) a p 1 1 (mod p)

Euler s totient function (n) (n) = the number of positive integers less than n and relatively prime to n (including 1) If p is prime, then (p) = p 1 If we have two primes p and q (which are different), then: (pq) = (p) (q) = (p 1)(q 1)

Euler s Theorem: For every a and n that are relatively prime, a (n) 1 (mod n) This generalizes Fermat s Theorem because (p) = p 1 if p is prime Proof is messier

Named for Rivest, Shamir, and Adleman Take a plaintext M converted to an integer Create an ciphertext C as follows: C = M e mod n Decrypt C back into M as follows: M = C d mod n = (M e ) d mod n = M ed mod n

Term Details Source M Message to be encrypted Sender C Encrypted message Computed by sender n Modulus, n = pq Known by everyone p Prime number Known by receiver q Prime number Known by receiver e Encryption exponent Known by everyone d Decryption exponent Computed by receiver (n) Totient of n Known by receiver

To encrypt: C = M e mod n e could be 3 and is often 65537, but is always publically known To decrypt: M = C d mod n = M ed mod n We get d by finding the multiplicative inverse of e mod (n) So, ed 1 (mod (n))

We know that ed 1 (mod (n)) This means that ed = k (n) + 1 for some nonnegative integer k M ed = M k (n) + 1 M (M (n) ) k (mod n) By Euler s Theorem M (n) 1 (mod n) So, M (M (n) ) k M (mod n)

M = 26 p = 17, q = 11, n = 187, e = 3 C = M 3 mod 187 = 185 (n) = (p 1)(q 1) = 160 d = e -1 mod 160 = 107 C d = 185 107 mod 187 = 26 If you can trust my modular arithmetic

You can t compute the multiplicative inverse of e mod (n) unless you know what (n) is If you know p and q, finding (n) is easy Finding (n) is equivalent to finding p and q by factoring n No one knows an efficient way to factor a large composite number

Public key cryptography would come crashing down if Advances in number theory could make RSA easy to break Quantum computers could make it easy to factor large composites

Choose your primes carefully p < q < 2p But, the primes can't be too close together either Some standards insist that p and q are strong primes, meaning that p 1 = 2m and p + 1 = 2n where m and n have large prime factors There are ways to factor poorly chosen pairs of primes Pad your data carefully Take the example of a credit card number If you know a credit card number is encrypted using RSA using a public n and an e of 3, how do you discover the credit card number?

Once you have great cryptographic primitives, managing keys is still a problem How do you distribute new keys? When you have a new user When old keys have been cracked or need to be replaced How do you store keys? As with the One Time Pad, if you could easily send secret keys confidentially, why not send messages the same way?

We will refer to several schemes for sending data Let X and Y be parties and Z be a message { Z } k means message Z encrypted with key k Thus, our standard notation will be: X Y: { Z } k Which means, X sends message Z, encrypted with key k, to Y X and Y will be participants like Alice and Bob and k will be a clearly labeled key A B means concatenate message A with B

Typical to key exchanges is the idea of interchange keys and session keys An interchange key is a key associated with a particular user over a (long) period of time A session key is a key used for a particular set of communication events Why have both kinds of keys?

If only a single key (instead of interchange and session keys) were used, participants are more vulnerable to: Known plaintext attacks (and potentially chosen plaintext attacks) Attacks requiring many copies of encrypted material for comparison Replay attacks in which old encrypted data is sent again from a malicious party Forward search attacks in which a user computes many likely messages using a public key and thereby learns the contents of such a message when it is sent

To be secure, a key exchange whose goal is to allow secret communication from Alice to Bob must meet this criteria: 1. Alice and Bob cannot transmit their key unencrypted 2. Alice and Bob may decide to trust a third party (Cathy or Trent) 3. Cryptosystems and protocols must be public, only the keys are secret

If Bob and Alice have no prior arrangements, classical cryptosystems require a trusted third party Trent Trent and Alice share a secret key k Alice and Trent and Bob share a secret key k Bob Here is the protocol: 1. Alice Trent: {request session key to Bob} k Alice 2. Trent Alice: { k session } k Alice { k session } k Bob 3. Alice Bob: { k session } k Bob

Unfortunately, this protocol is vulnerable to a replay attack (Evil user) Eve records { k session } k Bob sent in step 3 and also some message enciphered with k session (such as "Deposit $500 in Dan's bank account") Eve can send the session key to Bob and then send the replayed message Maybe Eve is in cahoots with Dan to get him paid twice Eve may or may not know the contents of the message she is sending The real problem is no authentication

We modify the protocol to add random numbers (called nonces) and user names for authentication 1. Alice Trent: { Alice Bob rand 1 } k Alice 2. Trent Alice: { Alice Bob rand 1 k session {Alice k session }k Bob } k Alice 3. Alice Bob: { Alice k session }k Bob 4. Bob Alice: { rand 2 } k session 5. Alice Bob: { rand 2 1 } k session

Needham-Schroeder assumes that all keys are secure Session keys may be less secure since they are generated with some kind of (possibly predictable) pseudorandom generator If Eve can recover a session key (maybe after a great deal of computational work), she can trick Bob into thinking she's Alice as follows: 1. Eve Bob: { Alice k session }k Bob 2. Bob Alice: { rand 3 } k session [intercepted by Eve] 3. Eve Bob: { rand 3 1 } k session

Denning and Sacco use timestamps (T) to let Bob detect the replay 1. Alice Trent: { Alice Bob rand 1 } k Alice 2. Trent Alice: { Alice Bob rand 1 k session {Alice T k session }k Bob } k Alice 3. Alice Bob: { Alice T k session }k Bob 4. Bob Alice: { rand 2 } k session 5. Alice Bob: { rand 2 1 } k session Unfortunately, this system requires synchronized clocks and a useful definition of when timestamp T is "too old"

The Otway-Rees protocol fixes these problem by using a unique integer num to label each session 1. Alice Bob: num Alice Bob { rand 1 num Alice Bob } k Alice 2. Bob Trent: num Alice Bob {rand 1 num Alice Bob } k Alice { rand 2 num Alice Bob } k Bob 3. Trent Bob: num { rand 1 k session } k Alice { rand 2 k session } k Bob 4. Bob Alice: num { rand 1 k session } k Alice

Strange as it seems, these key exchange protocols are actually used Kerberos was created at MIT as a modified Needham- Schroeder protocol (with timestamps) Originally used to control access to network services for MIT students and staff Current versions of Windows use a modified version of Kerberos for authentication Many Linux and Unix implementations have an implementation of Kerberos Kerberos uses a central server that issues tickets to users which give them the authority to access a service on some other server

Suddenly, the sun comes out! Public key exchanges should be really easy The basic outline is: 1. Alice Bob: { k session } e Bob e Bob is Bob's public key Only Bob can read it, everything's perfect! Except There is still no authentication

Alice only needs to encrypt the session key with her private key That way, Bob will be able to decrypt it with her public key when it arrives New protocol: 1. Alice Bob: {{ k session } d Alice }e Bob Any problems now?

A vulnerability arises if Alice needs to fetch Bob's public key from a public server Peter Then, Eve can cause problems Attack: 1. Alice Peter: Send me Bob's key [intercepted by Eve] 2. Eve Peter: Send me Bob's key 3. Peter Eve: e Bob 4. Eve Alice: e Eve 5. Alice Bob: { k session } e Eve [intercepted by Eve] 6. Eve Bob { k session } e Bob

The previous man in the middle attack shows a significant problem How do we know whose public key is whose? We could sign a public key with a private key, but then We would still be dependent on knowing the public key matching the private key used for signing It's a massive chicken and egg or bootstrapping problem

A typical approach is to create a long chain of individuals you trust Then, you can get the public key from someone you trust who trusts someone else who etc. This can be arranged in a tree layout, with a central root certificate everyone knows and trusts This system is used by X.509 Alternatively, it can be arranged haphazardly, with an arbitrary web of trust This system is used by PGP, which incorporates different levels of trust

Finish key management Hash functions David Gallop presents

Read section 12.4 Finish Project 1 Due tonight by midnight!