[taler-anastasis] branch master updated: indentation only

[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 af0dc29  indentation only
af0dc29 is described below

commit af0dc29b88c3aebb24d933e76bee87dc6ebb3ce4
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sun Jun 7 01:14:18 2020 +0200

    indentation only
---
 doc/thesis/design.tex | 82 ++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 68 insertions(+), 14 deletions(-)

diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 86608eb..7b8e679 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -1,14 +1,62 @@
 \section{Design}
-Anastasis is a service that allows the user to securely deposit a core secret 
with an open set of escrow providers and recover it if the secret is lost. The 
core secret itself is protected from the escrow providers by encrypting it with 
a master key. The main objective of Anastasis is to ensure that the user can 
reliably recover the core secret, while making this difficult for everyone 
else. Furthermore, it is assumed that the user is unable to reliably remember 
any secret with sufficien [...]
- \\
-To uniquely identify users, an “unforgettable” identifier is used. This 
identifier should be difficult to guess for anybody but the user. However, the 
identifier is not expected to have sufficient entropy or secrecy to be 
cryptographically secure. Examples for such identifier would be a concatenation 
of the full name of the user and their social security or passport number(s). 
For Swiss citizens, the AHV number could also be used. \\
- \\
-The adversary model of Anastasis has two types of adversaries: weak 
adversaries which do not know the user’s identifier, and strong adversaries 
which somehow do know a user’s identifier. For weak adversaries, the system 
guarantees full confidentiality. For strong adversaries, breaking 
confidentiality additionally requires that Anastasis escrow providers must have 
colluded. The user can specify a set of policies which determine which 
Anastasis escrow providers would need to collude to bre [...]
- \\
-A recovery document includes all the information a user needs to recover 
access to their core secret. It specifies a set of escrow methods, which 
specify how the user should convince the Anastasis server that they are “real”. 
Escrow methods can for example include SMS-based verification, 
Video-identification or a security question. For each escrow method, the 
Anastasis server is provided with truth, that is data the Anastasis operator 
may learn during the recovery process to authenticate [...]
+
+Anastasis is a service that allows the user to securely deposit a core
+secret with an open set of escrow providers and recover it if the
+secret is lost. The core secret itself is protected from the escrow
+providers by encrypting it with a master key. The main objective of
+Anastasis is to ensure that the user can reliably recover the core
+secret, while making this difficult for everyone else. Furthermore, it
+is assumed that the user is unable to reliably remember any secret
+with sufficiently high entropy, so we cannot simply encrypt using some
+other key material in possession of the user.
+
+To uniquely identify users, an “unforgettable” identifier is
+used. This identifier should be difficult to guess for anybody but the
+user. However, the identifier is not expected to have sufficient
+entropy or secrecy to be cryptographically secure. Examples for such
+identifier would be a concatenation of the full name of the user and
+their social security or passport number(s). For Swiss citizens, the
+AHV number could also be used.
+
+The adversary model of Anastasis has two types of adversaries: weak
+adversaries which do not know the user’s identifier, and strong
+adversaries which somehow do know a user’s identifier. For weak
+adversaries, the system guarantees full confidentiality. For strong
+adversaries, breaking confidentiality additionally requires that
+Anastasis escrow providers must have colluded. The user can specify a
+set of policies which determine which Anastasis escrow providers would
+need to collude to break confidentiality. These policies also set the
+bar for the user to recover their core secret.
+
+A recovery document includes all the information a user needs to
+recover access to their core secret. It specifies a set of escrow
+methods, which specify how the user should convince the Anastasis
+server that they are “real”. Escrow methods can for example include
+SMS-based verification, Video-identification or a security
+question. For each escrow method, the Anastasis server is provided
+with truth, that is data the Anastasis operator may learn during the
+recovery process to authenticate the user. Examples for truth would be
+a phone number (for SMS), a picture of the user (for video
+identification), or the (hash of) a security answer. A strong
+adversary is assumed to be able to learn the truth, while weak
+adversaries must not. In addition to a set of escrow methods and
+associated Anastasis server operators, the recovery document also
+specifies policies, which describe the combination(s) of the escrow
+methods that suffice to obtain access to the core secret. For example,
+a policy could say that the escrow methods (A and B) suffice, and a
+second policy may permit (A and C). A different user may choose to use
+the policy that (A and B and C) are all required. Anastasis imposes no
+limit on the number of policies in a recovery document, or the set of
+providers or escrow methods involved in guarding a user’s secret. Weak
+adversaries must not be able to deduce information about a user’s
+recovery document (except for its length, which may be exposed to an
+adversary which monitors the user’s network traffic).
 
 \subsection{System architecture}
-This graphic shows the basic construct of the Anastasis application. It shows 
a simplified flow of the application. The details of each component is shown 
later.
+
+This graphic shows the basic architecture of the Anastasis
+application. It shows a simplified flow of the application. The
+details of each component is shown later.
 \begin{figure}[H]
        \centering
                \includegraphics[scale=0.4]{images/system_design.png}
@@ -35,10 +83,14 @@ The crypto\_api is later also responsible for the 
decryption and encryption of t
 
 \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} \\
- \\
+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.
+
+\subsubsection{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
@@ -101,8 +153,10 @@ anastasis-splitter> publish "my super secret"
 Thank you for using Anastasis.
 $
 \end{lstlisting}
-\textbf{Anastasis assembler} \\
- \\
+
+
+\subsubsection{Anastasis assembler}
+
 \textbf{Available commands:} \\
 \begin{itemize}
 \item truth : shows all available truths in the recovery document and its 
status

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