Cryptography
ECT 582
–
Winter 2004
Robin Burke
Discussion
Outline
Background
Symmetric encryption
Cryptographic attacks
Public

key encryption
Protecting message integrity
Digital signatures
Cryptographic software
Why cryptography?
Two roles
confidentiality
integrity
Essential security properties
especially important on a public
network
Cryptography in History
Very old
probably as old as writing
Hebrew ATBASH cipher
500

600 BC
Julius Caesar's substitution cipher
50

60 BC
Basic idea
Plaintext (P)
message to send
Alice
sender
Bob
recipient
Eve
eavesdropper
Ciphertext (C)
scrambled version of the message
Algorithm
technique for turning P into C (and back)
How it works
The algorithm f is a secret
shared by A and B
Process
A computes f(P) = C
Transmits C to B
B computes f'(C) = P
E doesn't know the secret
Problem
Secret algorithms hard to develop
Once disclosed
all messages readable
Better solution
f is a function of two values
f(k, P) = C
Usually reversible
f' (k, C) = P
k = the secret key
Symmetric encryption
Alice and Bob perform the same
operation
same key k
Benefits
Algorithm doesn't have to be secret
Disclosure of one key leaves other
message still protected
New problem
Shared secret
Alice and Bob need to know k
Why can't Alice encrypt k and send it
to Bob?
Attacks
confidentiality
Brute force
try every possible key
Cryptanalysis
use properties of encrypted message
to narrow range of possible keys
Cryptographic algorithms
Very difficult to develop
Existing algorithms
DES
•
obsolete
Triple DES
RCx
AES
IDEA
Blowfish
Differences
Key size
Variable
Fixed size
Proprietary vs open
History
Cryptographic strength
The Real Issue
Plaintext contains information
Ciphertext should "look random"
no information for cryptanalysis
How to do this
spread the information around
use the key as a seed for a complex
pattern
Brute force effort
We assume that keys are chosen
randomly
all bit patterns equally likely
Three bit key
2
3
= 8 possibilities from 000 to 111
How long to guess?
on average 4 guesses will be enough
Key Size
Larger key protects against a brute
force attack
56 bits = 72 quintillion keys
But
"Deep Crack" 90 billion keys / sec.
distributed.net 250 billion keys / sec.
Key Space
Whole key space isn't used?
less space to search
this can make a big difference
Passwords = poor keyspace
Can only use keyboard characters
People often use only a fraction of that
Sharing Secret Data
How do A and B agree on k?
Need an alternative secure channel
Solvable for spies
Unsolvable for the Internet
Public

key encryption
asymmetric
one key to encipher
another to decipher
A pair of functions
f
1
(k
1
, P) = C
f
2
(k
2
, C) = P
Public key = k
1
Private key = k
2
What's the big deal?
Shared secret no longer needed
k
1
can be divulged to the world
All it can do is encrypt
k
2
must be secret
Encryption mode
Alice gets Bob's public key b
1
Alice computes f
1
(b
1
, P) = C
Bob receives C
Bob computes f
2
(b
2
, C) = P
Authentication mode
Alice computes f
2
(a
2
, P) = C
Bob computes f
1
(a
1
, C) = P
anyone could do this
No privacy
but identifies origin
only Alice could have encoded C
Public

key algorithms
Very, very difficult to create
Algorithms
Diffie

Helman / ElGamal
RSA
Elliptic curve
RSA
Select e
Select p and q
prime
p

1 and e have no common divisors
q

1 and e also
public modulus n = pq
private modulus d
(de
–
1) divisible by (p
–
1) and (q
–
1)
RSA continued
public key
n + e
private key
n + d
P
e
mod n = C
C
d
mod n = P
Example: key generation
e = 5, p = 7, q = 17
n = 119
d = 77
de
–
1 = 384. divisible by 6 and 16.
k
1
= (5, 119)
k
2
= (77, 119),
Example: encryption
Encryption
P = 65 (ASCII 'A')
C = 65
5
mod 119 = 46
Decryption
C = 46
P = 46
77
mod 119 = 65
Example: authentication
P = 65
Authenticate
S = 65
77
mod 119 = 39
Send S, k1
Verify
P = 39
5
mod 119 = 65
Only the private key holder could have
sent
ElGamal
RSA depends on the mathematical
properties of primes
factoring of a large n
into primes p and q
ElGamal
uses "discrete logarithm"
ElGamal
Alice and Bob agree on
prime number p
generator a
Generation step
Alice generates a random number x
Bob generates a random number y
Exchange step
Alice sends Bob a
x
mod p
Bob sends Alice a
y
mod p
Shared key
Alice and Bob both compute K = a
xy
mod p
ElGamal
Eve listening
knows a and p
learns a
x
mod p and a
y
mod p
but cannot recover K
Note
Bob won't learn x either
Not useful for encryption
"One

way function"
Public key version
Bob generates both x and y
public key is a
y
mod p
Practical Cryptographic
Implementation
PGP
Uses RSA for public

key crypto
Problem
too slow
Solution
Use IDEA
Generate a symmetric key
Share it using RSA
PGP Dataflow
Protecting integrity
Message Authentication Code
Process
Alice writes P
Alice computes m(P) = M
Alice sends Bob P + M
Bob computes m(P). Compares M
Useful even if P is not encrypted
Attacks
If Eve modifies P
P'
Bob computes m(P').
Won't match M
What if Eve modifies P
P' and
also computes m(P') = M'
sends P' + M'
m also needs a shared secret
m(k, P)
MAC Features
should be much shorter than the
original message
small change in message should
result in very different MAC
difficult to reverse engineer
Digital Signatures
MAC does not support non

repudiation
Bob could receive P + M
verify that it came from Alice
But Bob could also alter P
P'
recompute m(k, P') = M'
Tell the judge that Alice sent P' + M'
how to prove otherwise
Digital Signature
Authentication
Only Alice can compute
f
2
(k
2
, P) = C
Combine with a message
P + C
Now anyone can check that P
matches C
Bob could not generate C
DSA
Federal standard
Uses a variant of ElGamal
Three public values
p = prime modulus
q = prime divisor of p

1
g = j
(p

1)/q
mod p
where j is a random integer < p
To sign
Generate a hash h of P
Pick a random number k
Generate two values
r = (g
k
mod p) mod q
s = (k

1
(h + kr) mod q
where (k

1
k) mod q = 1
Send message P + r + s
To verify
(complicated)
Receive message P' with r' and s'
Compute hash h' of received P'
w = s'

1
mod q
u1 = h' w mod q
u2 = r' w mod q
v = (g
u1
y
u2
mod p) mod q
r' should equal v
Attacker
Knows p, q, and g
Does not know k
Infeasible to compute the r, s pair
without knowing k
Elliptic curve
Math is very complex
But the basic idea is that we define a
curve
y
2
+ xy = x
3
+ ax
2
+ b
the parameters of the curve are the
secret knowledge
Encryption
P and Q are points on the curve
P+Q is defined geometrically
k*P = C
Encryption, cont'd
A specific base point G is selected and
published for use with the curve E(q).
A private key k is selected as a random
integer;
the value P = k*G is published as the public
key
If Alice and Bob have private keys kA and
kB, and public keys PA and PB, then
Alice can calculate kA*PB = (kA*kB)*G; and
Bob can compute the same value as kB*PA
= (kB*kA)*G.
Elliptic curve
Benefits
Faster to compute than RSA or
ElGamal
Computationally "harder" inverse
problem = better security for same key
size
Drawback
still somewhat new
maybe flaws not yet known
Attacking digital signatures
Bob wants to send Alice a secure message P
Eve wants to modify it
Bob signs P with private key k
b1,
creating MAC M
Bob sends P + M + k
b2
to Alice
Eve intercepts this message
Eve creates a modified message P'
Signs it with her private key k
e1
Sends P' + M' + k
e2
Alice gets P'
Verifies the signature against the public key
Eve wins
Man in the middle
The "man in the middle" can masquerade
as the sender
DSA has no authentication defense
We know
the message was unchanged since signing
whoever signed it used the private key that
matches the supplied public key
We don't know
that the signer is actually the sender
who does the public key belong to?
Answer: next two weeks
Public key certificates
Public key infrastructure
Read
Ford & Baum, Ch. 6
Assignment #2
Question 1
effectiveness of brute force
Questions 2 & 3 running PGP
use shrike
Question 4
1

2 page discussion of the results of 2
& 3
Comments 0
Log in to post a comment