Transcript Lecture 4
Previous lecture
•
•
•
•
More on hash functions
Digital signatures
Message Authentication Codes
Padding
Feb 25, 2003
Mårten Trolin
1
This lecture
• General differences between asymmetric and symmetric
cryptography
• General design of interactive protocols
• Key exchange
• Man-in-the-middle
Feb 25, 2003
Mårten Trolin
2
Symmetric vs. asymmetric
cryptography
• Asymmetric cryptography has easier key management
• Why not always use asymmetric cryptography
– Slower
– Needs longer keys
Feb 25, 2003
Mårten Trolin
3
When to use what type
• Symmetric
– Speed
– Key size
– Signature size (MACs)
• Asymmetric
– Key distribution
– Parties with no secure side-channel (for key distribution)
Feb 25, 2003
Mårten Trolin
4
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?
Feb 25, 2003
Mårten Trolin
5
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
Feb 25, 2003
Web server
Mårten Trolin
6
Interactive protocols – first approach
• We try with public key cryptography
TCP/IP
User
User’s public key pu
Web server
Server’s public key ps
Request encrypted under ps
Response encrypted under pu
Feb 25, 2003
Mårten Trolin
7
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.
Feb 25, 2003
Mårten Trolin
8
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
Feb 25, 2003
Mårten Trolin
9
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
Feb 25, 2003
Mårten Trolin
10
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.
Feb 25, 2003
Mårten Trolin
11
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)
Feb 25, 2003
Mårten Trolin
12
Key exchange – general idea
TCP/IP
User User’s public key p
u
(pu, su)
Decrypts k
using su
Feb 25, 2003
Web server
Generates
symmetric key k
Symmetric key k encrypted under pu
Communication encrypted under k
Mårten Trolin
13
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
Feb 25, 2003
Mårten Trolin
14
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.
Feb 25, 2003
Mårten Trolin
15
User
(pu, su)
Man in the middle
(pm, sm)
User’s public
key pu
Symmetric key k
encrypted under pu
Replaces pu with
his own pm
Web server
pm
Generates symmetric
key k
Decrypts k using
Symmetric key k
sm and reencrypts
encrypted under pm
using pu
Decrypts k
using su
Communication encrypted under k
Feb 25, 2003
Mårten Trolin
16
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
Feb 25, 2003
Mårten Trolin
17