diff -r e2180cead443 -r 4ebc97e6fdf0 handouts/ho01.tex
--- a/handouts/ho01.tex	Wed Sep 24 23:35:47 2014 +0100
+++ b/handouts/ho01.tex	Thu Sep 25 00:24:41 2014 +0100
@@ -257,6 +257,64 @@
 chicken-and-egg problem). So encryption seems to not solve the
 problem we face with the integrity of our counter.
 
+Fortunately, \emph{hash function} seem to be more suitable for
+our purpose. Like encryption, hash functions scrambles data
+but in such a way that it is easy to calculate the output of a
+has function from the input. But it is hard (i.e.~practically
+impossible) to calculate the input from knowing the output.
+Therefore has functions are often called one-way functions.
+There are several such hashing function. For example SHA-1
+would has the string \pcode{"hello world"} to
+
+\begin{center}
+\pcode{2aae6c35c94fcfb415dbe95f408b9ce91ee846ed}
+\end{center}
+
+\noindent Another handy feature of hash functions is that if
+the input changes a little bit, the output changes 
+drastically. For example \pcode{"iello world"} produces under 
+SHA-1 the output
+
+\begin{center}
+\pcode{d2b1402d84e8bcef5ae18f828e43e7065b841ff1}
+\end{center}
+
+\noindent That means it is not predictable what the output
+will be from input that is ``close by''. 
+
+We can use hashes and store in the cookie the value of the
+counter together with its hash. We need to store both pieces
+of data such we can extract both components (below I will just
+separate them using a \pcode{"-"}). If we now read back the
+cookie when the client visits our webpage, we can extract the
+counter, hash it again and compare the result to the stored
+hash value inside the cookie. If these hashes disagree, then
+we can deduce that cookie has been tampered with.
+Unfortunately if they agree, we can still not be entirely sure
+that not a clever hacker has tampered with the cookie. The
+reason is that the hacker can see the clear text part of the
+cookie, say \pcode{3}, and its hash. It does not take much
+trial and error to find out that we used the SHA-1 hashing
+functions and then graft a cookie accordingly. This is eased
+by the fact that for SHA-1 many strings and corresponding
+hashvalues are precalculated. Type into Google for example the
+hash value for \pcode{"hello wolrd"} and you will actually
+pretty quickly find that it was generated by \pcode{"hello
+wolrd"}. This defeats the purpose of a hashing functions and
+would not help us for our web-applications. The corresponding
+attack is called \emph{dictionary attack}\ldots hashes are not
+reversed by brute force calculations, that is trying out all
+possible combinations.
+
+
+There is one ingredient missing, which happens to be called
+\emph{salt}. The salt is a random key, which is added to the
+counter before the hash is calculated. In our case we need
+to keep the salt secrete.  
+
+\begin{figure}[p]
+\lstinputlisting{../progs/App3.js}
+\end{figure}