[GNUnet-SVN] [taler-docs] branch master updated: language fixes

[gnunet]

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

grothoff pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 54144bd  language fixes
54144bd is described below

commit 54144bd38929eaf0678df2998ea00dca227df248
Author: Christian Grothoff <address@hidden>
AuthorDate: Tue Oct 8 15:39:29 2019 +0200

    language fixes
---
 anastasis.rst | 88 +++++++++++++++++++++++++++++++----------------------------
 1 file changed, 47 insertions(+), 41 deletions(-)

diff --git a/anastasis.rst b/anastasis.rst
index 409318f..3144c31 100644
--- a/anastasis.rst
+++ b/anastasis.rst
@@ -43,36 +43,39 @@ adversaries which do not know the user's **identifier**, 
and strong
 adversaries which somehow do know a user's **identifier**.  For weak
 adversaries the system guarantees full confidentiality.  For strong
 adversaries, breaking confidentiality additionally requires that Anastasis
-escrow providers must have colluded.  The user is able to define a **policy**
-which determines which Anastasis escrow providers would need to collude to
-break confidentiality. The policy also also sets the bar for the user to
-recover their core secret.
-
-A policy specifies a set of **escrow methods**, which specify how the user
-should convince the Anastasis server that they are "real".  Escrow methods can
-for example include SMS-based verification, Video-identfication or a security
-question.  For each escrow method, the Anastasis server is provided with
-**truth**, that is data the Anastasis operator may learn during the recovery
-process to authenticate the user.  Examples for truth would be a phone number
-(for SMS), a picture of the user (for video identification), or the (hash of)
-a security answer.  A strong adversary is assumed to be able to learn the
-truth, while weak adversaries must not.  In addition to a set of escrow
-methods and associated Anastasis server operators, the policy also specifies
-which combination(s) of these methods should suffice to obtain access.  For
-example, a policy could say that methods (A and B) suffice, and a second
-policy may permit (A and C).  A different user may choose to use the policy
-that (A and B and C) are all required.  Anastasis imposes no limit on the
-number of policies (per user's secret), or the set of providers or escrow
-methods involved in guarding a user's secret.  Weak adversaries must not be
-able to deduce information about a user's policies (except for their length
-if the weak adversary can monitor the user's network traffic).
+escrow providers must have colluded.  The user is able to specify a set of
+**policies** which determine which Anastasis escrow providers would need to
+collude to break confidentiality. These policies also set the bar for the user
+to recover their core secret.
+
+A **recovery document** includes all of the information a user needs to
+recover access to their core secret.  It specifies a set of **escrow
+methods**, which specify how the user should convince the Anastasis server
+that they are "real".  Escrow methods can for example include SMS-based
+verification, Video-identfication or a security question.  For each escrow
+method, the Anastasis server is provided with **truth**, that is data the
+Anastasis operator may learn during the recovery process to authenticate the
+user.  Examples for truth would be a phone number (for SMS), a picture of the
+user (for video identification), or the (hash of) a security answer.  A strong
+adversary is assumed to be able to learn the truth, while weak adversaries
+must not.  In addition to a set of escrow methods and associated Anastasis
+server operators, the **recovery document** also specifies **policies**, which
+describe the combination(s) of the escrow methods that suffice to obtain
+access to the core secret.  For example, a **policy** could say that the
+escrow methods (A and B) suffice, and a second policy may permit (A and C).  A
+different user may choose to use the policy that (A and B and C) are all
+required.  Anastasis imposes no limit on the number of policies in a
+**recovery document**, or the set of providers or escrow methods involved in
+guarding a user's secret.  Weak adversaries must not be able to deduce
+information about a user's **recovery document** (except for its length, which
+may be exposed to an adversary which monitors the user's network traffic).
 
 
 ----------------------
 Anastasis Cryptography
 ----------------------
 
-When a user needs to interact with Anastsis, the system first derives some key
+When a user needs to interact with Anastasis, the system first derives some key
 material, but not the master secret, from the user's **identifier** using
 different HKDFs.  These HKDFs are salted using the respective escrow
 provider's **server salt**, which ensures that the accounts for the same user
@@ -151,19 +154,19 @@ likely also be available to other actors.
 Verification
 ^^^^^^^^^^^^
 
-For users to authorize **policy** operations we need an EdDSA key pair.  As we
+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).
+not the core secret), or upload a new version of the
+**encrypted recovery document** (but not delete an existing version).
 
-For the generation of the private key we use the kdf_id as the entropy source,
+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.  Here, "ver" is used as a salt for the
 HKDF to ensure that the result differs from other cases where we hash
-kdf_id.
+**kdf_id**.
 
 .. code-block:: tsref
 
@@ -225,8 +228,8 @@ key material using an HKDF over a nonce and the kdf_id.
 Key Usage
 ---------
 
-The keys we have generated, are now used to encrypt the recovery_document and
-the key_share of the user.
+The keys we have generated are then used to encrypt the **recovery document** 
and
+the **key_share** of the user.
 
 
 Encryption
@@ -234,17 +237,20 @@ Encryption
 
 Before every encryption a 32-byte nonce is generated.
 From this the symmetric key is computed as described above.
-We use AES256-GCM for the encryption of the recovery_document and
-key_share.
+We use AES256-GCM for the encryption of the **recovery document** and
+the **key_share**.
 
 .. code-block:: tsref
 
-    (encrypted_recovery_document, aes_gcm_tag) = AES256_GCM(recovery_document, 
key, iv)
-    (encrypted_key_share, aes_gcm_tag) = AES256_GCM(key_share, key, iv)
+    (iv0, key0) = HKDF(key_id, nonce0, keysize + ivsize)
+    (encrypted_recovery_document, aes_gcm_tag) = AES256_GCM(recovery_document, 
key0, iv0)
+    (iv_i, key_i) = HKDF(key_id, nonce_i, keysize + ivsize)
+    (encrypted_key_share_i, aes_gcm_tag_i) = AES256_GCM(key_share_i, key_i, 
iv_i)
 
-**encrypted_recovery_document**: The encrypted RecoveryDocument 
(recovery_document) which contains the policies.
+**encrypted_recovery_document**: The encrypted **recovery document** which 
contains the escrow methods, policies and the encrypted **core secret**.
+
+**encrypted_key_share_i**: The encrypted **key_share** which the escrow 
provider must release upon successful authentication.  Here, **i** must a 
positive number used to iterate over the various **key shares** used for the 
various **escrow methods** at the various providers.
 
-**encrypted_key_share**: The encrypted KeyShare (key_share).
 
 Signatures
 ^^^^^^^^^^
@@ -258,11 +264,11 @@ algorithm is equivalent for 
**Anastasis-Policy-Signature**.
     (anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
     ver_res = eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub)
 
-**anastasis-account-signature**: Signature over the hash of body.
+**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).
 
 **h_body**: The hashed body.
 
-**ver_res**: A boolean value. True: Verification passed, False: Verification 
failed.
+**ver_res**: A boolean value. True: Signature verification passed, False: 
Signature verification failed.
 
 
 -------------------
@@ -395,13 +401,13 @@ Receiving Terms of Service
       // HTML text describing the terms of service in legalese.
       // May include placeholders like "${truth_upload_fee}" to
       // reference entries in this response.
-      tos: String;
+      tos: string;
 
     }
 
     interface AuthenticationMethod {
       // name of the authentication method
-      name: String;
+      name: string;
 
       // Fee for accessing truth using this method
       usage_fee: Amount;

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