[taler-anastasis] 01/03: some fixes

[gnunet]

This is an automated email from the git hooks/post-receive script.

dennis-neufeld pushed a commit to branch master
in repository anastasis.

commit 250540aa0c2195ce3533c99cc74866fb5befe0b1
Author: Dennis Neufeld <dennis.neufeld@students.bfh.ch>
AuthorDate: Sun Jun 7 17:41:59 2020 +0000

    some fixes
---
 doc/thesis/bibliothek.bib   | 7 +++++++
 doc/thesis/introduction.tex | 4 ++--
 doc/thesis/related_work.tex | 5 ++---
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/doc/thesis/bibliothek.bib b/doc/thesis/bibliothek.bib
index 94e6d54..5cb334b 100644
--- a/doc/thesis/bibliothek.bib
+++ b/doc/thesis/bibliothek.bib
@@ -365,4 +365,11 @@
   pages={20},
   year={2002}
 }
+@article{marlinspike2011,
+  title={SSL and the future of authenticity},
+  author={Marlinspike, Moxie},
+  journal={Black Hat USA},
+  volume={6},
+  year={2011}
+}
 
diff --git a/doc/thesis/introduction.tex b/doc/thesis/introduction.tex
index f622500..8a224e1 100644
--- a/doc/thesis/introduction.tex
+++ b/doc/thesis/introduction.tex
@@ -10,7 +10,7 @@ owner of a key must have the possibility to recover a lost 
key.
 But how can one create a confidential backup of a key? It certainly
 makes no sense to encrypt a key with a different password and then use
 the result as a backup. After all, this merely shifts the problem from
-the original key to the password, which is bascially yet another key.
+the original key to the password, which is basically yet another key.
 So simply encrypting the key is not helpful.  But without encryption,
 any copy of a key increases availability, but also the risk of the
 key's confidentiality being compromised.
@@ -126,7 +126,7 @@ for citizens, for public offices and for
 enterprises''~\cite{pepdoc}. It secures communication via email by
 providing end-to-end encryption similar to PGP.  A major difference is
 that p\equiv p uses opportunistic encryption and so-called trustwords
-to etablish authenticity to avoid usability and privacy problems
+to establish authenticity to avoid usability and privacy problems
 associated with the ``Web of trust''.
 
 The impact of losing control over the private key is similar in both
diff --git a/doc/thesis/related_work.tex b/doc/thesis/related_work.tex
index f40d156..dc7ea38 100644
--- a/doc/thesis/related_work.tex
+++ b/doc/thesis/related_work.tex
@@ -351,7 +351,7 @@ security measure to prevent malicious actions if the user's 
email
 account was compromised. Also the token should be a randomly generated
 passphrase which has at least 8 characters.
 
-Another import part is that the email should not already contain the
+Another important part is that the email should not already contain the
 requested information, so in the case of Anastasis the keyshare.  This
 is because the SMTP protocol used for email offers no hard security
 assurances. In particular, the email is likely to be stored for a
@@ -484,8 +484,7 @@ three ways:
    is used. As a result, we worry that it may be possible for an attacker
    to successfully use social engineering via email (or other means)
    to illegitimately trigger a recovery process.
- \item The MIDATA system also does not offer any trust agility.
-   % FIXME: cite Moxie on trust agility!
+ \item The MIDATA system also does not offer any trust 
agility~\cite{marlinspike2011}.
    The user is forced to accept the 2-out-of-5 rule with trustees
    provided by MIDATA.
 \end{enumerate}

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.