rogaway fixes

3 files changed, 121 insertions, 107 deletions

diff --git a/taler/design.tex b/taler/design.tex
index 4350dfe..c715e70 100644
--- a/taler/design.tex
+++ b/taler/design.tex
@@ -115,7 +115,7 @@ system%
   simpler technical means such as keeping balances on tamper-proof smart cards,
   and thus can lead to an overall more complex system.
 }.  We assume the contact information of the exchange is known to
-both customer and merchant from the start, including that the customer
+both customer and merchant from the start, and the customer
 can authenticate the merchant, for example by using X.509
 certificates~\cite{rfc6818}.  A GNU Taler merchant is expected to deliver
 the service or goods to the customer upon receiving payment.  The
@@ -164,17 +164,17 @@ reserve creation.  The exchange chosen by the customer must support the wire
 transfer method used by the bank, which will be automatically checked by the
 wallet.  Typically, an exchange is already selected by default, as banks can
 suggest a default exchange provider to the wallet, and additionally wallets
-have a pre-defined list of trusted exchange providers.  Subsequently the wallet
+have a pre-defined list of trusted exchange providers.  Subsequently, the wallet
 hands the reserve public key and the bank account information of the selected
 exchange back to the bank.  The bank---typically after asking for a second authentication
 factor from the customer---will then trigger a wire transfer to the exchange with
 the information obtained from the wallet.
 
 When the customer's bank does not offer tight integration with GNU Taler, the
-customer can still manually instruct their wallet create a reserve.  The public
+customer can still manually instruct their wallet to create a reserve.  The public
 key must then be included in a bank transaction to the exchange.  When the
-customer's banking app supports pre-filling wire transfer details from URLs or
-QR code, the wallet can generate such a URL or QR code that includes the
+customer's banking app supports pre-filling wire transfer details from a URL or
+a QR code, the wallet can generate such a URL or QR code that includes the
 pre-filled bank account details of the exchange as well as the reserve public
 key.  The customer clicks on this link or scans the QR code to invoke their
 banking app with pre-filled transaction details.  Since there currently is no
@@ -303,7 +303,7 @@ over the funds.  A useful application for sharing are peer-to-peer payments
 between mutually trusting parties, such as families and friends.
 
 \subsection{Aggregation}
-For each payment, the merchant can specify a deadline after which the exchange
+For each payment, the merchant can specify a deadline before which the exchange
 must issue a wire transfer to the merchant's bank account.  Before this
 deadline occurs, multiple payments from deposited coins to the same merchant
 can be \emph{aggregated} into one bigger payment.  This reduces transaction
@@ -338,13 +338,13 @@ is willing to cover.  Fees exceeding this amount must be explicitly paid by the
 customer.
 
 Another consideration for fees is the prevention of denial-of-service attacks.
-To prevent ``useless'' operations, such as repeated refreshing on coins
-(causing the exchange to use relatively expensive storage) unattractive to an
+To make ``useless'' operations, such as repeated refreshing on coins
+(causing the exchange to use relatively expensive storage), unattractive to an
 adversary, these operations must charge a fee.  Again, for every refresh
 following a payment, the merchant can cover the costs up to a limit set by the
 merchant, effectively hiding the fees from the customer.
 
-Yet another type of fees are the \emph{wire transfer fees}, which are charged
+Yet another type of fee are the \emph{wire transfer fees}, which are charged
 by the exchange for every wire transfer to a merchant in order to compensate for
 the cost of making a transaction in the underlying bank system.  The wire
 transfer fees encourage merchants to choose longer aggregation periods, as the
@@ -391,7 +391,7 @@ before the customer is allowed to withdraw again.
 
 However since the withdraw loophole allows only one additional ``payment'' (without any
 cryptographic evidence that can be used in disputes) before the coin must be deposited,
-these additional mitigations might not even justified considering their additional cost.
+these additional mitigations might not even be justified considering their additional cost.
 
 
 \section{Auditing}
@@ -440,7 +440,7 @@ coin.  If a denomination key has been revoked, the wallets use the
 \emph{payback} protocol to recover funds from coins of revoked denominations.
 Once a denomination is revoked, new coins of this denomination can't be
 withdrawn or used as the target denomination for a refresh operation. A revoked
-coin cannot be spend, and can only be refreshed if its public key was recorded
+coin cannot be spent, and can only be refreshed if its public key was recorded
 in the exchange's database (as spending/refresh operations) before it was
 revoked.
 
@@ -466,7 +466,7 @@ The following cases are possible for payback:
 
 These rules limit the maximum financial damage that the exchange can incur from
 a compromised denomination key $D$ to $2nv$, with $n$ being the
-maximum amount of $D$-coins simultaneously in circulation and $v$ the financial
+maximum number of $D$-coins simultaneously in circulation and $v$ the financial
 value of a single $D$-coin.  Say denomination $D$ was withdrawn by
 legitimate users $n$ times.  As soon as the exchange sees more
 than $n$ pairwise different $D$-coins, it must immediately
@@ -475,15 +475,16 @@ refreshing into other non-revoked denominations or spending the forged $D$-coins
 The legitimate users can then request a payback for their coins, resulting in
 a total financial damage of at most $2nv$.
 
-The payback protocol preserves anonymity except in one special situation.
-Specifically in case (1), the coin obtained from the credited reserve is
-blindly singed, in case (2) the refresh protocol guarantees unlinkability of
-the non-revoked change, and in case (3) the revoked coin $C_R$ is assumed to be
-fresh.  If $C_R$ from case (3) has been seen by a merchant before in an
-aborted/unfinished transaction, this transaction would be linkable to
-transactions on $C_A$.  Thus, anonymity is not preserved when an aborted
-transaction coincides with revoked denomination, which should be rare in
-practice.
+With one rare exception, the payback protocol does not negatively impact the
+anonymity of customers.  We show this by looking at the three different cases
+for payback on a revoked coin.  Specifically, in case (1), the coin obtained
+from the credited reserve is blindly signed, in case (2) the refresh protocol
+guarantees unlinkability of the non-revoked change, and in case (3) the revoked
+coin $C_R$ is assumed to be fresh.  If $C_R$ from case (3) has been seen by a
+merchant before in an aborted/unfinished transaction, this transaction would be
+linkable to transactions on $C_A$.  Thus, anonymity is not preserved when an
+aborted transaction coincides with revoked denomination, which should be rare
+in practice.
 
 Unlike most other operations, the
 payback protocol does not incur any transaction fees. The primary use of the
@@ -579,7 +580,7 @@ probabilistic deposit auditing, and honest merchants have proper
 incentives to participate in the process.
 
 \subsubsection{Compromise of the Database}
-If an adversary would be abe to modify the exchange, this would be detected
+If an adversary would be able to modify the exchange, this would be detected
 rather quickly by the auditor, provided that the database has appropriate
 integrity mechanisms.  An attacker could also prevent database updates to block
 the recording of spend operations, and then double spend.  This is effectively
@@ -687,10 +688,10 @@ double-spending at the finest granularity.  Thus, highly divisible coins incur
 large storage and computational costs for the exchange.
 
 An e-cash system with multiple denominations with different financial values
-was proposed by Canard \cite{canard2006handy} in the context of a divisible
+was proposed by Canard and Gouget~\cite{canard2006handy} in the context of a divisible
 coupon system.
 
-On of the earliest mentions of an explicit change protocol can be found in
+One of the earliest mentions of an explicit change protocol can be found in
 \cite{brickell1995trustee}.  Ian Goldberg's HINDE system is another design that
 allows the merchant to provide change, but the mechanism could be abused to
 hide income from taxation.\footnote{Description based on personal
@@ -926,7 +927,8 @@ GNU Taler
 \subsection{Blockchains}
 The term ``blockchain'' refers to a wide variety of protocols and systems concerned with
 maintaining a ledger---typically involving financial transactions---in a
-distributed and decentralized manner.
+distributed and decentralized manner.\footnote{Even though there is a centralization tendency
+from various sources in practice \cite{walch2019deconstructing}.}
 
 The first and most prominent system that would be categorized as a
 ``blockchain'' today\footnote{The paper that introduces Bitcoin does not
@@ -963,7 +965,7 @@ Some of the most important decisions for the design of blockchains are the follo
     that the hash $H(n \Vert c)$ ends with a certain number of zeroes (as
     determined by the difficulty derived from previous blocks).  Under the
     random oracle, the only way to find such a nonce is by trial-and-error.
-    This nonce proves to a verifier that the creator of the block spend
+    This nonce proves to a verifier that the creator of the block spent
     computational resources to construct it, and the correctness is easily
     verified by computing $H(n \Vert c)$.  The creator of a block is rewarded
     with a mining reward and transaction fees for transactions within the
@@ -1024,7 +1026,7 @@ Some of the most important decisions for the design of blockchains are the follo
     inflation, and a basic income mechanism for participants.
 
   \item Expressivity of transactions.  Transactions in Bitcoin are small programs
-    in a stack-based programming languages that are guaranteed to terminate.
+    in a stack-based programming language that are guaranteed to terminate.
     Ethereum \cite{wood2014ethereum} takes this idea further and allows smart contracts with
     Turing-complete computation and access to external oracles.
 
@@ -1041,7 +1043,7 @@ Some of the most important decisions for the design of blockchains are the follo
     find a ``meta-consensus'' on the rules that govern such systems, and how
     these rules can be adapted and changed in a consensus process.
 
-  \item Anonymity and Zero Knowledge Proofs.  Bitcoin transactions are only
+  \item Anonymity and Zero-Knowledge Proofs.  Bitcoin transactions are only
     pseudoymous, the full transaction history is publicly available and leads
     to reduced anonymity in practice \cite{reid2013analysis}.  Tumblers
     \cite{bonneau2014mixcoin,heilman2017tumblebit} are an approach to increase
@@ -1114,7 +1116,7 @@ final receiver can only receive a payment on a payment channel if it correctly
 forwards it to the next node.
 
 Experimental deployments of the Lightning network recently suffered heavily
-from denial of service attacks. % FIXME: citation needed!
+from denial-of-service attacks. % FIXME: citation needed!
 
 BOLT \cite{green2016bolt} is an anonymous payment channel for ZeroCash, and is
 intended to be used as a building block for a second-layer payment protocol
@@ -1136,7 +1138,7 @@ side-chain according to the side-chain's rules.
 
 At the time of writing, Plasma is not yet implemented.  Potential problems with
 Plasma include the high costs of exits, lack of access to data needed to verify
-exit claims, and associated potential for denial of service attacks.
+exit claims, and associated potential for denial-of-service attacks.
 
 
 %\subsection{Other Payment Systems}
@@ -1176,7 +1178,7 @@ the customer lock-in.
 
 \subsection{Web Integration}
 
-Finally, we will discuss software solutions to Web payments.  We
+Finally, we will discuss software solutions to web payments.  We
 consider other types of payments, including general payments and in
 particular hardware solutions as out of scope for this thesis.
 
@@ -1199,10 +1201,10 @@ payment system handlers.
 
 In order to integrate Taler as a payment method, browsers would need to either
 offer Taler as a native, built-in payment method or allow an extension to
-register Web payment handlers.
+register web payment handlers.
 
 
-The Web Payments working group discontinued work on a HTTP-based API for
+The Web Payments Working Group discontinued work on a HTTP-based API for
 machine-to-machine payments.\footnote{See
 \url{https://www.w3.org/TR/webpayments-http-api/}.}
 
@@ -1256,7 +1258,7 @@ online shopping~\cite[p. 50]{ibi2014}.
 \subsubsection{Other Proprietary Payment APIs}
 The Electronic Payment Standard URI scheme \texttt{epspayment:} is a
 proprietary/unregistered URI scheme used by predominantly Austrian banks and
-merchants to trigger payments from within Websites on mobile devices.
+merchants to trigger payments from within websites on mobile devices.
 Merchants can register an invoice with a central server.  The user's banking
 app is associated with the \texttt{epspayment} URI scheme and will open to
 settle the invoice.  It lies conceptually between \texttt{payto://} and
diff --git a/taler/implementation.tex b/taler/implementation.tex
index aebfd8e..eac2323 100644
--- a/taler/implementation.tex
+++ b/taler/implementation.tex
@@ -5,8 +5,8 @@ design decisions, protocol details and our reference implementation are
 discussed.
 
 We implemented the GNU Taler protocol in the context of a payment system for
-the Web, as shown in Figure~\ref{fig:taler-arch}.  The system was designed for
-real-world usage with current Web technologies and within existing
+the web, as shown in Figure~\ref{fig:taler-arch}.  The system was designed for
+real-world usage with current web technologies and within existing
 financial systems.
 
 The following technical goals and constraints influenced the design of the
@@ -22,12 +22,12 @@ concrete protocol and implementation:
     implementation must take care to not introduce additional threats to
     security and privacy.  Features that trade privacy for convenience should
     be clearly communicated to the user, and the user must have the choice to
-    deactivate them.  Integration with the Web should minimize the potential
+    deactivate them.  Integration with the web should minimize the potential
     for additional user tracking.
   \item The integration for merchants must be simple.  In particular, merchants
     should not have to write code involving cryptographic operations or have to
     manage Taler-specific secrets in their own application processes.
-  \item The Web integration must not be specific to a single browser platform, but
+  \item The web integration must not be specific to a single browser platform, but
     instead must be able to use the lowest common denominator of what is
     currently available.  User experience enhancements supported for only
     specific platforms are possible, but fallbacks must be provided for other
@@ -111,7 +111,7 @@ LOC) is implemented in TypeScript as a cross-browser extension using
 the WebExtensions API, which is available for a majority of widely
 used browsers.  It also uses libgcrypt (compiled to JavaScript) for
 cryptographic operations as the required primitives are not yet
-natively supported by Web browsers.  Sample merchant websites (1,000
+natively supported by web browsers.  Sample merchant websites (1,000
 LOC) and an example bank (2,000 LOC) with tight Taler integration are
 provided in Python.
 
@@ -478,8 +478,8 @@ exchange should not learn about the full details of the business agreement
 between customer and merchant.
 
 \subsection{Resource-based Web Payments}
-In order to integrate natively with the concepts and architecture of the Web,
-Taler supports paying for a Web resource in the form of a URL.  In fact all
+In order to integrate natively with the concepts and architecture of the web,
+Taler supports paying for a web resource in the form of a URL.  In fact all
 Taler contract terms contain a \emph{fulfillment URL}, which identifies the
 resource that is being paid for.  If the customer is not paying for a digital
 product (such as an movie, song or article), the fulfillment URL can point to a
@@ -528,7 +528,7 @@ Taler-Resource-Url: https://alice-shop.example.com/*\break\contl*essay-24.pdf
     id from the contract as an additional parameter and navigates the browser
     to the resulting URL
     \nolinkurl{https://alice-shop.example.com/esasy-24.pdf?order\_id=...}.
-  \item The shop receives the request to the extended fulfillment URI and
+  \item The shop receives the request to the extended fulfillment URL and
     checks if the payment corresponding to the order ID was completed.  In case
     the payment was successful, it serves the purchased content.
 \end{enumerate}
@@ -548,7 +548,7 @@ found, the wallet instead redirects the user to the extended fulfillment URL
 for this contract, instead of downloading the new contract terms and prompting
 for payment.
 
-In the example given above, the URL that triggers the payment is same as the fulfillment URL.
+In the example given above, the URL that triggers the payment is the same as the fulfillment URL.
 This may not always the case in practice.  When the merchant backend is hosted by a third
 party, say \nolinkurl{https://bob.example.com/}, the page that triggers the payment
 even has a different origin, i.e. the scheme, host or port may differ \cite{rfc6454}.
@@ -563,7 +563,7 @@ wallet will navigate to the extended fulfillment URL corresponding to $u$.
 Otherwise, the wallet will try to download a contract from the URL given by the
 attacker.  In order to prevent this attack on privacy, the wallet must only
 redirect to $u$ if the origin of the page responding with HTTP 402 is the same
-origin as either the $u$ or the pay URI.\footnote{This type of countermeasure is well
+origin as either the $u$ or the pay URL.\footnote{This type of countermeasure is well
 known in browsers as the same origin policy, as also outlined in \cite{rfc6454}.}
 
 \subsubsection{Loose Browser Integration}\label{sec:loose-browser-integration}
@@ -589,7 +589,7 @@ GNU Taler wallet applications register themselves as a handler for the
 \texttt{taler} URI scheme, and thus following a \texttt{taler:pay} link opens
 the dedicated wallet, even if GNU Taler is not supported by the browser or a
 browser extension.  Registration a custom protocol handler for a URI scheme is
-possible on all modern platforms with Web browsers that we are aware of.
+possible on all modern platforms with web browsers that we are aware of.
 
 Note that wallets communicating with the merchant do so from a different
 browsing context, and thus the merchant backend cannot rely on cookies that
@@ -607,7 +607,7 @@ As we described the payment protocol so far, an extended fulfillment URL
 is
 not bound to a browser session.  When sharing an extended fulfillment
 URL, another user would get access to the same content.  This might be appropriate
-for some types of fulfillment pages (such as a donation receipt), but is generally is not
+for some types of fulfillment pages (such as a donation receipt), but is generally not
 appropriate when digital content is sold.  Even though it is trivial to share digital content
 unless digital restrictions management (DRM) is employed, the ability to share
 links might set the bar for sharing too low.
@@ -645,7 +645,7 @@ same contract terms and restrict a session to one IP address, limiting sharing.
 
 For the situation where a user accesses a session-bound paid resource and
 neither has a corresponding contract in their wallet nor does the merchant
-provide a contract URI to buy access to the resource, the merchant can specify
+provide a contract URL to buy access to the resource, the merchant can specify
 an \emph{offer URL} in the ``Taler-Offer-Url'' header.  If the wallet is not
 able to take any other steps to complete the payment, it will redirect the user
 to the offer URL.  As the name suggests, the offer URL can point to a page with
@@ -691,7 +691,7 @@ contain the following information:
   \item the claim public key provided by the customer, used to prove they have claimed the contract terms,
   \item the order ID, which is a short, human-friendly identifier for the contract terms within
     the merchant,
-  \item the \texttt{fulfillment\_url}, which identifies the resources that is being paid for
+  \item the \texttt{fulfillment\_url}, which identifies the resources that is being paid for,
   \item a human-readable summary and product list,
   \item the fees covered by the merchant (if the fees for the payment exceed this value, the
     customer must explicitly pay the additional fees),
@@ -743,8 +743,9 @@ obligations) into the user's wallet.
 To be able to give tips, the merchant must create a reserve with an exchange.  The reserve private key
 is used to sign blinded coins generated by the user that is being given the tip.
 
-The merchant triggers giving a tip with an HTTP 402 response that has the ``Taler-Tip'' header. The value
-of the tip header (called the tip token) contains
+The merchant triggers the wallet by returning an HTTP 402 Payment Required
+response that includes the ``Taler-Tip'' header. The value of the tip header (called the
+tip token) contains
 \begin{itemize}
   \item the amount of the tip,
   \item the exchange to use,
@@ -756,12 +757,13 @@ of the tip header (called the tip token) contains
 Upon receiving the tip token, the wallet creates coin planchets that sum up to at most
 the amount specified in the tip token, with denominations offered by the exchange specified in the tip token.
 
-The list of planchets is then sent to the merchant via an HTTP \texttt{POST} request to the tip
-pickup URL.  The merchant creates a withdrawal confirmation signature for each
-planchet, using the private key of the tipping reserve, and responds to the HTTP
-\texttt{POST} request with the resulting list of signatures.  The user then uses these signatures
-in the normal withdrawal protocol with the exchange to obtain coins ``paid
-for'' by the merchant, but anonymized and only spendable by the customer.
+The list of planchets is then sent to the merchant via an HTTP \texttt{POST}
+request to the tip-pickup URL.  The merchant creates a withdrawal confirmation
+signature for each planchet, using the private key of the tipping reserve, and
+responds to the HTTP \texttt{POST} request with the resulting list of
+signatures.  The user then uses these signatures in the normal withdrawal
+protocol with the exchange to obtain coins ``paid for'' by the merchant, but
+anonymized and only spendable by the customer.
 
 
 \section{Bank Integration}
@@ -965,7 +967,7 @@ on the append-only tables.  Each append-only table has a monotonically
 increasing row ID.  Thus, the auditor's checkpoint simply consists of the set of
 row IDs that were last seen.
 
-The auditor exposes a Web server with the \texttt{taler-auditor-httpd} process.
+The auditor exposes a web server with the \texttt{taler-auditor-httpd} process.
 Currently, it only shows a website that allows the customer to add the auditor
 to the list of trusted auditors in their wallet.  In future versions, the
 auditor will also have HTTP endpoints that allow merchants to submit samples of
@@ -1099,13 +1101,13 @@ library written in C as well as its dependencies (such as libgcrypt) to asm.js
 toolchain \cite{zakai2011emscripten}.
 
 Cryptographic operations run in an isolated process implemented as a
-WebWorker\footnote{\url{https://html.spec.whatwg.org/}}.  This design allows
+WebWorker.\footnote{\url{https://html.spec.whatwg.org/}}  This design allows
 the relatively slow cryptographic operations to run concurrently in the
 background in multiple threads.  Since the crypto WebWorkers are started on-demand,
 the wallet only uses minimal resources when not actively used.
 
 \subsection{Optimizations}\label{sec:wallet-optimizations}
-To reduce the perceived performance of cryptographic operations,
+To improve the perceived performance of cryptographic operations,
 the wallet optimistically creates signatures in the background
 while the user is looking at the ``confirm payment'' dialog.  If the user does
 not accept the contract, these signatures are thrown away instead of being sent
@@ -1218,7 +1220,7 @@ with HTTP 402 and at least one Taler-specific header.
 % via URL
 The steps to process a payment trigger are as follows.  The algorithm takes the
 following parameters: \texttt{current\_url} (the URL of the page that
-raises the 402 status or \texttt{null} if triggered by a \texttt{taler:pay} URI),
+raises the 402 status or \texttt{null} if triggered by a \texttt{taler:pay} URL),
 \texttt{contract\_url}, \texttt{resource\_url}, \texttt{session\_id},
 \texttt{offer\_url}, \texttt{refund\_url}, \texttt{tip\_token} (from the
 ``Taler-\dots'' headers or \emph{taler:pay} URL parameters respectively)
@@ -1244,9 +1246,9 @@ raises the 402 status or \texttt{null} if triggered by a \texttt{taler:pay} URI)
   \item If \texttt{tip\_url} is a non-empty URL, process the tip and stop.
 \end{enumerate}
 
-For interactive Web applications that request payments, such as games or single
+For interactive web applications that request payments, such as games or single
 page apps (SPAs), the payments initiated by navigating to a page with HTTP
-status code 402 are not appropriate, since the state of the Web application is
+status code 402 are not appropriate, since the state of the web application is
 destroyed by the navigation.  Instead the wallet can offer a JavaScript-based
 API, exposed as a single function with a subset of the parameters of the
 402-based payment: \texttt{contract\_url}, \texttt{resource\_url},
@@ -1757,7 +1759,7 @@ is the bottleneck for the performance of the system.
 We provide a microbenchmark for the performance of cryptographic operations in
 the wallet (Table~\ref{table:wallet-benchmark}.  Even on a low-end smartphone
 device, the most expensive cryptographic operations remain well under
-$150ms$, a threshold for user-interface latency under which user happyiness and
+$150ms$, a threshold for user-interface latency under which user happiness and
 productivity is considered to be unaffected \cite{tolia2006quantifying}.
 
 \begin{table}
@@ -1832,7 +1834,7 @@ used a  development version of the exchange (with git commit hash
 
 \subsection{Coins Per Transaction}\label{sec:coins-per-transaction}
 The transaction rate is an important characteristic of a payment system.  Since
-GNU Taler internally operates on the level of coins instead of transaction, we
+GNU Taler internally operates on the level of coins instead of transactions, we
 need to define what actually consititutes one transaction in our measurements.
 This includes both how many coins are used per transaction on average, as well
 as how often refresh operations are run.
@@ -1842,7 +1844,7 @@ the parameters that characterize the average transaction.  The source code for
 the simulation can be found in Appendix \ref{appendix:coinsim}.
 
 In the simulation, thirteen denominations of values $2^0,\dots,2^{12}$ are
-available.  Customers repeatedly select a random value to be spend between $4$ and $5000$.
+available.  Customers repeatedly select a random value to be spent between $4$ and $5000$.
 When customers do not have enough coins for a transaction, they withdraw a
 uniform random amount between the minimum amount to complete the transaction
 and $10000$.  The denominations selected for withdrawal are chosen by greedy
@@ -1894,12 +1896,12 @@ withdraw and spend $10000$ coins, with $10\%$ refresh probability.
 % FIXME: talk about TFO, compression and keep-alive
 
 Table~\ref{table:benchmark:ops-baseline} shows the time used for cryptographic
-operations, together with the number of times they are executed by the
-clients (plus the mock bank) and exchange, respectively.  Note that while we measured the
-wall-clock time for these operations, the averages should correspond to the
-actual CPU time required for the respective operations, as the benchmark with
-one client runs significantly fewer processes/threads than the number of
-available CPUs on our machine.
+operations, together with the number of times they are executed by the clients
+(plus the mock bank and benchmark setup) and exchange, respectively.  Note that
+while we measured the wall-clock time for these operations, the averages should
+correspond to the actual CPU time required for the respective operations, as
+the benchmark with one client runs significantly fewer processes/threads than
+the number of available CPUs on our machine.
 
 The benchmark completed in $17.14$ minutes. We obtained the total CPU usage of
 the benchmark testbed and exchange.  The refresh operations are rather slow in comparison
@@ -1912,24 +1914,24 @@ minutes to complete.
   \toprule
   Operation & {Time/Op (\si{\micro\second})} & {Count (exchange)} & {Count (clients)} \\
   \midrule
-eddsa key create            & 1896.27   &  0      & 12180  \\ 
+ecdh eddsa                  & 1338.62   &  2430   & 3645   \\ 
+ecdhe key create            & 1825.38   &  0      & 3645   \\ 
 ecdhe key get public        & 1272.64   &  2430   & 4860   \\ 
-rsa unblind                 & 1348.62   &  0      & 21898  \\ 
-eddsa key get public        & 1729.69   &  9720   & 80340  \\ 
 eddsa ecdh                  & 1301.78   &  0      & 4860   \\ 
-rsa sign blinded            & 5284.88   &  17053  & 0      \\ 
-rsa blind                   & 695.25   &  9720   & 31633  \\ 
-hkdf                        & 40.61   &  65057  & 193506 \\ 
+eddsa key create            & 1896.27   &  0      & 12180  \\ 
+eddsa key get public        & 1729.69   &  9720   & 80340  \\ 
 eddsa sign                  & 5182.33   &  13393  & 25608  \\ 
-ecdh eddsa                  & 1338.62   &  2430   & 3645   \\ 
-rsa verify                  & 421.19   &  13393  & 29216  \\ 
-ecdhe key create            & 1825.38   &  0      & 3645   \\ 
-rsa private key get public  & 5.30       &  0      & 40     \\ 
 eddsa verify                & 3976.96   &  25586  & 25627  \\ 
 hash                        & 1.41   &  165608 & 169445 \\ 
-hash context start          & 11.38   &  1215   & 1227   \\ 
-hash context read           & 0.81  &  25515  & 25655  \\ 
 hash context finish         & 0.28  &  1215   & 1227   \\ 
+hash context read           & 0.81  &  25515  & 25655  \\ 
+hash context start          & 11.38   &  1215   & 1227   \\ 
+hkdf                        & 40.61   &  65057  & 193506 \\ 
+rsa blind                   & 695.25   &  9720   & 31633  \\ 
+rsa private key get public  & 5.30       &  0      & 40     \\ 
+rsa sign blinded            & 5284.88   &  17053  & 0      \\ 
+rsa unblind                 & 1348.62   &  0      & 21898  \\ 
+rsa verify                  & 421.19   &  13393  & 29216  \\ 
   \bottomrule
   \end{tabular}
   \caption{Cryptographic operations in the benchmark with one client and $10000$ operations.}
@@ -1959,7 +1961,7 @@ hash context finish         & 0.28  &  1215   & 1227   \\
     \emph{Sum} & 26.14 & 13.88 & 40.02 \\
   \bottomrule
   \end{tabular}
-  \caption{Space usage by database for $10000$ deposits with $10\%$ refresh probability.}
+  \caption{Space usage by database table for $10000$ deposits with $10\%$ refresh probability.}
   \label{table:exchange-db-size}
 \end{table}
 
@@ -2057,7 +2059,10 @@ already terminated before it reaches the exchange service, and exchanges can be
 operated securely even without TLS.
 
 The comparison between no additional delay and a \SI{100}{\milli\second} delay
-is shown in Table~\ref{table:latency}.  In the incremental request to
+is shown in Table~\ref{table:latency}.  As TCP Fast Open was enabled on both \texttt{gv}
+and \texttt{firefly}
+
+In the incremental request to
 \texttt{/keys} (which only returns keys added after the requested date), the
 artificial latency reveals that the request is completed with one round trip.
 The request is already sent in the first TCP packet from the client to the
@@ -2077,18 +2082,25 @@ grows linearly for a single client.  We note that in larger benchmarks with
 multiple parallel clients, the effect of additional delay would likely not just
 be linear, due to timeouts raised by clients.
 
+\newcommand{\specialcell}[2][c]{%
+  \begin{tabular}[#1]{@{}c@{}}#2\end{tabular}}
+
 \begin{table}
   \centering
-  \begin{tabular}{lSS}
+  \begin{tabular}{lSSSS}
   \toprule
-  Endpoint & {Base latency (\si{\milli\second})} & {Delay (\SI{100}{\milli\second}) latency (\si{\milli\second})} \\
+    Endpoint &
+    {\specialcell[c]{Base latency\\(\si{\milli\second})}} &
+    {\specialcell[c]{Latency with\\\SI{100}{\milli\second} delay\\(\si{\milli\second})}} &
+    {\specialcell[c]{Request size\\(\si{\kilo\byte})}} &
+    {\specialcell{Response size\\(\si{\kilo\byte})}} \\
   \midrule
-  \texttt{/keys}             &  0.95   &    400.91   \\ 
-  \texttt{/keys} (incremental)  &  0.52   &    200.55   \\ 
-  \texttt{/deposit}          &  19.66  &   420.32    \\
-  \texttt{/reserve/withdraw} &  19.43  &    419.98   \\ 
-  \texttt{/refresh/melt}     &  19.96  &    419.80   \\ 
-  \texttt{/refresh/reveal}   &  82.87  &   483.33    \\
+  %\texttt{/keys} (incremental)  &  0.52   &    200.55   \\ 
+    \texttt{/keys}                &  1.01   &    201.042  & 0.012  & 3.72  \\ 
+    \texttt{/deposit}             &  28.94  &   434.212    & 3.97  & 0.34  \\
+    \texttt{/reserve/withdraw}    &  29.38  &    432.491  & 2.95    & 0.72 \\ 
+    \texttt{/refresh/melt}        &  37.0143  &    419.80  & 3.55   & 0.35 \\ 
+    \texttt{/refresh/reveal}      &  82.87  &   483.33    & 3.84  & 2.11 \\
   \bottomrule
   \end{tabular}
   \caption{Effects of \SI{100}{\milli\second} symmetric network delay on total latency.}
@@ -2122,13 +2134,13 @@ of the system, a threshold signature scheme could be used.
 The current implementation is focused on web payments.  To use GNU Taler for
 payments in brick-and-mortar stores, hardware wallets and smartphone apps for
 devices with near-field-communication (NFC) must be developed.  In some
-scenarios, either the customer or the merchant might not have an internet
+scenarios, either the customer or the merchant might not have an Internet
 connection, and this must be considered in the protocol design.  In typical
 western brick-and-mortar stores, it is currently more likely that the merchant
-has internet connectivity, and thus the protocol must allow operations of the
+has Internet connectivity, and thus the protocol must allow operations of the
 wallet (such as refreshing) to be securely routed over the merchant's
 connection.  In other scenarios, typically in developing countries, the
-merchant (for example a street vendor) might not have internet connection.  If
+merchant (for example a street vendor) might not have Internet connection.  If
 the vendor has a smartphone, the connection to the merchant can be routed
 through the customer.  In other cases, street vendors only have a ``dumb
 phone'' that can receive text messages, and the payment goes through a provider
@@ -2155,7 +2167,7 @@ exchange:
     a single shard, transactions can be further partitioned based on the coin's
     public key.  Each would maintain the database of spent/refreshed coins for
     a subset of all possible coin public keys.  This approach has been
-    suggested for a centrally banked cryprocurrency by Danezis and Meiklejohn
+    suggested for a centrally-banked cryprocurrency by Danezis and Meiklejohn
     \cite{danezis2016rscoin}.
 \end{itemize}
 
diff --git a/taler/security.tex b/taler/security.tex
index 52861e4..101cbc4 100644
--- a/taler/security.tex
+++ b/taler/security.tex
@@ -51,7 +51,7 @@ satisfies those properties.
 
 \section{Introduction to Provable Security}
 Provable security
-\cite{pointcheval2005provable,shoup2004sequences,coron2000exact} is a common
+\cite{goldwasser1982probabilistic,pointcheval2005provable,shoup2004sequences,coron2000exact} is a common
 approach for constructing formal arguments that support the security of a cryptographic
 protocol with respect to specific security properties and underlying
 assumptions on cryptographic primitives.
@@ -63,10 +63,10 @@ length) of the protocol.
 Contrary to what the name might suggest, a protocol that is ``provably secure''
 is not necessarily secure in practice
 \cite{koblitz2007another,damgaard2007proof}.  Instead, provable security
-results are typically based on reductions of the form \emph{``If there is
+results are typically based on reductions of the form \emph{``if there is an
 effective adversary~$\mathcal{A}$ against my protocol $P$, then I can use
 $\mathcal{A}$ to construct an effective adversary~$\mathcal{A}'$ against
-$Q$.''}, where $Q$ is a protocol or primitive that is assumed to be secure or a
+$Q$''} where $Q$ is a protocol or primitive that is assumed to be secure or a
 computational problem that is assumed to be hard.  The practical value of a
 security proof depends on various factors:
 \begin{itemize}
@@ -101,7 +101,7 @@ not be sufficient or complete for the application.
 
 For our purposes, we focus on game-based provable security
 \cite{bellare2006code,pointcheval2005provable,shoup2004sequences,guo2018introduction}
-as opposed to simulation-based provable security \cite{lindell2017simulate},
+as opposed to simulation-based provable security \cite{goldwasser1989knowledge,lindell2017simulate},
 which is another approach to provable security typically used for
 zero-knowledge proofs and secure multiparty computation protocols.
 
@@ -259,9 +259,9 @@ The goal of a security proof is to transform an attacker against
 the protocol under consideration into an attacker against the security
 of an underlying assumption.  Typical examples for common assumptions might be:
 \begin{itemize}
-  \item the difficulty of the decisional/computational Diffie--Hellman problem \cite{boneh1998decision}
+  \item the difficulty of the decisional/computational Diffie--Hellman problem (nicely described by~\cite{boneh1998decision})
   \item existential unforgeability under chosen message attack (EUF-CMA) of a signature scheme \cite{goldwasser1988digital}
-  \item indistinguishability against chosen-plaintext attacks (IND-CPA) of an
+  \item indistinguishability against chosen-plaintext attacks (IND-CPA) of a symmetric
     encryption algorithm \cite{bellare1998relations}
 \end{itemize}
 
@@ -972,7 +972,7 @@ successful attempt to obtain untaxed income.
   any probability space used by the adversary and challenger.
 \end{definition}
 
-For some instantiations, e.g. ones based on zero knowledge proofs, $\kappa$
+For some instantiations, e.g. ones based on zero-knowledge proofs, $\kappa$
 might be a security parameter in the traditional sense.  However for an e-cash
 scheme to be useful in practice, the adversary does not need to have only
 negligible success probability to win the income transparency game.  It
@@ -1353,7 +1353,7 @@ with the generic instantiation of Taler.
 \begin{proof}
   We give a proof via a sequence of games $\mathbb{G}_0(b), \mathbb{G}_1(b),
   \mathbb{G}_2(b)$, where $\mathbb{G}_0(b)$ is the original anonymity game
-  $\mathit{Exp}_{\cal A}^{anon}(1^\lambda, 1^\kappa, b)$.  We show the
+  $\mathit{Exp}_{\cal A}^{anon}(1^\lambda, 1^\kappa, b)$.  We show that the
   adversary can distinguish between subsequent games with only negligible
   probability.  Let $\epsilon_{HC}$ and $\epsilon_{KX}$ be the advantage of an
   adversary for finding hash collisions and for breaking the security of the
@@ -1634,9 +1634,9 @@ In particular, the following features are left out of the formal discussion:
     before the exchange settles the transaction with the merchant.  This simple
     extension preserves unlinkability of payments through refresh.
   %\item Indian merchant scenario.  In some markets (such as India), it is more
-  %  likely for the customer to have internet access (via smart phones) than for
+  %  likely for the customer to have Internet access (via smart phones) than for
   %  merchants, who in the case of street vendors often have simple phones
-  %  without internet access or support for apps.  To use Taler in this case,
+  %  without Internet access or support for apps.  To use Taler in this case,
   %  it must be possible 
   \item Timeouts.  In practice, a merchant gives the customer a deadline until
     which the payment for a contract must have been completed, potentially by