Applied Cryptography

Feb 25, 2003

Mårten Trolin

1

Previous lecture

•
More on hash functions

•
Digital signatures

•
Message Authentication Codes

•
Padding

Feb 25, 2003

Mårten Trolin

2

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

3

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

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)

Feb 25, 2003

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?

Feb 25, 2003

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

Feb 25, 2003

Mårten Trolin

7

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

Feb 25, 2003

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.

Feb 25, 2003

Mårten Trolin

9

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

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

Feb 25, 2003

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.

Feb 25, 2003

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)

Feb 25, 2003

Mårten Trolin

13

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

Feb 25, 2003

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
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

Feb 25, 2003

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.

Feb 25, 2003

Mårten Trolin

16

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
)

p
m

Decrypts
k

using
s
m

and reencrypts
using

p
u

Symmetric key
k

encrypted under
p
u

Feb 25, 2003

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