diff options
| -rw-r--r-- | anastasis.rst | 14 | ||||
| -rw-r--r-- | core/wireformats.rst | 4 | ||||
| -rw-r--r-- | design-documents/007-payment.rst | 12 | ||||
| -rw-r--r-- | developers-manual.rst | 10 | ||||
| -rw-r--r-- | taler-merchant-manual.rst | 4 |
5 files changed, 22 insertions, 22 deletions
diff --git a/anastasis.rst b/anastasis.rst index 1d34acd..9773e95 100644 --- a/anastasis.rst +++ b/anastasis.rst @@ -145,7 +145,7 @@ determined by an adversary performing a targeted attack, as a user's likely also be available to other actors. -:: +.. code-block:: none kdf_id := Argon2( identifier, server_salt, keysize ) @@ -173,7 +173,7 @@ 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**. -:: +.. code-block:: none ver_secret := HKDF(kdf_id, "ver", keysize) eddsa_priv := eddsa_d_to_a(ver_secret) @@ -190,7 +190,7 @@ HKDF to ensure that the result differs from other cases where we hash **eddsa_d_to_a()**: Function which converts the ver_key to a valid EdDSA private key. Specifically, assuming the value eddsa_priv is in a 32-byte array "digest", the function clears and sets certain bits as follows: -:: +.. code-block:: none digest[0] = (digest[0] & 0x7f) | 0x40; digest[31] &= 0xf8; @@ -208,7 +208,7 @@ symmetric key and an initialization vector (IV). To ensure that the symmetric key changes for each encryption operation, we compute the key material using an HKDF over a nonce and the kdf_id. -:: +.. code-block:: none (iv,key) := HKDF(kdf_id, nonce, keysize + ivsize) @@ -248,7 +248,7 @@ the **key_share**. 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 ("erd" and "eks" respectively). -:: +.. code-block:: none (iv0, key0) = HKDF(key_id, nonce0, "erd", keysize + ivsize) (encrypted_recovery_document, aes_gcm_tag) = AES256_GCM(recovery_document, key0, iv0) @@ -277,7 +277,7 @@ The EdDSA keys are used to sign the data sent from the client to the server. Everything the client sends to server is signed. The following algorithm is equivalent for **Anastasis-Policy-Signature**. -:: +.. code-block:: none (anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv) ver_res = eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub) @@ -291,7 +291,7 @@ algorithm is equivalent for **Anastasis-Policy-Signature**. When requesting policy downloads, the client must also provide a signature: -:: +.. code-block:: none (anastasis-account-signature) = eddsa_sign(version, eddsa_priv) ver_res = eddsa_verifiy(version, anastasis-account-signature, eddsa_pub) diff --git a/core/wireformats.rst b/core/wireformats.rst index 33cda9c..2f1c964 100644 --- a/core/wireformats.rst +++ b/core/wireformats.rst @@ -23,7 +23,7 @@ fully test the Taler system without using "real" currencies. The URL format for ``x-taler-bank`` is simple, in that it only specifies an account number and the origin (domain and optionally a port) of the bank: -:: +.. code-block:: none payto://x-taler-bank/BANK_URI/ACCOUNT_IDENTIFIER @@ -54,7 +54,7 @@ levied by the receiving bank. For the merchant to receive deposits through SEPA, the deposit request must follow the payto:// specification for SEPA: -:: +.. code-block:: none payto://sepa/IBAN diff --git a/design-documents/007-payment.rst b/design-documents/007-payment.rst index 9a16776..432816a 100644 --- a/design-documents/007-payment.rst +++ b/design-documents/007-payment.rst @@ -75,7 +75,7 @@ The merchant backend runs the following steps to generate the 2. If *order-ID* does not identify an existing order, return a 404 Not Found response. **Terminate**. 3. If *order-ID* identifies an order that is *unclaimed* and has claim token *claim-token*, return the URL - :: + .. code-block:: none {backendBaseUrl}/orders/{order-ID}?token={claim-token}&session_id={session-ID} @@ -85,7 +85,7 @@ The merchant backend runs the following steps to generate the 5. If the order remains unpaid or was paid for a different *session-ID*, obtain the contract terms hash *contract-hash* and return the URL - :: + .. code-block:: none {backendBaseUrl}/orders/{order-ID}?h_contract={contract-hash}&session_id={session-ID} @@ -94,7 +94,7 @@ The merchant backend runs the following steps to generate the 6. Here *order-ID* must now identify an order that is *paid* or *refunded*. Obtain the contract terms hash *contract-hash* and return the URL - :: + .. code-block:: none {backendBaseUrl}/orders/{order-ID}?h_contract={contract-hash}&session_id={session-ID} @@ -117,7 +117,7 @@ The merchant backend runs the following steps to generate the HTML page for 2. If the order has granted refunds that have not been obtained by the wallet yet, prompt the URI - :: + .. code-block:: none taler{proto_suffix}://refund/{/merchant_prefix*}/{order-id}/{session-id} @@ -138,7 +138,7 @@ The merchant backend runs the following steps to generate the HTML page for 2. Prompt the URI - :: + .. code-block:: none taler{proto_suffix}://pay/{/merchant_prefix*}/{order-id}/{session-ID}?c={claim-token} @@ -163,7 +163,7 @@ The merchant backend runs the following steps to generate the HTML page for 4. Prompt the URI - :: + .. code-block:: none taler{proto_suffix}://pay/{/merchant_prefix*}/{order-id}/{session-ID} diff --git a/developers-manual.rst b/developers-manual.rst index 842fd39..9fddc8d 100644 --- a/developers-manual.rst +++ b/developers-manual.rst @@ -51,7 +51,7 @@ Code Repositories Taler code is versioned with Git. For those users without write access, all the codebases are found at the following URL: -:: +.. code-block:: none git://git.taler.net/<repository> @@ -78,7 +78,7 @@ in the `Git book <https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Yo If you have been granted write access, you first of all must change the URL of the respective repository to: -:: +.. code-block:: none ssh://git@git.taler.net/<repository> @@ -218,7 +218,7 @@ Tagging components All Taler components must be tagged with git before they are deployed on the ``demo`` environment, using a tag of the following form: -:: +.. code-block:: none demo-YYYY-MM-DD-SS YYYY = year @@ -232,7 +232,7 @@ Environment Layout Environments have the following layout: -:: +.. code-block:: none $HOME/ deployment (deployment.git checkout) @@ -601,7 +601,7 @@ See https://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads Directive file: -:: +.. code-block:: none version: 1.2 directory: taler diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst index 8e9ff04..bff0e84 100644 --- a/taler-merchant-manual.rst +++ b/taler-merchant-manual.rst @@ -800,7 +800,7 @@ If everything worked as expected, the command should return the message - :: +.. code-block:: none Hello, I'm a merchant's Taler backend. This HTTP server is not for humans. @@ -1245,7 +1245,7 @@ FIXME: add full example output. In our example, the output for the wire transfer subject is: -:: +.. code-block:: none QPE24X8PBX3BZ6E7GQ5VAVHV32FWTTCADR0TRQ183MSSJD2CHNEG |