[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.