--- a/handouts/ho01.tex	Tue Oct 07 12:48:07 2014 +0100
+++ b/handouts/ho01.tex	Thu Oct 09 14:41:36 2014 +0100
@@ -42,7 +42,7 @@
 hack into things. I beg to differ: You have this mindset
 already when in school you were thinking, at least
 hypothetically, about ways in which you can cheat in an exam
-(whether it is about hiding notes or looking over the
+(whether it is by hiding notes or by looking over the
 shoulders of your fellow pupils). Right? To defend a system,
 you need to have this kind mindset and be able to think like
 an attacker. This will include understanding techniques that
@@ -108,7 +108,7 @@
 authorisation. Even though the banks involved trumpeted their
 system as being absolutely secure and indeed fraud rates
 initially went down, security researchers were not convinced
-(especially the group around Ross Anderson). To begin with,
+(especially not the group around Ross Anderson). To begin with,
 the Chip-and-PIN system introduced a ``new player'' into the
 system that needed to be trusted: the PIN terminals and their
 manufacturers. It was claimed that these terminals were
@@ -122,7 +122,7 @@
 mostly beyond the control of customers who need to use these
 terminals.
 
-To make matters worse for Chip-and-PIN, in around 2009 Ross
+To make matters worse for Chip-and-PIN, around 2009 Ross
 Anderson and his group were able to perform man-in-the-middle
 attacks against Chip-and-PIN. Essentially they made the
 terminal think the correct PIN was entered and the card think
@@ -148,15 +148,15 @@
 Since banks managed to successfully claim that their
 Chip-and-PIN system is secure, they were under the new system
 able to point the finger at the customer when fraud occurred:
-customers must have been negligent losing their PIN and they
-had almost no way of defending themselves in such situations.
-That is why the work of \emph{ethical} hackers like Ross
-Anderson's group was so important, because they and others
-established that the bank's claim that their system is secure
-and it must have been the customer's fault, was bogus. In 2009
-the law changed and the burden of proof went back to the
-banks. They need to prove whether it was really the customer
-who used a card or not.
+customers must have been negligent losing their PIN and
+customers had almost no way of defending themselves in such
+situations. That is why the work of \emph{ethical} hackers
+like Ross Anderson's group was so important, because they and
+others established that the banks' claim that their system is
+secure and it must have been the customer's fault, was bogus.
+In 2009 the law changed and the burden of proof went back to
+the banks. They need to prove whether it was really the
+customer who used a card or not.
 
 This is a classic example where a security design principle
 was violated: Namely, the one who is in the position to
@@ -183,7 +183,7 @@
 
 \subsection*{Of Cookies and Salts}
 
-Lets look at another example which will help with
+Let us look at another example which will help with
 understanding how passwords should be verified and stored.
 Imagine you need to develop a web-application that has the
 feature of recording how many times a customer visits a page.
@@ -271,7 +271,7 @@
 the server's perspective is a potentially hostile environment.
 What we need to ensure is the integrity of this counter in
 this hostile environment. We could think of encrypting the
-counter. But this has two drawbacks to do with the key for
+counter. But this has two drawbacks to do with the keys for
 encryption. If you use a single, global key for all the
 clients that visit our site, then we risk that our whole
 ``business'' might collapse in the event this key gets known
@@ -410,8 +410,8 @@
 \pcode{foobar} as password, we need to verify whether it
 matches with the password that is already stored for this user
 in the system. Why not doing this with plain-text passwords?
-But doing this verification in plain text is really a bad
-idea. Unfortunately, evidence suggests it is still a
+Unfortunately doing this verification in plain text is really
+a bad idea. Alas, evidence suggests it is still a
 widespread practice. I leave you to think about why verifying
 passwords in plain text is a bad idea.
 
@@ -481,43 +481,46 @@
 as possible of such likely candidates of passwords and also
 compute their hash-values. The difference between a brute
 force attack, where maybe $2^{80}$ many strings need to be
-considered, a dictionary attack might get away witch checking
-only 10 Million (remember the language English ``only''
-contains 600,000 words). This is a drastic simplification for
-attackers. Now if the attacker knows the hash-value of a
-password is
+considered, is that a dictionary attack might get away with
+checking only 10 Million words (remember the language English
+``only'' contains 600,000 words). This is a drastic
+simplification for attackers. Now, if the attacker knows the
+hash-value of a password is
 
 \begin{center}
 \pcode{5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8}
 \end{center}
 
-\noindent then just a lookup in the dictionary will reveal that the
-plain-text password was \pcode{password}. What is good about this
-attack is that the dictionary can be precompiled in the ``comfort of
-the hacker's home'' before an actual attack is launched. It just needs
-sufficient storage space, which nowadays is pretty cheap. A hacker
-might in this way not be able to crack all passwords in our database,
-but even being able to crack 50\% can be serious damage for a large
-company (because then you have to think about how to make users to
-change their old passwords---a major hassle).  And hackers are very
-industrious in compiling these dictionaries: for example they
-definitely include variations like \pcode{passw0rd} and also include
-rules that cover cases like \pcode{passwordpassword} or
-\pcode{drowssap} (password reversed).\footnote{Some entertaining rules
-  for creating effective dictionaries are described in the book
-  ``Applied Cryptography'' by Bruce Schneier (in case you can find it
-  in the library), and also in the original research literature which
-  can be accessed for free from
-  \url{http://www.klein.com/dvk/publications/passwd.pdf}.}
-Historically, compiling a list for a dictionary attack is not as
-simple as it might seem. At the beginning only ``real'' dictionaries
-were available (like the Oxford English Dictionary), but such
-dictionaries are not ``optimised'' for the purpose of passwords. The
-first real hard data about actually used passwords was obtained when a
-company called RockYou ``lost'' 32 Million plain-text passwords. With
-this data of real-life passwords, dictionary attacks took
-off. Compiling such dictionaries is nowadays very easy with the help
-of off-the-shelf tools.
+\noindent then just a lookup in the dictionary will reveal
+that the plain-text password was \pcode{password}. What is
+good about this attack is that the dictionary can be
+precompiled in the ``comfort of the hacker's home'' before an
+actual attack is launched. It just needs sufficient storage
+space, which nowadays is pretty cheap. A hacker might in this
+way not be able to crack all passwords in our database, but
+even being able to crack 50\% can be serious damage for a
+large company (because then you have to think about how to
+make users to change their old passwords---a major hassle).
+And hackers are very industrious in compiling these
+dictionaries: for example they definitely include variations
+like \pcode{passw0rd} and also include rules that cover cases
+like \pcode{passwordpassword} or \pcode{drowssap} (password
+reversed).\footnote{Some entertaining rules for creating
+effective dictionaries are described in the book ``Applied
+Cryptography'' by Bruce Schneier (in case you can find it in
+the library), and also in the original research literature
+which can be accessed for free from
+\url{http://www.klein.com/dvk/publications/passwd.pdf}.}
+Historically, compiling a list for a dictionary attack is not
+as simple as it might seem. At the beginning only ``real''
+dictionaries were available (like the Oxford English
+Dictionary), but such dictionaries are not optimised for the
+purpose of cracking passwords. The first real hard data about actually
+used passwords was obtained when a company called RockYou
+``lost'' 32 Million plain-text passwords. With this data of
+real-life passwords, dictionary attacks took off. Compiling
+such dictionaries is nowadays very easy with the help of
+off-the-shelf tools.
 
 These dictionary attacks can be prevented by using salts.
 Remember a hacker needs to use the most likely candidates 
@@ -544,7 +547,7 @@
 \noindent where the first part is the login-name, followed by
 a field \pcode{$6$} which specifies which hash-function is
 used. After that follows the salt \pcode{3WWbKfr1} and after
-that the hash-value that is stored for the password ( which
+that the hash-value that is stored for the password (which
 includes the salt). I leave it to you to figure out how the
 password verification would need to work based on this data.
 
@@ -561,18 +564,20 @@
 will be associated with a different hash-value. This will
 make the life harder for an attacker.
 
-Note another interesting point. The web-application from the previous
-section was only secure when the salt was secret. In the password
-case, this is not needed. The salt can be public as shown above in the
-Unix password file where is actually stored as part of the password
-entry. Knowing the salt does not give the attacker any advantage, but
-prevents that dictionaries can be precompiled. While salts do not
-solve every problem, they help with protecting against dictionary
-attacks on password files. It protects people who have the same
-passwords on multiple machines. But it does not protect against a
-focused attack against a single password and also does not make poorly
-chosen passwords any better. Still the moral is that you should never
-store passwords in plain text. Never ever.\medskip
+Note another interesting point. The web-application from the
+previous section was only secure when the salt was secret. In
+the password case, this is not needed. The salt can be public
+as shown above in the Unix password file where it is actually
+stored as part of the password entry. Knowing the salt does
+not give the attacker any advantage, but prevents that
+dictionaries can be precompiled. While salts do not solve
+every problem, they help with protecting against dictionary
+attacks on password files. It protects people who have the
+same passwords on multiple machines. But it does not protect
+against a focused attack against a single password and also
+does not make poorly chosen passwords any better. Still the
+moral is that you should never store passwords in plain text.
+Never ever.\medskip
 
 \noindent
 If you want to know more about passwords I recommend viewing some