Cryptography

wanderooswarrenAI and Robotics

Nov 21, 2013 (3 years and 8 months ago)

71 views

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