[taler-anastasis] branch master updated (182ca5e -> 71de3c1)

[gnunet]

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

dennis-neufeld pushed a change to branch master
in repository anastasis.

    from 182ca5e  simplify
     new 05faf18  H to Figure
     new 2976e65  Merge branch 'master' of ssh://git.taler.net/anastasis
     new 6813baf  combined sections of key derivations...
     new 71de3c1  Merge branch 'master' of ssh://git.taler.net/anastasis

The 4 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 |   6 ++
 doc/thesis/design.tex     | 150 ++++++++++++++++++++++------------------------
 2 files changed, 77 insertions(+), 79 deletions(-)

diff --git a/doc/thesis/bibliothek.bib b/doc/thesis/bibliothek.bib
index 5cb334b..fc202dc 100644
--- a/doc/thesis/bibliothek.bib
+++ b/doc/thesis/bibliothek.bib
@@ -372,4 +372,10 @@
   volume={6},
   year={2011}
 }
+@article{jerome2015,
+  title={AHV-Nummer als einheitlicher, organisations{\"u}bergreifender 
Personenidentifikator},
+  author={J{\'e}r{\^o}me, Brugger and Angelina, BFH Dungga and Esther, BFH 
Hefti and ZH, Kt},
+  year={2015},
+  organization={BFH}
+}
 
diff --git a/doc/thesis/design.tex b/doc/thesis/design.tex
index d041867..3e3f6aa 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -227,7 +227,7 @@ the computation of the {\em kdf id}. The inputs are:
        \item[keysize]{The desired output size of the KDF, here 32 bytes.}
 \end{description}
 
-\begin{figure}
+\begin{figure}[H]
 \begin{lstlisting}
 user_identifier_derive(attributes, server_salt, keysize)
 {
@@ -249,11 +249,79 @@ user_identifier_derive(attributes, server_salt, keysize)
 \label{fig:argon2}
 \end{figure}
 
+Anastasis derives symmetric key material --- but not the master secret --- 
from the {\em kdf id} using different HKDFs~\cite{krawczyk2010}.
+
+When confidential data --- such as the recovery document or the truth
+--- is uploaded to an Anastasis server, the respective payload is
+encrypted using AES-GCM with the respective symmetric key and
+initialization vector derived key material as shown 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, so both for encrypted authentication data
+(\texttt{/truth} uploads) and encrypted recovery documents
+(\texttt{/policy} uploads).
+
+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 for different types of operations (“erd” and
+“eks” respectively):
+
+\begin{lstlisting}
+encryption_key_create(kdf_id, salt, nonce)
+{
+iv, key = HKDF (kdf_id, nonce, salt, keysize + ivsize)
+return iv,key
+}
+\end{lstlisting}
+
+\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}
+
+
+\begin{lstlisting}
+encrypt(kdf_id, data, salt)
+{
+nonce = generate_random_bytes(32)
+iv, key = encryption_key_create(kdf_id, salt, nonce)
+encrypted_data, aes_gcm_tag =  AES256_GCM(data, iv, key)
+encrypted_data = nonce + aes_gcm_tag + encrypted_data
+return encrypted_data
+}
+
+key_share_encrypt(kdf_id, key_share)
+{
+encrypted_key_share = encrypt(kdf_id, key_share, "eks")
+return encrypted_key_share
+}
+
+recovery_document_encrypt(kdf_id, recovery_document)
+{
+encrypted_recovery_document =
+encrypt(kdf_id, recovery_document, "erd")
+return encrypted_recovery_document
+}
+
+\end{lstlisting}
+
+\begin{description}
+       \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 32 Bytes are the nonce and 
the next 12 Bytes are the aes\_gcm\_tag.}
+\end{description}
+
 
 \subsection{Authenticity of recovery documents}
 
-At each Anastasis server, an EdDSA-based {\em account key} is used to
-identify the ``account'' of the user.  EdDSA public keys are always points
+In addition to the symmetric keys, at each Anastasis server, an EdDSA-based 
{\em account key} is used to identify the ``account'' of the user.  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 in the RESTful
@@ -365,82 +433,6 @@ provider during recovery.  The signature process for truth 
is
 analogous to that for accounts.
 
 
-\subsection{Symmetric key derivations}
-
-In addition to the account private key, Anastasis derives symmetric
-key material --- but not the master secret --- from the {\em kdf id}
-using different HKDFs~\cite{krawczyk2010}.
-
-When confidential data --- such as the recovery document or the truth
---- is uploaded to an Anastasis server, the respective payload is
-encrypted using AES-GCM with the respective symmetric key and
-initialization vector derived key material as shown 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, so both for encrypted authentication data
-(\texttt{/truth} uploads) and encrypted recovery documents
-(\texttt{/policy} uploads).
-
-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 for different types of operations (“erd” and
-“eks” respectively):
-
-\begin{lstlisting}
-encryption_key_create(kdf_id, salt, nonce)
-{
-  iv, key = HKDF (kdf_id, nonce, salt, keysize + ivsize)
-  return iv,key
-}
-\end{lstlisting}
-
-\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}
-
-
-\begin{lstlisting}
-encrypt(kdf_id, data, salt)
-{
-  nonce = generate_random_bytes(32)
-  iv, key = encryption_key_create(kdf_id, salt, nonce)
-  encrypted_data, aes_gcm_tag =  AES256_GCM(data, iv, key)
-  encrypted_data = nonce + aes_gcm_tag + encrypted_data
-  return encrypted_data
-}
-
-key_share_encrypt(kdf_id, key_share)
-{
-  encrypted_key_share = encrypt(kdf_id, key_share, "eks")
-  return encrypted_key_share
-}
-
-recovery_document_encrypt(kdf_id, recovery_document)
-{
-  encrypted_recovery_document =
-    encrypt(kdf_id, recovery_document, "erd")
-  return encrypted_recovery_document
-}
-
-\end{lstlisting}
-
-\begin{description}
-       \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 32 Bytes are the nonce and 
the next 12 Bytes are the aes\_gcm\_tag.}
-\end{description}
-
-
-
-
 \subsection{Availability considerations}
 
 Anastasis considers two main threats against availability. First, the

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