%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentstyle[12pt,twoside,alltt]{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, 1996}  }
\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{6}{September 27, 1996}{Ron Rivest}{George M. Candea} 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% 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{Stream Ciphers -- RC4}

RC4 (meaning ``Ron's Code 4'') is a variable-size stream cipher. The
algorithm works in Output Feedback (OFB) mode -- the keystream is
independent of the plaintext. It has a 8 * 8 S-box: $S_0, S_1, ...,
S_{255}$.  The entries are a permutation of the numbers 0 through 255,
and the permutation is a function of the variable-length key. It has
two counters, $i$ and $j$, initialized to zero.

To generate a random byte, do the following:
\begin{verbatim}
		i = (i + 1) mod 256
		j = (j + Si) mod 256
	swap (Si, Sj)
	t = (Si + Sj) mod 256
	K = St
\end{verbatim}

The byte (key) K is XORed with the plaintext to produce ciphertext or
XORed with the ciphertext to produce plaintext. Encryption with RC4 is
fast -- about 10 times faster than DES.

Initializing the S-box is also easy. First, fill it linearly: $S_0=0,
S_1=1, ..., S_{255}=255$. Then fill another 256-byte array with the key,
repeating the key as necessary to fill the entire array: $K_0, K_1,
..., K_{255}$. Set the index j to zero. Then:
\begin{verbatim}
	for i = 0 to 255
	   j = (j + Si + Ki) mod 256
	   swap (Si, Sj)
\end{verbatim}

RC4 guarantess a pseudo-random key (pad), which is what characterizes
stream ciphers. According to RSA Data Security, Inc. the algorithm is
immune to differential and linear cryptanalysis and is highly
non-linear. RC4 can be in about $256! * 256^2 = 2^{1700}$ possible
states. The S-box slowly evolves with use: $i$ ensures that every
element changes and $j$ ensures that the elements change randomly.
		
RC4 is exportable as long as its key is shorter or equal to 40 bits.
But given this restriction, it becomes vulnerable to brute force attacks.
RC4 is currently being used in commercial products such as Lotus Notes,
Apple's AOCE, and Oracle Secure SQL. It is also part of the Cellular
Digital Packet Data specification.

So we've seen 2 major categories of ciphers so far:
\begin{itemize}
\item
	Block ciphers (DES, RC5)
\item
	Stream ciphers (CBC, RC4)

\end{itemize}

Now on to new stuff: message digests and message authentication codes.

\section{Message digests}

\subsection{What is a message digest?}

When messages get very long, encrypting them to use as a digital signature
with algorithms such as RSA can be very expensive. We'd like to sign our
messages with something much shorter, a ``fingerprint'' of the message,
also called a ``message digest.''

To create the fingerprint, we use a function (fingerprint function, 
MD-function, cryptographic hash function, etc.) that compresses messages
of arbitrary length into a preset set. This function, $h(x)$, normally
produces a fingerprint either 128 or 160 bits long. This shorter value is 
much easier to sign than the full message. Our goal is that:

\begin{itemize}
\item The function $h$ is efficient
\item The length of $h(x)$ is short
\item The function $h(x)$ is secure (i.e. it has strong collision-resistance,
defined below)
\end{itemize}

\subsection{Hashing Security}

The security of hash functions is measured by the existence of 
{\em collisions}. A collision is when two different messages produce the
same hash. (i.e. $h(m_{1}) = h(m_{2})$) 
Here are some terms used in describing the security hash functions:

{\bf Strong Collision-Resistance:} It is infeasible for an attacker to
find $x$ and $x^{\prime}$ forming a collision. (i.e. $h(x) = h(x^{\prime})$)

{\bf Weak Collision-Resistance:} Given an $x$ and $h(x)$, it is infeasible to
find $x^{\prime}$ such that $h(x) = h(x^{\prime})$. This implies that given
$h(x)$, it is infeasible to find any $x^{\prime}$ such that 
$h(x) = h(x^{\prime})$. (i.e. That $h$ is a one-way function.)

\subsection{An example: MD5}

MD5 was originally designed and optimized for 32-bit processors.  It
uses four 32-bit registers ($A$,$B$,$C$,$D$), each one initialized
with some magic constants.  The return value of this digest function
will be the hash value $H(M)$ that satisfies the required properties
of a correct hash functions.

To prepare the message $M$ for MD5, we append a single 1 to $M$ and
then concatenate enough 0's until the message is 64 bits shy of being
a multiple of 512 bits long.

Now we append a 64-bit representation of the message length to the end
of the message.  We process each 512-bit (16-word) segment as follows:

\begin{enumerate}
\item 
	save A, B, C, D (as $A_A, B_B, C_C, D_D$)
\item 
	go through four rounds of updating A, B, C, D
\item 
	add $A_A$ back to $A$, $B_B$ to $B$, $C_C$ to $C$, and $D_D$
	to $D$

\end{enumerate}

Each round processes 16 words and updates each register 4
times. A typical update would be: 

\[ A = B + ((A + F(B,C,D) + X[k] + T[i]) < \! < \! < s) \] 

where 

\begin{itemize} 
\item 
	$A$ $<\!<\!<$ $s$ means $a$ left-rotated by $s$ bits 
\item 
	$F(B,C,D) = (B \wedge C) \oplus ((\neg B) \wedge D)$ 
\item 
	$X[k] = $ a message word 
\item 
	$T[i] = $ a magic constant 

\end{itemize}

\subsection{Secure Hash Algoritm (SHA)}

SHA is a hash function developed by the US government. It's similar to MD5, but
uses five 32-bit words and five rounds
per message block to produce a 160-bit hash, using linear transformations
of the message in each block.

\subsection{Birthday Attacks}

A birthday attack on a hash function attempts to use the birthday paradox
to find collisions in a hash function. (i.e. creating random messages,
taking their hash value, and checking if that hash value has been 
encountered before.) For MD5, as an example, an attacker
could expect to find collisions after trying $2^{64}$ messages. Given
today's computing power, this is a difficult, but not impossible problem.
Hence the move to stronger hashing algorithms, like SHA.

\subsection{CvHP}

Yet another hash function is CvHP. It's full name is the Chaum-vanHeijst-Pfitzmann 
hash function. First, we need to choose prime numbers $p$ and $q$ such that
$p = 2q + 1$. Next, we need an $\alpha$ and a $\beta$ that are both an
element of order $q$ (i.e. $\alpha^{q} \equiv 1 (\bmod p)$) and that
$\alpha \neq \beta$. For security, it must be 
difficult to compute $\log_{\alpha} \beta$.

The hash function splits the message into two parts $m_{1}$
and $m_{2}$. $h(m_{1},m_{2}) = \alpha^{m_{1}} * \beta^{m_{2}} (\bmod p)$.
It is necessary that $1 \leq |m_{1}| , |m_{2}| \leq q$.

The heart of CvHP is that it's infeasible to find $\alpha$ and $\beta$.
As an example, let's say that we have a collision:

\begin{center}
$\alpha^{m_{1}} * \beta^{m_{2}} = \alpha^{m_{3}} * \beta^{m_{4}} (\bmod p)$)
\end{center}

We can transform this to be 

\begin{center}
$\alpha^{m_{1} - m_{3}} = \beta^{m_{4} - m_{2}} (\bmod p)$
\end{center}

If we set $r = m_{1} - m_{3}$ and $s = m_{4} - m_{2}$, we get

\begin{center} 
$\alpha^{r} = \beta^{s} (\bmod p)$
\end{center}

If then we choose $t$ such that $t = s^{-1} (\bmod q)$, we can use 

\begin{center}
$\alpha^{rt} = \beta^{st} (\bmod p)$
\end{center}

to get $\alpha^{rt} = \beta (\bmod p)$. Since we said it's difficult to 
compute $log_{\alpha} \beta$, an attacker cannot get past this stage.

\section{Applications of One-way Hash Functions}
\begin{itemize}
\item Virus Checking
\begin{itemize}
\item virus modifies file contents
\item producer makes checksum $c=h(F)$ where $F$ is the original file content and $h$ is a weakly collision-free one-way hash function
\item $c$ is distributed to users via secure channels (e.g. floppy disk, CD)  
\item users compare $c$ with $h(F')$, where $F'$ is the suspected copy of the file
\end{itemize}
\item Software/Public Key Distribution
\begin{itemize}
\item objective: get the ``true'' copy of software or public key
\item same idea as virus checking
\item obtain a hash value of the software/public key via a secure channel and compare it to the hash value of user's copy. 
\end{itemize}
\item Swapping to insecure storage
\begin{itemize}
\item keep a table of hash values of the pages before swapping them out to an insecure storage
\item check the hash value of the page when retrieved back next time
\end{itemize}
\item Secure Reference or Pointer
\begin{itemize}
\item used as web page reference
\item URLs are hashed
\end{itemize}
\item Time stamp
\begin{itemize}
\item files or documents are hashed and then time-stamped by some time-stamping services
\end{itemize}
\item One-time Password (S-Key)
\begin{itemize}
\item pick a seed $x_0$ to create a chain of hash values: $x_0\stackrel{h(x_0)}\longrightarrow x_1\stackrel{h(x_1)}\longrightarrow x_2\cdots\stackrel{h(x_{n})}\longrightarrow x_{n}$
\item originally system stores $x_n$, user enters password $x_{n-1}$
\item system verifies $h(x_{n-1})\stackrel{?}=x_n$
\item adversaries cannot find $x_{n-1}$ even if knowing $x_n$, since $h$ is weakly collision-free
\item system then stores $h_{n-1}$, next time user enters $h_{n-2}$ as password
\end{itemize}

\end{itemize}

\section{Randomized Hash Functions}
Sometimes we are concerned about whether $h(x)$ reveals any information of $x$ for a
one-way hash function $h$. For example, in a multi-user system, users' passwords are 
usually hashed by a certain hash function and stored in a password file. Is it totally safe then?

Adversaries may get their way to the password file and read the list of the hashed passwords. It is common (though strongly discouraged) that English words are used as passwords. As a result, adversaries can create a table of hash values for all the dictionary words in advance and look up the hashed passwords in the table. This is known as the {\it dictionary attack}.

Also, if two people have the same password, the adversary knows that, since the hash
function is deterministic. 

As a solution, we introduce random factors. To do this, every time a user password is created, a random number $r$ (called a {\it salt}) is picked and hashed with the password. The random number $r$ is kept for verification. Now the adversary only sees a ``random'' number.

e.g. $h(x)=(r, MD5(r,x))$ or $h(x)=(r,r^{MD5(x)})$

In this case, the adversary needs to generate a separate dictionary hash table for each random number (i.e. user password). Same passwords are very unlikely to give the same hash values because of the salt.
 
\subsection{Application: Auction \& Commitment}
Imagine we are designing a computer system for secure auction. The auction works this way:
\begin{enumerate}
\item bidders submit ``sealed'' bids
\item auction over
\item bidders ``open'' bids, auctioneer announces the winning bid
\end{enumerate}

All bidders do not want the auctioneer and other people know what their bids are. On the other hand, the auctioneer needs to prevent the bidders from changing their bids once they have submitted. Such a scenario is called {\it commitment}. 

To keep confidentiality, bidders need to somehow encrypt their bids before submitting to the auctioneer and keep the key until the auction is over. To avoid changing bids, the auctioneer has to prevent the bidders from changing their keys because changing the keys essentially changes the bids as well. 

One solution may come. The auctioneer chooses a public, randomized, weakly collision-free, one-way hash function $h$. And each bidder picks a random salt $r$ for himself and makes his bid $b$. Bidders submit $h(r,b)$ to the auctioneer. At the end, bidders open their bids by disclosing $r$ and $b$. 

In this way, the auctioneer cannot get any information of the bids because the submitted hash values are randomized. On the other hand, bidders cannot change their bids because it is hard to compute another pair $(r',b')$ such that $h(r',b')=h(r,b)$. 

One example of the hash functions that can be used is the randomized CvHP. The auctioneer picks $p, \alpha$ and $\beta$ and bidders choose their own random salt $r$ and their bids $b$. Bidders submit $\alpha^r\beta^b$ modulo $p$ to the auctioneer. At the end of the auction, the bidders disclose $r$ and $b$ and the auctioneer verifies that $\alpha^r\beta^b$ modulo $p$ is the submitted value. 

\section{Message Authentication Codes (MAC)}

\subsection{What is a MAC?}

Good secrecy does not imply authenticity, and thus not good security
either. The only indication of a sender's authenticity is the
intelligibility of the received message. This is no guarantee,
however.

An example where authentication is particularly important is in bank
transactions. If an intruder knows the approximate format of a bank
transaction, they can alter bits to record that a user has deposited or
withdrawn \$10,000 instead of \$1,000. The bank needs a way to
authenticate an ATM machine.

We cannot simply append an encrypted string to the message because
this does not authenticate the front part of the message.  Instead, we
can use one-time keys for authentication by creating a MAC -- a
function of the key and of the message.

If we want to send a message $M$ and prove we are who we claim to be,
we can send $M$ with a ${\sc MAC}(M,K')$ appendend to it. $K'$ is the
shared key for authentication and $K$ is the key we use for
encryption. The receiver of the message now computes the MAC with $M$
and $K'$. If the received MAC equals the computed MAC, the message is
authentic.

The MAC function needs to have some special properties in order to be
secure. In particular we want an adversary to be unable to compute
MAC's of messages in a reasonable amount of time without knowing the
key $K'$.

\subsection{An example: CBC-MAC}

The simplest way to make a key-dependent one-way hash function is to
encrypt the message with a block algorithm in CBC mode. The hash is
the last encrypted block, encrypted once more in CBC mode. The CBC-MAC
method is part of many ANSI standards, however it can be easily
broken.  

\subsection{Another example: HMAC}

This method has been proposed for ``authenticated IP'' in an upcoming
Internet standard. It essentially works this way:

\begin{itemize}
\item
	$HMAC_k(M) = H_{K_1} ( H_{K_2} (M) )$
\item
	$K = (K_1, K_2)$
\item
	$H_k(M) =$ MD5 with $IV = k$

\end{itemize}

\section{Pay-TV and Related Applications}
One area in which stream ciphers may be used is for Pay-TV.  The programs being 
distributed can be encrypted so that only certain viewers may watch a particular 
program or channel.  In order to do this, the client must have a unique key 
which is shared with the TV center.  Program keys can be changed dynamically 
through a secure channel between the client and the center. 
	
For instance, if Alice wants to watch pay-per-view, she can send a message to 
the center through the secure channel requesting the key.  The center then 
responds with the key for the PPV channel encrypted and MAC'd with Alice's set-
top box key.  (For services such as HBO, a longer term group key may be used.)
	
Software distribution via CD can also be key encrypted.  Each program on the CD 
can have a separate key, and the user can purchase the key for a particular 
desired program.  A problem with this distribution method is that the CD does 
not have a unique key, and the keys could be posted on the internet.

\section {Key Distribution Center}
One problem with maintaining security is the creation and distribution of keys.  
One way of handling this is through a Key Distribution Center (KDC).  In order 
for this to work, the KDC must be a trusted entity, and be accessible by all 
parties.  Examples of how the KDC works can be illustrated through the users 
Alice(A) and Bob(B).  Alice shares Ka with KDC and Bob shares Kb with the KDC.  

Methodologies of communication:
 1) Have KDC encrypt/decrypt messages to and from Alice and Bob.  KDC is the 
intermediary.
\begin{description}	
\item[m1] $A->KDC: "Hi, Bob..." [Ka]$
\item[m2]$KDC->Bob: "Hi, Bob.." [Kb]$
\end{description}

The message is encrypted and MACed by Alice with her key [Ka], the message is sent to the KDC, who decrypts the message.

2) Have KDC help Alice and Bob establis a common key Kab.
\begin{description}
\item[m1]	$A->KDC: "I want to talk to Bob" [KA]$
\item[m2]	$KDC->Bob: "Alice wants to talk privately to you, use key
			  Kab = 029" [KB]$

	\item[m3]$KDC->Alice: "Use key Kab=029 to talk to Bob"[Ka]$
\item[m4]	$A->B: "Hi"[Kab]$
\end{description}

Variations:
\begin {itemize}
\item 	Alice making up the key.
\item	Alice could be sent m3, who forwards it to Bob
\item	IDs could be sent in clear so that Bob could know which key to use
\item	If there are multiple keys/sender, the keys may need IDs
\item	 Keys could be made up by Alice, Bob, the KDC or a combination
\item	Expiration.  How long should Bob keep 'Kab'.
\end {itemize}
One way of handling the expiration problem would be:	
	\begin {description}
\item[m1] $A->KDC: A,keyID, {A,B, "request", newkeyid, newkey, timeout}Ka$
\item[m2]	$KDC->A: C,keyID, {C,A, "reply", newkeyid, newkey, timeout}Ka$
\item[m3]	$KDC->B: C,keyID, {C,B, "newkey", newkeyid, newkey,timeout}Kb$
\item[m4]	$A->B:A,newKeyID, {"Hi"}newkey$
\end{description}
where ${}$Key  denotes an encrypted MACed message.

The KDC can be used for establishing keys with other KDCs.  The KDCs establish 
contact with each other, and key transactions are handled at a higher level.

Problems with the KDC method is that the KDC must be trusted completely, must be 
available, and that there are no digital signatures.

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

\end{document}



