fix typo

1 files changed, 54 insertions, 54 deletions

diff --git a/texinfo/anastasis.texi b/texinfo/anastasis.texi
index a35a6666..be8c50be 100644
--- a/texinfo/anastasis.texi
+++ b/texinfo/anastasis.texi
@@ -75,7 +75,7 @@ this difficult for everyone else.  Furthermore, it is assumed that the user is
 unable to reliably remember any secret with sufficiently high entropy, so we
 cannot simply encrypt using some other key material in possession of the user.
 
-To uniquely identify users, an "unforgettable" @strong{identifier} is used.  This
+To uniquely identify users, an “unforgettable” @strong{identifier} is used.  This
 identifier should be difficult to guess for anybody but the user. However, the
 @strong{identifier} is not expected to have sufficient entropy or secrecy to be
 cryptographically secure. Examples for such identifier would be a
@@ -83,8 +83,8 @@ concatenation of the full name of the user and their social security or
 passport number(s).  For Swiss citizens, the AHV number could also be used.
 
 The adversary model of Anastasis has two types of adversaries: weak
-adversaries which do not know the user's @strong{identifier}, and strong
-adversaries which somehow do know a user's @strong{identifier}.  For weak
+adversaries which do not know the user’s @strong{identifier}, and strong
+adversaries which somehow do know a user’s @strong{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 specify a set of
@@ -95,7 +95,7 @@ to recover their core secret.
 A @strong{recovery document} includes all of the information a user needs to
 recover access to their core secret.  It specifies a set of @strong{escrow
 methods}, which specify how the user should convince the Anastasis server
-that they are "real".  Escrow methods can for example include SMS-based
+that they are “real”.  Escrow methods can for example include SMS-based
 verification, video identification or a security question.  For each escrow
 method, the Anastasis server is provided with @strong{truth}, that is data the
 Anastasis operator may learn during the recovery process to authenticate the
@@ -110,9 +110,9 @@ 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
 @strong{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 @strong{recovery document} (except for its length, which
-may be exposed to an adversary which monitors the user's network traffic).
+guarding a user’s secret.  Weak adversaries must not be able to deduce
+information about a user’s @strong{recovery document} (except for its length, which
+may be exposed to an adversary which monitors the user’s network traffic).
 
 @menu
 * Anastasis DB Schema:: 
@@ -144,16 +144,16 @@ may be exposed to an adversary which monitors the user's network traffic).
 
 
 When a user needs to interact with Anastasis, the system first derives some key
-material, but not the master secret, from the user's @strong{identifier} using
+material, but not the master secret, from the user’s @strong{identifier} using
 different HKDFs.  These HKDFs are salted using the respective escrow
-provider's @strong{server salt}, which ensures that the accounts for the same user
+provider’s @strong{server salt}, which ensures that the accounts for the same user
 cannot be easily correlated across the various Anastasis servers.
 
 Each Anastasis server uses an EdDSA @strong{account key} to identify the account of
-the user.  The account private key is derived from the user's @strong{identifier} using
+the user.  The account private key is derived from the user’s @strong{identifier} using
 a computationally expensive cryptographic hash function.  Using an
 expensive hash algorithm is assumed to make it infeasible for a weak adversary to
-determine account keys by brute force (without knowing the user's identifier).
+determine account keys by brute force (without knowing the user’s identifier).
 However, it is assumed that a strong adversary performing a targeted attack can
 compute the account key pair.
 
@@ -205,10 +205,10 @@ This identifier will be first hashed with Argon2, to provide a @strong{kdf_id}
 which will be used to derive other keys later. The Hash must also include the
 respective @strong{server_salt}. This also ensures that the @strong{kdf_id} is different
 on each server. The use of Argon2 and the respective @strong{server_salt} is intended
-to make it difficult to brute-force @strong{kdf_id} values and help protect the user's
+to make it difficult to brute-force @strong{kdf_id} values and help protect the user’s
 privacy. Also this ensures that the @strong{kdf_id}s on every server differs. However,
 we do not assume that the @strong{identifier} or the @strong{kdf_id} cannot be
-determined by an adversary performing a targeted attack, as a user's
+determined by an adversary performing a targeted attack, as a user’s
 @strong{identifier} is likely to always be known to state actors and may
 likely also be available to other actors.
 
@@ -233,17 +233,17 @@ kdf_id := Argon2( identifier, server_salt, keysize )
 @subsection 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 @strong{kdf_id}, decrypt) the user's policy (but
+key, they could access (and with the @strong{kdf_id}, decrypt) the user’s policy (but
 not the core secret), or upload a new version of the
 @strong{encrypted recovery document} (but not delete an existing version).
 
 For the generation of the private key we use the @strong{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
+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
 @strong{kdf_id}.
 
@@ -261,7 +261,7 @@ eddsa_pub := get_EdDSA_Pub(eddsa_priv)
 
 @strong{ver_secret}: Derived key from the @code{kdf_id}, serves as intermediate step for the generation of the private key.
 
-@strong{eddsa_d_to_a()}: Function which converts the ver_key to a valid EdDSA private key. Specifically, assuming the value @code{eddsa_priv} is in a 32-byte array "digest", the function clears and sets certain bits as follows:
+@strong{eddsa_d_to_a()}: Function which converts the ver_key to a valid EdDSA private key. Specifically, assuming the value @code{eddsa_priv} is in a 32-byte array “digest”, the function clears and sets certain bits as follows:
 
 @example
 digest[0] = (digest[0] & 0x7f) | 0x40;
@@ -296,7 +296,7 @@ key material using an HKDF over a @code{nonce} and the @code{kdf_id}.
 
 @strong{prekey}: Original key material.
 
-@strong{nonce}: 32-byte nonce, must never match "ver" (which it cannot as the length is different). Of course, we must
+@strong{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 have to use different nonces to get different keys and IVs (see below).
 
 @strong{key}: Symmetric key which is later used to encrypt the documents with AES256-GCM.
@@ -327,7 +327,7 @@ From this the symmetric key is computed as described above.
 We use AES256-GCM for the encryption of the @strong{recovery document} and
 the @strong{key_share}.  To ensure that the key derivation for the encryption
 of the @strong{recovery document} differs fundamentally from that of an
-individual @strong{key share}, we use different salts ("erd" and "eks", respectively).
+individual @strong{key share}, we use different salts (“erd” and “eks”, respectively).
 
 @example
 (iv0, key0) := HKDF(key_id, nonce0, "erd", keysize + ivsize)
@@ -340,7 +340,7 @@ individual @strong{key share}, we use different salts ("erd" and "eks", respecti
 and the encrypted @strong{core secret}.
 
 @strong{nonce0}: Nonce which is used to generate @emph{key0} and @emph{iv0} which are used for the encryption of the @emph{recovery document}.
-Nonce must contain the string "ERD".
+Nonce must contain the string “ERD”.
 
 @strong{optional data}: Key material that optionally is contributed from the authentication method to further obfuscate the key share from the escrow provider.
 
@@ -349,10 +349,10 @@ Here, @strong{i} must be a positive number used to iterate over the various @str
 at the various providers.
 
 @strong{nonce_i}: Nonce which is used to generate @emph{key_i} and @emph{iv_i} which are used for the encryption of the @strong{key share}. @strong{i} must be
-the same number as specified above for @emph{encrypted_key_share_i}. Nonce must contain the string "EKS" plus the according @emph{i}.
+the same number as specified above for @emph{encrypted_key_share_i}. Nonce must contain the string “EKS” plus the according @emph{i}.
 
 As a special rule, when a @strong{security question} is used to authorize access to an
-@strong{encrypted_key_share_i}, then the salt "eks" is replaced with an (expensive) hash
+@strong{encrypted_key_share_i}, then the salt “eks” is replaced with an (expensive) hash
 of the answer to the security question as an additional way to make the key share
 inaccessible to those who do not have the answer:
 
@@ -372,7 +372,7 @@ ekss := HKDF("Anastasis-secure-question-uuid-salting",
 
 @strong{uuid}: UUID of the challenge associated with the security question and the encrypted key share.
 
-@strong{ekss}: Replacement salt to be used instead of "eks" when deriving the key to encrypt/decrypt the key share.
+@strong{ekss}: Replacement salt to be used instead of “eks” when deriving the key to encrypt/decrypt the key share.
 
 @node Signatures,,Encryption<2>,Key Usage
 @anchor{anastasis signatures}@anchor{9}
@@ -403,7 +403,7 @@ ver_res := eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)
 
 @strong{anastasis-account-signature}: Signature over the SHA-512 hash of the body using the purpose code @code{TALER_SIGNATURE_ANASTASIS_POLICY_DOWNLOAD} (1401) (see GNUnet EdDSA signature API for the use of purpose).
 
-@strong{version}: The version requested as a 64-bit integer, 2^64-1 for the "latest version".
+@strong{version}: The version requested as a 64-bit integer, 2^64-1 for the “latest version”.
 
 @strong{ver_res}: A boolean value. True: Signature verification passed, False: Signature verification failed.
 
@@ -414,7 +414,7 @@ ver_res := eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)
 
 Anastasis considers two main threats against availability. First, the
 Anastasis server operators must be protected against denial-of-service attacks
-where an adversary attempts to exhaust the operator's resources.  The API protects
+where an adversary attempts to exhaust the operator’s resources.  The API protects
 against these attacks by allowing operators to set fees for all
 operations. Furthermore, all data stored comes with an expiration logic, so an
 attacker cannot force servers to store data indefinitely.
@@ -430,7 +430,7 @@ merely create another version.  This way, even if an adversary uploads a
 malicious policy, a user can still retrieve an older version of the policy to
 recover access to their data.  This append-only storage for policies still
 leaves a strong adversary with the option of uploading many policies to
-exhaust the Anastasis server's capacity.  We limit this attack by requiring a
+exhaust the Anastasis server’s capacity.  We limit this attack by requiring a
 policy upload to include a reference to a @strong{payment identifier} from a payment
 made by the user.  Thus, a policy upload requires both knowledge of the
 @strong{identity} and making a payment.  This effectively prevents an adversary
@@ -535,7 +535,7 @@ Obtain the terms of service provided by the escrow provider.
 @strong{Response:}
 
 Returns the terms of service of the provider, in the best language
-and format available based on the client's request.
+and format available based on the client’s request.
 @end deffn
 
 @anchor{anastasis get--privacy}@anchor{15}
@@ -546,7 +546,7 @@ Obtain the privacy policy of the service provided by the escrow provider.
 @strong{Response:}
 
 Returns the privacy policy of the provider, in the best language
-and format available based on the client's request.
+and format available based on the client’s request.
 @end deffn
 
 @node Manage policy,Managing truth,Receiving Terms of Service,Anastasis REST API
@@ -568,7 +568,7 @@ In the following, UUID is always defined and used according to RFC 4122@footnote
 @anchor{anastasis get--policy-$ACCOUNT_PUB[?version=$NUMBER]}@anchor{18}
 @deffn {HTTP Get} GET /policy/$ACCOUNT_PUB[?version=$NUMBER]
 
-Get the customer's encrypted recovery document.  If @code{version}
+Get the customer’s encrypted recovery document.  If @code{version}
 is not specified, the server returns the latest available version.  If
 @code{version} is specified, returns the policy with the respective
 @code{version}.  The response must begin with the nonce and
@@ -613,7 +613,7 @@ The @code{$ACCOUNT_PUB} is not an EdDSA public key.
 
 @item 402 Payment Required@footnote{http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.3}:
 
-The account's balance is too low for the specified operation.
+The account’s balance is too low for the specified operation.
 See the Taler payment protocol specification for how to pay.
 
 @item 403 Forbidden@footnote{http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4}:
@@ -625,7 +625,7 @@ The required account signature was invalid.
 The requested resource was not found.
 @end table
 
-@emph{Anastasis-Version}: $NUMBER --- The server must return actual version of the encrypted recovery document via this header.
+@emph{Anastasis-Version}: $NUMBER — The server must return actual version of the encrypted recovery document via this header.
 If the client specified a version number in the header of the request, the server must return that version. If the client
 did not specify a version in the request, the server returns latest version of the @ref{19,,EncryptedRecoveryDocument}.
 
@@ -640,8 +640,8 @@ The client SHOULD send this header with every request (except for the first requ
 @anchor{anastasis post--policy-$ACCOUNT_PUB}@anchor{1a}
 @deffn {HTTP Post} POST /policy/$ACCOUNT_PUB
 
-Upload a new version of the customer's encrypted recovery document.
-While the document's structure is described in JSON below, the upload
+Upload a new version of the customer’s encrypted recovery document.
+While the document’s structure is described in JSON below, the upload
 should just be the bytestream of the raw data (i.e. 32-byte nonce followed
 by 16-byte tag followed by the encrypted document).
 If the request has been seen before, the server should do nothing, and otherwise store the new version.
@@ -657,7 +657,7 @@ minimum and maximum size limits.
 @itemize *
 
 @item 
-@code{pay} -- Optional argument, any non-empty value will do,
+@code{pay} – Optional argument, any non-empty value will do,
 suggested is @code{y} for @code{yes}.
 The client insists on making a payment for the respective
 account, even if this is not yet required. The server
@@ -670,7 +670,7 @@ option will be checked before the @code{304 Not modified}
 case.
 
 @item 
-@code{timeout_ms=NUMBER} -- @emph{Optional.}  If specified, the Anastasis server will
+@code{timeout_ms=NUMBER} – @emph{Optional.}  If specified, the Anastasis server will
 wait up to @code{timeout_ms} milliseconds for completion of the payment before
 sending the HTTP response.  A client must never rely on this behavior, as the
 backend may return a response immediately.
@@ -686,7 +686,7 @@ the latest version already known to the server.
 
 @emph{Anastasis-Policy-Signature}: The client must provide Base-32 encoded EdDSA signature over hash of body with @code{$ACCOUNT_PRIV}, affirming desire to upload an encrypted recovery document.
 
-@emph{Payment-Identifier}: Base-32 encoded 32-byte payment identifier that was included in a previous payment (see @code{402} status code). Used to allow the server to check that the client paid for the upload (to protect the server against DoS attacks) and that the client knows a real secret of financial value (as the @strong{kdf_id} might be known to an attacker). If this header is missing in the client's request (or the associated payment has exceeded the upload limit), the server must return a @code{402} response.  When making payments, the server must include a fresh, randomly-generated payment-identifier in the payment request.
+@emph{Payment-Identifier}: Base-32 encoded 32-byte payment identifier that was included in a previous payment (see @code{402} status code). Used to allow the server to check that the client paid for the upload (to protect the server against DoS attacks) and that the client knows a real secret of financial value (as the @strong{kdf_id} might be known to an attacker). If this header is missing in the client’s request (or the associated payment has exceeded the upload limit), the server must return a @code{402} response.  When making payments, the server must include a fresh, randomly-generated payment-identifier in the payment request.
 
 @strong{Response}:
 
@@ -710,7 +710,7 @@ The response body MUST elaborate on the error using a Taler error code in the ty
 
 @item 402 Payment required@footnote{http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.3}:
 
-The account's balance is too low for the specified operation.
+The account’s balance is too low for the specified operation.
 See the Taler payment protocol specification for how to pay.
 The response body MAY provide alternative means for payment.
 
@@ -840,7 +840,7 @@ If request has been seen before, the server should do nothing, and otherwise sto
 @itemize *
 
 @item 
-@code{timeout_ms=NUMBER} -- @emph{Optional.}  If specified, the Anastasis server will
+@code{timeout_ms=NUMBER} – @emph{Optional.}  If specified, the Anastasis server will
 wait up to @code{timeout_ms} milliseconds for completion of the payment before
 sending the HTTP response.  A client must never rely on this behavior, as the
 backend may return a response immediately.
@@ -955,7 +955,7 @@ The response body MAY provide alternative means for payment.
 
 @item 403 Forbidden@footnote{http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4}:
 
-The server requires a valid "response" to the challenge associated with the UUID.
+The server requires a valid “response” to the challenge associated with the UUID.
 
 @item 404 Not found@footnote{http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5}:
 
@@ -1269,7 +1269,7 @@ process.
 
 In the following, the individual transitions will be specified in more detail.
 Note that we only show fields added by the reducer, typically the previous
-state is preserved to enable "back" transitions to function smoothly.
+state is preserved to enable “back” transitions to function smoothly.
 
 @menu
 * Initial state:: 
@@ -1310,7 +1310,7 @@ The initial states for backup and recovery processes are:
 @}
 @end example
 
-Here, "continents" is an array of English strings with the names of the
+Here, “continents” is an array of English strings with the names of the
 continents which contain countries for which Anastasis could function (based
 on having providers that are known to operate and rules being provided for
 user attributes from those countries).
@@ -1409,7 +1409,7 @@ currency of the country, if a country has multiple currencies, it may appear
 multiple times in the list.  In this case, the user should select the entry
 with the currency they intend to pay with.  It is also possible for users
 to select a currency that does not match their country, but user interfaces
-should by default try to use currencies that match the user's residence.
+should by default try to use currencies that match the user’s residence.
 
 @strong{select_country:}
 
@@ -1428,7 +1428,7 @@ Arguments (example):
 @end example
 
 The @code{country_code} must be an ISO 3166-1 alpha-2 country code from
-the array of @code{countries} of the reducer's state.  The @code{currency}
+the array of @code{countries} of the reducer’s state.  The @code{currency}
 field must be a valid currency accepted by the Taler payment system.
 
 The reducer returns a new state with the list of attributes the
@@ -1561,7 +1561,7 @@ Translated descriptions may be provided under @strong{label_i18n}.
 different countries. Useful to preserve values should the user enter
 some attributes, and then switch to another country.  Note that
 attributes must not be preserved if they merely have the same @strong{name},
-only the @strong{uuid} will be identical if the semantics is identicial.
+only the @strong{uuid} will be identical if the semantics is identical.
 
 @item 
 @strong{widget}: An optional name of a widget that is known to nicely render
@@ -1632,11 +1632,11 @@ will match all of the fees.
 both recovery document and truth data) in megabytes.
 
 @item 
-@strong{provider_name}: Human-readable name of the provider's business.
+@strong{provider_name}: Human-readable name of the provider’s business.
 
 @item 
 @strong{salt}: Salt value used by the provider, used to derive the
-user's identity at this provider. Should be unique per provider,
+user’s identity at this provider. Should be unique per provider,
 and must never change for a given provider.  The salt is
 base32 encoded.
 @end itemize
@@ -1734,7 +1734,7 @@ port 8888 was now added:
 
 @strong{enter_user_attributes:}
 
-This transition provides the user's personal attributes. The specific set of
+This transition provides the user’s personal attributes. The specific set of
 attributes required depends on the country of residence of the user.  Some
 attributes may be optional, in which case they should be omitted entirely
 (that is, not simply be set to @code{null} or an empty string).  Example
@@ -1787,7 +1787,7 @@ is specific to the failure, and optional details.  Example:
 @}
 @end example
 
-Clients may safely repeat this transition to validate the user's inputs
+Clients may safely repeat this transition to validate the user’s inputs
 until they satisfy all of the constraints.  This way, the user interface
 does not have to perform the input validation directly.
 
@@ -1974,7 +1974,7 @@ An example for a possible argument would thus be:
 Note that the specified providers must already be in the
 @code{authentication_providers} of the state. You cannot add new providers at
 this stage.  The reducer will simply attempt to append the suggested policy to
-the "policies" array, returning an updated state:
+the “policies” array, returning an updated state:
 
 @example
 @{
@@ -2235,7 +2235,7 @@ store information into its database.
 
 @strong{enter_user_attributes:}
 
-This transition provides the user's personal attributes. The specific set of
+This transition provides the user’s personal attributes. The specific set of
 attributes required depends on the country of residence of the user.  Some
 attributes may be optional, in which case they should be omitted entirely
 (that is, not simply be set to @code{null} or an empty string).  The
@@ -2373,7 +2373,7 @@ which takes a provider URL and policy version as arguments:
 @}
 @end example
 
-Note that using a version of 0 implies fetching "the latest version".  The
+Note that using a version of 0 implies fetching “the latest version”.  The
 resulting states are the same as those of the @code{enter_user_attributes}
 transition, except that the recovery document version is not necessarily the
 latest available version at the provider.
@@ -2720,7 +2720,7 @@ maximum permissible frequency.
 @section SMS (sms)
 
 
-Sends an SMS with a code (prefixed with @code{A-}) to the user's phone, including
+Sends an SMS with a code (prefixed with @code{A-}) to the user’s phone, including
 a UUID which identifies the challenge the code is for.  The user must send
 this code back with his request (see @code{$RESPONSE} under @ref{1e,,Managing truth}).
 If the transmitted code is correct, the server responses with the requested
@@ -2731,7 +2731,7 @@ encrypted key share.
 @section Email verification (email)
 
 
-Sends an email with a code (prefixed with @code{A-}) to the user's mail address,
+Sends an email with a code (prefixed with @code{A-}) to the user’s mail address,
 including a UUID which identifies the challenge the code is for.  The user
 must send this code back with his request (see @code{$RESPONSE} under @ref{1e,,Managing truth}).  If the transmitted code is correct, the server responses with the
 requested encrypted key share.
@@ -2783,7 +2783,7 @@ storing the security question is malicious.
 
 
 Sends physical mail (snail mail) with a code (prefixed with @code{A-}) to the
-user's mail address, including a UUID which identifies the challenge the code
+user’s mail address, including a UUID which identifies the challenge the code
 is for.  The user must send this code back with their request (see
 @code{$RESPONSE} under @ref{1e,,Managing truth}).  If the transmitted code is correct,
 the server responds with the requested encrypted key share.