--- a/handouts/ho01.tex	Mon Sep 21 14:23:41 2015 +0100
+++ b/handouts/ho01.tex	Mon Sep 21 19:08:34 2015 +0100
@@ -6,7 +6,7 @@
 
 
 \begin{document}
-\fnote{\copyright{} Christian Urban, 2014}
+\fnote{\copyright{} Christian Urban, 2014, 2015}
 
 \section*{Handout 1 (Security Engineering)}
 
@@ -134,8 +134,8 @@
 that a link between the card and the bank is established at
 every time the card is used. Even later this group found
 another problem with Chip-and-PIN and ATMs which did not
-generate random enough numbers (nonces) on which the security
-of the underlying protocols relies. 
+generate random enough numbers (cryptographic nonces) on which
+the security of the underlying protocols relies. 
 
 The overarching problem with all this is that the banks who
 introduced Chip-and-PIN managed with the new system to shift
@@ -300,7 +300,7 @@
 given a message and a hash, it is computationally infeasible to
 find another message with the same hash. This is called
 \emph{collusion resistance}. Because of these properties hash
-functions are often called \emph{one-way functions}\ldots you
+functions are often called \emph{one-way functions}: you
 cannot go back from the output to the input (without some
 tricks, see below). 
 
@@ -332,13 +332,14 @@
 cookie the value of the counter in plain text but together
 with its hash. We need to store both pieces of data in such a
 way that we can extract them again later on. In the code below
-I will just separate them using a \pcode{"-"}, for example
+I will just separate them using a \pcode{"-"}. For the
+counter \pcode{1} for example
 
 \begin{center}
 \pcode{1-356a192b7913b04c54574d18c28d46e6395428ab}
 \end{center}
 
-\noindent for the counter \pcode{1}. If we now read back the
+\noindent 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
@@ -395,7 +396,7 @@
 salt.
 
 There is an interesting and very subtle point to note with
-respect to the New York Times' way of checking the number
+respect to the 'New York Times' way of checking the number
 visits. Essentially they have their `resource' unlocked at the
 beginning and lock it only when the data in the cookie states
 that the allowed free number of visits are up. As said before,
@@ -408,7 +409,7 @@
 web-application has the resource (discount) locked at the
 beginning and only unlocks it if the cookie data says so. If
 the cookie is deleted, well then the resource just does not
-get unlocked. No mayor harm will result to us. You can see:
+get unlocked. No major harm will result to us. You can see:
 the same security mechanism behaves rather differently
 depending on whether the ``resource'' needs to be locked or
 unlocked. Apart from thinking about the difference very