[taler-anastasis] branch master updated: delete uuid

[gnunet]

This is an automated email from the git hooks/post-receive script.

ds-meister pushed a commit to branch master
in repository anastasis.

The following commit(s) were added to refs/heads/master by this push:
     new a49dea1  delete uuid
a49dea1 is described below

commit a49dea1fa3fea688f1434fe3cd8d1f70d217ab05
Author: Dominik Meister <dominiksamuel.meister@students.bfh.ch>
AuthorDate: Thu Jun 11 12:05:15 2020 +0200

    delete uuid
---
 doc/thesis/client_architecture.tex | 84 +++++++++++++-------------------------
 doc/thesis/implementation.tex      |  2 +-
 2 files changed, 30 insertions(+), 56 deletions(-)

diff --git a/doc/thesis/client_architecture.tex 
b/doc/thesis/client_architecture.tex
index d6894eb..898a870 100644
--- a/doc/thesis/client_architecture.tex
+++ b/doc/thesis/client_architecture.tex
@@ -24,9 +24,10 @@ The most important data structures in the crypto API are the 
following:
 
 \begin{itemize}
   \item
-The kdf id is a hash code which was generated with Argon2. The
-entropy source is the user's unforgettable secret. The kdf id is used
+The kdf\_id is a hash code which was generated with Argon2. The
+entropy source is the user's unforgettable secret. The kdf\_id is used
 to create various key's, for more details see Chapter~\ref{chap:design}.
+
 \begin{lstlisting}
 struct kdf_id
 {
@@ -35,57 +36,29 @@ struct kdf_id
 \end{lstlisting}
 
 \item
-The account private key is used to sign the encrypted recovery document. It is 
a 256-bit eddsa private key. It is generated with the kdf id as entropy source.
-\begin{lstlisting}
-struct account_private_key
-{
-  eddsa_private_key;
-}
-\end{lstlisting}
-
-\item
-The account public key is used as the user identification on the different 
providers in case of uploaded encrypted recovery documents and is also used for 
verification of the signature of the encrypted recovery document. It is 
generated from the account private key.
-\begin{lstlisting}
-struct account_public_key
-{
-  eddsa_public_key;
-}
-\end{lstlisting}
-
-\item
-The truth seed is a randomly generated nonce with a size of 32 Bytes. It is 
used to derive a truth private key
-and is stored within an encrypted recovery document.
+The private key is used to sign the data and check the signature later. It is 
a 256-bit eddsa private key. It is generated with the kdf\_id as entropy source.
 \begin{lstlisting}
-struct truth_seed
-{
-  nonce; //256Bit
-}
-\end{lstlisting}
-
-\item
-The truth private key is used to sign the encrypted key share and the 
encrypted authentication data. It is a 256-bit eddsa private key. It is 
generated with the truth seed as entropy source.
-\begin{lstlisting}
-struct truth_private_key
+struct private_key
 {
   eddsa_private_key;
 }
 \end{lstlisting}
 
 \item
-The truth public key is used as the user identification on the different 
providers in case of uploaded truths. It is generated from the truth private 
key.
+The public key is used as the user identification on the different providers. 
It is generated from the private\_key.
 \begin{lstlisting}
-struct truth_public_key
+struct public_key
 {
   eddsa_public_key;
 }
 \end{lstlisting}
 
 \item
-The truth key is a randomly generated AES-256 GCM key. It is used to encrypt 
the user specifiy data in the truth object.
+The truth\_key is a randomly generated AES-256 GCM key. It is used to encrypt 
the user specifiy data in the truth object.
 \begin{lstlisting}
 struct truth_key
 {
-  key; //256Bit
+  key; //256-bit
 }
 \end{lstlisting}
 
@@ -94,26 +67,26 @@ Anastasis needs different symmetric keys to encrypt data 
for example, the recove
 \begin{lstlisting}
 struct symmetric_key
 {
-  hashcode; //256Bit
+  hashcode; //256-bit
 }
 \end{lstlisting}
 
 \item
-Each policy has a separate policy\_key. The key is used to encrypt the master 
key.
-The policy key is also a AES-256 GCM key. It is generated through the 
combination of a set of key shares.
+Each policy has a separate policy\_key. The key is used to encrypt the 
master\_key.
+The policy\_key is also a AES-256 GCM key. It is generated through the 
combination of a set of key\_shares.
 \begin{lstlisting}
 struct policy_key
 {
-  hashcode; //256Bit
+  hashcode; //256-bit
 }
 \end{lstlisting}
 
 \item
-Every truth object contains a key share. A key share is a 256-bit random 
generated bit sequence.
+Every truth object contains a key\_share. A key\_share is a 256-bit random 
generated bit sequence.
 \begin{lstlisting}
 struct key_share
 {
-  hashcode; //256Bit
+  hashcode; //256-bit
 }
 \end{lstlisting}
 
@@ -122,25 +95,25 @@ Before every encryption a random 256-bit large nonce is 
generated. This gives th
 \begin{lstlisting}
 struct nonce
 {
-  hashcode; //256Bit
+  hashcode; //256-bit
 }
 \end{lstlisting}
 
 \item
-To use AES-256 GCM an IV must be generated. It is generated with an HKDF over 
a salt the kdf id and a symmetric key.
+To use AES-256 GCM an IV must be generated. It is generated with an HKDF over 
a salt the kdf\_id and a symmetric key.
 \begin{lstlisting}
 struct iv
 {
-  hashcode; //128Bit
+  hashcode; //128 bit
 }
 \end{lstlisting}
 
 \item
-The aes tag is generated after each encryption, it is later used to check the 
integrity of the data.
+The aes\_tag is generated after each encryption, it is later used to check the 
integrity of the data.
 \begin{lstlisting}
 struct aes_tag
 {
-  hashcode; //128Bit
+  hashcode; //128 bit
 }
 \end{lstlisting}
 \end{itemize}
@@ -155,7 +128,7 @@ basic data structures.
 The most important data structures in the client API are the following:
 
 \begin{itemize}
- \item
+  \item
 The secret share data structure is used to upload a new recovery document.
 \begin{lstlisting}
 struct secret_share
@@ -215,11 +188,11 @@ struct recovery
 \end{itemize}
 
 \item
-A truth data structure is used to upload a new authentication method to a 
provider. It is identified by a UUID which the user creates. The truth data 
structure is only used for the secret share process and not for the recovery.
+A truth data structure is used to upload a new authentication method to a 
provider. It is identified by the TRUTH\_PUB which the user creates through a 
HKDF over the truth\_seed. The truth data structure is only used for the secret 
share process and not for the recovery.
 \begin{lstlisting}
 struct truth
 {
-  uuid;
+  truth_seed;
   method;
   mime_type;
   encrypted_truth;
@@ -227,7 +200,8 @@ struct truth
 }
 \end{lstlisting}
 \begin{itemize}
-\item uuid: the uuid is the identification of the truth object. The truth 
objects are not linked to the user. A list of these uuids are stored inside the 
recovery document, with this the user data is more anonymous.
+\item truth\_seed: the truth\_seed is the identification of the truth object.
+It is used as entropy source to generate the TRUTH\_PUB, which later 
identificates the truth object. The truth objects are not linked to the user. A 
list of these truth\_seeds are stored inside the recovery document, with this 
the user data is more anonymous.
 \item method: this defines which method the user chose to configure, for 
example SMS, email, secure question.
 \item mime\_type: this defines in which format the truth was safed, for 
example jpeg, png, txt, json.
 \item encrypted\_truth: the encrypted truth holds the authentication specific 
data. It holds for example the hashed answer and the question. It is encrypted 
with the specific truth\_key which is stored inside the recovery\_document.
@@ -255,13 +229,13 @@ The decryption\_policy data structure is used in the 
recovery process. It has sl
 \begin{lstlisting}
 struct decryption_policy
 {
-  uuids;
+  truth_seeds;
   encrypted_master_key;
   salt;
 }
 \end{lstlisting}
 \begin{itemize}
-\item uuids: is a list of uuids which need to be solved to recreate the policy 
key. Each uuid has a corresponding challenge.
+\item truth\_seeds: is a list of truth\_seeds which need to be solved to 
recreate the policy key. Each truth\_seed has a corresponding challenge.
 \item encrypted\_master\_key: holds an encrypted version of the master\_key 
which was used to encrypt the core secret. In every policy lies the same 
master\_key which was encrypted by the specific policy\_key.
 \item salt: defines the salt which was used to create this policy\_key.
 \end{itemize}
@@ -273,7 +247,7 @@ It has slightly different variables as the truth data 
structure.
 \begin{lstlisting}
 struct challenge
 {
-  uuid;
+  truth_seed;
   url;
   truth_key;
   method;
@@ -282,7 +256,7 @@ struct challenge
 }
 \end{lstlisting}
 \begin{itemize}
-\item uuid: the identification of the truth on the server.
+\item truth\_seed: Entropy source to generate the TRUTH\_PUB, which identifies 
the challenge on the server.
 \item url: defines the provider URL on which the truth was stored.
 \item truth\_key: this key is sent to the server within the authentication 
procedure. The server can decrypt the truth with this key to start the 
authentication.
 \item method: defines the method of this challenge, for example email, SMS, 
secure question.
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index c7563ec..d5c4a0d 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -125,7 +125,7 @@ process.
   recover their secret.
 \item After the user has generated the policies the client will
   generate a recovery document. The recovery document contains a list
-  of all UUID's used, a list of the policies and the encrypted core
+  of all truth\_seed's used, a list of the policies and the encrypted core
   secret of the user. The client will now send a encrypted recovery
   document to each provider used in the recovery document (POST
   /policy/\$ACCOUNT\_PUB). Through this, the recovery document is

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