Skip to content
Snippets Groups Projects
Commit 4c599503 authored by Peter Schwabe's avatar Peter Schwabe
Browse files

Fixed a few typos.

parent 37041aaa
No related branches found
No related tags found
No related merge requests found
......@@ -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.
......@@ -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$.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment