From 4c599503d00b442067da9c78fc3bb04aff3ed08e Mon Sep 17 00:00:00 2001
From: Peter Schwabe <peter@cryptojedi.org>
Date: Mon, 19 Aug 2019 00:05:53 +0200
Subject: [PATCH] Fixed a few typos.

---
 conclusion.tex |  8 ++++----
 intro.tex      | 10 +++++-----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/conclusion.tex b/conclusion.tex
index d646cbb..0a8053f 100644
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -17,7 +17,7 @@ The analysis in this paper shows that using prime-order Weierstraß curves
 with complete addition formulas is between $\approx 1.5$ times and $\approx 2.9$
 times slower than using state-of-the-art Montgomery curve arithmetic.
 In an area where even a $10$\% improvement in performance is often
-considered important an worth publication in major venues, this is
+considered important and worth publication in major venues, this is
 a pretty heavy price to pay; at least for some applications that 
 are bottlenecked by ECC performance.
 
@@ -25,11 +25,11 @@ However, for applications that primarily aim at simplicity and safety against
 subgroup attacks, the performance penalty might be acceptable. 
 This point of view is supported, for example, also by the fact that
 the attempt to standardize the high-performance ``Four$\mathbb{Q}$'' 
-curve~\cite{CL15} in CFRG~\cite{LLB17} was only very short lived\footnote{For the full discussion, see \url{https://mailarchive.ietf.org/arch/msg/cfrg/sCqu86nFiAw_9beBXVqBM_zES_k.}}. 
+curve~\cite{CL15} in CFRG~\cite{LLB17} was only very short lived.
 The discussion around this proposal acknowledged that Four$\mathbb{Q}$
 offers considerably faster arithmetic than Curve25519, but questioned
-that there are any applications that really need that performance.
+that there are any applications that really need that performance\footnote{For the full discussion, see \url{https://mailarchive.ietf.org/arch/msg/cfrg/sCqu86nFiAw_9beBXVqBM_zES_k.}}.
 
 In our opinion, for the design of new protocols the best compromise 
-is to use Curve25519 in twisted Edwards form with the Ristretto encoding
+remains Curve25519 in twisted Edwards form with the Ristretto encoding
 to remove the non-trivial cofactor.
diff --git a/intro.tex b/intro.tex
index b323de1..dbad91f 100644
--- a/intro.tex
+++ b/intro.tex
@@ -187,7 +187,7 @@ curves.
   \subheading{Related work.}
   The most relevant related work for this paper can be grouped in two
   categories: papers presenting optimized implementations of Curve25519
-  and papers estimating performance of complete group addition on Weierstraß curves.
+  and papers investigating performance of complete group addition on Weierstraß curves.
 
   In the first category, the directly related papers present results for
   optimized scalar multiplication on Curve25519 targeting the same microarchitectures
@@ -220,19 +220,19 @@ curves.
   the complete formulas from~\cite{RCB16}. They claim that their results are
   ``competitive with current literature'', but also state that 
   ``it is not straightforward to do a well-founded comparison among works in the literature''.
-  This is because hardware implementations have a much larger design space, with
-  not only tradeoffs between area and speed, but also flexibility with regards
+  This is because hardware implementations have a much larger design space,
+  not only with tradeoffs between area and speed, but also flexibility with regards
   to the supported elliptic curves (e.g., through different curve shapes or 
   support for specialized or generic field arithmetic).
   Finally, in~\cite{SM17} Susella and Montrasio estimate performance of different
   scalar-multiplication approaches. They report estimates in terms of multiplications
   per scalar bit, assuming that 
-  assume that multiplication costs as much as squaring and multiplication by (small) constants, 
+  multiplication costs as much as squaring and multiplication by (small) constants, 
   and that addition costs 10\% of a multiplication.
   In this metric the ladder from \cite{SM17} is very slightly cheaper at $19.1$ than
   scalar multiplication using the formulas from~\cite{RCB16} at $19.33$. 
   However, if we understand correctly, the estimates for~\cite{RCB16} are computed
-  without taking into account \emph{signed}-window scalar multiplication.
+  without taking into account \emph{signed} fixed-window scalar multiplication.
   In this metric, the Montgomery ladder used in X25519 software would come at a cost
   of~$10.8$.
 
-- 
GitLab