Presentation is loading. Please wait.

Presentation is loading. Please wait.

Feb 25, 2003Mårten Trolin1 Previous lecture More on hash functions Digital signatures Message Authentication Codes Padding.

Similar presentations


Presentation on theme: "Feb 25, 2003Mårten Trolin1 Previous lecture More on hash functions Digital signatures Message Authentication Codes Padding."— Presentation transcript:

1 Feb 25, 2003Mårten Trolin1 Previous lecture More on hash functions Digital signatures Message Authentication Codes Padding

2 Feb 25, 2003Mårten Trolin2 This lecture General differences between asymmetric and symmetric cryptography General design of interactive protocols Key exchange Man-in-the-middle

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

4 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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 Feb 25, 2003Må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


Download ppt "Feb 25, 2003Mårten Trolin1 Previous lecture More on hash functions Digital signatures Message Authentication Codes Padding."

Similar presentations


Ads by Google