%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentstyle[12pt,twoside,alltt,psfig]{article}
\textwidth=6in
\oddsidemargin=0.25in
\evensidemargin=0.25in
\topmargin=-0.1in
\footskip=0.8in
\parindent=0.0cm
\parskip=0.3cm
\textheight=8.00in
\setcounter{tocdepth} {3}
\setcounter{secnumdepth} {2}
\sloppy

\newenvironment{proof}{\noindent{\bf Proof:}}{\qed\bigskip}
\newenvironment{proof_sketch}{\noindent{\bf Sketch of 
Proof}\hspace*{1em}}{\qed\bigskip}

\newtheorem{theorem}{Theorem}
\newtheorem{corollary}{Corollary}
\newtheorem{lemma}{Lemma}
\newtheorem{claim}{Claim}
\newtheorem{fact}{Fact}
\newtheorem{definition}{Definition}
\newtheorem{assumption}{Assumption}
\newtheorem{observation}{Observation}
\newtheorem{example}{Example}
\newcommand{\qed}{\rule{7pt}{7pt}}

\newcommand{\lecture}[4]{
\pagestyle{headings}
\thispagestyle{plain}
\newpage
\noindent
\begin{center}
\framebox{
\vbox{
\hbox to 5.75in { {\bf 6.857 Computer and Network Security
\hfill Fall Term, 1997}  }
\vspace{4mm}
\hbox to 5.75in { {\Large \hfill Lecture #1 : #2 \hfill} }
\vspace{2mm}
\hbox to 5.75in { {\it Lecturer: #3 \hfill Scribe: #4} }
}
}
\end{center}
\markboth{Lecture #1 : #2}{Lecture #1 : #2}
\vspace*{4mm}
}

\begin{document}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Lecture command takes 4 arguments:
%		ordinal number of the lecure
%		date of the lecure
%		lecturer
%		scribe---that is you
%
\lecture{5}{16 September 1997}{Ron Rivest}{Michelle Goldberg} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% For theorems, lemmas, definitions, remarks, etc. use commands
% \begin{theorem} .... \end{theorem} 
% \begin{definition} ... \end{definition} 
% \begin{proof} ... \end{proof}
% and so on ...
%
% If you want to insert figures in your notes do the following: 
% 1) Prepare your figures using your favourite graphic editor
% 	for example idraw or xfig
% 2) Save your pictures in PostScript form using the following convention
% 	notes-nn-fig-mm.ps where nn is the number of the lecture you 
% 	are scribing and mm is the sequential number of the picture in the 
% 	notes
% 3) Insert the following block in your LaTeX code in the place you 
% 	want to insert the figure BUT LEAVE IT AS A COMMENT (with the %
% 	at the beginning of the line) since it will not work on athena: 
%
% \begin{figure}[h]
% \begin{center}
% \mbox{\psfig{figure=notes-nn-fig-mm.ps}}
% \caption{A very nice picture.}
% \label{fig:mm}
% \end{center}
% \end{figure}
%
% 	of course the picture will not show up when you compile and 
% 	print your notes, but don't worry the TA will take care of it. 
% 4) When you mail the TA the LaTeX code mail him/her the PostScript
%	files for the figures as well 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Your notes start here!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Conditionally Secure Cryptography}

Conditionally (or computationally) secure cryptography uses a 
shared secret key of limited length to provide security against
an oponent with limited computational resources by making it
computationally infeasable extract the key or message.


\subsection{Standards of Proof}

Rigorous proofs of conditional cryptography are in very limited
supply.  It would be nice to be able to prove that a keyspace search
or comparable effort (order of $2^n$, for key length n) would be
required to find a key or decode a message, but for the most part it's
not possible.  One way of showing a given system to be computationally
secure is to show that breaking it (reliably) would be comparable in
difficulty to solving an NP-hard problem -- but given that whether $P
\neq NP$ (whether the class of problems solveable in polynomial time is
the same as the class of problems solveable in non-deterministic
polynomial time) is not yet known, even showing a system to be NP-hard
to break isn't entirely conclusive.  Were it to be shown that $P =
NP$, much of computationally secure cryptography as it presently
exists would collapse.  Even the ``proveably secure'' systems are
based on the {\em assumption} that factoring (or another such problem)
is sufficiently hard.

So what are the resources of the limited adversary, and what test(s)
might a cryptographics system be asked to pass to demonstrate
reasonable security?  One proposed ``turing test'' for a cryptographic
system is that an adversary, given $M_{x}$ and $M_{y}$, should not be
able to determine (with greater than 50\% probability) which of two
ciphertexts is $C(M_{x})$ and which is $C(M_{y})$ with less than a
keyspace search.  Another proposed test is that an adversary should
not be able to determine the encryption key even with many examples
of
\begin{itemize}
\item known ciphertext (an eavesdropper), or
\item known ciphertext/plaintext pairs (an eavesdropper able to correlate
to plaintexts stolen or made public), or
\item chosen ciphertext/plaintext pairs (someone able to submit items
for encryption, possibly an insider\footnote{The field of
differential cryptanalysis is based on analyzing CT/PT pairs with
slight differences.}), or
\item related keys used.
\end{itemize}
There are no proofs that any of these practical proposals are sufficient
tests.

\subsection{Block Ciphers}

A block cipher is an algorithm which takes in a fixed-length message
block (64 or 128 bits) and a key (not necessarily the same length),
and produces a block of ciphertext of the same length as the original
message block.  The key is reused for many different message blocks,
so it needs to be added in to the message in a ``complex way.''

\begin{figure}[h]
\begin{center}
\mbox{\psfig{figure=notes-05-fig-01.ps}}
\caption{General Block Cipher}
\label{fig:01}
\end{center}
\end{figure}

{\bf Feistel ciphers} are based on a certain (public domain) style of
design.  For such a cipher, the key $K$ is broken into round keys
$\{K_{1}, K_{2}, K_{3},...K_{n}\}$, and the message $M$ broken into
left and right halves $L$ and $R$.  For each of $n$ rounds, the
operation $L \leftarrow L \oplus f(K_{i}, R)$ is executed, followed by
an exchange of L and R.  After $n$ rounds, the final left and right
halves are swapped and concatenated to return as the ciphertext.
Decrypting is straightforward, as it is possible with the key to
recompute the the round keys and each $f(R, K_{i})$ in turn, and the
XOR function is its own inverse.  The final swap of the two halves
of the ciphertext allows decryption to be done with the same
hardware as encryption, with only reversing the order of the round
keys necessary.

\begin{figure}[h]
\begin{center}
\mbox{\psfig{figure=notes-05-fig-02.ps}}
\caption{Feistel Cipher}
\label{fig:02}
\end{center}
\end{figure}

How the key is turned into round keys and the selection of the function
$f(R, K_{i})$ are the distinguishing features of specific Feistel ciphers.
The design of a good function $f(R, K_{i})$ is an art form.

% should these be under DES?  I have them listed after Feistel,
% before DES, in my notes, which seems odd.  Should at least say
% how long the key is.
In 1993, Wiener % ought to have a full name
proposed to build for one million dollars a machine that would crack
a Feistel cipher in seven hours.  Matsui % full name wanted again
did undertake to break one, and found a key in about 50 hours after
searching $2^{42}$ plaintext/ciphertext pairs\footnote{This using linear
cryptanalysis, which looks at statistical variations in the ciphertext
in relation to the plaintext.}.  The recent Internet Challenge this year
did so as well, applying a full keyspace search run in spare cycles on
machines scattered across the net. % how much was searched?


{\bf DES}, the national Data Encryption Standard, is a Feistel-type cipher
of sixteen rounds, using a 64 bit message block and a 56 bit key.  The
round keys are generated by selecting 48 bits out of the 56.  The
function $f(R, K_{i})$ expands $R$ from 32 to 48 bits, XORs $R$ with
$K_{i}$, breaks the resulting sequence into six bit chunks, looks up
each six bit chunk in a table of ``S-boxes'' to get back four bits,
scrambles the resulting 32 bits, and returns the result.\footnote{See
the applied cryptography book for details.}  One of many functions of
the S-boxes is to magnify the effect of changes in the plaintext on
the ciphertext.

\begin{figure}[h]
\begin{center}
\mbox{\psfig{figure=notes-05-fig-03.ps}}
\caption{DES: $f(R, K_{i})$ for one round}
\label{fig:03}
\end{center}
\end{figure}

The NSA was involved in the design of DES; the motivation and effect
of the changes they proposed has been debated.  Current differential
analysis suggests that their changes to the S-boxes strengthened DES, but
the NSA pushed for the 56 bit key length -- down from 128 bits that had
been suggested.


Variations on DES in use now as possibly stronger include DESX,
wherein $C(M) = K_{2} \oplus DES(K, M \oplus K_{1})$, % check K subscripts
and triple DES, for which $C(M) =
DES_{K_{1}}(DES^{-1}_{K_{2}}(DES_{K_{1}}(M)))$\footnote{Double DES is
vulnerable to bidirectional attacks, working forward from the plaintext
and backwards from the ciphertext.}.

DES is expected to be replaced as a national standard by AES, a cipher
to be determined by the NIST.  A call for proposals for a 128 bit
block cipher with a 128 bit key is expected soon.

Other block ciphers include Blowfish, IDEA, CAST, and RC5.  RC5 is a
Fiestel-type cipher, possibly to be proposed by Rivest % title?
for AES, in which the round function is $L \leftarrow ((L \oplus R) <<< R)
\oplus K_{i})$, where $<<<$ indicates rotation.


\subsection{Modes of Operation of Block Ciphers}

{\bf Electronic Codebook Mode} (ECB) is using a block cipher as-is --
padding a message to a multiple of block length, breaking it into
blocks, and encrypting it.  This is rarely used in practice.  Two
matching blocks of of plaintext would produce matching blocks of
ciphertext, and 64 bits is a small enough chunk that building
meaningful messages out of known plaintext/ciphertext pairs would be a
real danger.  A one bit transmission error in this mode spoils a whole
message block.

{\bf Counter Mode} uses a block cipher as a pseudo-random generator.
Rather than encrypting the message text, a known string of numbers
(possibly just $\{1, 2, 3, ... \}$) is encrypted in ECB mode,
producing a string of output blocks $\{R_{1}, R_{2}, R_{3}, ...\}$,
which are XORed with the message blocks to produce the ciphertext:
$C_{i} \leftarrow M_{i} \oplus c(K, i)$.  This has the advantage that
the ciphertext transmitted can be the same length as the message, no
padding needed -- extra characters at the end of the last random block
are just dropped -- and a one bit transmission error spoils only one bit.

{\bf Output Feedback Mode}, like counter mode, produces a string of
``random'' blocks which are XORed with the message to produce the
ciphertext, but instead of feeding the cipher a fixed sequence of
numbers, each random block is used as input to the block cipher to
generate the next (an initialization block is needed).  This, too,
needs no padding and loses only one bit to a one-bit transmission error.

\begin{figure}[h]
\begin{center}
\mbox{\psfig{figure=notes-05-fig-04.ps}}
\caption{Output Feedback Mode}
\label{fig:04}
\end{center}
\end{figure}

{\bf Cipher Block Chaining} (CBC) XORs each message block with the
ciphertext of the previous block before encrypting it; an
initialization vector, possibly public, is XORed with the first
message block before encryption.  This does require padding the
message to a multiple of the block size, but cipher block stealing
(below) can be used to create a ciphertext of the same size as the
original message.  A one-bit error in transmission will ruin one
block and cause a one-bit error in decrypting the next.

\begin{figure}[h]
\begin{center}
\mbox{\psfig{figure=notes-05-fig-05.ps}}
\caption{Cipher Block Chaining}
\label{fig:05}
\end{center}
\end{figure}

Cipher Block Stealing alters the last two ciphertext blocks of a
message generated with CBC to avoid a ciphertext longer than the
message text.  The message is padded with zeros and CBC run as usual.
Then the last ciphertext block is transmitted as the second to last,
followed by only as many bits of the second-to-last (generated) as
there are non-padding bits in the last message block.  To recover the
message, the last full ciphertext block is decrypted, yielding the
second-to-last block generated XORed with the final message block --
but since the message was padded with zeros, the final bits are the
unmodified bits that were dropped from the second-to-last block
(generated) before it was transmitted.  The fractional transmitted
block is combined with the decrypted final block to recover the final
message block, and to decrypt to recover the second-to-last message
block.

\begin{figure}[h]
\begin{center}
\mbox{\psfig{figure=notes-05-fig-06.ps}}
\caption{Cipher Block Stealing}
\label{fig:06}
\end{center}
\end{figure}

\section{Attacks on block ciphers}

Computational security is based on the computational difficulty of
breaking an encryption. It is based on a key that is not consumed each
time a message is encrypted or decrypted.

When designing a computational cipher, give the adversary a lot more
power than may be true in practice.  Make worst case assumptions.  We
would like to be able to state proofs about the computation required
to break a cipher.  Most of the study of algorithms has focused on
proving worst case computation time, when we should be more worried
about average case computation time.  Ideally, we would like to be
able to prove lower bounds on computation, but this is still a
difficult open problem.  People have been working on this for
decades.

Many of these systems are a classic form of the P=NP problem.  If it
is ever shown that P does equal NP, then ciphers based on
computational difficulty will fall apart.  Compare this to information
theoretic systems which do not have this problem.  We continue
on the assumption that P is not equal to NP\@.

Unfortunately, since we cannot prove lower bounds on computational
difficulty, we live with security based on trial by fire.  After
a cipher algorithm has been tested for a while without failing,
we begin to place some trust in it.  Sometimes we are surprised.

{\bf Chosen plaintext attack:}
The cipher encryption algorithm
is openly available to the attacker.  The encryption key,
which is unknown to the attacker, represents the only
changeable portion of the encryption algorithm.  The attacker
has the ability to choose messages to encrypt and
get the resulting ciphertext.

\subsection{Brute Force}
Attacker must try all $2^{56}$ possible keys to match a given
message-ciphertext pair.

How expensive (in time and money) is this?

In 1977, Diffie and Hellman postulated that they could build a machine
for \$20 million dollars which could find the key in 10 hours. They
extrapolated that in 1987, they could build a similar machine for
\$200,000.

More recently, a VLSI designer named Wiener designed a chip which could
do 5,000,000 encryptions/second for \$10.50/chip. He designed a machine
which uses 5760 chips in parallel to break the DES key in 1.5 days. With
\$1 million dollars, he could build a machine which could break the key 
in 3 hours.
%% [This was from last year's notes, and so is not really true now. -darrin]
%%The paper describing this design is available from the 
%%class Web page. 

\subsection{Differential Attack}
A more clever (non-brute) method of breaking the DES key requires Alice
to encrypt whatever the adversary wants (chosen plaintext). This method
may not be realistic in most cases. It reduces the number of keys to
$2^{47}$ by accumulating statistical evidence about the key.  This
method to break the DES key was known when it was designed, so the 
S--boxes are designed to be amazingly resilient under this form of attack.

\subsection{Linear Attack}
The linear method of breaking the DES encryption scheme relies on
forming a linear approximation to the encryption key. It also gathers
statistical evidence about the key from observation (as opposed to
requiring encryption of chosen plaintexts), but only needs to search
$2^{43}$ randomly generated keys. This method has actually been used.

The time to break encryption keys continues to decrease as processing
speed increases. Approximately every 18 months, processing time doubles
in speed. There have been about 13 doublings since 1977. To stay at the
same level of security as 1977, DES needs to have 70 bits, and the
number of bits must be able to increase as computing power grows.
Unfortunately, the DES 56 bit key is of fixed length.

\section{Design of encryption and decryption boxes}

An encryption/decryption algorithm is a one-to-one and unto mapping.
(For any key, there is only one remapping of the output to the input)
Imagine DES implementation which is a box with lots of memory
for a table lookup.  This would require $2^{126}$ bits of storage.
($2^{56}$ keys * $2^{64}$ bits/message * $2^{6}$)
We would like to design a box which is indistinguishable from a
random table.  This gives us a definition of an optimal algorithm.

\subsection{New Encryption Methods}

Professor Rivest has recently designed another encryption method
called RC5.  This stands for Ron's Code 5.  (RC1 and RC3 have been
trashed, although RC2 and RC4 appear to be standing so far.)

First, there is a separate extension that expands the key to
have as many words as rounds.  Then, letting

$A,B$ = halves of message\\
$S[1\ldots{}]$ = key information

it does the following operation 16 times: (rounds)
\[ A \leftarrow ((A \oplus B) \ll  B) + S[i] \]
\[ Swap A,B\]
where $\ll X$  is bit rotation by X bits. This rotation is dependent on
the lower 5 bits of the data.  Note that on older machines, the time to
left shift may be proportional to the value being left shifted by.
This could leave RC5 vulnerable to a timing attack.  However, most
modern computers do this operation in a single cycle.

The output is then $A,B$.

RC5 has the advantage that it is fast and easily parameterizable.
It can use variable sized keys and a variable number of iterations.
So far, it has held up against both linear and differential
attack.
%%A paper describing RC5 in more details is
%%available from the class Web page.

\subsection{Strengthening DES} 

{\bf Double DES:}
The Double DES encryption method cascades two DES boxes with different
keys.  One might think that this method is equivalent to using DES with
a 112 bit key, but this is not true. It can be attacked with the ``Meet in
the Middle'' attack which requires $O(2^{56})$ keys to be searched. 
%See Figure \ref{fig:meet}.

%\begin{figure}[h]
%\begin{center}
%\mbox{\psfig{figure=notes-4-fig-3.ps}}
%\caption{Double DES Meet in the Middle Attack}
%\label{fig:meet}
%\end{center}
%\end{figure}

\medskip
{\bf Triple DES:}
Let $DES_K(M)$ denote the DES--encryption
of message $M$ with key $K$. Let $DES^{-1}_K(M)$ denote the 
DES--decryption of message $M$ with key $K$.

Triple DES uses two keys $K_1$ and $K_2$ and encrypts a message 
$M$ as follows: 
\[ C = DES_{K_1}(DES^{-1}_{K_2}(DES_{K_1}(M))) \]

This method has an effective key of 90 bits.

An observation about this method is that if $K_1 = K_2$, we can get single
DES, so Triple DES is backwards compatible. This is why the middle 
encryption uses DES in decryption mode.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Your notes end here!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}
