[taler-anastasis] branch master updated: rewrite recovery document

[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 142a290  rewrite recovery document
     new 653cdfb  Merge branch 'master' of git+ssh://git.taler.net/anastasis
142a290 is described below

commit 142a2908e8a809f0858d9efb28c11765f6d51293
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Jun 11 12:30:35 2020 +0200

    rewrite recovery document
---
 doc/thesis/design.tex | 56 +++++++++++++++++++++++++++++----------------------
 1 file changed, 32 insertions(+), 24 deletions(-)

diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 1d96f2c..b209279 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -141,29 +141,37 @@ trust, resulting in trust agility~\cite{marlinspike2011}.
 \subsection{The recovery document}
 
 A {\em recovery document} includes all the information a user needs to
-recover access to their core secret. It specifies a set of {\em authentication
-  methods}, which specify how the user should convince the Anastasis
-server that they are ``real''. Authentication methods can for example include
-SMS-based verification, Video-identification or a security
-question. For each authentication method, the Anastasis server is provided
-with (initially encrypted) {\em 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 (except if they are the provider and
-then they may learn it only during key recovery).
-
-In addition to a set of authentication methods and associated Anastasis server
-operators, the recovery document also specifies {\em policies}, which
-describe the combination(s) of the authentication methods that suffice to
-obtain access to the core secret. For example, a policy could say that
-the authentication 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 authentication methods involved in guarding a user’s secret. Weak
-adversaries must not be able to deduce information about a user’s
+recover access to their core secret. It primarily identifies a set of
+{\em encrypted key shares} which have been entrusted to different
+Anastasis providers. For each key share, the recovery document
+specifies the respective Anastasis provider and also prescribes the
+{\em authentication method}, which specifies how the user should
+convince the Anastasis server that they are authorized to retreive the
+encrypted key share.  Authentication methods can for example include
+SMS-based verification, Video-identification or a security question.
+
+For each authentication method, specific Anastasis providers are separately
+provided (see Section~\ref{sec:truth}) with the associated {\em encrypted key
+  share} and (separately encrypted) {\em authentication
+  data}. Anastasis operators may learn the authentication data during
+the recovery process to authenticate the user. Examples for
+authentication data 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
+authentication data, while weak adversaries must not (except if they
+are the provider and then they may learn it only during key recovery).
+
+The recovery document also specifies {\em policies}, which describe
+the combination(s) of the key shares (and thus authentication
+processes) that would suffice to obtain access to the core secret. For
+example, a policy could say that the authentication 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
+authentication 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 meta data such as its length or
 approximate creation time, which may be exposed to an adversary which
 monitors the user’s network traffic or operates an escrow provider).
@@ -345,7 +353,7 @@ ver_res =
 \end{description}
 
 
-\subsection{Authenticity of truth}
+\subsection{Authenticity of truth} \label{sec:truth}
 
 \texttt{/truth/} requests are used to upload encrypted authentication data
 and encrypted key shares to an Anastasis escrow service.  As an additional

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