[taler-anastasis] branch master updated: restructure

[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 2cd8c2a  restructure
2cd8c2a is described below

commit 2cd8c2a3b548106863f21f5fb1f130f08366b066
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Jun 11 12:51:52 2020 +0200

    restructure
---
 doc/thesis/design.tex | 43 +++++++++++++++++++++++--------------------
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 0d040bf..b02c783 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -321,27 +321,30 @@ return encrypted_recovery_document
 
 \subsection{Authenticity of recovery documents}
 
-In addition to the symmetric keys an EdDSA-based {\em account key} is used to 
identify the ``account'' of the user at each Anastasis server.  EdDSA public 
keys are always points
-on Curve25519 and represented using the standard 256-bit Ed25519
-compact format. The binary representation is converted to Crockford
-Base32 when transmitted inside JSON or as part of URLs in the RESTful
-API of Anastasis (see Section~\ref{sec:serverarch}).  EdDSA signatures
-are also provided in Crockford Base32-encoding and transmitted using
-the HTTP header \texttt{Anastasis-Account-Signature}.  Encrypted
-recovery documents are stored using the public account key as the
-identifier.
-
 \texttt{/policy/} requests are used to upload new encrypted recovery
-documents. For users to authorize \texttt{/policy} operations, we need an
-account key pair.  The account keys are derived from the {\em kdf id}
-(see Figure~\ref{fig:keys_anastasis}).  Hence, we cannot assure that
-the corresponding private account key is truly secret. Thus, policy
-operations must never be destructive: A strong adversary can derive
-the private key and access (and with the {\em kdf id} also decrypt)
-the user’s recovery document (but not the core secret!), and also
-upload a new version of the encrypted recovery document. However,
-because uploads are not destructive, even a strong adversary cannot
-delete an existing version and thus cannot break availability.
+documents. For users to authorize \texttt{/policy} operations, we need
+an account key pair.  Thus, in addition to the symmetric keys, an
+EdDSA-based {\em account key} is derived from the {\em kdf id} (see
+Figure~\ref{fig:keys_anastasis}) and used to identify the ``account''
+of the user at each Anastasis server.  EdDSA public keys are always
+points on Curve25519 and represented using the standard 256-bit
+Ed25519 compact format. The binary representation is converted to
+Crockford Base32 when transmitted inside JSON or as part of URLs in
+the RESTful API of Anastasis (see Section~\ref{sec:serverarch}).
+EdDSA signatures are also provided in Crockford Base32-encoding and
+transmitted using the HTTP header
+\texttt{Anastasis-Account-Signature}.  Encrypted recovery documents
+are stored using the public account key as the identifier.
+
+As the account keys are derived from the {\em kdf id} which strong
+adversaries might know, we cannot assure that the corresponding
+private account key is truly secret. Thus, policy operations must
+never be destructive: A strong adversary can derive the private key
+and access (and with the {\em kdf id} also decrypt) the user’s
+recovery document (but not the core secret!), and also upload a new
+version of the encrypted recovery document. However, because uploads
+are not destructive, even a strong adversary cannot delete an existing
+version and thus cannot break availability.
 
 For the generation of the private key we use the {\em kdf id} as the
 entropy source, hash it to derive a base secret which will then be

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