-
Notifications
You must be signed in to change notification settings - Fork 30
/
Lecture03.tex
216 lines (175 loc) · 8.89 KB
/
Lecture03.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
%!TEX root = InfoSec.tex
% Lecture 3: 17 September 2014
\sektion{3}{Block ciphers}
\sidenote{
{\bf Story from WWII:}
Pacific war: lots of radio communications; crypto and US decryptions paid a
huge role
Admiral Nimitz had advantage of code break giving Japanese battle plan
(Battle of Midway)
Most successful code was used by the US Marines: the Navajo language served
as a code by translating the first letter of an English word into a
Navajo word and sending that by radio (allowed speech communication).
Even when they got a Navajo speaker, the Japanese were unable to usefully
decrypt these messages.
}
Last time: Stream ciphers
$$E(k,m) = D(k, m) = \text{PRG}(k) \xor m$$
Alternative approach: Block ciphers
Start with function that encrypts a fixed-size block of data (and fixed-size
key) and build up from there
\begin{itemize}
\item may run faster
\item many PRGs work this way anyway
\end{itemize}
Note that block cipher is not the same thing as a PRF, since a PRF may have no
inverse ($\exists x_1, x_2 \text{ s.t. } f(k,x_1) = f(k,x_2)$
Want: psuedorandom permutation (PRP)
\begin{itemize}
\item function from $n$-bit input (plus key) to $n$-bit output
\item if $x_1 \neq x_2$, then $f(k, x_1) \neq f(k, x_2)$
\item psuedorandom as expected from previous definitions -- should be
indistinguishable from truly random to an adversary
\end{itemize}
It is useful to compare the different types of security functions we have
seen. Note: Can use any of PR function/permutation/generator to build
the other two.
\begin{center}
\begin{tabular}{l|llll}
Property & PR Functions & PR Permutations & PR Generators & Hash Functions \\
\hline
Input & Any & Fixed-size & Fixed-size & Any \\
Output & Fixed-size & Fixed-size & Any & Fixed-size \\
Has Key & Yes & Yes & Yes & No \\
Invertible & No & With key & No & Depends \\
Collisions & Yes, but can't find & No & No & Yes, but can't find \\
\end{tabular}
\end{center}
Challenge: design a very hairy function that's invertible, but only by someone
who knows the key. A PRP will have this property.\\
Minimal properties of a good block cipher:
\begin{itemize}
\item efficient
\item highly nonlinear (``confusion property'') - hard for adversary to
invert
\item mix input bits together (``diffusion'') - every input bit affects the output
\item depend on the key
\end{itemize}
How to get these properties: Feistel network, given that $f$ is a PRF
\makebox[6cm]{plaintext}\\
\framebox[6cm]{\makebox[3cm]{left half}\textbar\makebox[3cm]{right half}}\\
\makebox[6cm]{\makebox[1cm]{$\downarrow$}\makebox[4cm]{}\makebox[1cm]{$\downarrow$}}\\
\makebox[6cm]{\makebox[1cm]{$\xor$}\makebox[1cm]{$\longleftarrow$}\framebox[2cm]{$f(k_0)$}\makebox[1cm]{$\longleftarrow$}\makebox[1cm]{$\downarrow$}} ``feistal round''\\
\makebox[6cm]{\makebox[1cm]{$\downarrow$}\makebox[4cm]{}\makebox[1cm]{$\downarrow$}}\\
\makebox[6cm]{------------------------------------------------}\\
\makebox[6cm]{\makebox[1cm]{$\downarrow$}\makebox[1cm]{$\longrightarrow$}\framebox[2cm]{$f(k_1)$}\makebox[1cm]{$\longrightarrow$}\makebox[1cm]{$\xor$}} another round\\
\makebox[6cm]{\makebox[1cm]{$\downarrow$}\makebox[4cm]{}\makebox[1cm]{$\downarrow$}}\\
Add as many rounds as you want, alternating left and right rounds.\\
Why? Easy to invert since each round is its own inverse, so inverse of series
of rounds is the same series in reverse order. This makes it so that $f$ can be
as difficult as we want and the process is still invertible, so why not make $f$
a PRF?\\
\begin{theorem*}
If $f$ is a PRF, then 4-round feistel network is a PRP.
\end{theorem*}
Often use weaker rounds (which may be faster to compute), but more of them.
\begin{example}{DES (Data Encryption Standard)}
\begin{itemize}
\item block size = 64 bits
\item 56-bit key
\item Feistel network - 16 (weak) rounds
\end{itemize}
History:
\begin{itemize}
\item designed in secrey by IBM and NSA in 1978
\item US government standard
\item private sector followed
\end{itemize}
Backdoor known to designers but not public? Concerns by public over the
source - history of US offering other governments intentionally weak ciphers
Reason for secrecy around design was that some of the classification: wanted
to make secure against differential cryptanalysis, but that wasn't publicly
known yet and NSA wanted to keep using it against others.
Designed to be slow in software to discourage it from being implemented in
software
Key size problem:\\
$2^{56}$ steps for a brute-force search to recover an unknown key, which is
currently feasable, though not in 1978 (except maybe by NSA?)
This can be addressed by iterating DES with multiple keys. Note that you
need to do this three times to get $2^{112}$ for brute force search.
\end{example}
\begin{example}{AES (Advanced Encryption Standard)}
Probably the best available today, coming from overcoming drawbacks of DES
\begin{itemize}
\item software efficiency a goal
\item large, variable key size (128-, 192-, 256-bit variants)
\item open, public process for choosing and generating the cipher\\
run by NIST and a design contest judged on pre-determined criteria
\end{itemize}
2002 - NIST chose Rijndael (Belgian designers)
\end{example}
\subsektion{128-bit AES}
\begin{itemize}
\item 128-bit input, output, and key
\item not feistel design
\item lookup table public
\item ten rounds (generally cryptanalysis is a small-round break and then
extending the tactic to a full number of rounds, so use a safe
number then add extra rounds for safety buffer), each with four steps
\begin{enumerate}
\item non-linear step (``confusion''):
run each byte through a certain non-linear function (lookup
table of a permutation)
\item shift step (``diffusion''):
think of 128-bits as 4x4 array of bytes: shift the $i$th row left $i$ steps; values that
fall off wrap around the same row. (circular shift)
spreads out columns
\item linear mix (``diffusion''):
take each column, treat as 4-vector and multiply by a certain
matrix (specified in standard)
mixes within column
\item key-addition step (key-dependent):
xor each byte with corresponding byte of the key
Note: the key expansion could be a source of weakness (to get
the ten keys needed from one)
\end{enumerate}
\item to decrypt, do inverses in reverse order
\end{itemize}
\subsektion{How to handle variable-size messages}
Problems:
\begin{itemize}
\item padding - plaintext not a multiple of blocksize
\item ``cipher modes'' - dealing with multi-block messages
\end{itemize}
Padding: most important property needs to be that recipient can unambiguously
tell what is padding and what is not\\
Good method: add bits 10* until reach end of block (pull off all 0's at end
then the 1). Remember that you must add {\emph some} padding (at least one
bit) to every message. This works similarly with bytes.\\
\bigskip
Cipher modes: encrypt multi-block messages
\begin{itemize}
\item ECB (Electronic Code Book) !! BAD - not semantically secure - do not use !!
$$C_i = E(k, P_i)$$
Same plaintext results in same ciphertext -- leaks information to
adversary
\item CBC (Cipher Block Chaining): Common, pretty good\\
``strawman CBC'', $R_i$ random
$$C_i = (R_i, E(k, R_i \xor P_i)$$
Good, but doubles message size\\
Idea: use $C_{i-1}$ instead of $R_i$\\
$$C_i = E(k, C_{i-1} \xor P_i)$$
What about the first block? Generate a random value, the
``initialization vector (IV)'', to prepend to message to serve as
$C_{-1}$. Don't want to reuse with same key, or adversary could compare
the first block of the ciphertext to see if same plaintext, but
random-ish generation good enough, and can use same key over and over.
\item CTR (Counter mode): Generally agreed on as best to use.
Similar to a stream cipher.
$$C_i = E(k, \text{messageid} || \text{counter}) \xor P_i$$
messageid must be unique, then it's okay to reuse key.\\
Note: this would not be forward secret as a PRG.\\
Reasons to use CTR over PRG: more efficient on commodity hardware and
perhaps you trust AES more than your PRF (even though you can't prove it
either way).
\end{itemize}