[taler-anastasis] 03/04: combined sections of key derivations...

[gnunet]

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

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

commit 6813bafb0bfe8d403b66d62e9b5361cd956141e5
Author: Dennis Neufeld <dennis.neufeld@students.bfh.ch>
AuthorDate: Thu Jun 11 10:46:57 2020 +0000

    combined sections of key derivations...
---
 doc/thesis/bibliothek.bib |   6 ++
 doc/thesis/design.tex     | 148 ++++++++++++++++++++++------------------------
 2 files changed, 76 insertions(+), 78 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 1e58935..3e3f6aa 100644
--- a/doc/thesis/design.tex
+++ b/doc/thesis/design.tex
@@ -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.