[taler-anastasis] 03/03: some fixes: \begin{description} etc

[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 1bd95fe7704ded5e278f03be3d81c958f084ecce
Author: Dennis Neufeld <dennis.neufeld@students.bfh.ch>
AuthorDate: Sun Jun 7 19:10:57 2020 +0000

    some fixes: \begin{description} etc
---
 doc/thesis/design.tex         | 98 +++++++++++++++++++------------------------
 doc/thesis/implementation.tex |  7 ++--
 doc/thesis/related_work.tex   |  5 ++-
 3 files changed, 49 insertions(+), 61 deletions(-)

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/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/related_work.tex b/doc/thesis/related_work.tex
index dc7ea38..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}
 

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