Previous lecture

1. Previous lecture • More on hash functions • Digital signatures • Message Authentication Codes • Padding Mårten Trolin

2. This lecture • General differences between asymmetric and symmetric cryptography • General design of interactive protocols • Key exchange • Man-in-the-middle Mårten Trolin

3. Symmetric vs. asymmetric cryptography • Asymmetric cryptography has easier key management • Why not always use asymmetric cryptography • Slower • Needs longer keys Mårten Trolin

4. When to use what type • Symmetric • Speed • Key size • Signature size (MACs) • Asymmetric • Key distribution • Parties with no secure side-channel (for key distribution) Mårten Trolin

5. 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? Mårten Trolin

6. 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 Mårten Trolin

7. Interactive protocols – first approach • We try with public key cryptography TCP/IP User Web server User’s public key pu Server’s public key ps Request encrypted under ps Response encrypted under pu Mårten Trolin

8. 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. Mårten Trolin

9. Interactive protocols – second approach • We try with secret key cryptography TCP/IP User Web server User and web server decideson a symmetric key k Request encrypted under k Response encrypted under k Mårten Trolin

10. 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 Mårten Trolin

11. 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. Mårten Trolin

12. 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) Mårten Trolin

13. Key exchange – general idea TCP/IP User(pu, su) Web server User’s public key pu Generates symmetric key k Symmetric key k encrypted under pu Decrypts k using su Communication encrypted under k Mårten Trolin

14. 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 su, server n-bit ss. The key s is computed as s = suss • Key exchange should be repeated at regular intervals Mårten Trolin

15. 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. Mårten Trolin

16. User(pu, su) Man in the middle(pm, sm) Web server User’s public key pu Replaces pu with his own pm pm Generates symmetric key k Decrypts k using sm and reencrypts using pu Symmetric key k encrypted under pu Symmetric key k encrypted under pm Decrypts k using su Communication encrypted under k Mårten Trolin

17. 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 Mårten Trolin