From 0e808b648a56e3e4e17d6e03ce776b0b7a422f25 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Wed, 22 Jul 2020 23:56:52 +0200 Subject: fix misc typos --- doc/paper/postquantum.tex | 60 +++++++++++++++++++++++------------------------ 1 file changed, 30 insertions(+), 30 deletions(-) (limited to 'doc/paper/postquantum.tex') diff --git a/doc/paper/postquantum.tex b/doc/paper/postquantum.tex index 9a4f2e9a8..9fc73205b 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 -- cgit v1.2.3