0% found this document useful (0 votes)
80 views87 pages

Cryptography Overview: John Mitchell

This document provides an overview of the CS155 cryptography course taught in Spring 2010, including topics like Caesar ciphers, the Enigma machine, information theory, complexity theory, public key cryptography, SSL/TLS, symmetric ciphers, hash functions, and message authentication codes.

Uploaded by

WIBF Kevin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
80 views87 pages

Cryptography Overview: John Mitchell

This document provides an overview of the CS155 cryptography course taught in Spring 2010, including topics like Caesar ciphers, the Enigma machine, information theory, complexity theory, public key cryptography, SSL/TLS, symmetric ciphers, hash functions, and message authentication codes.

Uploaded by

WIBF Kevin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 87

CS155 Spring 2010

Cryptography Overview

John Mitchell
Caesar cipher
German Enigma
Information theory

Claude Shannon
Complexity theory
hard PSpace

NP

BPP

easy
25
Elliptic curves

20

15

10

0
0 2 4 6 8 10 12 14 16 18 20
Cryptography
Is
 A tremendous tool
 The basis for many security mechanisms
Is not
 The solution to all security problems
 Reliable unless implemented properly
 Reliable unless used properly
 Something you should try to invent yourself unless
 you spend a lot of time becoming an expert
 you subject your design to outside review
Basic Cryptographic Concepts
Encryption scheme:
 functions to encrypt, decrypt data
Symmetric encryption
 Block, stream ciphers
Hash function, MAC
 Map any input to short hash; ideally, no collisions
 MAC (keyed hash) used for message integrity
Public-key cryptography
 PK encryption: public key does not reveal key-1
 Signatures: sign data, verify signature
Example: network transactions

Assume attackers can control the network


 We will talk about how they do this in a few weeks
 Attackers can intercept packets, tamper with or suppress them, and inject arbitrary packets
Secure communication
 Based on
 Cryptography
 Key management protocols
Secure Sockets Layer / TLS
Standard for Internet security
 Originally designed by Netscape
 Goal: “... provide privacy and reliability between two
communicating applications”
Two main parts
 Handshake Protocol
 Establish shared secret key using public-key cryptography
 Signed certificates for authentication
 Record Layer
 Transmit data using negotiated key, encryption function
SSL/TLS Cryptography
Public-key encryption
 Key chosen secretly (handshake protocol)
 Key material sent encrypted with public key
Symmetric encryption
 Shared (secret) key encryption of data packets
Signature-based authentication
 Client can check signed server certificate
 And vice-versa, if client certificates used
Hash for integrity
 Client, server check hash of sequence of messages
 MAC used in data packets (record protocol)
Goal 2: protected files
Disk

Alice File 1 Alice

No eavesdropping
No tampering
File 2

Analogous to secure communication:


Alice today sends a message to Alice tomorrow
Symmetric Cryptography
Symmetric encryption
Alice Bob
m, n E(k,m,n)=c c, n D(k,c,n)=m
E D

k k
E, D: cipher k: secret key (e.g., 128 bits)
m, c: plaintext, ciphertext n: nonce (aka IV)

Encryption algorithm is publicly known



Never use a proprietary cipher
First example: One Time Pad
(single use key)

Vernam (1917)

Key: 0 1 0 1 1 1 0 0 1 0

Plaintext: 1 1 0 0 0 1 1 0 0 0

Ciphertext: 1 0 0 1 1 0 1 0 1 0

Shannon ‘49:
 OTP is “secure” against ciphertext-only attacks
Stream ciphers (single use key)

Problem: OTP key is as long the message


Solution: Pseudo random key -- stream ciphers
key

c PRBG(k) m
PRBG

 message

ciphertext

Stream ciphers: RC4 (113MB/sec) , SEAL (293MB/sec)


Dangers in using stream ciphers
One time key !! “Two time pad” is insecure:

C1  m1  PRBG(k)
C2  m2  PRBG(k)

Eavesdropper does:
C1  C2  m1  m2

Enough redundant information in English that:


m1  m2  m1 , m2
Symmetric encryption: nonce (IV)
nonce
Alice Bob
m, n E(k,m,n)=c c, n D(k,c,n)=m
E D

k k

E, D: cipher k: secret key (e.g., 128 bits)


m, c: plaintext, ciphertext n: nonce (aka IV)
Use Cases
Single use key: (one time key)
 Key is only used to encrypt one message
 encrypted email: new key generated for every email
 No need for nonce (set to 0)
Multi use key:
 Key used to encrypt multiple messages
 SSL: same key used to encrypt many packets
 Need either unique nonce or random nonce
Multi use key, but all plaintexts are distinct:
 Can eliminate nonce (use 0) using special mode (SIV)
Block ciphers: crypto work horse
n Bits n Bits
PT Block E, D CT Block

Key k Bits

Canonical examples:
1. 3DES: n= 64 bits, k = 168 bits
2. AES: n=128 bits, k = 128, 192, 256 bits
IV handled as part of PT block
Building a block cipher
Input: (m, k)
Repeat simple mixing operation several times
 DES: Repeat 16 times:
mL  mR
mR  mLF(k,mR)

 AES-128: Mixing step repeated 10 times

Difficult to design: must resist subtle attacks


 differential attacks, linear attacks, brute-force, …
Block Ciphers Built by Iteration
key k

key expansion

k1 k2 k3 kn
R(k1, )

R(k2, )

R(k3, )

R(kn, )
m c

R(k,m): round function


for DES (n=16), for AES (n=10)
Incorrect use of block ciphers
Electronic Code Book (ECB):
PT: m1 m2

CT: c1 c2

Problem:
 if m1=m2 then c1=c2
In pictures
Correct use of block ciphers I: CBC mode
E a secure PRP. Cipher Block Chaining with IV:

IV m[0] m[1] m[2] m[3]

   

E(k,) E(k,) E(k,) E(k,)

IV c[0] c[1] c[2] c[3]

ciphertext
Q: how to do decryption?
Use cases: how to choose an IV
Single use key: no IV needed (IV=0)

Multi use key: (CPA Security)

Best: use a fresh random IV for every message (IV  X)

Can use unique IV (e.g counter) [Bitlocker]


but then first step in CBC must be IV’  E(k,IV)
benefit: may save transmitting IV with ciphertext

Multi-use key, but unique messages


SIV: eliminate IV by setting IV  F(k’, PT)
F: secure PRF with key k’
CBC with Unique IVs
unique IV means: (k,IV) pair is used for only one message
may be predictable so use E(k,) as PRF

IV m[0] m[1] m[2] m[3]

IV′
   

E(k,) E(k,) E(k,) E(k,) E(k,)

IV c[0] c[1] c[2] c[3]

ciphertext
In pictures
Correct use of block ciphers II: CTR mode

Counter mode with a random IV: (parallel encryption)

IV m[0] m[1] … m[L]



E(k,IV) E(k,IV+1) … E(k,IV+L)

IV c[0] c[1] … c[L]


ciphertext

• Why are these modes secure? not today.


Performance: Crypto++ 5.2.1 [ Wei Dai ]

Pentium 4, 2.1 GHz ( on Windows XP SP1, Visual C++ 2003 )

Cipher Block/key size Speed (MB/sec)


RC4 113
SEAL 293
3DES 64/168 9

AES 128/128 61

IDEA 64/128 19
SHACAL-2 512/128 20
Hash functions and
message integrity
Cryptographic hash functions
Length-reducing function h
 Map arbitrary strings to strings of fixed length
One way (“preimage resistance”)
 Given y, hard to find x with h(x)=y
Collision resistant
 Hard to find any distinct m, m’ with h(m)=h(m’)
Also useful: 2nd preimage resistance
 Given x, hard to find x’x with h(x’)=h(x)
 Collision resistance  2nd preimage resistance
Applications of one-way hash
Password files (one way)
Digital signatures (collision resistant)
 Sign hash of message instead of entire message
Data integrity
 Compute and securely store hash of some data
 Check later by recomputing hash and comparing
Keyed hash for message authentication
 MAC – Message Authentication Code
Message Integrity: MACs
Goal: message integrity. No confidentiality.
 ex: Protecting public binaries on disk.

k k
Message m tag
Alice Bob

Generate tag: Verify tag: ?


tag  S(k, m) V(k, m, tag) = `yes’

note: non-keyed checksum (CRC) is an insecure MAC !!


Secure MACs
Attacker’s power: chosen message attack.
 for m1,m2,…,mq attacker is given ti  S(k,mi)

Attacker’s goal: existential forgery.


 produce some new valid message/tag pair (m,t).
(m,t)  { (m1,t1) , … , (mq,tq) }

A secure PRF gives a secure MAC:


 S(k,m) = F(k,m)
 V(k,m,t): `yes’ if t = F(k,m) and `no’ otherwise.
Construction 1: ECBC
m[0] m[1] m[2] m[3]

  

E(k,) E(k,) E(k,) E(k,)

Raw CBC

key = (k, k1) E(k1,) tag


Construction 2: HMAC (Hash-MAC)
Most widely used MAC on the Internet.

H: hash function.
example: SHA-256 ; output is 256 bits

Building a MAC out of a hash function:

Standardized method: HMAC


S( k, m ) = H( kopad || H( kipad || m ))
SHA-256: Merkle-Damgard
m[0] m[1] m[2] m[3]

IV H(m)
h h h h

h(t, m[i]): compression function


Thm 1: if h is collision resistant then so is H
“Thm 2”: if h is a PRF then HMAC is a PRF
Construction 3: PMAC – parallel MAC
ECBC and HMAC are sequential. PMAC:
m[0] m[1] m[2] m[3]

P(k,0)  P(k,1)  P(k,2)  P(k,3) 

F(k,) F(k,) F(k,) F(k,)


F(k1,) tag
Why are these MAC constructions secure?
 … not today – take CS255

Why the last encryption step in ECBC?


 CBC (aka Raw-CBC) is not a secure MAC:
 Given tag on a message m, attacker can deduce
tag for some other message m’
 How: good exercise.
Authenticated Encryption:
Encryption + MAC
Combining MAC and ENC (CCA)
Encryption key KE MAC key = KI

Option 1: MAC-then-Encrypt (SSL)


MAC(M,KI) Enc KE
Msg M Msg M MAC

Option 2: Encrypt-then-MAC (IPsec)


Enc KE MAC(C, KI)
Secure on
general Msg M MAC
grounds

Option 3: Encrypt-and-MAC (SSH)


Enc KE MAC(M, KI)

Msg M MAC
Recent developments: OCB
offset codebook mode

More efficient authenticated encryption

m[0] m[1] m[2] m[3] checksum

P(N,k,0)  P(N,k,1)  P(N,k,2)  P(N,k,3)  P(N,k,0) 

E(k,) E(k,) E(k,) E(k,) E(k,)

P(N,k,0)  P(N,k,1)  P(N,k,2)  P(N,k,3)  auth 


c[0] c[1] c[2] c[3] c[4]

Rogaway, …
Public-key Cryptography
Complexity Classes
hard PSpace
Answer in polynomial space
may need exhaustive search

NP
If yes, can guess and check in
polynomial time

Answer in polynomial time, with


BPP high probability

P
Answer in polynomial time
easy compute answer directly
Example: RSA
Arithmetic modulo pq
 Generate secret primes p, q
n
 Generate secret numbers a, b with xab  x mod pq
Public encryption key n, a
 Encrypt(n, a, x) = xa mod n
Private decryption key n, b
 Decrypt(n, b, y) = yb mod n
Main properties
 This appears to be a “trapdoor permutation”
 Cannot compute b from n,a
 Apparently, need to factor n = pq
Why RSA works (quick sketch)
Let p, q be two distinct primes and let n=p*q
 Encryption, decryption based on group Zn*
 For n=p*q, order (n) = (p-1)*(q-1)
 Proof: (p-1)*(q-1) = p*q - p - q + 1

Key pair: a, b with ab  1 mod (n)


 Encrypt(x) = xa mod n
 Decrypt(y) = yb mod n
 Since ab  1 mod (n), have xab  x mod n
 Proof: if gcd(x,n) = 1, then by general group theory,
otherwise use “Chinese remainder theorem”.
Textbook RSA is insecure
What if message is from a small set (yes/no)?
 Can build table
What if I want to outbid you in secret
auction?
 I take your encrypted bid c and submit
c (101/100)e mod n
What if there’s some protocol in which I can
learn other message decryptions?
OAEP [BR94, Shoup ’01]
Preprocess message for RSA
Message 01 00..0 rand.

+ H
Check pad
on decryption.
Reject CT if invalid. G +

{0,1}n-1
Plaintext to encrypt with RSA
If RSA is trapdoor permutation, then this is chosen-ciphertext
secure (if H,G “random oracles”)
In practice: use SHA-1 or MD5 for H and G
Digital Signatures
Public-key encryption
 Alice publishes encryption key
 Anyone can send encrypted message
 Only Alice can decrypt messages with this key
Digital signature scheme
 Alice publishes key for verifying signatures
 Anyone can check a message signed by Alice
 Only Alice can send signed messages
Properties of signatures
Functions to sign and verify
 Sign(Key-1, message)

 Verify(Key, x, m) = true if x = Sign(Key-1, m)


false otherwise

Resists forgery
 Cannot compute Sign(Key-1, m) from m and Key
 Resists existential forgery:
given Key, cannot produce Sign(Key-1, m)
for any random or arbitrary m
RSA Signature Scheme
Publish decryption instead of encryption key
 Alice publishes decryption key
 Anyone can decrypt a message encrypted by Alice
 Only Alice can send encrypt messages
In more detail,
 Alice generates primes p, q and key pair a, b
 Sign(x) = xa mod n
 Verify(y) = yb mod n
 Since ab  1 mod (n), have xab  x mod n

Generally, sign hash of message instead of full plaintext


Public-Key Infrastructure (PKI)
Anyone can send Bob a secret message
 Provided they know Bob’s public key
How do we know a key belongs to Bob?
 If imposter substitutes another key, can read Bob’s mail
One solution: PKI
 Trusted root authority (VeriSign, IBM, United Nations)
 Everyone must know the verification key of root authority
 Check your browser; there are hundreds!!
 Root authority can sign certificates
 Certificates identify others, including other authorities
 Leads to certificate chains
Public-Key Infrastructure
Known public signature verification key Ka
Certificate
Certificate
Sign(Ka-1, Ks)
Ka Authority
Ks

Client Sign(Ka-1, Ks), Sign(Ks, msg) Server

Server certificate can be verified by any client that has CA key Ka


Certificate authority is “off line”
Back to SSL/TLS
Version, Crypto choice, nonce

Version, Choice, nonce,


Signed certificate
containing server’s
public key Ks

C
Secret key K
encrypted with
server’s key Ks
S
switch to negotiated cipher

Hash of sequence of messages

Hash of sequence of messages

data transmission
Crypto Summary
Encryption scheme:
 functions to encrypt, decrypt data
Symmetric encryption
 Block, stream ciphers
Hash function, MAC
 Map any input to short hash; ideally, no collisions
 MAC (keyed hash) used for message integrity
Public-key cryptography
 PK encryption: public key does not reveal key-1
 Signatures: sign data, verify signature
Limitations of cryptography
Most security problems are not crypto problems
 This is good
 Cryptography works!
 This is bad
 People make other mistakes; crypto doesn’t solve them

Misuse of cryptography is fatal for security


 WEP – ineffective, highly embarrassing for industry
 Occasional unexpected attacks on systems subjected
to serious review
Auguste Kerckhoffs
A cryptosystem should be secure
even if everything about the
system, except the key, is public
knowledge.

baptised as Jean-Guillaume-Hubert-Victor-François-
Alexandre-Auguste Kerckhoffs von Nieuwenhof
Example cryptosystems
One-time pad
 “Theoretical idea,” but leads to stream cipher
Feistel construction for symmetric key crypto
 Iterate a “scrambling function”
 Examples: DES, Lucifer, FREAL, Khufu, Khafre, LOKI,
GOST, CAST, Blowfish, …
 AES (Rijndael) is also block cipher, but different …
Complexity-based public-key cryptography
 Modular exponentiation is a “one-way” function
 Examples: RSA, El Gamal, elliptic curve systems, ...
Symmetric Encryption
Encryption keeps communication secret
Encryption algorithm has two functions: E and D
 To communicate secretly, parties share secret key K
Given a message M, and a key K:
 M is known as the plaintext
 E(K,M) → C (C known as the ciphertext)
 D(K, C) → M
 Attacker cannot efficiently derive M from C without K
Note E and D use same key K
 Reason for the name “symmetric encryption”
One-time pad
Share a random key K
Encrypt plaintext by xor with sequence of bits
 encrypt(key, text) = key  text (bit-by-bit)
Decrypt ciphertext by xor with same bits
 decrypt(key, text) = key  text (bit-by-bit)
Advantages
 Easy to compute encrypt, decrypt from key, text
 This is an information-theoretically secure cipher
Disadvantage
 Key is as long as the plaintext
 How does sender get key to receiver securely?

Idea for stream cipher: use pseudo-random generators for key …


Types of symmetric encryption
Stream ciphers – pseudo-random pad
 Generate pseudo-random stream of bits from short key
 Encrypt/decrypt by XORing as with one-time pad
 But NOT one-time PAD! (People who claim so are frauds!)
Block cipher
 Operates on fixed-size blocks (e.g., 64 or 128 bits)
 Maps plaintext blocks to same size ciphertext blocks
 Today use AES; other algorithms: DES, Blowfish, . . .
Feistel network: One Round
Divide n-bit input in half and repeat

Scheme requires
L i-1 R i-1  Function f(Ri-1 ,Ki)
 Computation for Ki
f Ki  e.g., permutation of key K
Advantage
 Systematic calculation
  Easy if f is table, etc.
 Invertible if Ki known
 Get Ri-1 from Li
Li R i
 Compute f(R i-1 ,Ki)
 Compute Li-1 by 
Data Encryption Standard
Developed at IBM, some input from NSA, widely used
Feistel structure
 Permute input bits
 Repeat application of a S-box function
 Apply inverse permutation to produce output
Worked well in practice (but brute-force attacks now)
 Efficient to encrypt, decrypt
 Not provably secure
Improvements
 Triple DES, AES (Rijndael)
Block cipher modes (for DES, AES, …)

ECB – Electronic Code Book mode


 Divide plaintext into blocks
 Encrypt each block independently, with same key
CBC – Cipher Block Chaining
 XOR each block with encryption of previous block
 Use initialization vector IV for first block
OFB – Output Feedback Mode
 Iterate encryption of IV to produce stream cipher
CFB – Cipher Feedback Mode
 Output block yi = input xi  encyrptK(yi-1)
Electronic Code Book (ECB)
Plain Text Plain Text

Block Block Block Block


Cipher Cipher Cipher Cipher

Ciphe r Tex t Cip her T

Problem: Identical blocks encrypted identically


Cipher Block Chaining (CBC)
Plain Text Plain Text

IV

Block Block Block Block


Cipher Cipher Cipher Cipher

Ciphe r Tex t Cip her T

Advantages: Identical blocks encrypted differently


Last ciphertext block depends on entire input
Comparison (for AES, by Bart Preneel)

Similar plaintext blocks


produce similar ciphertext (see
outline of head)

No apparent pattern
Structure of AES
RC4 stream cipher – “Ron’s Code”
Design goals (Ron Rivest, 1987):
 speed
 support of 8-bit architecture
 simplicity (circumvent export regulations)
Widely used
 SSL/TLS
 Windows, Lotus Notes, Oracle, etc.
 Cellular Digital Packet Data
 OpenBSD pseudo-random number generator
RSA Trade Secret
History
 1994 – leaked to cypherpunks mailing list
 1995 – first weakness (USENET post)
 1996 – appeared in Applied Crypto as “alleged RC4”
 1997 – first published analysis

Weakness is predictability of first bits; best to discard them


Encryption/Decryption
key

state 000111101010110101

plain text plain text

=
cipher text cipher t

Stream cipher: one-time pad based on pseudo-random generator


Security
Goal: indistinguishable from random sequence
 given part of the output stream, it is impossible to
distinguish it from a random string
Problems
 Second byte [MS01]
 Second byte of RC4 is 0 with twice expected probability
 Related key attack [FMS01]
 Bad to use many related keys (see WEP 802.11b)

Recommendation
 Discard the first 256 bytes of RC4 output [RSA, MS]
(all arithmetic mod 256)
Complete Algorithm
Key scheduling
for i := 0 to 255 S[i] := i
0 1 2 3 4 5 6 …
j := 0
for i := 0 to 255 Permutation of 256
j := j + S[i] + key[i] bytes, depending on key
swap (S[i], S[j])
2 123 134 24 1 218 53 …
i, j := 0
repeat Random generator
i := i + 1
j := j + S[i]
swap (S[i], S[j]) 2 123 134 24 9 218 53 …
output (S[ S[i] + S[j] ]) i j
+24
Example use of stream cipher?
Share secret s with web vendor
Exchange payment information as follows
 Send: E(s, “Visa card #3273. . . ”)
 Receive: E(s, “Order confirmed, have a nice day”)
Now eavesdropper can’t get out your Visa #
Wrong!
Suppose attacker overhears
 c1 = Encrypt(s, “Visa card #3273. . . ”)
 c2 = Encrypt(s, “Order confirmed, have a nice day”)
Now compute
 m ← c1 ⊕ c2 ⊕ “Order confirmed, have a nice day”
Lesson: Never re-use keys with a stream cipher
 Basic problem with one-time pads
 This is why they’re called one-time pads
Public-key Cryptosystem
Trapdoor function to encrypt and decrypt
 encrypt(key, message)
key pair
 decrypt(key -1, encrypt(key, message)) = message

Resists attack
 Cannot compute m from encrypt(key, m) and key,
unless you have key-1
Iterated hash functions
Repeat use of block cipher or custom function
 Pad input to some multiple of block length
 Iterate a length-reducing function f
 f : 22k -> 2k reduces bits by 2 x
 Repeat h0= some seed
Pad to x=x1x2 …xk
hi+1 = f(hi, xi)
xi
 Some final function g
completes calculation f(xi-1) f

g
MAC: Message Authentication Code
General pattern of use
 Sender sends Message and M1 = MAC(Message)
 Receiver receives both parts
 Receiver computes M2 = MAC(Message)
 If M2 == M1, data is valid
 If M2 != M1, data has been corrupted

This requires a shared secret key


 Suppose an attacker can compute MAC(x)
 Intercept M and MAC(M), resend as M' and MAC(M')
 Receiver cannot detect that message has been altered
Basic CBC-MAC
Plain Text Plain Text

IV=0

Block Block Block Block


Cipher Cipher Cipher Cipher

CBC block cipher, discarding all but last output block


Additional post-processing (e.g, encrypt with second key) can improve output
HMAC: Keyed Hash-Based MAC
Internet standard RFC2104

Uses hash of key, message:
HMACK(M)
= Hash[ (K+ XOR opad) ||
Hash[(K+ XOR ipad)||M)] ]

Low overhead

 opad, ipad are constants

Any of MD5, SHA-1, … can be


used

K+ is the key padded out to size


Order of Encryption and MACs

Should you Encrypt then MAC, or vice versa?

MACing encrypted data is always secure

Encrypting {Data+MAC} may not be secure!

You might also like