1. Mar 5, 2002Mårten Trolin1 Previous lecture More on hash functions Digital signatures Message Authentication Codes Padding

2. Mar 5, 2002Mårten Trolin2 This lecture General differences between asymmetric and symmetric cryptography General design of interactive protocols Key exchange Man-in-the-middle Diffie-Hellman key agreement

3. Mar 5, 2002Mårten Trolin3 Symmetric vs. asymmetric cryptography Asymmetric cryptography has easier key management Why not always use asymmetric cryptography –Slower –Needs longer keys

4. Mar 5, 2002Mårten Trolin4 When to use what type Symmetric –Speed –Key size –Signature size (MACs) Asymmetric –Key distribution –Parties with no secure side-channel (for key distribution)

5. Mar 5, 2002Mårten Trolin5 Communication with many parties Example: Users want to connect securely to web sites There are many web sites There are even more users Impossible for each web site to know all its potential visitors The solution – use public key cryptography –What if public key cryptography is too slow?

6. Mar 5, 2002Mårten Trolin6 Designing interactive protocols The web surfer (user) and the web server wishes to exchange large amount of information The user will send a request, and the server will answer (think http!) TCP/IP User Web server

7. Mar 5, 2002Mårten Trolin7 Interactive protocols – first approach We try with public key cryptography TCP/IP User Web server User’s public key p u Server’s public key p s Request encrypted under p s Response encrypted under p u

8. Mar 5, 2002Mårten Trolin8 Problems with first approach Speed –Each public key operation takes a significant amount of time. When used on large messages this becomes significant. –The server may have to handle several hundred connections simultanously, making encryption slow. Size –For encryption the message has to split into smaller messages that can be encrypted. –Since public key cryptography is more vulnerable to “weak clear texts” (e.g., small numbers) some padding technique must be used on every block. This makes the cipher text much longer than the clear text.

9. Mar 5, 2002Mårten Trolin9 Interactive protocols – second approach We try with secret key cryptography TCP/IP User Web server User and web server decides on a symmetric key k Request encrypted under k Response encrypted under k

10. Mar 5, 2002Mårten Trolin10 Problems with second approach Encryption and decryption is fast, cipher text not much larger than the clear text, but... How does the user and the web server decide on a common secret key? –The user and the web server physically exchange data –The web server sends the key to the user via a secure off-line channel (registered mail etc.) Feasible only when the number of users is low, and there is time to do key-exchange off-line –Possible solution for Internet banking, but not for e-commerce

11. Mar 5, 2002Mårten Trolin11 Interactive protocols Both the public key and secret key approach has serious problems. What we want – use symmetric cryptography for encryption of the traffic, but avoid the need for complicated off-line key exchange schemes.

12. Mar 5, 2002Mårten Trolin12 Key exchange The symmetric key can be sent encrypted under the public key Either party can create the key (or they can create it together) Other techniques for key exchange exist (Diffie-Hellman)

13. Mar 5, 2002Mårten Trolin13 Key exchange – general idea TCP/IP User (p u, s u ) Web server User’s public key p u Symmetric key k encrypted under p u Communication encrypted under k Generates symmetric key k Decrypts k using s u

14. Mar 5, 2002Mårten Trolin14 Key exchange – possible enhancements Both parties can take part in key generation Assuming the length of the symmetric key s is n, the following variants are possible –First n / 2 bits of s are created by user, last n / 2 by server –User creates n-bit s u, server n-bit s s. The key s is computed as s = s u  s s Key exchange should be repeated at regular intervals

15. Mar 5, 2002Mårten Trolin15 Man-in-the-middle Access to the key exchange does not give you any useful information about the key. A person that can modify messages can use this to gain knowledge of the symmetric key. This kind of attack is for obvious reasons known as a man-in-the-middle attack.

16. Mar 5, 2002Mårten Trolin16 User (p u, s u ) Web server User’s public key p u Symmetric key k encrypted under p m Communication encrypted under k Generates symmetric key k Decrypts k using s u Replaces p u with his own p m Man in the middle (p m, s m ) pmpm Decrypts k using s m and reencrypts using p u Symmetric key k encrypted under p u

17. Mar 5, 2002Mårten Trolin17 Man-in-the-middle After this scheme, the Man-in-the-middle knows the symmetric key k, and can decrypt (or modify) data as he wishes. Different techniques exist to address this problems –Public key certificates

18. Mar 5, 2002Mårten Trolin18 Diffie-Hellman The first public key type result to be published! Performs agreement on a common key without a need for the parties to have public and private keys

19. Mar 5, 2002Mårten Trolin19 Diffie-Hellman key agreement TCP/IP User Web server Sends x ( = g a mod p) Communication encrypted under k = g ab mod p Generates a number 0 < a < p and computes x = g a mod p Decides on a prime p and a number g < p Generates a number 0 < b < p and computes y = g b mod p Sends y ( = g b mod p) Computes k = x b mod p Computes k = y a mod p

20. Mar 5, 2002Mårten Trolin20 Diffie-Hellman key agreement The user computes x b = (g a ) b mod p The server computes y a = (g b ) a mod p Since (g a ) b = g ab = g ba = (g b ) a mod p both parties will use the same key!