[taler-anastasis] branch master updated (ab88ece -> 1bd95fe)

[gnunet]

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

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

    from ab88ece  fix table list
     new 250540a  some fixes
     new 44b0340  _handle -> _handler
     new 1bd95fe  some fixes: \begin{description} etc

The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 doc/thesis/bibliothek.bib           |   7 +++
 doc/thesis/design.tex               |  98 ++++++++++++++++--------------------
 doc/thesis/images/system_design.png | Bin 52261 -> 57272 bytes
 doc/thesis/implementation.tex       |   7 ++-
 doc/thesis/introduction.tex         |   4 +-
 doc/thesis/related_work.tex         |  10 ++--
 6 files changed, 60 insertions(+), 66 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/design.tex b/doc/thesis/design.tex
index 75d46cc..659211e 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -141,14 +141,11 @@ user_identifier_derive(identifier, server_salt, keysize)
 }
 \end{lstlisting}
 
-% FIXME: use \begin{description} \item[identifier] {TEXT} ...
-% (ditto below)
-\textbf{identifier}: The secret defined from the user beforehand. \\
-
-\textbf{server\_salt}: The salt from the Server \\
-
-\textbf{keysize}: The desired output size of the KDF, here 32 bytes. \\
-
+\begin{description}
+       \item[identifier] {The secret defined from the user beforehand.}
+       \item[server\_salt]{The salt from the Server.}
+       \item[keysize]{The desired output size of the KDF, here 32 bytes.}
+\end{description}
 
 \subsection{Verification}
 
@@ -177,26 +174,24 @@ return eddsa_priv, eddsa_pub
 }
 \end{lstlisting}
 
-\textbf{HKDF()}: The HKDF-function uses to phases: First we use HMAC-SHA512 
for the extraction phase, then HMAC-SHA256 is used for expansion phase. \\
-
-\textbf{kdf\_id}: Hashed identifier. \\
-
-\textbf{salt}: used that different keys are generated, the salt here is "ver". 
\\
-
-\textbf{key\_size}: Size of the output, here 32 bytes. \\
-
-\textbf{ver\_secret}: Derived key from the kdf\_id, serves as intermediate 
step for the generation of the private key. \\
-
-\textbf{eddsa\_d\_to\_a()}: Function which converts the ver\_key to a valid 
EdDSA private key. Specifically, assuming the value eddsa\_priv is in a 32-byte 
array “digest”, the function clears and sets certain bits as follows: \\
+\begin{description}
+       \item[HKDF()] {The HKDF-function uses to phases: First we use 
HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion 
phase.}
+       \item[kdf\_id] {Hashed identifier.}
+       \item[salt] {Is used that different keys are generated, the salt here 
is "ver".}
+       \item[key\_size] {Size of the output, here 32 bytes.}
+       \item[ver\_secret] {Derived key from the kdf\_id, serves as 
intermediate step for the generation of the private key.}
+       \item[eddsa\_d\_to\_a()] {Function which converts the ver\_key to a 
valid EdDSA private key. Specifically, assuming the value eddsa\_priv is in a 
32-byte array “digest”, the function clears and sets certain bits as follows:}
+\end{description}
 
 \begin{lstlisting}
 digest[0] = (digest[0] & 0x7f) | 0x40;
 digest[31] &= 0xf8;
 \end{lstlisting}
 
-\textbf{eddsa\_priv}: The generated EdDSA private key. \\
-
-\textbf{eddsa\_pub}: The generated EdDSA public key. \\
+\begin{description}
+       \item[eddsa\_priv] {The generated EdDSA private key.}
+       \item[eddsa\_pub] {The generated EdDSA public key.}
+\end{description}
 
 
 \subsection{Symmetric encryption}
@@ -217,20 +212,15 @@ return iv,key
 }
 \end{lstlisting}
 
-\textbf{HKDF()}: The HKDF-function uses to phases: First we use HMAC-SHA512 
for the extraction phase, then HMAC-SHA256 is used for expansion phase. \\
-
-\textbf{kdf\_id}: Hashed identifier \\
-
-\textbf{keysize}: Size of the AES symmetric key, here 32 bytes \\
-
-\textbf{ivsize}: Size of the AES GCM IV, here 12 bytes \\
-
-\textbf{nonce}: 32-byte nonce, must never match “ver” (which it cannot as the 
length is different). Of course, we must avoid key reuse. So, we must use 
different nonces to get different keys and ivs (see below). \\
-
-\textbf{key}: Symmetric key which is later used to encrypt the documents with 
AES256-GCM. \\
-
-\textbf{iv}: IV which will be used for AES-GCM \\
-
+\begin{description}
+       \item[HKDF()] {The HKDF-function uses to phases: First we use 
HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion 
phase.}
+       \item[kdf\_id] {Hashed identifier.}
+       \item[keysize] {Size of the AES symmetric key, here 32 bytes.}
+       \item[ivsize] {Size of the AES GCM IV, here 12 bytes.}
+       \item[nonce] {32-byte nonce, must never match “ver” (which it cannot as 
the length is different). Of course, we must avoid key reuse. So, we must use 
different nonces to get different keys and ivs (see below).}
+       \item[key] {Symmetric key which is later used to encrypt the documents 
with AES256-GCM.}
+       \item[iv] {IV which will be used for AES-GCM.}
+\end{description}
 
 The keys we have generated are then used to encrypt the \textbf{recovery 
document} and the \textbf{key\_share} of the user.
 
@@ -265,14 +255,12 @@ recovery_document_encrypt(kdf_id, recovery_document)
 
 \end{lstlisting}
 
-\textbf{encrypted\_recovery\_document}: The encrypted recovery document which 
contains the escrow methods, policies and the encrypted core secret. \\
-
-\textbf{encrypted\_key\_share}: The encrypted key\_share which the escrow 
provider must release upon successful authentication.\\
-
-\textbf{nonce}: Nonce which is used to generate keys and ivs which are used 
for the encryption. The nonce must contain either eks or erd.
-
-\textbf{encrypted\_data}: The encrypted data contains the either a recovery 
document or a key share which was encrypted and the nonce and the 
aes\_gcm\_tag. To be able to decrypt it the first 32Bytes are the nonce and the 
next 12 Bytes are the
-aes\_gcm\_tag.
+\begin{description}
+       \item[encrypted\_recovery\_document] {The encrypted recovery document 
which contains the escrow methods, policies and the encrypted core secret.}
+       \item[encrypted\_key\_share] {The encrypted key\_share which the escrow 
provider must release upon successful authentication.}
+       \item[nonce] {Nonce which is used to generate keys and ivs which are 
used for the encryption. The nonce must contain either eks or erd.}
+       \item[encrypted\_data] {The encrypted data contains the either a 
recovery document or a key share which was encrypted and the nonce and the 
aes\_gcm\_tag. To be able to decrypt it the first 32Bytes are the nonce and the 
next 12 Bytes are the aes\_gcm\_tag.}
+\end{description}
 
 
 \subsection{Signatures}
@@ -287,24 +275,24 @@ algorithm is also used to generate the
 ver_res = eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub
 \end{lstlisting}
 
-\textbf{anastasis-account-signature}: Signature over the SHA-512 hash of the 
body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_UPLOAD (1400) 
(see GNUnet EdDSA signature API for the use of purpose) \\
-
-\textbf{h\_body}: The hashed body. \\
+\begin{description}
+       \item[anastasis-account-signature] {Signature over the SHA-512 hash of 
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_UPLOAD 
(1400) (see GNUnet EdDSA signature API for the use of purpose).}
+       \item[h\_body] {The hashed body.}
+       \item[ver\_res] {A Boolean value. True: Signature verification passed, 
False: Signature verification failed.}
+\end{description}
 
-\textbf{ver\_res}: A Boolean value. True: Signature verification passed, 
False: Signature verification failed. \\
-\\
+\noindent 
 When requesting policy downloads, the client must also provide a signature:
 \begin{lstlisting}
 (anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
 ver_res = eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)
 \end{lstlisting}
 
-\textbf{anastasis-account-signature}: Signature over the SHA-512 hash of the 
body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_DOWNLOAD 
(1401) (see GNUnet EdDSA signature API for the use of purpose) \\
-
-\textbf{version}: The version requested as a 64-bit integer, for the “latest 
version”. \\
-
-\textbf{ver\_res}: A Boolean value. True: Signature verification passed, 
False: Signature verification failed. \\
-
+\begin{description}
+       \item[anastasis-account-signature] {Signature over the SHA-512 hash of 
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_DOWNLOAD 
(1401) (see GNUnet EdDSA signature API for the use of purpose).}
+       \item[version] {The version requested as a 64-bit integer, for the 
“latest version”.}
+       \item[ver\_res] {A Boolean value. True: Signature verification passed, 
False: Signature verification failed.}
+\end{description}
 
 
 \subsection{Availability considerations}
diff --git a/doc/thesis/images/system_design.png 
b/doc/thesis/images/system_design.png
index 20d7de7..52ff118 100644
Binary files a/doc/thesis/images/system_design.png and 
b/doc/thesis/images/system_design.png differ
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index 2fb65a5..15cc054 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -37,7 +37,6 @@ application. It shows a simplified flow of the application. 
The
 details of each component are explained later.
 
 \begin{figure}[H]
-  % FIXME: _handle => handler (!)
        \centering
                \includegraphics[scale=0.4]{images/system_design.png}
        \caption{System design overview}
@@ -229,12 +228,12 @@ Below is an example transcript of an interaction with the 
splitter:
 $ anastasis-splitter --me=identity.json
 anastasis-splitter> server add $URL1
 version: 1.0
-annual fee: EUR:4.99,
+annual fee: 4.99 KUDOS,
 available policy methods: sms
 Server #1 available
 anastasis-splitter> server add $URL2
 version: 1.0
-annual fee: EUR:3.99,
+annual fee: 3.99 KUDOS,
 available policy methods: sms, question
 Server #2 available
 anastasis-splitter> truth add server#1 sms +492452526
@@ -400,7 +399,7 @@ and Free Software.~\cite{libmicrohttpd}
 To test our application, we used the GNU Taler testing library as our
 foundation.  This library allows you to create testing instances of
 both the Anastasis application and the GNU Taler payment system. We
-implemented unit tests for every command in our application. A
+implemented unit tests for the crypto functions and the simple HTTP REST. A
 simplified test flow would be the following:
 
 \begin{enumerate}
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..bc0dc89 100644
--- a/doc/thesis/related_work.tex
+++ b/doc/thesis/related_work.tex
@@ -96,7 +96,7 @@ $HMAC_{K}(M) = H(K \oplus opad,H(K \oplus ipad, M))$ with 
"ipad" and
 the hash function~\cite{BCK1996}. The blocksize of a modern hash
 function like SHA-512 is 64 bytes.
 
-In Anastasis we use HMACs to achieve verifiability.
+% In Anastasis we use HMACs to achieve verifiability.
 % CG: verifiability of WHAT?
 % CG: I don't recall seeing HMACs in Anastasis, except for:
 
@@ -177,7 +177,8 @@ conceive users providing more than a handful of 
authentication methods
 For Anastasis, we thus decided to opt for more flexible approach that
 allows complex policies for recovery authorization, instead of only
 $k$-out-of-$n$. Each user of Anastasis is also able to decide which
-combinations of \textit{players} shall be permitted. % CG: players!?!?
+combinations of \textit{players}, which in case of Anastasis are the 
+escrow providers, shall be permitted. % CG: players!?!?
 
 \subsubsection{Verifiable Secret Sharing}
 
@@ -351,7 +352,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 +485,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.