[GNUnet-SVN] [taler-anastasis] branch master updated: crypto spec wip, english, fixes, comments

[gnunet]

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

grothoff pushed a commit to branch master
in repository anastasis.

The following commit(s) were added to refs/heads/master by this push:
     new ddee90e  crypto spec wip, english, fixes, comments
ddee90e is described below

commit ddee90ea750831e4a23f5b595f7827caec4cb934
Author: Christian Grothoff <address@hidden>
AuthorDate: Thu Sep 26 16:52:54 2019 +0200

    crypto spec wip, english, fixes, comments
---
 src/api/crypto-anastasis.rst | 103 ++++++++++++++++++++++++++-----------------
 1 file changed, 63 insertions(+), 40 deletions(-)

diff --git a/src/api/crypto-anastasis.rst b/src/api/crypto-anastasis.rst
index 1bb62ce..9bcda4a 100644
--- a/src/api/crypto-anastasis.rst
+++ b/src/api/crypto-anastasis.rst
@@ -26,31 +26,64 @@ This document specifies the Crypto used in Anastasis.
 -------------------
 1. Key derivations
 -------------------
-EdDSA and ECDHE public keys always point on Curve25519
-and represented  using the standard 256 bits Ed25519 compact format,
-converted to Crockford Base32.
 
-At the begin the user choses a secret e.g. AHV Number with full name we define 
it here as user_identifier. 
-This user_identifier will be Hashed first with SCRYPT. From this Hash the Key 
Pairs(ECDHE, EdDSA) will be derived.
+EdDSA and ECDHE 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.
+
+To start, a user provides their private, unique and unforgettable
+**identifier** as a seed to identify their account.  For example, this could
+be a social security number together with their full name.  Specifics may
+depend on the cultural context, in this document we will simply refer to this
+information as the **user_identifier**.
+
+This user_identifier will be first hashed with SCrypt, to provide a **kdf_id**
+which will be used to derive other keys later.  The use of SCrypt is intended
+to make it difficult to brute-force **kdf_id** values and help protect user's
+privacy. However, we do not assume that the **user_identifier** or the
+**kdf_id** cannot be determined by an adversary performing a targeted attack,
+as a user's **user_identifier** is likely to always be known to state actors
+and may likely also be available to other actors.
+
+The kdf_id derivation also includes the Anastasis' server's **server_salt**,
+again to make it difficult to brute-force values as the computation would have
+to be done per Anastasis server.
+
+FIXME: What do we do if a user backs up their data using 3 different
+Anastasis operators with 3 different salts? We must check that the
+kdf_id can differ between servers, and maybe then clarify that it is
+kdf_id^S (^S = per server), instead of one value for all servers!
+NOTE that api-anastasis in the introduction already explains that the
+server_salt should NOT be used to derive the **kdf_id**. So this is
+likely wrong.
 
-.. code-block:: 
+
+.. code-block::
 
     kdf_id := SCrypt( user_identifier, server_salt, keysize )
 
 **user_identifier**: The secret defined from the user beforehand.
 
-**server_salt**: The Salt from the Server
+**server_salt**: The salt from the Server
 
-**keysize**: The output Size of the KDF, here 32Byte.
+**keysize**: The desired output size of the KDF, here 32 bytes.
 
 
 1.1 Verification
 ^^^^^^^^^^^^^^^^
-For the verficiation of the Data we need a EdDSA Key Pair. For the
-generation of the Private Key we use the kdf_id and derive another
-key from this. This Key will then be proccessed to fit for EdDSA 
-private Key. With this private Key we can then generate a matching
-Public Key.
+
+For users to authorize **policy** operations we need an EdDSA key pair.  As we
+cannot assure that the corresponding private key is truly secret, such policy
+operations must never be destructive: Should an adversary learn the private
+key, they could access (and with the kdf_id decrypt) the user's policy (but
+not the core secret), or upload a new version of the policy (but not delete an
+existing version).
+
+For the generation of the private key we use the kdf_id as the entropy source,
+hash it to derive a base secret which will then be processed to fit the
+requirements for EdDSA private keys.  From the private key we can then
+generate the corresponding public key.
 
 .. code-block::
 
@@ -60,28 +93,30 @@ Public Key.
 
 **HKDF()**: The HKDF-function uses to phases: First we use HMAC-SHA512 for the 
extraction phase, then HMAC-SHA256 is used for expansion phase.
 
-**kdf_id**: Hashed user secret
+**kdf_id**: Hashed user_identifier.
 
-**salt_ver**: Salt for the derivation of the verficiation Keys
+**salt_ver**: Salt for the derivation of the verficiation keys (FIXME: specify 
precise value used).  FIXME: isn't this supposed to be the server_salt?
 
-**key_size**: Size of the output, here 32Byte
+**key_size**: Size of the output, here 32 bytes.
 
-**ver_secret**: Derived Key from the kdf_id, serves as intermediate Step for 
the generation of the private Key
+**ver_secret**: Derived key from the kdf_id, serves as intermediate step for 
the generation of the private key
 
-**eddsa_d_to_a()**: Function which converts the ver_key to a valid 
-EdDSA private Key (modulo p etc..)
+**eddsa_d_to_a()**: Function which converts the ver_key to a valid EdDSA 
private key.
 
-**eddsa_priv**: The generated EdDSA private Key
+**eddsa_priv**: The generated EdDSA private key.
 
-**eddsa_pub**: The generated EdDSA public Key
+**eddsa_pub**: The generated EdDSA public key.
 
 
 1.2 Encryption
-^^^^^^^^^^^^^^^^
-For the encryption of our data we use AES256-GCM. For this we need
-a symetric Key and IV. To derive such a symetric Key we use ECDHE.
-The ECDHE private Key is another key derivation from our kdf_id.
-The public Key is an ephemeral ECDHE Key which is always generated
+^^^^^^^^^^^^^^
+
+For symmetric encryption of data we use AES256-GCM. For this we need a
+symmetric key and an initialization vector (IV).
+
+To derive such a symmetric key
+we use ECDHE.  The ECDHE private key is another key derivation from our
+kdf_id.  The public Key is an ephemeral ECDHE Key which is always generated
 before every encryption.
 
 .. code-block::
@@ -91,7 +126,7 @@ before every encryption.
     ecdhe_pub := get_ecdhe_pub(ecdhe_priv)
     sym_key := ecdhe(ecdhe_priv, ecdhe_pub)
     enc_key:= HKDF(sym_key, salt_enc, keysize)
-    
+
 **HKDF()**: The HKDF-function uses to phases: First we use HMAC-SHA512 for the 
extraction phase, then HMAC-SHA256 is used for expansion phase.
 
 **kdf_id**: Hashed user secret
@@ -117,21 +152,9 @@ The Keys we have generated, are now used to encrypt the 
recovery_document and th
 ^^^^^^^^^^^^^^^^
 Before every encryption an ephemeral ECDHE public key is generated.
 From this the symetric Key is computed as described above.
-We use AES256-GCM for the encryption of the recovery_document and 
+We use AES256-GCM for the encryption of the recovery_document and
 key_share.
 
 2.2 Signatures
 ^^^^^^^^^^^^^^^^
 The EdDSA Keys are used to sign the data sent from the client to the server. 
Everything the client sends to server is signed.
-
-
-
-
-
-
-
-
-
-
-
-

-- 
To stop receiving notification emails like this one, please contact
address@hidden.