[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-anastasis] branch master updated (ab88ece -> 1bd95fe)
From: |
gnunet |
Subject: |
[taler-anastasis] branch master updated (ab88ece -> 1bd95fe) |
Date: |
Sun, 07 Jun 2020 21:11:21 +0200 |
This is an automated email from the git hooks/post-receive script.
dennis-neufeld pushed a change to branch master
in repository anastasis.
from ab88ece fix table list
new 250540a some fixes
new 44b0340 _handle -> _handler
new 1bd95fe some fixes: \begin{description} etc
The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
doc/thesis/bibliothek.bib | 7 +++
doc/thesis/design.tex | 98 ++++++++++++++++--------------------
doc/thesis/images/system_design.png | Bin 52261 -> 57272 bytes
doc/thesis/implementation.tex | 7 ++-
doc/thesis/introduction.tex | 4 +-
doc/thesis/related_work.tex | 10 ++--
6 files changed, 60 insertions(+), 66 deletions(-)
diff --git a/doc/thesis/bibliothek.bib b/doc/thesis/bibliothek.bib
index 94e6d54..5cb334b 100644
--- a/doc/thesis/bibliothek.bib
+++ b/doc/thesis/bibliothek.bib
@@ -365,4 +365,11 @@
pages={20},
year={2002}
}
+@article{marlinspike2011,
+ title={SSL and the future of authenticity},
+ author={Marlinspike, Moxie},
+ journal={Black Hat USA},
+ volume={6},
+ year={2011}
+}
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index 75d46cc..659211e 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -141,14 +141,11 @@ user_identifier_derive(identifier, server_salt, keysize)
}
\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. \\
-
+\begin{description}
+ \item[identifier] {The secret defined from the user beforehand.}
+ \item[server\_salt]{The salt from the Server.}
+ \item[keysize]{The desired output size of the KDF, here 32 bytes.}
+\end{description}
\subsection{Verification}
@@ -177,26 +174,24 @@ return eddsa_priv, eddsa_pub
}
\end{lstlisting}
-\textbf{HKDF()}: The HKDF-function uses to phases: First we use HMAC-SHA512
for the extraction phase, then HMAC-SHA256 is used for expansion phase. \\
-
-\textbf{kdf\_id}: Hashed identifier. \\
-
-\textbf{salt}: used that different keys are generated, the salt here is "ver".
\\
-
-\textbf{key\_size}: Size of the output, here 32 bytes. \\
-
-\textbf{ver\_secret}: Derived key from the kdf\_id, serves as intermediate
step for the generation of the private key. \\
-
-\textbf{eddsa\_d\_to\_a()}: Function which converts the ver\_key to a valid
EdDSA private key. Specifically, assuming the value eddsa\_priv is in a 32-byte
array “digest”, the function clears and sets certain bits as follows: \\
+\begin{description}
+ \item[HKDF()] {The HKDF-function uses to phases: First we use
HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion
phase.}
+ \item[kdf\_id] {Hashed identifier.}
+ \item[salt] {Is used that different keys are generated, the salt here
is "ver".}
+ \item[key\_size] {Size of the output, here 32 bytes.}
+ \item[ver\_secret] {Derived key from the kdf\_id, serves as
intermediate step for the generation of the private key.}
+ \item[eddsa\_d\_to\_a()] {Function which converts the ver\_key to a
valid EdDSA private key. Specifically, assuming the value eddsa\_priv is in a
32-byte array “digest”, the function clears and sets certain bits as follows:}
+\end{description}
\begin{lstlisting}
digest[0] = (digest[0] & 0x7f) | 0x40;
digest[31] &= 0xf8;
\end{lstlisting}
-\textbf{eddsa\_priv}: The generated EdDSA private key. \\
-
-\textbf{eddsa\_pub}: The generated EdDSA public key. \\
+\begin{description}
+ \item[eddsa\_priv] {The generated EdDSA private key.}
+ \item[eddsa\_pub] {The generated EdDSA public key.}
+\end{description}
\subsection{Symmetric encryption}
@@ -217,20 +212,15 @@ return iv,key
}
\end{lstlisting}
-\textbf{HKDF()}: The HKDF-function uses to phases: First we use HMAC-SHA512
for the extraction phase, then HMAC-SHA256 is used for expansion phase. \\
-
-\textbf{kdf\_id}: Hashed identifier \\
-
-\textbf{keysize}: Size of the AES symmetric key, here 32 bytes \\
-
-\textbf{ivsize}: Size of the AES GCM IV, here 12 bytes \\
-
-\textbf{nonce}: 32-byte nonce, must never match “ver” (which it cannot as the
length is different). Of course, we must avoid key reuse. So, we must use
different nonces to get different keys and ivs (see below). \\
-
-\textbf{key}: Symmetric key which is later used to encrypt the documents with
AES256-GCM. \\
-
-\textbf{iv}: IV which will be used for AES-GCM \\
-
+\begin{description}
+ \item[HKDF()] {The HKDF-function uses to phases: First we use
HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion
phase.}
+ \item[kdf\_id] {Hashed identifier.}
+ \item[keysize] {Size of the AES symmetric key, here 32 bytes.}
+ \item[ivsize] {Size of the AES GCM IV, here 12 bytes.}
+ \item[nonce] {32-byte nonce, must never match “ver” (which it cannot as
the length is different). Of course, we must avoid key reuse. So, we must use
different nonces to get different keys and ivs (see below).}
+ \item[key] {Symmetric key which is later used to encrypt the documents
with AES256-GCM.}
+ \item[iv] {IV which will be used for AES-GCM.}
+\end{description}
The keys we have generated are then used to encrypt the \textbf{recovery
document} and the \textbf{key\_share} of the user.
@@ -265,14 +255,12 @@ recovery_document_encrypt(kdf_id, recovery_document)
\end{lstlisting}
-\textbf{encrypted\_recovery\_document}: The encrypted recovery document which
contains the escrow methods, policies and the encrypted core secret. \\
-
-\textbf{encrypted\_key\_share}: The encrypted key\_share which the escrow
provider must release upon successful authentication.\\
-
-\textbf{nonce}: Nonce which is used to generate keys and ivs which are used
for the encryption. The nonce must contain either eks or erd.
-
-\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.
+\begin{description}
+ \item[encrypted\_recovery\_document] {The encrypted recovery document
which contains the escrow 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.}
+\end{description}
\subsection{Signatures}
@@ -287,24 +275,24 @@ algorithm is also used to generate the
ver_res = eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub
\end{lstlisting}
-\textbf{anastasis-account-signature}: Signature over the SHA-512 hash of the
body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_UPLOAD (1400)
(see GNUnet EdDSA signature API for the use of purpose) \\
-
-\textbf{h\_body}: The hashed body. \\
+\begin{description}
+ \item[anastasis-account-signature] {Signature over the SHA-512 hash of
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_UPLOAD
(1400) (see GNUnet EdDSA signature API for the use of purpose).}
+ \item[h\_body] {The hashed body.}
+ \item[ver\_res] {A Boolean value. True: Signature verification passed,
False: Signature verification failed.}
+\end{description}
-\textbf{ver\_res}: A Boolean value. True: Signature verification passed,
False: Signature verification failed. \\
-\\
+\noindent
When requesting policy downloads, the client must also provide a signature:
\begin{lstlisting}
(anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
ver_res = eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)
\end{lstlisting}
-\textbf{anastasis-account-signature}: Signature over the SHA-512 hash of the
body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_DOWNLOAD
(1401) (see GNUnet EdDSA signature API for the use of purpose) \\
-
-\textbf{version}: The version requested as a 64-bit integer, for the “latest
version”. \\
-
-\textbf{ver\_res}: A Boolean value. True: Signature verification passed,
False: Signature verification failed. \\
-
+\begin{description}
+ \item[anastasis-account-signature] {Signature over the SHA-512 hash of
the body using the purpose code TALER\_SIGNATURE\_ANASTASIS\_POLICY\_DOWNLOAD
(1401) (see GNUnet EdDSA signature API for the use of purpose).}
+ \item[version] {The version requested as a 64-bit integer, for the
“latest version”.}
+ \item[ver\_res] {A Boolean value. True: Signature verification passed,
False: Signature verification failed.}
+\end{description}
\subsection{Availability considerations}
diff --git a/doc/thesis/images/system_design.png
b/doc/thesis/images/system_design.png
index 20d7de7..52ff118 100644
Binary files a/doc/thesis/images/system_design.png and
b/doc/thesis/images/system_design.png differ
diff --git a/doc/thesis/implementation.tex b/doc/thesis/implementation.tex
index 2fb65a5..15cc054 100644
--- a/doc/thesis/implementation.tex
+++ b/doc/thesis/implementation.tex
@@ -37,7 +37,6 @@ application. It shows a simplified flow of the application.
The
details of each component are explained later.
\begin{figure}[H]
- % FIXME: _handle => handler (!)
\centering
\includegraphics[scale=0.4]{images/system_design.png}
\caption{System design overview}
@@ -229,12 +228,12 @@ Below is an example transcript of an interaction with the
splitter:
$ anastasis-splitter --me=identity.json
anastasis-splitter> server add $URL1
version: 1.0
-annual fee: EUR:4.99,
+annual fee: 4.99 KUDOS,
available policy methods: sms
Server #1 available
anastasis-splitter> server add $URL2
version: 1.0
-annual fee: EUR:3.99,
+annual fee: 3.99 KUDOS,
available policy methods: sms, question
Server #2 available
anastasis-splitter> truth add server#1 sms +492452526
@@ -400,7 +399,7 @@ and Free Software.~\cite{libmicrohttpd}
To test our application, we used the GNU Taler testing library as our
foundation. This library allows you to create testing instances of
both the Anastasis application and the GNU Taler payment system. We
-implemented unit tests for every command in our application. A
+implemented unit tests for the crypto functions and the simple HTTP REST. A
simplified test flow would be the following:
\begin{enumerate}
diff --git a/doc/thesis/introduction.tex b/doc/thesis/introduction.tex
index f622500..8a224e1 100644
--- a/doc/thesis/introduction.tex
+++ b/doc/thesis/introduction.tex
@@ -10,7 +10,7 @@ owner of a key must have the possibility to recover a lost
key.
But how can one create a confidential backup of a key? It certainly
makes no sense to encrypt a key with a different password and then use
the result as a backup. After all, this merely shifts the problem from
-the original key to the password, which is bascially yet another key.
+the original key to the password, which is basically yet another key.
So simply encrypting the key is not helpful. But without encryption,
any copy of a key increases availability, but also the risk of the
key's confidentiality being compromised.
@@ -126,7 +126,7 @@ for citizens, for public offices and for
enterprises''~\cite{pepdoc}. It secures communication via email by
providing end-to-end encryption similar to PGP. A major difference is
that p\equiv p uses opportunistic encryption and so-called trustwords
-to etablish authenticity to avoid usability and privacy problems
+to establish authenticity to avoid usability and privacy problems
associated with the ``Web of trust''.
The impact of losing control over the private key is similar in both
diff --git a/doc/thesis/related_work.tex b/doc/thesis/related_work.tex
index f40d156..bc0dc89 100644
--- a/doc/thesis/related_work.tex
+++ b/doc/thesis/related_work.tex
@@ -96,7 +96,7 @@ $HMAC_{K}(M) = H(K \oplus opad,H(K \oplus ipad, M))$ with
"ipad" and
the hash function~\cite{BCK1996}. The blocksize of a modern hash
function like SHA-512 is 64 bytes.
-In Anastasis we use HMACs to achieve verifiability.
+% In Anastasis we use HMACs to achieve verifiability.
% CG: verifiability of WHAT?
% CG: I don't recall seeing HMACs in Anastasis, except for:
@@ -177,7 +177,8 @@ conceive users providing more than a handful of
authentication methods
For Anastasis, we thus decided to opt for more flexible approach that
allows complex policies for recovery authorization, instead of only
$k$-out-of-$n$. Each user of Anastasis is also able to decide which
-combinations of \textit{players} shall be permitted. % CG: players!?!?
+combinations of \textit{players}, which in case of Anastasis are the
+escrow providers, shall be permitted. % CG: players!?!?
\subsubsection{Verifiable Secret Sharing}
@@ -351,7 +352,7 @@ security measure to prevent malicious actions if the user's
email
account was compromised. Also the token should be a randomly generated
passphrase which has at least 8 characters.
-Another import part is that the email should not already contain the
+Another important part is that the email should not already contain the
requested information, so in the case of Anastasis the keyshare. This
is because the SMTP protocol used for email offers no hard security
assurances. In particular, the email is likely to be stored for a
@@ -484,8 +485,7 @@ three ways:
is used. As a result, we worry that it may be possible for an attacker
to successfully use social engineering via email (or other means)
to illegitimately trigger a recovery process.
- \item The MIDATA system also does not offer any trust agility.
- % FIXME: cite Moxie on trust agility!
+ \item The MIDATA system also does not offer any trust
agility~\cite{marlinspike2011}.
The user is forced to accept the 2-out-of-5 rule with trustees
provided by MIDATA.
\end{enumerate}
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [taler-anastasis] branch master updated (ab88ece -> 1bd95fe),
gnunet <=