[taler-anastasis] branch master updated: major fixme

[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 2a4bdb6  major fixme
2a4bdb6 is described below

commit 2a4bdb61eb4c45f6fbba7e2a6331e0744188b97e
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Jun 10 23:11:22 2020 +0200

    major fixme
---
 doc/thesis/design.tex              | 78 +++++++++++++++++++++++++-------------
 doc/thesis/server_architecture.tex |  2 +-
 2 files changed, 53 insertions(+), 27 deletions(-)

diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index b49357c..513104d 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -38,12 +38,12 @@ The figure~\ref{fig:keys_anastasis} gives an overview of 
the keys used in Anasta
        \label{fig:keys_anastasis}
 \end{figure}
 
-\noindent In the following the keys shown in the 
figure~\ref{fig:keys_anastasis} on
+\noindent In the following the keys shown in the 
Figure~\ref{fig:keys_anastasis} on
 page~\pageref{fig:keys_anastasis} are explained:
 
 \begin{description}
        \item[kdf id] {The {\em kdf id} is derived from the user attributes and 
a
-       randomly generated server salt provided by the escrow provider using 
Argon2. It is used to derive
+       randomly generated public and constant salt value provided by the 
escrow provider using Argon2. It is used to derive
        the {\em private account key}, the {\em symmetric key 1} and the {\em 
symmetric key 2}.}
        \item[private account key] {The {\em private account key} is used to 
sign the {\em encrypted
        recovery document}. It is derived from the {\em identity key} using 
{\em HKDF-1}}.
@@ -57,8 +57,9 @@ page~\pageref{fig:keys_anastasis} are explained:
        {\em HKDF-3}. It is used to encrypt and decrypt the different {\em 
encrypted key shares} which
        are stored by the escrow providers.}
        \item[truth key] {The {\em truth key} is randomly generated for each 
{\em encrypted authentication data}
-       and is stored within the {\em encrypted recovery document}. It must be 
provided by the user to let the
-       server decrypt the {\em encrypted authentication data} for 
authentication purposes.}
+         and is stored within the {\em encrypted recovery document}. It may 
later be disclosed by the user to
+          the escrow provider to let it decrypt the {\em encrypted 
authentication data} which allows the provider
+          to then run the recovery authorization process.}
        \item[master key] {The {\em master key} is randomly generated and is 
used to encrypt and decrypt the
        {\em encrypted core secret} which is stored within an {\em encrypted 
recovery document}. The {\em encrypted master key} also is stored within the 
{\em encrypted recovery document}.}
        \item[policy key] {The {\em policy keys} are used for encryption and 
decryption of the {\em encrypted master key}. A {\em policy key} is constructed 
by hashing a specific combination of {\em key shares} specified by the
@@ -72,13 +73,16 @@ 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
 identifier. Against weak adversaries, the system guarantees full
-confidentiality, except for the information disclosed to the providers
-when authorizing key recovery. Weak adversaries cannot break
+confidentiality, except for a provider-specific public account key
+which links requests from the same user, and the data necessary for
+authentication. The latter is only disclosed to the providers when the
+user requests key recovery. Weak adversaries cannot break
 confidentiality even if all escrow providers are part of a conspiracy
 of weak adversaries.  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
+of the core secret still requires that a sufficient subset of the
+Anastasis escrow providers must have colluded with the strong
+adversary. 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.
 
@@ -127,9 +131,9 @@ 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
+assumed to make it harder for a weak adversary to determine
+user attributes by brute force guessing.
+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
@@ -138,28 +142,35 @@ also provided in base32-encoding and transmitted using 
the HTTP header
 \texttt{Anastasis-Account-Signature}.
 
 When confidential data is uploaded to an Anastasis server, the
-respective payload is encrypted using AES-GCM with a symmetric key and
-initialization vector derived from the identifier and a high-entropy
+respective payload is encrypted using AES-GCM with the respective
+symmetric key and initialization vector derived as show in
+Figure~\ref{fig:keys_anastasis} and a high-entropy
 nonce. The nonce and the GCM tag are prepended to the ciphertext
 before being uploaded to the Anastasis server. This is done whenever
-confidential data is stored with the server.
+confidential data is stored with the server, so both for
+encrypted authentication data and encrypted recovery documents.
 
 The core secret of the user is (AES) encrypted using a symmetric
-master key. Recovering this master key requires the user to satisfy a
+master key. The result becomes part of the encrypted recovery
+document, which is cryptographically signed and thus further
+integrity protections for the core secret are unnecessary.
+Recovering the master key requires the user to satisfy a
 policy. Policies specify a set of escrow methods, each of which leads
 the user to a key share. Combining those key shares (by hashing)
 allows the user to obtain a policy key, which can be used to decrypt
-the master key. There can be many policies, satisfying any of these
+the master key.
+There can be many policies, satisfying any of these
 will allow the user to recover the master key. A recovery document
 contains the encrypted core secret, a set of escrow methods and a set
-of policies.
+of policies, including one encryption of the master key per policy.
 
 \subsection{Key derivations}
 
 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.
+transmitted inside JSON or as part of URLs in the RESTful API of
+Anastasis (see Section~\ref{sec:serverarch}).
 
 To start, a user provides their private (alas not really secret),
 unique and unforgettable identifier as a seed to identify their
@@ -208,8 +219,8 @@ For the generation of the private key we use the kdf\_id as 
the
 entropy source, hash it to derive a base secret which will then be
 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.
+the string “ver” is used for the salt value 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)
@@ -247,9 +258,10 @@ 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
 symmetric key changes for each encryption operation, we compute the
 key material using an HKDF over a nonce and the kdf\_id. Additionally,
-a salt is added so the different encryption keys differ
-fundamentally. For example for the recovery document key the salt
-"erd" is added.
+a salt is added so the encryption keys differ
+fundamentally for different types of operations.
+For example, for the recovery document key the string "erd" is used
+for the salt.
 
 \begin{lstlisting}
 encryption_key_create(kdf_id, salt, nonce)
@@ -271,10 +283,20 @@ encryption_key_create(kdf_id, salt, nonce)
 
 The keys we have generated are then used to encrypt the \textbf{recovery 
document} and the \textbf{key\_share} of the user.
 
+% FIXME: key_share??? I thought the truth!
+
 
 Before every encryption a 32-byte nonce is generated. From this the
 symmetric key is computed as described above. We use AES256-GCM for
-the encryption of the recovery document and the key\_share. To ensure
+the encryption of the recovery document and the key\_share.
+% Why the key share??? That we SHOULD AES-encrypt and then EdDSA-sign
+% so that we can check that the server returned the right truth,
+% but for AES-GCM I'd expect us to use that for the encryption of the
+% truth (and the AES-k2-encrypted key share).
+%
+% FIXME: we should discuss how to protect against Anastasis providers
+% that return a bogus EKS.
+To ensure
 that the key derivation for the encryption of the recovery document
 differs fundamentally from that of an individual key share, we use
 different salts (“erd” and “eks” respectively).
@@ -308,7 +330,7 @@ recovery_document_encrypt(kdf_id, recovery_document)
        \item[encrypted\_recovery\_document] {The encrypted recovery document 
which contains the authentication methods, policies and the encrypted core 
secret.}
        \item[encrypted\_key\_share] {The encrypted key\_share which the escrow 
provider must release upon successful authentication.}
        \item[nonce] {Nonce which is used to generate keys and ivs which are 
used for the encryption. The nonce must contain either eks or erd.}
-       \item[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.}
+       \item[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 32 Bytes are the nonce and 
the next 12 Bytes are the aes\_gcm\_tag.}
 \end{description}
 
 
@@ -319,6 +341,10 @@ server. Everything the client sends to server is signed. 
An equivalent
 algorithm is also used to generate the
 \texttt{Anastasis-Policy-Signature}.
 
+% FIXME: "everything"? I don't think we can sign the encrypted truth
+% with the eddsa_priv, as that would link the truth to the ERD.
+% We need ANOTHER acocunt key here, one per truth + provider?
+
 \begin{lstlisting}
 (anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
 ver_res =
diff --git a/doc/thesis/server_architecture.tex 
b/doc/thesis/server_architecture.tex
index dc8996e..21e8c88 100644
--- a/doc/thesis/server_architecture.tex
+++ b/doc/thesis/server_architecture.tex
@@ -1,4 +1,4 @@
-\subsection{Server architecture}
+\subsection{Server architecture} \label{sec:serverarch}
 
 The Anastasis server architecture consists of two components. A web
 server with a REST API and a PostgreSQL database. The structure of

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