**diff options**

author | Christian Grothoff <christian@grothoff.org> | 2020-07-22 23:56:52 +0200 |
---|---|---|

committer | Christian Grothoff <christian@grothoff.org> | 2020-07-22 23:56:52 +0200 |

commit | 0e808b648a56e3e4e17d6e03ce776b0b7a422f25 (patch) | |

tree | 59720c0b409f30fc6520526ba7170b0ba60c255c /doc/paper | |

parent | c8a370d9111cee69b6d9b6edc177dcc58eec976a (diff) | |

download | exchange-0e808b648a56e3e4e17d6e03ce776b0b7a422f25.tar.gz exchange-0e808b648a56e3e4e17d6e03ce776b0b7a422f25.tar.bz2 exchange-0e808b648a56e3e4e17d6e03ce776b0b7a422f25.zip |

fix misc typos

Diffstat (limited to 'doc/paper')

-rw-r--r-- | doc/paper/figs/refresh.tex | 4 | ||||

-rw-r--r-- | doc/paper/offline.tex | 10 | ||||

-rw-r--r-- | doc/paper/postquantum.tex | 60 | ||||

-rw-r--r-- | doc/paper/taler.bib | 2 | ||||

-rw-r--r-- | doc/paper/taler.tex | 4 | ||||

-rw-r--r-- | doc/paper/taler_FC2016.txt | 4 | ||||

-rw-r--r-- | doc/paper/taler_FC2017.txt | 4 |

7 files changed, 44 insertions, 44 deletions

diff --git a/doc/paper/figs/refresh.tex b/doc/paper/figs/refresh.tex index 6908527e..7575e453 100644 --- a/doc/paper/figs/refresh.tex +++ b/doc/paper/figs/refresh.tex @@ -134,7 +134,7 @@ \item[$\beta_\gamma$] $:= \big[ B_\gamma^{(i)} \big]_i$ \item[$\cal S$] $:= \left[ S_{DK^{(i)}}( B_\gamma^{(i)} ) \right]_i$ \\ \smallskip - \item[$Z$] Cut-and-choose missmatch information + \item[$Z$] Cut-and-choose mismatch information \end{description} \end{minipage} \end{figure} @@ -165,7 +165,7 @@ minimum height = 10cm ] (h2) at (4, 0) {}; \node[above = 0cm of h1] {Customer}; - \node[above = 0cm of h2] {Exchagne}; + \node[above = 0cm of h2] {Exchange}; \path[->, color = MidnightBlue, very thick, >=stealth] (-5, 4.5) edge diff --git a/doc/paper/offline.tex b/doc/paper/offline.tex index bc4ac0ab..d4ddeb1d 100644 --- a/doc/paper/offline.tex +++ b/doc/paper/offline.tex @@ -74,11 +74,11 @@ $n_\mu$ denote the maximum number of coins returned by a refresh. \smallskip -Let $\iota$ denote a coin idetity paramater that +Let $\iota$ denote a coin idetity parameter that links together the different commitments but must reemain secret from the exchange. -Let $n_\nu$ denote the identity security paramater. +Let $n_\nu$ denote the identity security parameter. An online coin's identity commitment $\Nu$ is the empty string. In the offline coin case, we begin with a reserve public key $R$ and a private identity commitment seed $\nu$. @@ -97,8 +97,8 @@ A coin $(C,\Nu,S)$ consists of an optional set of offline identity commitments $\Nu = \{\Nu_k | k \in \Gamma \}$ an RSA-FDH signature $S = S_d(\FDH(C) * \Pi_{k \in \Gamma} \FDH(\Nu_k))$ by a denomination key $d$. A coin is spent by signing a contract with $C$. The contract must -specify the recipiant merchant and what portion of the value denoted -by the denomination $d$ they recieve. +specify the recipient merchant and what portion of the value denoted +by the denomination $d$ they receive. There was of course a blinding factor $b$ used in the creation of the coin's signature $S$. In addition, there was a private seed $s$ @@ -114,7 +114,7 @@ We generate $\nu = H("Offline" || s)$ from $s$ as well, We begin refresh with a possibly tainted coin $(C,S)$ whose value we wish to save by refreshing it into untainted coins. -In the change sitaution, our coin $(C,\Nu,S)$ was partially spent and +In the change situation, our coin $(C,\Nu,S)$ was partially spent and retains only a part of the value determined by the denominaton $d$. For $x$ amongst the symbols $c$, $C$, $b$, and $s$, diff --git a/doc/paper/postquantum.tex b/doc/paper/postquantum.tex index 9a4f2e9a..9fc73205 100644 --- a/doc/paper/postquantum.tex +++ b/doc/paper/postquantum.tex @@ -95,7 +95,7 @@ when coins are double spent \cite{B??}. Importantly, there are reasons why exchanges must replace coins that do not involve actual financial transactons, like to reissue a coin before the exchange rotates the denomination key that signed it, or -protect users' anonymity after a merchant recieves a coin, but fails +protect users' anonymity after a merchant receives a coin, but fails to process it or deliver good. In Taler, coins can be partially spent by signing with the coin's key @@ -111,7 +111,7 @@ as well as for coin replacement due to denomination key roration. If this protocol were simply a second transaction, then customers would retain information theoreticaly secure anonymity. -In Taler however, we require that the exchange learns acurate income +In Taler however, we require that the exchange learns accurate income information for merchants. If we use a regular transaction, then a customer could conspire to help the merchant hide their income \cite[]{Taler??}. @@ -138,14 +138,14 @@ These provide strong post-quantum security so long as the underlying scheme remains secure; however, these schemes' youth leaves them relatively untested. -Second, we propose a hash based scheme whose anonymity garentee needs +Second, we propose a hash based scheme whose anonymity guarantee needs only the one-way assumption on our hash function. In this scheme, -the vible security paramater is numerically far smaller than in the +the vible security parameter is numerically far smaller than in the key exchange systems, but covers query complexity which we believe suffices. We describe this hash based proof-of-encryption-to-self scheme to -align the discription of all our schemes. +align the description of all our schemes. ... @@ -191,9 +191,9 @@ We label place holders $\eta$, $\lambda$, $\Lambda$, $\mu$, and $\Mu$ for key material involved in post-quantum operations. We view $\Lambda$ and $\Mu$ as public keys with respective private keys $\lambda$ and $\mu$, and -$\eta$ as the symetric key resulting from the key exchange between them. +$\eta$ as the symmetric key resulting from the key exchange between them. -We need effeciently computable functions +We need efficiently computable functions $\CPK$, $\CSK$, $\LPK$, $\LSK$, $\KEX_2$ and $\KEX_3$ such that \begin{itemize} \item $\mu = \CSK(s)$ for a random bitstring $s$, @@ -216,10 +216,10 @@ A coin $(C,\Mu,S)$ consists of a post-quantum public key $\Mu$, and an RSA-FDH signature $S = S_d(C || \Mu)$ by a denomination key $d$. A coin is spent by signing a contract with $C$. The contract must -specify the recipiant merchant and what portion of the value denoted -by the denomination $d$ they recieve. +specify the recipient merchant and what portion of the value denoted +by the denomination $d$ they receive. If $\Mu$ is large, we may replace it by $H(C || \Mu)$ to make signing -contracts more efficent. +contracts more efficient. There was of course a blinding factor $b$ used in the creation of the coin's signature $S$. In addition, there was a private seed $s$ @@ -234,7 +234,7 @@ $$ c = H(\textrm{"Ed25519"} || s) We begin refresh with a possibly tainted coin $(C,\Mu,S)$ that we wish to refresh into $n \le \theta$ untainted coins. -In the change sitaution, our coin $(C,\Mu,S)$ was partially spent and +In the change situation, our coin $(C,\Mu,S)$ was partially spent and retains only a part of the value determined by the denominaton $d$. There is usually no denomination that matchets this risidual value so we must refresh from one coin into $n \le \theta$. @@ -291,8 +291,8 @@ In other words, $c'$, $\mu'$, and $b_j$ are derived from $s_j$, \item For $j = 1 \cdots \kappa$ except $\gamma$: \begin{itemize} \item Create a proof $\lambda_j^{\textrm{proof}}$ that - $\lambda_j$ is compatable with $\Lambda_j$ and $\Mu$. - \item Set a responce tuple + $\lambda_j$ is compatible with $\Lambda_j$ and $\Mu$. + \item Set a response tuple $R_j = (\zeta_j,l_j,\lambda_j,\lambda_j^{\textrm{proof}})$. \end{itemize} \item Send $S_C(R_j \quad\textrm{for}\quad j \ne \gamma )$. @@ -321,7 +321,7 @@ We could optionally save long-term storage space by replacing $\Gamma_*$ with both $\Gamma_{\gamma,0}$ and $S_C(\Eta_{j,i} \quad\textrm{for}\quad j \ne \gamma )$. It's clear this requires the wallet send that signature in some phase, -but also the wallet must accept a phase 2 responce to a phase 1 request. +but also the wallet must accept a phase 2 response to a phase 1 request. \smallskip @@ -356,7 +356,7 @@ This rigidity makes constructing signature schemes with SIDH hard \cite{??SIDHsig??}, but does not impact our use case. We let $\mu$ and $\Mu$ be the SIDH 2-torsion private and public keys, -repectively. We simlarly let $\lambda$ and $\Lambda$ be the +respectively. We similarly let $\lambda$ and $\Lambda$ be the SIDH 3-torsion private and public keys. We envision the 2-torsion secret key generation function $\CSK(s)$ @@ -396,7 +396,7 @@ groups \cite{??,??}, but also a reasuring relationship with NP-hard problems. We again let $\mu$ and $\Mu$ denote the Alice (initator) side the -private and public keys, repectively. We likewise let $\lambda$ +private and public keys, respectively. We likewise let $\lambda$ and $\Lambda$ be the Bob (respondent) private and public keys. % DO IT? Again now, $\CPK$, $\CSK$, $\LPK$, $\LSK$, $\KEX_2$ and $\KEX_3$ @@ -407,12 +407,12 @@ the Ring-LWE key exchange itself being broken because $\lambda_j$ and $\Lambda_j$ are constructed using the public key $\Mu$. First, the polynomial $a$ commonly depends upon $\Mu$, like in -\cite{NewHope}, so unlinkability explicity depends upon the Ring-LWE +\cite{NewHope}, so unlinkability explicitly depends upon the Ring-LWE problem\cite{}. [[ PROOF ??? ]] Second, the reconciliation information in $\Lambda$ might leak additional information about $\lambda$. -[[ LITTERATURE ADDRESSES THIS POINT ??? ]] +[[ LITERATURE ADDRESSES THIS POINT ??? ]] Ring-LWE key exchanges require that both Alice and Bob's keys be ephemeral because the success or failure of the key exchange @@ -423,7 +423,7 @@ schemes\cite{??RLWEsig??}, and this situation impacts us as well. A Taler wallet should control both sides during the refresh protocol, which produces an interesting connundrum. An honest wallet could ensure that the key exchange always succeeds. -If wallets were honest, then one could tune the Ring-LWE paramaters +If wallets were honest, then one could tune the Ring-LWE parameters to leave the probability of failure rather high, saving the exchange bandwidth, storage, and verification time. A dishonest wallet and merchant could conversely search the key space @@ -432,25 +432,25 @@ merchant in tax evasion. [[ IS THE FOLLOWING IMPOSSIBLE ??? ]] -If possible, we should tune the Ring-LWE paramaters to reduce costs +If possible, we should tune the Ring-LWE parameters to reduce costs to the exchange, and boost the unlinkability for the users, while simultaniously % \smallskip % \subsection{Comparson} -At present, the SIDH implemention in \cite{SIDH16} requires about +At present, the SIDH implementation in \cite{SIDH16} requires about one third the key material and 100?? times as much CPU time as the -Ring-LWE implemention in \cite{NewHope}. +Ring-LWE implementation in \cite{NewHope}. [[ We believe this provides a strong reason to continue exploring -paramater choices for Ring-LWE key exchange along with protocol tweaks. +parameter choices for Ring-LWE key exchange along with protocol tweaks. ... ]] \section{Hashed-based one-sided public keys} We now define our hash-based encryption scheme. -Let $\delta$ denote our query security paramater and +Let $\delta$ denote our query security parameter and let $\mu$ be a bit string. For $j \le \kappa$, we define a Merkle tree $T_j$ of height $\delta$ with leaves $\eta_j = H(\mu || "YeyCoins!" || t || j)$ @@ -500,8 +500,8 @@ an attacker to pursue $\eta_j$ alone unless they expect to break curve25519 in the future, either through mathematical advances or by building a quantum computer. -We therefore view $\delta$ as a query complexity paramater whose -optimial setting depends upo nthe strength of the overall protocoll. +We therefore view $\delta$ as a query complexity parameter whose +optimial setting depends upo nthe strength of the overall protocol. \smallskip @@ -510,7 +510,7 @@ We can magnify the effective $\delta$ by using multiple $\eta_j$. ... analysis ... % multiple withdrawals -We believe this provides sufficent post-quantum security for +We believe this provides sufficient post-quantum security for refreshing change. @@ -518,11 +518,11 @@ refreshing change. We noted in \S\ref{subsec:withdrawal} above that exchange might require that initial withdrawals employs a refresh-like operation. -In this scenarion, we refresh from a pseudo-coin $(C,\Mu)$ where +In this scenario, we refresh from a pseudo-coin $(C,\Mu)$ where $C$ is the user's reserve key \cite[??]{Taler} and $\Mu$ s a post-quantum public key kept with $C$. As a result, our hash-based scheme should increase the security -paramater $\delta$ to allow a query for every withdrawal operation. +parameter $\delta$ to allow a query for every withdrawal operation. Instead, ... [[ ??? we propose using a Merkle tree of Alice side Ring-LWE keys, @@ -565,7 +565,7 @@ Crazy pants ideas : Use a larger Mrkle tree with start points seeded throughout -Use a Merkle tree of SWIFFT hash functions becuase +Use a Merkle tree of SWIFFT hash functions because their additive homomorphic property lets you keep the form of a polynomial diff --git a/doc/paper/taler.bib b/doc/paper/taler.bib index a46c9384..14b57092 100644 --- a/doc/paper/taler.bib +++ b/doc/paper/taler.bib @@ -413,7 +413,7 @@ issn="1432-1378", volume="16", number="3", pages="185--215", - abstract="We introduce a new class of computational problems which we call the ``one-more-RSA-inversion'' problems. Our main result is that two problems in this class, which we call the chosen-target and known-target inversion problems, respectively, have polynomially equivalent computational complexity. We show how this leads to a proof of security for Chaum's RSA-based blind signature scheme in the random oracle model based on the assumed hardness of either of these problems. We define and prove analogous results for ``one-more-discrete-logarithm'' problems. Since the appearence of the preliminary version of this paper, the new problems we have introduced have found other uses as well.", + abstract="We introduce a new class of computational problems which we call the ``one-more-RSA-inversion'' problems. Our main result is that two problems in this class, which we call the chosen-target and known-target inversion problems, respectively, have polynomially equivalent computational complexity. We show how this leads to a proof of security for Chaum's RSA-based blind signature scheme in the random oracle model based on the assumed hardness of either of these problems. We define and prove analogous results for ``one-more-discrete-logarithm'' problems. Since the appearance of the preliminary version of this paper, the new problems we have introduced have found other uses as well.", issn="1432-1378", doi="10.1007/s00145-002-0120-1", doi_url="http://dx.doi.org/10.1007/s00145-002-0120-1", diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index e1a120c9..45eeacdf 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -1243,7 +1243,7 @@ certification process. We assume the exchange operates honestly when discussing taxability. We feel this assumption is warranted mostly because a Taler exchange requires licenses to operate as a financial institution, which it -risks loosing if it knowingly facilitates tax evasion. +risks losing if it knowingly facilitates tax evasion. We also expect an auditor monitors the exchange similarly to how government regulators monitor financial institutions. In fact, our auditor software component gives the auditor read access @@ -1772,7 +1772,7 @@ currency. A tax auditor can then request the merchant to reveal (meaningful) details about the business transaction ($\mathcal{D}$, $a$, $p$, $r$), including proof that applicable taxes were paid. -If a merchant is not able to provide theses values, they can be +If a merchant is not able to provide these values, they can be subjected to financial penalties by the state in relation to the amount transferred by the traditional currency transfer. diff --git a/doc/paper/taler_FC2016.txt b/doc/paper/taler_FC2016.txt index 80e590c3..176e9c75 100644 --- a/doc/paper/taler_FC2016.txt +++ b/doc/paper/taler_FC2016.txt @@ -118,7 +118,7 @@ is less a currency and more an open protocol for creating new currencies. So what? And why do altcoins become a ponzi scheme? (Noting that you do not say that they might become one, rather that they do). -> We have adjusted that langauge, as some like Dogecoin have removed +> We have adjusted that language, as some like Dogecoin have removed > the 21 billion BTC cap to reduce the ponzi-like tendencies. > There remains a large trend towards ponzi schemes in the altcoin > world however, amusingly noted by https://ponzico.win/ and @@ -307,7 +307,7 @@ scheme suggests that a any transfers of value should be taxed. However, the issuing protocol in 4.1 can be abused to transfer a coin, without paying tax, and in an unlikable manner. -> Technically 4.1 is not transfering a coin, as it is issuing a coin. +> Technically 4.1 is not transferring a coin, as it is issuing a coin. > Again, the loophole is/was discussed in the paper. The party withdrawing the coin diff --git a/doc/paper/taler_FC2017.txt b/doc/paper/taler_FC2017.txt index 66f8560a..f66530c6 100644 --- a/doc/paper/taler_FC2017.txt +++ b/doc/paper/taler_FC2017.txt @@ -220,11 +220,11 @@ wanting this features is that it enables refunds from a merchant that later can be refreshed into "clean" coins that are unlinkable to the refunded coins. The protocol is based on what appears to be a standard cut-and-choose approach, which does not appear to be particularly -novel. On the postive side, the problem appears a natural and if it +novel. On the positive side, the problem appears a natural and if it hasn't been done before certainly useful. On the negative side, since the paper does not contain any formal definitions, or even semi-formal specifications of the desiderata, it is very hard to understand what -actually is acheived. Furthermore, no proofs of security are given, +actually is achieved. Furthermore, no proofs of security are given, and even the protocol is hard to fully understand. As such, I would suggest the authors to first formalize their approach and resubmitting. |