of Foundations Network and Computer Security
John Black
Lecture #4 Sep 2nd 2004
CSCI 6268/TLEN 5831, Fall 2004
Announcements
Please sign up for class mailing list Quiz #1 will be on Thursday, Sep 9th
About 30 mins At end of class Office hours day before and morning of Covers all lecture materials and assigned readings
Blockcipher Review
DES
Old, 64-bit blocksize, 56 bit keys Feistel construction Never broken except for exhaustive key search
AES
New, 128-bit blocksize, 128-256 bit keys Non-Feistel Fast, elegant, so far so good
Aren't We Done?
Blockciphers are only a start
They take n-bits to n-bits under a k-bit key Oftentimes we want to encrypt a message and the message might be less than or greater than n bits! We need a "mode of operation" which encrypts any M {0,1}* There are many, but we focus on three: ECB, CBC, CTR
ECB Electronic Codebook
This is the most natural way to encrypt
It's what we used with the Substitution Cipher For blockcipher E under key K: n)+ First, pad (if required) to ensure M ({0,1} Write M = M1 M2 ... Mm where each Mi has size n-bits Then just encipher each chunk:
Ci = EK(Mi) for all 1 i m
Ciphertext is C = C1 C2 ... Cm
ECB (cont)
What's bad about ECB?
Repeated plaintext blocks are evident in the ciphertext
Called "deterministic encryption" and considered bad This was the feature of the Substitution Cipher that allowed us to do frequency analysis Not as bad when n is large, but it's easy to fix, so why not fix it!
Encrypting the same M twice will yield the same C
Usually we'd like to avoid this as well
Goals of Encryption
Cryptographers want to give up exactly two pieces of information when encrypting a message
1) That M exists 2) The approximate length of M
The military sometimes does not even want to give up these two things!
Traffic analysis
We definitely don't want to make it obvious when a message repeats
CBC Mode Encryption
Start with an n-bit "nonce" called the IV
Initialization Vector Usually a counter or a random string
Blockcipher E under key K, M broken into m blocks of n bits as usual
C0 = IV Ci = EK(Mi Ci-1) for all 1 i m
M1 IV EK EK EK M2 Mm
C1
C2
Cm
Features of CBC Mode
Ciphertext is C = C0 C1 ... Cm
Ciphertext expansion of n-bits (because of C0)
Same block Mi, or same message M looks different when encrypted twice under the same key (with different IV's) No parallelism when encrypting
Need to know Ci before we can encipher Mi+1 Decryption is parallelizable however
CBC mode is probably the most widely-used mode of operation for symmetric key encryption
Digression on the One-Time Pad
Suppose Alice and Bob shared a 10,000 bit string K that was secret, uniformly random
Can Alice send Bob a 1KB message M with "perfect" security? 1KB is 8,000 bits; let X be the first 8,000 bits of the shared string K Alice sets C = M X, and sends C to Bob Bob computes C X and recovers M
Recall that M X X = M
Security of the One-Time Pad
Consider any bit of M, mi, and the corresponding bits of X and C, (xi, ci)
Then ci = mi xi Given that some adversary sees ci go across a wire, what can he discern about the bit mi?
Nothing! Since xi is equally likely to be 0 or 1
So why not use the one-time pad all the time?
Shannon proved (1948) that for perfect security the key must be at least as long as the message
Impractical
One-Time Pad (cont)
Still used for very-top-secret stuff
Purportedly used by Russians in WW II
Note that it is very important that each bit of the pad be used at most one time!
The infamous "two time pad" is easily broken
Imagine C = M X, C' = M' X Then C C' = M X M' X = M M' Knowing the xor of the two messages is potentially very useful n-time pad for large n is even worse (WEP does this)
Counter Mode CTR
Blockcipher E under key K, M broken into m blocks of n bits, as usual Nonce N is typically a counter, but not required
C0 = N Ci = EK(N++) Mi
Ciphertext is C = C0 C1 ... Cm
CTR Mode
Again, n bits of ciphertext expansion Non-deterministic encryption Fully parallelizable in both directions Not that widely used despite being known for a long time
People worry about counter overlap producing pad reuse
Why I Like Modes of Operation
Modes are "provably secure"
Unlike blockciphers which are deemed "hopefully secure" after intense scrutiny by experts, modes can be proven secure like this:
Assume blockcipher E is secure (computationally indistinguishable from random, as we described) Then the mode is secure in an analogous black-box experiment
The proof technique is done via a "reduction" much like you did in your NP-Completeness class The argument goes like this: suppose we could break the mode with computational resources X, Y, Z. Then we could distinguish the blockcipher with resources X', Y', Z' where these resources aren't that much different from X, Y, and Z
Security Model
Alice and Bob
Traditional names Let's us abbreviate A and B Adversary is the bad guy
This adversary is passive; sometimes called "eve"
Note also the absence of side-channels
Power consumption, timing, error messages, etc
Alice Adversary Key K Bob
Key K
Various Attack Models
Known-Ciphertext Attack (KCA)
You only know the ciphertext Requires you know something about the plaintext (eg, it's English text, an MP3, C source code, etc) This is the model for the Sunday cryptograms which use a substitution cipher
Known-Plaintext Attack (KPA)
You have some number of plaintext-ciphertext pairs, but you cannot choose which plaintexts you would like to see This was our model for exhaustive key search and the meet in the middle attack
Attack Models (cont)
Chosen-Plaintext Attack (CPA)
You get to submit plaintexts of your choice to an encryption oracle (black box) and receive the ciphertexts in return Models the ability to inject traffic into a channel
Send a piece of disinformation to an enemy and watch for its encryption Send plaintext to a wireless WEP user and sniff the traffic as he receives it
This is the model we used for defining blockcipher security (computational indistinguishability)
Attack Models (cont)
Chosen-Ciphertext Attack (CCA)
The strongest definition (gives you the most attacking power) You get to submit plaintexts and ciphertexts to your oracles (black boxes) Sometimes called a "lunchtime attack" We haven't used this one yet, but it's a reasonable model for blockcipher security as well
So What about CBC, for example?
CBC Mode encryption
It's computationally indistinguishable under chosen plaintext attack
You can't distinguish between the encryption of your query M and the encryption of a random string of the same length
In the lingo, "CBC is IND-CPA" It's not IND-CCA
You need to add authentication to get this
The Big (Partial) Picture
Second-Level Protocols (Can do proofs) First-Level Protocols (Can do proofs)
SSH, SSL/TLS, IPSec Electronic Cash, Electronic Voting
Symmetric Encryption
MAC Schemes
Asymmetric Encryption
Digital Signatures
Primitives (No one knows how to prove security; make assumptions)
Block Ciphers
Stream Ciphers
Hash Functions
Hard Problems
Symmetric Authentication: The Intuitive Model
Here's the intuition underlying the authentication model:
Alice and Bob have some shared, random string K They wish to communicate over some insecure channel An active adversary is able to eavesdrop and arbitrarily insert packets into the channel
Alice Adversary Key K Bob
Key K
Authentication: The Goal
Alice and Bob's Goal:
Alice wishes to send packets to Bob in such a way that Bob can be certain (with overwhelming probability) that Alice was the true originator
Adversary's Goal:
The adversary will listen to the traffic and then (after some time) attempt to impersonate Alice to Bob If there is a significant probability that Bob will accept the forgery, the adversary has succeeded
The Solution: MACs
The cryptographic solution to this problem is called a Message Authentication Code (MAC)
A MAC is an algorithm which accepts a message M, a key K, and possibly some state (like a nonce N), and outputs a short string called a "tag"
M K N MAC tag = MACK(M, N)
MACs (cont)
Alice computes tag = MACK(M, N) and sends Bob the message (M, N, tag) Bob receives (M', N', tag') and checks if MACK(M', N') == tag'
If YES, he accepts M' as authentic If NO, he rejects M' as an attempted forgery
Note: We said nothing about privacy here! M might not be encrypted
Bob
(M', N', tag') ?? MACK(M', N') == tag' Y N
ACCEPT
REJECT
Security for MACs
The normal model is the ACMA model
Adaptive Chosen-Message Attack
Adversary gets a black-box called an "oracle"
Oracle contains the MAC algorithm the and key K Adversary submits messages of his choice and the oracle returns the MAC tag After some "reasonable" number of queries, the adversary must "forge"
To forge, the adversary must produce a new message M* along with a valid MAC tag for M*
If no adversary can efficiently forge, we say the MAC is secure in the ACMA model
Building a MAC with a Blockcipher
Let's use AES to build a MAC
A common method is the CBC MAC:
CBC MAC is stateless (no nonce N is used) Proven security in the ACMA model provided messages are all of once fixed length Resistance to forgery quadratic in the aggregate length of adversarial queries plus any insecurity of AES Widely used: ANSI X9.19, FIPS 113, ISO 9797-1
M1 M2 Mm
AESK
AESK
AESK tag
CBC MAC notes
Just like CBC mode encryption except:
No IV (or equivalently, IV is 0n) We output only the last value
Not parallelizable Insecure if message lengths vary
Breaking CBC MAC
If we allow msg lengths to vary, the MAC breaks
To "forge" we need to do some (reasonable) number of queries, then submit a new message and a valid tag
Ask M1 = 0n We're done! we get t = AESK(0n) back
We announce that M* = 0n || t has tag t as well (Note that A || B denotes the concatenation of strings A and B)
Varying Message Lengths: XCBC
There are several well-known ways to overcome this limitation of CBC MAC XCBC, is the most efficient one known, and is provablysecure (when the underlying block cipher is computationally indistinguishable from random)
Uses blockcipher key K1 and needs two additional n-bit keys K2 and K3 which are XORed in just before the last encipherment
A proposed NIST standard (as "CMAC")
M1 M2 Mm
K2 K3 if n divides |M| otherwise
AESK1
AESK1
AESK1 tag
UMAC: MACing Faster
In many contexts, cryptography needs to be as fast as possible
High-end routers process > 1Gbps High-end web servers process > 1000 requests/sec
But AES (a very fast block cipher) is already more than 15 cycles-per-byte on a PPro
Block ciphers are relatively expensive; it's possible to build faster MACs
UMAC is roughly ten times as fast as current practice
UMAC follows the Wegman-Carter Paradigm
Since AES is (relatively) slow, let's avoid using it unless we have to
Wegman-Carter MACs provide a way to process M first with a non-cryptographic hash function to reduce its size, and then encrypt the result
Message M hash key hash function hash(M) encryption key encrypt tag
The Ubiquitous HMAC
The most widely-used MAC (IPSec, SSL, many VPNs) Doesn't use a blockcipher or any universal hash family
Instead uses something called a "collision resistant hash function" H
Sometimes called "cryptographic hash functions" Keyless object more in a moment HMACK(M) = H(K opad || H(K ipad || M)) opad is 0x36 repeated as needed ipad is 0x5C repeated as needed
Notes on HMAC
Fast
Faster than CBC MAC or XCBC
Because these crypto hash functions are fast
Slow
Slower than UMAC and other universal-hash-family MACs
Proven security
But these crypto hash functions have recently been attacked and may show further weaknesses soon
What are cryptographic hash functions?
A cryptographic hash function takes a message from {0,1}* and produces a fixed size output Output is called "hash" or "digest" or "fingerprint" There is no key The most well-known are MD5 and SHA-1 but there are other options MD5 outputs 128 bits SHA-1 outputs 160 bits
Message
% md5 Hello There ^D A82fadb196cba39eb884736dcca303a6 % Hash Function
Output
e.g., MD5,SHA-1
512 bits
SHA-1
...
Mm 0 t 15 16 t 79 E H4i-1
M1
M2
for i = 1 to m do Wt =
{
t-th word of Mi ( Wt-3 Wt-8 Wt-14 Wt-16 ) << 1 B H1i-1; C H2i-1; D H3i-1;
A H0i-1;
for t = 1 to 80 do T A << 5 + gt (B, C, D) + E + Kt + Wt E D; end H0i A + H0i-1; H3i D + H3i-1; H1i B + H1i-1; H4i E + H4i-1 H2i C+ H2i-1; D C; C B >> 2; B A; A T
end return H0m H1m H2m H3m H4m
160 bits
Real-world applications
Hash functions are pervasive
Message authentication codes (HMAC) Digital signatures (hash-and-sign) File comparison (compare-by-hash, eg, RSYNC) Micropayment schemes Commitment protocols Timestamping Key exchange ...
A cryptographic property
(quite informal) 1. Collision resistance given a hash function it is hard to find two colliding inputs BAD: H(M) = M mod 701
M H H M'
{0,1}n
Strings
More cryptographic properties
1. Collision resistance given a hash function it is hard to find two colliding inputs 2. Second-preimage resistance given a hash function and given a first input, it is hard to find a second input that collides with the first given a hash function and given an hash output it is hard to invert that output
3. Preimage resistance
Merkle-Damgard construction
Compression function
M1
n
M2
M3
IV
k
f
k
h1
f
h2
f
h3 = H (M)
Fixed initial value
Chaining value
MD Theorem: if f is CR, then so is H
Mi1
M2
512 bits
...
Mm
for i = 1 to m do Wt =
{
t-th word of Mi ( Wt-3 Wt-8 Wt-14 Wt-16 ) << 1 B H1i-1; C H2i-1; D H3i-1;
0 t 15 16 t 79 E H4i-1
A H0i-1;
for t = 1 to 80 do T A << 5 + gt (B, C, D) + E + Kt + Wt 160 bits E D; D C; C B >> 2; B A; A T end H0..4i-1 H0i A + H0...