gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-anastasis] branch master updated: spellchecker


From: gnunet
Subject: [taler-anastasis] branch master updated: spellchecker
Date: Sat, 06 Jun 2020 19:22:49 +0200

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 7b220c5  spellchecker
7b220c5 is described below

commit 7b220c5118970276389ef6f44e33a67b81922349
Author: Dominik Meister <dominiksamuel.meister@students.bfh.ch>
AuthorDate: Sat Jun 6 19:22:42 2020 +0200

    spellchecker
---
 doc/thesis/client_architecture.tex | 81 +++++++++++++++++++-------------------
 1 file changed, 40 insertions(+), 41 deletions(-)

diff --git a/doc/thesis/client_architecture.tex 
b/doc/thesis/client_architecture.tex
index f7ee262..6fe2ba4 100644
--- a/doc/thesis/client_architecture.tex
+++ b/doc/thesis/client_architecture.tex
@@ -11,17 +11,17 @@ Following is a list over the most important data structures 
in the crypto API.
 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 Implementation Cryptography
 \begin{lstlisting}
 struct kdf_id
-{ 
+{
   Hashcode; //512Bit
-} 
+}
 \end{lstlisting}
 
-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.
+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 private_key
-{ 
+{
   eddsa_private_key;
-} 
+}
 \end{lstlisting}
 
 The public key is used as the user identification on the different providers. 
It is generated from the private\_key.
@@ -36,44 +36,44 @@ The truth\_key is a randomly generated AES-256 GCM key. It 
is used to encrypt th
 \begin{lstlisting}
 struct truth_key
 {
-  key; //256 bit
+  key; //256-bit
 }
 \end{lstlisting}
 
-Anastasis needs different symetric keys to encrypt data. For example the 
recovery document. These symetric keys are all 256 bit large hashcodes. These 
symetric keys are generated through the key routine defined in Implementation 
Key usage.
+Anastasis needs different symmetric keys to encrypt data for example, the 
recovery document. These symmetric keys are all 256-bit large hashcodes. These 
symmetric keys are generated through the key routine defined in Implementation 
Key usage.
 \begin{lstlisting}
-struct symetric_key
+struct symmetric_key
 {
-  hashcode; //256 bit
+  hashcode; //256-bit
 }
 \end{lstlisting}
 
-Each policy has a seperate policy\_key. The key is used to encrypt the 
master\_key.
+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; //256 bit
+  hashcode; //256-bit
 }
 \end{lstlisting}
 
-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; //256 bit
+  hashcode; //256-bit
 }
 \end{lstlisting}
 
-Before every encryption a random 256 bit large nonce is generated. This gives 
the encrpytion algorithm a random factor.
+Before every encryption a random 256-bit large nonce is generated. This gives 
the encrpytion algorithm a random factor.
 \begin{lstlisting}
 struct nonce
 {
-  hashcode; //256 bit
+  hashcode; //256-bit
 }
 \end{lstlisting}
 
-To use AES-256 GCM an IV must be generated. It is generated with an HKDF over 
a salt the kdf\_id and a symetric 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
 {
@@ -91,25 +91,25 @@ struct aes_tag
 
 
 \subsubsection{Client API}
-Following is a list over the most important data structures in the client API. 
\\ 
+Following is a list over the most important data structures in the client API. 
\\
 The secret share data structure is used to upload a new recovery document.
 \begin{lstlisting}
 struct secret_share
 {
-  kdf_id;      
-  last_etag;   
-  policies;    
+  kdf_id;
+  last_etag;
+  policies;
   core_secret;
 }
 \end{lstlisting}
 \begin{itemize}
 \item kdf\_id: is used to compute the account public and private key. The hash 
is 512bit large.
-\item last\_etag: this hash is sent with the recovery document. The server 
will check the hash if the document on the server is the same. This prevents 
unneccessary uploads. The hash is 512 bit large.
+\item last\_etag: this hash is sent with the recovery document. The server 
will check the hash if the document on the server is the same. This prevents 
unnecessary uploads. The hash is 512-bit large.
 \item policies: is a list of all generated policies the user wants to combine 
into a recovery document.
 \item core\_secret: is the user provided core secret. This is just a binary 
blob so Anastasis does not have a restriction for the user secret. This could 
be a for example a private key or a password the user wants to backup.
 \end{itemize}
 
-The recovery information data structure holds a recovery document. It is 
downloaded within the recovery process and stored inside a recovery data 
structure. 
+The recovery information data structure holds a recovery document. It is 
downloaded within the recovery process and stored inside a recovery data 
structure.
 \begin{lstlisting}
 struct recovery_information
 {
@@ -123,14 +123,14 @@ struct recovery_information
 \item decryption\_policies: holds all available policies within the downloaded 
recovery document.
 \item challenges: holds all available authentication methods within the 
recovery document.
 \item version: the version of the downloaded recovery document is stored here.
-\item salt: this is the salt used for the generation of the policy keys. The 
salt is a 512 bit value.
+\item salt: this is the salt used for the generation of the policy keys. The 
salt is a 512-bit value.
 \end{itemize}
 
 
-The recovery data structure is generated at the start of a secret recovery. It 
contains all available policies and lists which challenges are solved. Through 
this 
-struct the client can check if a policy was solved completly.
+The recovery data structure is generated at the start of a secret recovery. It 
contains all available policies and lists which challenges are solved. Through 
this
+struct the client can check if a policy was solved completely.
 \begin{lstlisting}
-struct recovery 
+struct recovery
 {
   kdf_id;
   version;
@@ -144,8 +144,8 @@ struct recovery
 \item kdf\_id: is used to compute the account public and private key. The hash 
is 512bit large.
 \item version: hold the user desired version he wishes to download. This can 
be null then the client downloads the latest version.
 \item provider\_url: the client will download the recovery document from this 
provider url.
-\item salt: this is the salt of the provider specified in provider\_url. 
-\item solved\_challenges: this is a list of all solved challenges. This list 
is updated after each successfull authentication. This allows the client to 
check if a policy is solved.
+\item salt: this is the salt of the provider specified in provider\_url.
+\item solved\_challenges: this is a list of all solved challenges. This list 
is updated after each successful authentication. This allows the client to 
check if a policy is solved.
 \item recovery\_information: as previously mentioned this data structure holds 
the downloaded recover document to process within the recovery
 \end{itemize}
 
@@ -157,7 +157,7 @@ struct truth
   method;
   mime_type;
   encrypted_truth;
-  encrypted_key_share;  
+  encrypted_key_share;
 }
 \end{lstlisting}
 \begin{itemize}
@@ -165,7 +165,7 @@ struct truth
 \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.
-\item encrypted\_key\_share: this is the key\_share protected by this truth. 
It is encrypted with a key which was derived with the kdf\_id of the user. The 
server will later send this key\_share to the user upon successfull 
authentication.
+\item encrypted\_key\_share: this is the key\_share protected by this truth. 
It is encrypted with a key which was derived with the kdf\_id of the user. The 
server will later send this key\_share to the user upon successful 
authentication.
 \end{itemize}
 The policy data structure is used to create new policies to combine them into 
the recovery document. The policy data structure is only used for the secret 
share process.
 \begin{lstlisting}
@@ -177,8 +177,8 @@ struct policy
 }
 \end{lstlisting}
 \begin{itemize}
-\item truths: every policy has a set of truths which need to solved to recover 
the policy\_key
-\item policy\_key: the policy\_key is created through the combination of the 
differen key\_shares within each of the truth objects. It is later used to 
encrypt the master\_key.
+\item truths: every policy has a set of truths which need to be solved to 
recover the policy\_key
+\item policy\_key: the policy\_key is created through the combination of the 
different key\_shares within each of the truth objects. It is later used to 
encrypt the master\_key.
 \item salt: defines the salt used to create the policy\_key.
 \end{itemize}
 
@@ -188,11 +188,11 @@ struct decryption_policy
 {
   uuids;
   encrypted_master_key;
-  salt;  
+  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 coresponding challenge.
+\item uuids: is a list of uuids which need to be solved to recreate the policy 
key. Each uuid 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}
@@ -201,24 +201,23 @@ The challenge data structure is used for the several 
key\_share lookups.
 We named the process of authentication on the providers as challenges.
 It has slightly different variables as the truth data structure.
 \begin{lstlisting}
-struct challenge 
-{ 
+struct challenge
+{
   uuid;
   url;
   truth_key;
   method;
   key_share;
-  instructions; 
+  instructions;
 }
 \end{lstlisting}
 \begin{itemize}
 \item uuid: the identification of the truth on the server.
-\item url: defines the provider url on which the truth was stored.
+\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.
-\item key\_share: After each successfull authentication the key\_share which 
was sent by the server will be saved within this variable. It is later used to 
recreate a policy\_key.
-\item instructions: this contains a string with the instructions for the user. 
This could for example be: "What is your favorite color?" or "An SMS was sent 
to the number +41...... please provide the pin"
-\end{itemize}
+\item key\_share: After each successful authentication the key\_share which 
was sent by the server will be saved within this variable. It is later used to 
recreate a policy\_key.
+\item instructions: this contains a string with the instructions for the user. 
This could for example be:” What is your favourite colour?” or” An SMS was sent 
to the number +41...... please provide the pin”.
 \subsubsection{Service API}
 The service API is responsible for sending the requests to the REST API of the 
server. The client has implemented functions for every end point. For more 
details see REST API documentation in the appendix.
 

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]