Transcript Cryptography

Cryptography
Lecture 3
Stefan Dziembowski
www.dziembowski.net
[email protected]
Plan
1. Encryption of multiple messages.
2. Stream ciphers
3. Block ciphers (an introduction)
Some images in this document are take from From Wikipedia, the free encyclopedia.
On the previous lecture:
cryptographic
PRGs
semantically-secure
encryption
Multiple messages
c210=Enc(k,m
...
0)
1
2
k
k
Alice
Bob
m0
c0=Enc(k,m0)
m1
c1=Enc(k,m1)
m2
Eve
c2=Enc(k,m2)
...
...
A chosen-plaintext attack (CPA)
security parameter
1n
chooses m’1
1. selects random k = Gen(1n)
2. chooses a random b = 0,1
m’1
c1 = Enc(k,m’1)
...
chooses m’t
challenge phase:
chooses m0,m1
m’t
ct = Enc(m’t)
m0,m1
c = Enc(k,mb)
the interaction continues . . .
has to guess b
oracle
CPA-security
Alternative name: CPA-secure
Security definition:
We say that (Gen,Enc,Dec) has indistinguishable encryptions under
a chosen-plaintext attack (CPA) if any
randomized polynomial time adversary
guesses b correctly
with probability at most 0.5 + ε(n), where ε is negligible.
Observation
Every CPA-secure encryption has to be
• randomized, or
• “have a state”.
CPA in real-life
Q: Aren’t we too pessimistic?
A: No! CPA can be implemented in practice.
A historical example: the battle of Midway (1942)
The Amercans suspected that Enc(“Midway island”) = “NF”
we are running
out of water
Midway
BINGO!
“. . .NF. . .”
How to encrypt multiple messages
using pseudorandom generators?
Of course we cannot just reuse the same seed
(remember the problem with the one-time pad?)
It is not just a theoretical problem!
Misuse of RC4 in Microsoft Office
[Hongjun Wu 2005]
RC4 – a popular PRG (or a “stream cipher”)
“Microsoft Strong Cryptographic Provider”
(encryption in Word and Excel, Office 2003)
The seed s is a function of a password and an initialization vector.
These values do not change between the different versions of the document!
Suppose Alice and Bob work together on some document:
Enc(k,m)
Enc(k,m’)
The adversary can compute m xor m’
What to do?
There are two solutions:
1. The synchronized mode
2. The unsynchronized mode
Synchronized mode
G : {0,1}n → {0,1}very large – a PRG.
s
G is computed “on fly”
...
G(s)
m0
m1
m2
m3
c0
c1
c2
c3
xor
Disadvantage: Alice and Bob need to know how much of G(s) was already used.
Unsynchronized mode
Idea
IVi
s
Randomize the encryption
procedure.
Assume that G takes as an
additional input
G(IVi,s)
mi
an initialization vector (IV).
The Enc algorithm selects a fresh
random IVi for each message mi.
xor
IVi
G(IVi,s)
Later, IVi is included in the
ciphertext
Enc(s,mi)
We need an “augmented” PRG
We need a PRG such that the adversary cannot distinguish G(IV,s) from a
random string even if she knows IV and some pairs
(IV0,G(IV0,s)), (IV1,G(IV1,s)), (IV2,G(IV2,s)), . . .
where s,IV,IV0,IV1,IV2... are random.
IV
s
with a non-negligible advantage
G
G(IV,s)
R
or
IV
(IV0,G(IV0,s)), (IV1,G(IV1,s)), (IV2,G(IV2,s)), . . .
?
How to construct such a PRG?
•
An old-fashioned approach:
1. take a standard PRG G
2. set G(IV,s) := G(H(IV,S))
often:
just concatenate
IV and S
where H is a “hash-function” (we will define
cryptographic hash functions later)
•
A more modern approach:
design such a G from scratch.
Constructions of PRGs
• A theoretical result: a PRG can be constructed from any
one-way function
[Håstad, Impagliazzo, Levin, Luby A Pseudorandom
Generator from any One-way Function]
(very elegant, impractical, inefficient)
• Based on hardness of some number-theoretic problems,
e.g.:
[Lenore Blum, Manuel Blum, and Michael Shub. A Simple
Unpredictable Pseudo-Random Number Generator]
(elegant, more efficient, still rather impractical)
• “Stream ciphers”
(ugly, very efficient, widely used in practice)
Popular stream ciphers
• RC4
• A5/1 and A5/1 (used in GSM)
• ...
not very secure
completely broken
Competitions for new stream ciphers
• NESSIE (New European Schemes for Signatures, Integrity and
Encryption, 2000 – 2003) project failed to select a new stream
cipher (all 6 candidates were broken)
(where “broken” can mean e.g. that one can distinguish the output
from random after seeing 236 bytes of output)
• eStream project (November 2004 – May 2008) will soon announce
the winners
RC4
• Designed by Ron Rivest (RSA Security)
in 1987.
RC4 = “Rivest Cipher 4”, or “Ron's Code 4”.
• Trade secret, but in September 1994 its
description leaked to the internet.
• For legal reasons sometimes it is called: "ARCFOUR" or
"ARC4“.
• Used in WEP and WPA and TLS.
• Very efficient and simple, but has some security flaws
RC4 – an overview
note: no IV
key k
|k| = 40 – 256 bits
key-scheduling
algorithm
(KSA)
indices
i
j
array S
|S| = 256 bytes
in each round this is updated
and
1 byte is output
(this is called a “pseudo-random generation algorithm (PRGA)”)
RC4
KSA
for i from 0 to 255
S[i] := i
end
for j := 0 for i from 0 to 255
j := (j + S[i] + key[i mod keylength]) mod 256
swap(S[i],S[j])
endfor
don’t read it!
PRGA
i := 0
j := 0
while GeneratingOutput:
i := (i + 1) mod 256
j := (j + S[i]) mod 256
swap(S[i],S[j])
output S[(S[i] + S[j]) mod 256]
endwhile
Problems with RC4
1.
Doesn’t have a separate IV.
2.
It was discovered that some bytes of the output are
biased.
[Mantin, Shamir, 2001]
3.
First few bytes of output sometimes leak some
information about the key
[Fluhrer, Mantin and Shamir, 2001]
Recommendation: discard the first 768-3072 bytes.
4.
Other weaknesses are also known...
Use of RC4 in WEP
• WEP = “Wired Equivalent Privacy”
• Introduced in 1999, still widely used to protect
WiFi communication.
• How RC4 is used:
to get the seed, the key k is concatenated with the IV
– old versions: |k| = 40 bits, |IV| = 24 bits
(artificially weak because of the US export
restrictions)
– new versions: |k| = 104 bits, |IV| = 24 bits.
RC5 in WEP – problems with the
key length
• |k| = 40 bits is not enough:
can be cracked using a brute-force attack
• IV is changed for each packet.
Hence |IV| = 24 bits is also not enough:
– assume that each packet has length 1500 bytes,
– with 5Mbps bandwidth the set of all possible IVs will
be exhausted in half a day
• Some implementations reset IV := 0 after each
restart – this makes things even worse.
see Nikita Borisov, Ian Goldberg, David Wagner (2001). "Intercepting
Mobile Communications: The Insecurity of 802.11"
RC5 in WEP – the weak IVs
[Fluhrer, Mantin and Shamir, 2001]
(we mentioned this attack already)
For so-called “weak IVs” the key stream reveals some
information about the key.
In response the vendors started to “filter” the weak IVs.
But then new weak IVs were discovered.
[see e.g. Bittau, Handley, Lackey The final nail in WEP's coffin.]
This attacks are practical!
[Fluhrer, Mantin and
Shamir, 2001] attack:
Using the Aircrack-ng tool one can break WEP in 1 minute (on a normal PC)
[see also: Tews, Weinmann, Pyshkin
Breaking 104 bit WEP in less than 60 seconds, 2007]
How bad is the situation?
RC4 is still rather secure if used in a correct way.
Example:
Wi-Fi Protected Access (WPA) – a successor of WEP:
several improvements (e.g. 128-bit key and a 48-bit IV).
Let’s hope the eStream project will be a success!
List of the eStream finalists:
Profie 1 (ciphers for the software applications):
CryptMT, Dragon, HC, LEX, NLS, Rabbit, Salsa20, SOSEMANUK
Profile 2 (ciphers for the hardware applications):
DECIM, Edon80, F-FCSR, Grain, MICKEY, Moustique, Pomaranch,
Trivium
Is there an alternative to the stream
ciphers?
Yes!
the block ciphers
Let’s start from scratch:
plaintext m
key k
encryption
ciphertext c
key k
decryption
plaintext m
Problem:
the plaintexts m may be extremally long, and therefore it may be hard to analyse
security of the cipher.
An idea!
1.
2.
Desing ciphers that work on small blocks
(e.g. of length 128 bits)
Then, build the real encryption schemes out of them.
plaintext m
this will be called:
a block cipher
key k
encryption
warning:
ciphertext c
key k
decryption
plaintext m
of course,
as a stand-alone
cipher it is not CPAsecure
Block ciphers – an intuition
For F : {0,1}* × {0,1}*→ {0,1}*
let Fk(m) denote F(k,m).
A block cipher is a function F such that
1. It is a keyed-permutation, i.e.:
2.
•
for every k function Fk is a permutation on some {0,1}n
(for simplicity assume: n = |k|).
•
for every k functions Fk and Fk-1 are efficiently computable.
for a random k and any m1,...,mt the values
Fk(m1),...,Fk(mt) “look random”
How to formalize it?
Remember:
stream ciphers ≈ pseudorandom generators
We will have
block ciphers ≈ pseudorandom permutations
Intuition:
a pseudorandom permutation
should not be distinguishable from
a “completely random permutation”.
Scenario 1
security parameter
1n
distinguisher D
m1 є {0,1}n
Fk(m1)
m2 є {0,1}n
Fk(m2)
...
mt є {0,1}n
Fk(mt)
outputs b є {0,1}
oracle
chooses a random k є {0,1}n.
Scenario 2
security parameter
1n
distinguisher D
m1 є {0,1}n
oracle
chooses a random function
F : {0,1}n→ {0,1}n
Fk(m1)
m2 є {0,1}n
Fk(m2)
...
mt є {0,1}n
Fk(mt)
outputs b є {0,1}
This of course cannot be
done efficiently, but it
doesn’t matter
Pseudorandom permutations – the
definition
We say that a keyed-permutation
F : {0,1}* × {0,1}*→ {0,1}*
is a pseudorandom permutation if
any polynomial-time randomized distinguisher D
cannot distinguish scenario 1 from scenario 2 with
a non-negligible advantage:
That is:
|P(D outputs “1” in scenario 1) - P(D outputs “1” in scenario 2)|
is negligible in n
How to construct such
pseudorandom permutations?
•
Theoretical constructions:
A pseudorandom permutation can be constructed from any one-way
function.
•
Practical constructions: block ciphers.
Famous block ciphers:
key length
block length
56
64
128
64
128, 192 or 256
128
DES (1976)
(Data Encryption Standard)
IDEA (1991)
(International Data Encryption
Algorithm)
AES (1998)
(Advanced Encryption Standard)
Other: Blowfish, Twofish, Serpent,...
“Practical security requirement”: the best attack should be the brute-force attack.
We will discuss these constructions on the next lecture.
Block cipher modes of operation
Block ciphers cannot be used directly for encryption.
They are always used in some “modes of operation”:
1.
2.
3.
4.
Electronic Codebook (ECB) mode ← not secure,
Cipher-Block Chaining (CBC) mode,
Output Feedback (OFB) mode,
Counter (CTR) mode,
...
Electronic Codebook mode
encryption
decryption
Electronic Codebook mode should
not be used!
This mode was used in the past.
It is not secure, and should not be used.
Example:
ECB
Cipher-Block Chaining (CBC)
random value that
becomes part of a
plaintext
encryption
decryption
CBC mode – properties
• Error propagation?
Error in block ci affects only ci and ci+1.
So, errors don’t propagate
(This mode is self-synchronizing) +
• Can encryption be parallelized?
No –
• Can decryption be parallelized?
Yes +
• What if one bit of plaintext is changed (somewhere at the
beginning)?
Everything needs to be recomputed (not so good e.g. for disc
encryption) –
Output Feedback (OFB) mode
encryption
decryption
CBC mode – properties
•
Error propagation?
Error in block ci affects only ci and ci+1. +
but this mode is not self-synchronizing –
•
Can encryption be parallelized?
No –
(but we can we can use precomputation) +
•
Can decryption be parallelized?
The same answer +
•
What if one bit of plaintext is changed (somewhere at the beginning)?
Only one block needs to be recomputed +
Counter (CTR) mode
IV + 1
IV + 2
IV + 3
encryption
IV + 1
IV + 2
decryption
IV + 3
Properties of CTR
CTR has all advantages of OFB.
Additionally it has the following property:
random access – it is possible to decrypt
one block without decrypting anything
else. +
Provable security
Remember the “provable security” idea?
Suppose that some
“computational
assumption A”
holds
scheme X is secure.
The following can be proven
Suppose that X is
a pseudorandom
permutation
scheme X-CBC is secure.
scheme X-CTR is secure.
scheme X-OFB is secure.
Of course, to get any information about practical relevance of these results one
needs to look at the concrete parameters hidden in the “asymptotics”.
Stream ciphers vs. block ciphers
• Stream ciphers are a bit more efficient.
• But they appear to be “less secure”.
• It is easier to misuse them (use the same
stream twice).
• If you encrypt a stream of data you can
always use a block cipher in a CTR mode.
• Probably at the moment block ciphers
are a better choice.