[taler-anastasis] branch master updated: restructure design chapter (high-level)

[gnunet]

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

grothoff pushed a commit to branch master
in repository anastasis.

The following commit(s) were added to refs/heads/master by this push:
     new 5a9cf2a  restructure design chapter (high-level)
5a9cf2a is described below

commit 5a9cf2ac42ebe945a711eebfd4c157b37c57d35c
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sun Jun 7 01:10:24 2020 +0200

    restructure design chapter (high-level)
---
 doc/thesis/client_architecture.tex |  31 +++++++---
 doc/thesis/design.tex              | 123 +++++++++++++++++++++++++++++++++++++
 doc/thesis/server_architecture.tex | 114 +++++++++++++++++++++++++++-------
 doc/thesis/thesis.bcf              |  81 ++++++++++++------------
 doc/thesis/thesis.lof              |   6 +-
 doc/thesis/thesis.tex              |   4 --
 6 files changed, 280 insertions(+), 79 deletions(-)

diff --git a/doc/thesis/client_architecture.tex 
b/doc/thesis/client_architecture.tex
index 05238a8..1dce670 100644
--- a/doc/thesis/client_architecture.tex
+++ b/doc/thesis/client_architecture.tex
@@ -1,14 +1,24 @@
-\section{Client architecture}
-The Anastasis client architecture consists of two components. A client API 
which communicates with the server and a command line application which 
interacts with the user. The structure of these two components is shown here.
+\subsection{Client architecture}
 
-\subsection{Client API}
-The Anastasis Client uses three APIs. The Crypto API which provides the 
different
-cryptographic functions, a service API which sends the request to the server 
and the main client API which manages the communication between the different 
APIs.
+The Anastasis client architecture consists of two components. A client
+API which communicates with the server and a command line application
+which interacts with the user. The structure of these two components
+is shown here.
+
+The Anastasis Client uses three APIs. The Crypto API which provides
+the different cryptographic functions, a service API which sends the
+request to the server and the main client API which manages the
+communication between the different APIs.
 
 \subsubsection{Crypto API}
-Following is a list over the most important data structures in the crypto API.
 
-The kdf\_id is a hash code which was generated with Argon2. The entropy source 
is the user's unforgettable secret. The kdf\_id is used to create various 
key's, for more details see Implementation Cryptography
+Following is a list over the most important data structures in the
+crypto API.
+
+The kdf\_id is a hash code which was generated with Argon2. The
+entropy source is the user's unforgettable secret. The kdf\_id is used
+to create various key's, for more details see Implementation
+Cryptography
 \begin{lstlisting}
 struct kdf_id
 {
@@ -221,9 +231,14 @@ struct challenge
 \end{itemize}
 
 \subsubsection{Service API}
-The service API is responsible for sending the requests to the REST API of the 
server. The client has implemented functions for every end point. For more 
details see REST API documentation in the appendix.
+
+The service API is responsible for sending the requests to the REST
+API of the server. The client has implemented functions for every end
+point. For more details see REST API documentation in the appendix.
+
 
 \subsection{Client Application CLI}
+
 There are two client applications which interact with the user. First the 
Anastasis splitter and second the Anastasis assembler. The splitter application 
is responsible for the backup of the core secret. The assembler is then 
responsible for the recovery of the secret. \\
  \\
 \textbf{Anastasis splitter} \\
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 74158f3..86608eb 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -25,3 +25,126 @@ The crypto\_api is later also responsible for the 
decryption and encryption of t
 \item The webserver handles the requests sent to him by the clients. It will 
then send the request to the according handle. The webserver will later send 
back the requested data or the status code of the operation back to the client 
application.
 \item Each operation has a different handle. The handle will then process the 
request. It will either store or lookup the requested data on the database. 
When the request is finished, the handle will send back the data or the status 
code to the webserver and afterwards to the client.
 \end{enumerate}
+
+
+\input{server_architecture}
+
+\input{client_architecture}
+
+
+
+\subsection{Client Application Command Line Interface (CLI)}
+
+There are two client applications which interact with the user. First the 
Anastasis splitter and second the Anastasis assembler. The splitter application 
is responsible for the backup of the core secret. The assembler is then 
responsible for the recovery of the secret. \\
+ \\
+\textbf{Anastasis splitter} \\
+ \\
+\textbf{Available commands: }
+\begin{itemize}
+\item server add \$URL : this command lets the user add escrow providers. The 
command will check if the server is available under the provided url. Afterwards
+it will download its terms and salt. The server needs to be added before the 
user can do any uploads on it.
+\item truth add \$server \$method \$truth : with this command the user can 
upload
+a truth on a previously added server. He needs to specify the method used and 
the
+truth for the method, for example the phone number or the question and the 
answer.
+The programm will check if the server supports the provided method before 
uploading.
+\item policy add \$truth1 \$truth2... : after the user has added all the 
truths he can start to create policies. He can combine the truths in any way he 
wishes. It is also possible to just store one truth in a policy, but this is 
not recommended since it defies the design of the application.
+\item policy : shows all created policies.
+\item truth : shows all created truths.
+\item server : shows all added servers.
+\item publish \$secret : if the user is finished he can publish the 
configuration. The application will then generate the recovery document with 
the provided information and secret. Afterwards it will upload the recovery 
document on every used server.
+\end{itemize}
+Below is an example flow of the application. \\
+\begin{lstlisting}
+//The user starts the programm and passes a json document
+//containing the unforgetable secret(name, social security number..)
+$ anastasis-splitter --me=identity.json
+anastasis-splitter> server add $URL1
+version: 1.0
+annual fee: EUR:4.99,
+available policy methods: sms
+Server #1 available
+anastasis-splitter> server add $URL2
+version: 1.0
+annual fee: EUR:3.99,
+available policy methods: sms, question
+Server #2 available
+anastasis-splitter> truth add server#1 sms +492452526
+Truth #1 added for server #1
+anastasis-splitter> truth add server#2 mail "hoehenweg 80, Biel"
+Sorry, server #2 does not support 'mail'
+anastasis-splitter> truth add question "favorite color" "red"
+Truth #2 added
+anastasis-splitter> policy add truth#1 truth#2
+Policy #1 defined
+anastasis-splitter> policy
+Policy#1: #truth#1 #truth2
+anastasis-splitter> truth
+truth#1: server#1 sms  +492452526
+truth#2: server#2 question "favorite color" <OMITTED>
+anastasis-splitter> truth --secrets
+truth#1: sms  +492452526
+truth#2: question "favorite color" "red"
+anastasis-splitter> server
+server#1: http://anastasis.example.com/ methods: sms,
+insured up to: 420 KUDOS, cost: 0.4 KUDOS
+anastasis-splitter> publish
+Server#1 failure: 402 payment required:
+payto://pay/ABALSASDFA KUDOS:0.3
+Server#2 failure: 402 payment required:
+payto://pay/ABALSAADAS KUDOS:0.5
+Total: 0.8 KUDOS
+# Here: taler-wallet-cli payto://pay/ABALASDFA used to pay!
+anastasis-splitter> publish
+Server#2 failure: 402 payment required
+# Here: taler-wallet-cli payto://pay/ABASDFASDF used to pay!
+anastasis-splitter> publish "my super secret"
+Thank you for using Anastasis.
+$
+\end{lstlisting}
+\textbf{Anastasis assembler} \\
+ \\
+\textbf{Available commands:} \\
+\begin{itemize}
+\item truth : shows all available truths in the recovery document and its 
status
+( (-) not solved (+) solved )
+\item policies : shows all available policies in the recovery document and
+the respective status of the truths used in each policy.
+\item try \$truth : this command starts a truth which needs interaction with 
external services like sms or e-mail. It also shows the instructions to solve a 
truth.
+\item answer \$truth \$answer : this command tries to answer the selected 
truth with the provided answer. The application will check the answer and give 
a feedback to the user. Everytime a truth is solved, the client\_api will check 
if a policy is solved, if a policy was solved successfully the application will 
print out the recovered core secret.
+\end{itemize}
+Below is an example flow of the application. \\
+\begin{lstlisting}
+//The user starts the programm and passes a json document
+//containing the unforgetable secret(name, social security number..),
+//a url to a escrow provider which stores his recovery document and
+//the requested version of the recovery document. The client will then
+//download the recovery document within the startup
+$ anastasis-assembler --import https://anastasis.example.com/
+--policy-version=42 --me=identity.json
+anastasis-assembler> truth
+truth#1(-): KUDOS 0.0 question "favorite color"
+truth#2(-): KUDOS 0.4 sms
+truth#3(-): KUDOS 2.6 post
+anastasis-assembler> policies
+policy#1: KUDOS 0.4 truth#1 truth#2 missing
+policy#2: KUDOS 3.0 truth#1 truth#2 truth#3 missing
+anastasis-assembler> try truth#2
+payto://pay/BASDFASD
+# SMS arrives asynchronously
+anastasis-assembler> answer truth#2 1234
+Success truth#2
+anastasis-assembler> answer truth#1 "blue"
+Failed truth#1
+anastasis-assembler> truth
+truth#1(-): KUDOS 0.0 question "favorite color"
+truth#2(+): KUDOS 0.4 sms
+truth#3(-): KUDOS 2.6 post
+anastasis-assembler> policies
+policy#1: KUDOS 0.0 truth#1 missing
+policy#2: KUDOS 2.6 truth#1 truth#3 missing
+anastasis-assembler> answer truth#2 "red"
+Success truth#2
+//One of the policies was solved successfully and the secret is recovered.
+Secret was: "my super secret"
+$
+\end{lstlisting}
diff --git a/doc/thesis/server_architecture.tex 
b/doc/thesis/server_architecture.tex
index 0692699..602542a 100644
--- a/doc/thesis/server_architecture.tex
+++ b/doc/thesis/server_architecture.tex
@@ -1,7 +1,13 @@
-\section{Server architecture}
-The Anastasis server architecture consists of two components. A web server 
with a REST API and a PostgreSQL database. The structure of these two 
components is shown here.
-\subsection{Database}
-The database schema of Anastasis is structured as follows.
+\subsection{Server architecture}
+
+The Anastasis server architecture consists of two components. A web
+server with a REST API and a PostgreSQL database. The structure of
+these two components is shown here.
+
+\subsubsection{Database}
+
+The database schema of Anastasis is shown in
+Figure~\ref{fig:anastasis_database}.
 \begin{figure}[H]
        \centering
                \includegraphics[scale=0.5]{images/anastasis-db.png}
@@ -9,30 +15,92 @@ The database schema of Anastasis is structured as follows.
        \label{fig:anastasis_database}
 \end{figure}
 
-The database schema consists of 4 tables. \\
-The Truth table is responsible for storing the key shares and its 
authentication method. The key share and the truth are stored encrypted in the 
database. The truth is only decrypted during authentication. The key share is 
never decrypted for the server. This protects the privacy of the customer. 
Likewise, the user data is protected after a possible theft. \\
-The User table contains the identification of the user and an expiration 
timestamp. This timestamp is a subscription period. This timestamp is updated 
after each payment the user makes. Users for whom the subscription has expired 
are periodically deleted. \\
-The Payments table contains the details of a payment from a user. The payment 
is used either for the post-counter or the subscription. The post-counter is 
decremented after each upload of a recovery document. The user can only upload 
the recovery document if the provided payment contains a post-counter which is 
at least 1.
-Through this measure we can prevent people from maliciously filling our 
database. \\
-The Recoverydocument table contains the recovery information. The recovery 
document is stored encrypted in the database. This offers better protection, as 
explained earlier for the Truth table. Each recovery document record also 
contains a version, a hash of the recovery document and a signature. The 
version attribute allows the user to lookup a specific version of the document. 
The hash is used to check if the user uploads a duplicate of the document. Last 
the signature ensures the inte [...]
+The database schema consists of 4 tables:
+
+\begin{itemize}
+\item The Truth table is responsible for storing the key shares and
+  its authentication method. The key share and the truth are stored
+  encrypted in the database. The truth is only decrypted during
+  authentication. The key share is never decrypted for the
+  server. This protects the privacy of the customer. Likewise, the
+  user data is protected after a possible theft.
+\item The User table contains the identification of the user and an
+  expiration timestamp. This timestamp is a subscription period. This
+  timestamp is updated after each payment the user makes. Users for
+  whom the subscription has expired are periodically deleted.
+\item The Payments table contains the details of a payment from a
+  user. The payment is used either for the post-counter or the
+  subscription. The post-counter is decremented after each upload of a
+  recovery document. The user can only upload the recovery document if
+  the provided payment contains a post-counter which is at least 1.
+  Through this measure we can prevent people from maliciously filling
+  our database.
+\item The Recoverydocument table contains the recovery
+  information. The recovery document is stored encrypted in the
+  database. This offers better protection, as explained earlier for
+  the Truth table. Each recovery document record also contains a
+  version, a hash of the recovery document and a signature. The
+  version attribute allows the user to lookup a specific version of
+  the document. The hash is used to check if the user uploads a
+  duplicate of the document. Last the signature ensures the integrity
+  of the data.
+\end{itemize}
+
+\subsubsection{Server API}
 
-\subsection{Server API}
 The webserver of Anastasis runs a RESTful API. For a detailed documentation of 
the
 REST API see the rest\_api\_documentation in the appendix.
 
-\subsection{Authentication Methods}
-This section describes an overview over the different possible authentication 
methods for Anastasis. In our implementation only the secure question is 
implemented. The other methods are just explained how they would be implemented.
+\subsubsection{Authentication Methods}
+
+This section describes an overview over the different possible
+authentication methods for Anastasis. In our implementation only the
+secure question is implemented. The other methods are just explained
+how they would be implemented.
+
+\paragraph{SMS (sms)}
+
+The user tells the server with a request that he wants to authenticate
+with him (GET /truth/\$UUID. The server will then generate a pin and
+send it with an SMS provider to the stored number in the truth
+object. The client then must send another request with the sent pin
+(GET /truth/\$UUID?resonse=\$RESPONSE). The server can now check if
+the two pins match. Upon success the server will release the encrypted
+key share.
+
+\paragraph{Video identification (vid)}
+
+Requires the user to identify via video-call. The user is expected to
+delete all metadata revealing information about him/her from the
+images before uploading them. Since the respective images must be
+passed on to the video identification service in the event of password
+recovery, it must be ensured that no further information about the
+user can be derived from them.
+
+The user first must send a request to server that he wants to
+authenticate(GET /truth/\$UUID).  The server will then send a request
+to the video authentication provider that a user wants to
+authenticate. The provider will generate a link to a video conference
+which is sent to the user. The authentication provider then checks
+with image if the user is legitimate. Upon success the video provider
+sends an ok to the server and the server will release the key share.
 
-\subsubsection{SMS (sms)}
-The user tells the server with a request that he wants to authenticate with 
him(GET /truth/\$UUID. The server will then generate a pin and send it with an 
SMS provider to the stored number in the truth object. The client then must 
send another request with the sent pin(GET /truth/\$UUID?resonse=\$RESPONSE). 
The server can now check if the two pins match. Upon success the server will 
release the encrypted key share.
+\paragraph{Post identification (post)}
 
-\subsubsection{Video identification (vid)}
-Requires the user to identify via video-call. The user is expected to delete 
all metadata revealing information about him/her from the images before 
uploading them. Since the respective images must be passed on to the video 
identification service in the event of password recovery, it must be ensured 
that no further information about the user can be derived from them. \\
-The user first must send a request to server that he wants to authenticate(GET 
/truth/\$UUID).
-The server will then send a request to the video authentication provider that 
a user wants to authenticate. The provider will generate a link to a video 
conference which is sent to the user. The authentication provider then checks 
with image if the user is legitimate. Upon success the video provider sends an 
ok to the server and the server will release the key share.
+The user tells the server with a request that he wants to authenticate
+with him (GET /truth/\$UUID). The server will then send a letter
+containing a pin with a post-service to the users address which is
+stored in the truth object. The client then has to send another
+request with the sent pin (GET /truth/\$UUID?resonse=\$RESPONSE). The
+server can now check if the two pins match. Upon success the server
+will release the encrypted key share.
 
-\subsubsection{Post identification (post)}
-The user tells the server with a request that he wants to authenticate with 
him(GET /truth/\$UUID. The server will then send a letter containing a pin with 
a post-service to the users address which is stored in the truth object. The 
client then has to send another request with the sent pin(GET 
/truth/\$UUID?resonse=\$RESPONSE). The server can now check if the two pins 
match. Upon success the server will release the encrypted key share.
+\paragraph{Security question (qa)}
 
-\subsubsection{Security question (qa)}
-The user defines a secure question and answer and stores it on a server. The 
server stores the instructions, here the question, encrypted. The answer is 
stored hashed on the server, the server will never learn the plaintext answer. 
If the user wants to release the key share from the server he must provide the 
hashed answer. The server then checks if the stored and the provided hash 
match. Upon success the server will send the encrypted key share.
+The user defines a secure question and answer and stores it on a
+server. The server stores the instructions, here the question,
+encrypted. The answer is stored hashed on the server, the server will
+never learn the plaintext answer. If the user wants to release the key
+share from the server he must provide the hashed answer. The server
+then checks if the stored and the provided hash match. Upon success
+the server will send the encrypted key share.
diff --git a/doc/thesis/thesis.bcf b/doc/thesis/thesis.bcf
index 3597da1..873c861 100644
--- a/doc/thesis/thesis.bcf
+++ b/doc/thesis/thesis.bcf
@@ -2189,52 +2189,51 @@
     <bcf:citekey order="4">millions_lost</bcf:citekey>
     <bcf:citekey order="5">bitcoin-keys</bcf:citekey>
     <bcf:citekey order="6">bitcoin-keys</bcf:citekey>
-    <bcf:citekey order="7">bitlocker</bcf:citekey>
-    <bcf:citekey order="8">bajikar2002</bcf:citekey>
+    <bcf:citekey order="7">bajikar2002</bcf:citekey>
+    <bcf:citekey order="8">vadhan2012</bcf:citekey>
     <bcf:citekey order="9">vadhan2012</bcf:citekey>
-    <bcf:citekey order="10">vadhan2012</bcf:citekey>
-    <bcf:citekey order="11">nielsen2002</bcf:citekey>
-    <bcf:citekey order="12">GGM1986</bcf:citekey>
-    <bcf:citekey order="13">Preneel1999</bcf:citekey>
+    <bcf:citekey order="10">nielsen2002</bcf:citekey>
+    <bcf:citekey order="11">GGM1986</bcf:citekey>
+    <bcf:citekey order="12">Preneel1999</bcf:citekey>
+    <bcf:citekey order="13">SG2012</bcf:citekey>
     <bcf:citekey order="14">SG2012</bcf:citekey>
     <bcf:citekey order="15">SG2012</bcf:citekey>
-    <bcf:citekey order="16">SG2012</bcf:citekey>
-    <bcf:citekey order="17">RK2011</bcf:citekey>
-    <bcf:citekey order="18">GJW2011</bcf:citekey>
-    <bcf:citekey order="19">BCK1996</bcf:citekey>
-    <bcf:citekey order="20">krawczyk2010</bcf:citekey>
-    <bcf:citekey order="21">trimberger2012</bcf:citekey>
-    <bcf:citekey order="22">madurawe2006</bcf:citekey>
-    <bcf:citekey order="23">BDK2016</bcf:citekey>
-    <bcf:citekey order="24">stamp2003</bcf:citekey>
+    <bcf:citekey order="16">RK2011</bcf:citekey>
+    <bcf:citekey order="17">GJW2011</bcf:citekey>
+    <bcf:citekey order="18">BCK1996</bcf:citekey>
+    <bcf:citekey order="19">krawczyk2010</bcf:citekey>
+    <bcf:citekey order="20">trimberger2012</bcf:citekey>
+    <bcf:citekey order="21">madurawe2006</bcf:citekey>
+    <bcf:citekey order="22">BDK2016</bcf:citekey>
+    <bcf:citekey order="23">stamp2003</bcf:citekey>
+    <bcf:citekey order="24">BDK2016</bcf:citekey>
     <bcf:citekey order="25">BDK2016</bcf:citekey>
-    <bcf:citekey order="26">BDK2016</bcf:citekey>
-    <bcf:citekey order="27">shamir_sharing</bcf:citekey>
-    <bcf:citekey order="28">pedersen_sharing_0</bcf:citekey>
-    <bcf:citekey order="29">feldman_sharing</bcf:citekey>
-    <bcf:citekey order="30">pedersen_sharing_5.2</bcf:citekey>
-    <bcf:citekey order="31">coinbase</bcf:citekey>
-    <bcf:citekey order="32">midata</bcf:citekey>
-    <bcf:citekey order="33">midata</bcf:citekey>
-    <bcf:citekey order="34">midata</bcf:citekey>
-    <bcf:citekey order="35">multifactor_authentication</bcf:citekey>
-    <bcf:citekey order="36">authentication_methods_review</bcf:citekey>
-    <bcf:citekey order="37">just2004</bcf:citekey>
-    <bcf:citekey order="38">just2004</bcf:citekey>
-    <bcf:citekey order="39">MBSS2013</bcf:citekey>
-    <bcf:citekey order="40">rieck_detection</bcf:citekey>
-    <bcf:citekey order="41">emailauthowasp</bcf:citekey>
-    <bcf:citekey order="42">pohlmann2017</bcf:citekey>
-    <bcf:citekey order="43">biometric_auth</bcf:citekey>
-    <bcf:citekey order="44">ccc_merkel</bcf:citekey>
+    <bcf:citekey order="26">shamir_sharing</bcf:citekey>
+    <bcf:citekey order="27">pedersen_sharing_0</bcf:citekey>
+    <bcf:citekey order="28">feldman_sharing</bcf:citekey>
+    <bcf:citekey order="29">pedersen_sharing_5.2</bcf:citekey>
+    <bcf:citekey order="30">multifactor_authentication</bcf:citekey>
+    <bcf:citekey order="31">authentication_methods_review</bcf:citekey>
+    <bcf:citekey order="32">just2004</bcf:citekey>
+    <bcf:citekey order="33">just2004</bcf:citekey>
+    <bcf:citekey order="34">MBSS2013</bcf:citekey>
+    <bcf:citekey order="35">rieck_detection</bcf:citekey>
+    <bcf:citekey order="36">emailauthowasp</bcf:citekey>
+    <bcf:citekey order="37">pohlmann2017</bcf:citekey>
+    <bcf:citekey order="38">biometric_auth</bcf:citekey>
+    <bcf:citekey order="39">ccc_merkel</bcf:citekey>
+    <bcf:citekey order="40">coinbase</bcf:citekey>
+    <bcf:citekey order="41">midata</bcf:citekey>
+    <bcf:citekey order="42">midata</bcf:citekey>
+    <bcf:citekey order="43">midata</bcf:citekey>
+    <bcf:citekey order="44">gnu_taler</bcf:citekey>
     <bcf:citekey order="45">gnu_taler</bcf:citekey>
-    <bcf:citekey order="46">gnu_taler</bcf:citekey>
-    <bcf:citekey order="47">postgresql</bcf:citekey>
-    <bcf:citekey order="48">libcurl</bcf:citekey>
-    <bcf:citekey order="49">libmicrohttpd</bcf:citekey>
-    <bcf:citekey order="50">global_data_index</bcf:citekey>
-    <bcf:citekey order="51">millions_lost</bcf:citekey>
-    <bcf:citekey order="52">forgot_my_pin</bcf:citekey>
+    <bcf:citekey order="46">postgresql</bcf:citekey>
+    <bcf:citekey order="47">libcurl</bcf:citekey>
+    <bcf:citekey order="48">libmicrohttpd</bcf:citekey>
+    <bcf:citekey order="49">global_data_index</bcf:citekey>
+    <bcf:citekey order="50">millions_lost</bcf:citekey>
+    <bcf:citekey order="51">forgot_my_pin</bcf:citekey>
   </bcf:section>
   <!-- SORTING TEMPLATES -->
   <bcf:sortingtemplate name="none">
diff --git a/doc/thesis/thesis.lof b/doc/thesis/thesis.lof
index 55a91f6..ffdd1d0 100644
--- a/doc/thesis/thesis.lof
+++ b/doc/thesis/thesis.lof
@@ -4,15 +4,15 @@
 \defcounter {refsection}{0}\relax 
 \contentsline {figure}{\numberline {1}{\ignorespaces System 
architecture}}{2}{figure.1}%
 \defcounter {refsection}{0}\relax 
-\contentsline {figure}{\numberline {2}{\ignorespaces Derivation of user 
identifier}}{2}{figure.2}%
+\contentsline {figure}{\numberline {2}{\ignorespaces Derivation of a user 
identifier}}{3}{figure.2}%
 \defcounter {refsection}{0}\relax 
 \contentsline {figure}{\numberline {3}{\ignorespaces Master key in Bitcoin 
Wallets\nobreakspace {}\cite {bitcoin-keys}}}{4}{figure.3}%
 \defcounter {refsection}{0}\relax 
 \contentsline {figure}{\numberline {4}{\ignorespaces Anasasis project 
plan}}{6}{figure.4}%
 \defcounter {refsection}{0}\relax 
-\contentsline {figure}{\numberline {5}{\ignorespaces System design 
overview}}{17}{figure.5}%
+\contentsline {figure}{\numberline {5}{\ignorespaces System design 
overview}}{16}{figure.5}%
 \defcounter {refsection}{0}\relax 
-\contentsline {figure}{\numberline {6}{\ignorespaces Anastasis 
database}}{19}{figure.6}%
+\contentsline {figure}{\numberline {6}{\ignorespaces Anastasis 
database}}{17}{figure.6}%
 \defcounter {refsection}{0}\relax 
 \contentsline {figure}{\numberline {7}{\ignorespaces Secret split 
process}}{32}{figure.7}%
 \defcounter {refsection}{0}\relax 
diff --git a/doc/thesis/thesis.tex b/doc/thesis/thesis.tex
index ec2bab5..2d81373 100644
--- a/doc/thesis/thesis.tex
+++ b/doc/thesis/thesis.tex
@@ -57,10 +57,6 @@
 
 \include{design}
 
-\include{server_architecture}
-
-\include{client_architecture}
-
 \include{implementation}
 
 \include{business_model}

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