[taler-anastasis] branch master updated: restructure design vs implementation

[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 c2b0e52  restructure design vs implementation
c2b0e52 is described below

commit c2b0e5277a2590e3c6b7ed6119f346038f3d96e5
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sun Jun 7 13:46:35 2020 +0200

    restructure design vs implementation
---
 doc/thesis/design.tex | 65 +++++++++++++++++++++++++++++----------------------
 1 file changed, 37 insertions(+), 28 deletions(-)

diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 97ee756..a3869bc 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -19,6 +19,8 @@ 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.
 
+\subsection{Adversary model}
+
 The adversary model of Anastasis has two types of adversaries: {\em
   weak adversaries} which do not know the user’s identifier, and {\em
   strong adversaries} which somehow do know a user’s
@@ -33,6 +35,9 @@ Anastasis escrow providers would need to collude to break
 confidentiality. These policies also set the bar for the user to
 recover their core secret.
 
+
+\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 escrow
   methods}, which specify how the user should convince the Anastasis
@@ -62,25 +67,23 @@ approximate creation time, which may be exposed to an 
adversary which
 monitors the user’s network traffic or operates an escrow provider).
 
 
-
-
-\subsection{Cryptography}
+\subsection{Identity-derived encryption}
 
 When a user needs to interact with Anastasis, the system first derives
 some key material, but not the master secret, from the user’s
-identifier using different HKDFs. These HKDFs are salted using the
+identifier using different HKDFs.  These HKDFs are salted using the
 respective escrow provider’s server salt, which ensures that the
 accounts for the same user cannot be easily correlated across the
 various Anastasis servers.
 
-Each Anastasis server uses an EdDSA account key to identify the
-account of the user. The account private key is derived from the
-user’s identifier using a computationally expensive cryptographic hash
-function. Using an expensive hash algorithm is assumed to make it
-infeasible for a weak adversary to determine account keys by brute
-force (without knowing the user’s identifier). However, it is assumed
-that a strong adversary performing a targeted attack can compute the
-account key pair.
+At each Anastasis server, an EdDSA-based account key is used to
+identify the account of the user. The account private key is derived
+from the user’s identifier using Aargon2, a computationally expensive
+cryptographic hash function. Using an expensive hash algorithm is
+assumed to make it infeasible for a weak adversary to determine
+account keys by brute force (without knowing the user’s
+identifier). However, it is assumed that a strong adversary performing
+a targeted attack can compute the account key pair.
 
 The public account key is Crockford base32-encoded in the URI to
 identify the account, and used to sign requests. These signatures are
@@ -106,22 +109,23 @@ of policies.
 
 \subsection{Key Derivations}
 
-EdDSA and ECDHE public keys are always points on Curve25519 and
+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.
 
-To start, a user provides their private, unique and unforgettable
-identifier as a seed to identify their account. For example, this
-could be a social security number together with their full
-name. Specifics may depend on the cultural context, in this document
-we will simply refer to this information as the identifier.
+To start, a user provides their private (alas not really secret),
+unique and unforgettable identifier as a seed to identify their
+account. For example, this could be a social security number together
+with their full name. Specifics may depend on the cultural context, in
+this document we will simply refer to this information as the
+identifier.
 
 This identifier will be first hashed with Argon2, to provide a kdf\_id
-which will be used to derive other keys later. The Hash must also
-include the respective server\_salt. This also ensures that the
-kdf\_id is different on each server. The use of Argon2 and the
-respective server\_salt is intended to make it difficult to
+which will be used to derive other keys later. The hash must also be
+made over the respective provider's server\_salt. This ensures that
+the kdf\_id is different on each server. The use of Argon2 and the
+respective server\_salt are intended to make it difficult to
 brute-force kdf\_id values and help protect user’s privacy. Also this
 ensures that the kdf\_ids on every server differs. However, we do not
 assume that the identifier or the kdf\_id cannot be determined by an
@@ -130,19 +134,22 @@ likely to always be known to state actors and may likely 
also be
 available to other actors.
 
 \begin{lstlisting}
-user_identifier_create(identifier, server_salt, keysize)
+user_identifier_derive(identifier, server_salt, keysize)
 {
   kdf_id = Argon2(identifier, server_salt, keysize)
   return kdf_id
 }
 \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. \\
 
+
 \subsection{Verification}
 
 For users to authorize “policy” operations we need an EdDSA key
@@ -159,6 +166,7 @@ processed to fit the requirements for EdDSA private keys. 
From the
 private key we can then generate the corresponding public key. Here,
 “ver” is used as a salt for the HKDF to ensure that the result differs
 from other cases where we hash kdf\_id.
+
 \begin{lstlisting}
 eddsa_keys_create (kdf_id, salt, keysize)
 {
@@ -190,7 +198,8 @@ digest[31] &= 0xf8;
 
 \textbf{eddsa\_pub}: The generated EdDSA public key. \\
 
-\subsection{Encryption}
+
+\subsection{Symmetric encryption}
 
 For symmetric encryption of data, we use AES256-GCM. For this we need
 a symmetric key and an initialization vector (IV). To ensure that the
@@ -222,11 +231,9 @@ return iv,key
 
 \textbf{iv}: IV which will be used for AES-GCM \\
 
-\subsection{Key usage}
 
 The keys we have generated are then used to encrypt the \textbf{recovery 
document} and the \textbf{key\_share} of the user.
 
-\subsubsection{Encryption}
 
 Before every encryption a 32-byte nonce is generated. From this the
 symmetric key is computed as described above. We use AES256-GCM for
@@ -267,11 +274,13 @@ recovery_document_encrypt(kdf_id, recovery_document)
 \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.
 
+
 \subsubsection{Signatures}
 
 The EdDSA keys are used to sign the data sent from the client to the
-server. Everything the client sends to server is signed. The following
-algorithm is equivalent for Anastasis-Policy-Signature.
+server. Everything the client sends to server is signed. An equivalent
+algorithm is also used to generate the
+\texttt{Anastasis-Policy-Signature}.
 
 \begin{lstlisting}
 (anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)

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