saymrwulf/risc0-curve25519-dalek-source
1
0
Fork 0
mirror of https://github.com/saymrwulf/risc0-curve25519-dalek-source.git synced 2026-09-04 20:03:40 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge branch 'release/0.16.3'

Browse source
This commit is contained in:
Henry de Valence 2018-04-09 12:26:54 -07:00
commit d44a0c9e04
15 changed files with 4058 additions and 607 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
Cargo.toml
View file

@ -1,6 +1,6 @@
[package]
name = "curve25519-dalek"
version = "0.16.2"
version = "0.16.3"
authors = ["Isis Lovecruft <isis@patternsinthevoid.net>",
"Henry de Valence <hdevalence@hdevalence.ca>"]
readme = "README.md"
@ -41,6 +41,7 @@ harness = false
# match exactly, since the build.rs uses the crate itself as a library.
[dependencies]
byteorder = "1"
digest = "0.7"
generic-array = "0.9"
clear_on_drop = "=0.2.3"
@ -49,6 +50,7 @@ serde = { version = "1.0", optional = true }
rand = { version = "0.4", optional = true }
[build-dependencies]
byteorder = "1"
digest = "0.7"
generic-array = "0.9"
clear_on_drop = "=0.2.3"

11
build.rs
View file

@ -5,6 +5,7 @@
#![allow(non_snake_case)]
#![allow(dead_code)]
extern crate byteorder;
extern crate clear_on_drop;
extern crate core;
extern crate digest;
@ -58,7 +59,7 @@ mod scalar_mul;
use edwards::EdwardsBasepointTable;
use curve_models::AffineNielsPoint;
use scalar_mul::window::OddLookupTable;
use scalar_mul::window::NafLookupTable8;
fn main() {
// Enable the "precomputed_tables" feature in the main build stage
@ -85,7 +86,7 @@ use edwards::EdwardsBasepointTable;
use curve_models::AffineNielsPoint;
use scalar_mul::window::LookupTable;
use scalar_mul::window::OddLookupTable;
use scalar_mul::window::NafLookupTable8;
/// Table containing precomputed multiples of the Ed25519 basepoint \\\\(B = (x, 4/5)\\\\).
pub const ED25519_BASEPOINT_TABLE: EdwardsBasepointTable = ED25519_BASEPOINT_TABLE_INNER_DOC_HIDDEN;
@ -100,13 +101,13 @@ pub const ED25519_BASEPOINT_TABLE_INNER_DOC_HIDDEN: EdwardsBasepointTable = {:?}
// Now generate AFFINE_ODD_MULTIPLES_OF_BASEPOINT
let B = &constants::ED25519_BASEPOINT_POINT;
let odd_multiples = OddLookupTable::<AffineNielsPoint>::from(B);
let odd_multiples = NafLookupTable8::<AffineNielsPoint>::from(B);
f.write_all(
format!(
"\n
/// Odd multiples of the basepoint `[B, 3B, 5B, 7B, 9B, 11B, 13B, 15B]`.
pub(crate) const AFFINE_ODD_MULTIPLES_OF_BASEPOINT: OddLookupTable<AffineNielsPoint> = {:?};
/// Odd multiples of the basepoint `[B, 3B, 5B, 7B, 9B, 11B, 13B, 15B, ..., 127B]`.
pub(crate) const AFFINE_ODD_MULTIPLES_OF_BASEPOINT: NafLookupTable8<AffineNielsPoint> = {:?};
\n\n",
&odd_multiples
).as_bytes(),

464
docs/avx2-notes.md Normal file
View file

@ -0,0 +1,464 @@
An implementation of group operations on the twisted Edwards form of
Curve25519, using AVX2 to implement the 4-way parallel formulas of
Hisil, Wong, Carter, and Dawson (HWCD).
Their 2008 paper [_Twisted Edwards Curves Revisited_][hwcd08], which
introduced the extended coordinates used in other parts of `-dalek`,
also describes 4-way parallel formulas for point addition and
doubling:
* a unified addition algorithm taking an effective \\(2\mathbf M +
1\mathbf D\\);
* a doubling algorithm taking an effective \\(1\mathbf M + 1\mathbf
S\\);
* a dedicated (i.e., for distinct points) addition algorithm taking
an effective \\(2 \mathbf M \\).
Here \\(\mathbf M\\) and \\(\mathbf S\\) represent the cost of
multiplication and squaring of generic field elements and \\(\mathbf
D\\) represents the cost of multiplication by a curve constant.
These formulas do not seem to have been implemented using SIMD before.
A 2015 paper by Hernández and López mentions using AVX2 for the X25519
Montgomery ladder, but neither the paper nor the code are publicly
available, and it apparently gives only a [slight speedup][avx2trac].
The 2008 HWCD paper also describes and analyzes a 2-wide variant of the
Montgomery ladder (for comparison with parallel Edwards formulas); this
strategy was used in 2015 by Tung Chou's `sandy2x` implementation, which
used a 2-wide field implementation in 128-bit vector registers.
Curiously, however, although the [`sandy2x` paper][sandy2x] also
implements Edwards arithmetic, and cites the HWCD paper, it doesn't
mention the parallel formulas from HWCD, suggesting that they have been
overlooked for software implementations.
The notes below describe a tweak to the \\( 2\mathbf M + 1\mathbf D \\)
unified addition formulas to give \\( 2\mathbf M \\) readdition with
\\(1\mathbf D\\) precomputation, and a tweak to the doubling formulas to
avoid an extra reduction. These tweaked formulas are the ones used by
the `avx2` backend of `curve25519-dalek`.
# Parallel formulas in HWCD'08
The doubling formula is presented in the HWCD paper as follows:
| Cost | Processor 1 | Processor 2 | Processor 3 | Processor 4 |
|------------------|--------------------------------|--------------------------------|--------------------------------|--------------------------------|
| | idle | idle | idle | \\( R\_1 \gets X\_1 + Y\_1 \\) |
| \\(1\mathbf S\\) | \\( R\_2 \gets X\_1\^2 \\) | \\( R\_3 \gets Y\_1\^2 \\) | \\( R\_4 \gets Z\_1\^2 \\) | \\( R\_5 \gets R\_1\^2 \\) |
| | \\( R\_6 \gets R\_2 + R\_3 \\) | \\( R\_7 \gets R\_2 - R\_3 \\) | \\( R\_4 \gets 2 R\_4 \\) | idle |
| | idle | \\( R\_1 \gets R\_4 + R\_7 \\) | idle | \\( R\_2 \gets R\_6 - R\_5 \\) |
| \\(1\mathbf M\\) | \\( X\_3 \gets R\_1 R\_2 \\) | \\( Y\_3 \gets R\_6 R\_7 \\) | \\( T\_3 \gets R\_2 R\_6 \\) | \\( Z\_3 \gets R\_1 R\_7 \\) |
and the unified addition algorithm is presented as follows:
| Cost | Processor 1 | Processor 2 | Processor 3 | Processor 4 |
|------------------|--------------------------------|--------------------------------|--------------------------------|--------------------------------|
| | \\( R\_1 \gets Y\_1 - X\_1 \\) | \\( R\_2 \gets Y\_2 - X\_2 \\) | \\( R\_3 \gets Y\_1 + X\_1 \\) | \\( R\_4 \gets Y\_2 + X\_2 \\) |
| \\(1\mathbf M\\) | \\( R\_5 \gets R\_1 R\_2 \\) | \\( R\_6 \gets R\_3 R\_4 \\) | \\( R\_7 \gets T\_1 T\_2 \\) | \\( R\_8 \gets Z\_1 Z\_2 \\) |
| \\(1\mathbf D\\) | idle | idle | \\( R\_7 \gets k R\_7 \\) | \\( R\_8 \gets 2 R\_8 \\) |
| | \\( R\_1 \gets R\_6 - R\_5 \\) | \\( R\_2 \gets R\_8 - R\_7 \\) | \\( R\_3 \gets R\_8 + R\_7 \\) | \\( R\_4 \gets R\_6 + R\_5 \\) |
| \\(1\mathbf M\\) | \\( X\_3 \gets R\_1 R\_2 \\) | \\( Y\_3 \gets R\_3 R\_4 \\) | \\( T\_3 \gets R\_1 R\_4 \\) | \\( Z\_3 \gets R\_2 R\_3 \\) |
Here \\( k = 2d \\) is a curve constant.
For a software implementation, each processor's operations are too
low-latency to parallelize across threads. However, the main cost
is in the multiplication and squaring steps, which are uniform, while
the divergent steps involve inexpensive additions and subtractions.
This means we can use SIMD to implement the expensive portions in
parallel, and handle the instruction divergence on the inexpensive parts
using masking.
The remaining obstacle to parallelism is the multiplication by the curve
constant \\(k = 2d\\). In the Curve25519 case, this is
$$ k \equiv 2 \frac{-121665}{121666} \\ \equiv 16295367250680780974490674513165176452449235426866156013048779062215315747161 \pmod p. $$
HWCD suggest parallelising this step by breaking \\(k\\) into four
parts as \\(k = k_0 + 2\^n k_1 + 2\^{2n} k_2 + 2\^{3n} k_3 \\) and
computing \\(k_i R_7 \\) in parallel. However, this would be
somewhat awkward in our case, since we would normally represent
\\(k\\) as \\( 10 \\) 32-bit limbs, and \\(10 \\) is not divisible
by \\(4\\), so we would need a specialized routine to perform a
vectorized multiplication by 64-bit constants.
Instead, since we are working projectively, we can multiply
\\(R_7\\) by \\( -2\cdot 121665 \\) and multiply the other three
variables by \\(121666\\). This trick was suggested by Mike
Hamburg. Ignoring the sign for the moment, since
\\(2 \cdot 121666 < 2\^{18}\\), all these constants fit in 32 bits,
so (up to sign) this can be done in parallel as four multiplications
by small constants \\( (121666, 121666, 2\cdot 121665, 2\cdot 121666) \\).
How do we handle the sign?
Since we're primarily interested in Ristretto performance, not
Curve25519 performance, we could alternately work on the
\\(4\\)-isogenous "IsoEd25519" curve, which has \\(d = 121665\\).
However, this would only save the negation step, since multiplying
one field element by a 32-bit constant is not much easier than
multiplying four field elements by 32-bit constants, and it would
prevent accelerating Curve25519, so we don't make this choice.
Instead, we just negate one lane, and move the \\(1 \mathbf D\\)
into precomputation (see below).
# Tweaked formulas
After tweaking the formulas as described above, we obtain the
following. To avoid confusion with the original HWCD formulas,
temporary variables are named \\(S\\) instead of \\(R\\) and are in
static single-assignment form.
## Addition
This implementation only implements readdition, but the tweaked addition
formulas are described first. To add points \\(P_1 = (X_1 : Y_1 : Z_1 :
T_1) \\) and \\(P_2 = (X_2 : Y_2 : Z_2 : T_2 ) \\), we compute
$$
\begin{aligned}
S\_0 &\gets Y\_1 - X\_1 \\\\
S\_1 &\gets Y\_1 + X\_1 \\\\
S\_2 &\gets Y\_2 - X\_2 \\\\
S\_3 &\gets Y\_2 + X\_2
\end{aligned}
$$
$$
\begin{aligned}
S\_4 &\gets S\_0 S\_2 \\\\
S\_5 &\gets S\_1 S\_3 \\\\
S\_6 &\gets Z\_1 Z\_2 \\\\
S\_7 &\gets T\_1 T\_2
\end{aligned}
$$
$$
\begin{aligned}
S\_8 &\gets S\_4 \cdot 121666 \\\\
S\_9 &\gets S\_5 \cdot 121666 \\\\
S\_{10} &\gets S\_6 \cdot 2 \cdot 121666 \\\\
S\_{11} &\gets S\_7 \cdot -2 \cdot 121665
\end{aligned}
$$
$$
\begin{aligned}
S\_{12} &\gets S\_9 - S\_8 \\\\
S\_{13} &\gets S\_9 + S\_8 \\\\
S\_{14} &\gets S\_{10} - S\_{11} \\\\
S\_{15} &\gets S\_{10} + S\_{11}
\end{aligned}
$$
$$
\begin{aligned}
X\_3 &\gets S\_{12} S\_{14} \\\\
Y\_3 &\gets S\_{15} S\_{13} \\\\
Z\_3 &\gets S\_{15} S\_{14} \\\\
T\_3 &\gets S\_{12} S\_{13}
\end{aligned}
$$
to obtain \\( P\_3 = (X\_3 : Y\_3 : Z\_3 : T\_3) = P\_1 + P\_2 \\).
## Readdition
If the point \\( P_2 = (X\_2 : Y\_2 : Z\_2 : T\_2) \\) is fixed, we can precompute
$$
\begin{aligned}
S\_2 &\gets Y\_2 - X\_2 \\\\
S\_3 &\gets Y\_2 + X\_2
\end{aligned}
$$
$$
\begin{aligned}
S\_2' &\gets S\_2 \cdot 121666 \\\\
S\_3' &\gets S\_3 \cdot 121666 \\\\
Z\_2' &\gets Z\_2 \cdot 2 \cdot 121666 \\\\
T\_2' &\gets T\_2 \cdot -2 \cdot 121665 \\\\
\end{aligned}
$$
to obtain the `CachedPoint` \\( (S\_2', S\_3', Z\_2', T\_2') \\).
This precomputation is essentially the same as that suggested in
§3.1 of HWCD, with the difference that the multiplication by the curve
constant \\( -121665 / 121666 \\) is spread over all four
coordinates, to allow a vectorized computation of four
multiplications of small constants instead of a serial computation
of multiplication by a large constant.
To perform readdition of \\(P_1 = (X_1 : Y_1 : Z_1 : T_1) \\) and
\\(P_2 = (S\_2', S\_3', Z\_2', T\_2') \\), we compute
$$
\begin{aligned}
S\_0 &\gets Y\_1 - X\_1 \\\\
S\_1 &\gets Y\_1 + X\_1
\end{aligned}
$$
$$
\begin{aligned}
S\_8 &\gets S\_0 S\_2' \\\\
S\_9 &\gets S\_1 S\_3' \\\\
S\_{10} &\gets Z\_1 Z\_2' \\\\
S\_{11} &\gets T\_1 T\_2'
\end{aligned}
$$
$$
\begin{aligned}
S\_{12} &\gets S\_9 - S\_8 \\\\
S\_{13} &\gets S\_9 + S\_8 \\\\
S\_{14} &\gets S\_{10} - S\_{11} \\\\
S\_{15} &\gets S\_{10} + S\_{11}
\end{aligned}
$$
$$
\begin{aligned}
X\_3 &\gets S\_{12} S\_{14} \\\\
Y\_3 &\gets S\_{15} S\_{13} \\\\
Z\_3 &\gets S\_{15} S\_{14} \\\\
T\_3 &\gets S\_{12} S\_{13}
\end{aligned}
$$
to obtain \\( P\_3 = (X\_3 : Y\_3 : Z\_3 : T\_3) = P\_1 + P\_2 \\).
Compared to the addition formulas above, this saves \\( 1\mathbf D \\).
## Doubling
To double a point \\( P = (X\_1 : Y\_1 : Z\_1 : T\_1) \\), we compute
$$ S\_0 \gets X\_1 + Y\_1 $$
$$
\begin{aligned}
S\_1 &\gets X\_1\^2 \\\\
S\_2 &\gets Y\_1\^2 \\\\
S\_3 &\gets Z\_1\^2 \\\\
S\_4 &\gets S\_0\^2
\end{aligned}
$$
$$
\begin{aligned}
S\_5 &\gets S\_1 + S\_2 \\\\
S\_6 &\gets S\_1 - S\_2 \\\\
S\_7 &\gets 2S\_3 \\\\
S\_8 &\gets S\_7 + S\_6 = S\_1 + 2S\_3 - S\_2 \\\\
S\_9 &\gets S\_5 - S\_4 = S\_1 + S\_2 - S\_4
\end{aligned}
$$
$$
\begin{aligned}
X\_3 &\gets S\_8 S\_9 \\\\
Y\_3 &\gets S\_5 S\_6 \\\\
Z\_3 &\gets S\_8 S\_6 \\\\
T\_3 &\gets S\_5 S\_9
\end{aligned}
$$
to obtain \\( P\_3 = (X\_3 : Y\_3 : Z\_3 : T\_3) = [2]P\_1 \\).
Unlike the (re)addition formulas, the divergent parts of these formulas
are less nice. However, with some careful bounds-juggling, it is
possible to implement them without inserting extra carry chains, as
described below.
# Field element representation
Our strategy is to implement 4-wide multiplication and squaring by
wordslicing, using one 64-bit AVX2 lane for each field element. Field
elements are represented in the usual way as 10 `u32` limbs in radix
\\(25.5\\) (i.e., alternating between \\(2\^{26}\\) for even limbs and
\\(2\^{25}\\) for odd limbs). This has the effect that passing between
the parallel 32-bit AVX2 representation and the serial 64-bit
representation (which uses radix \\(2^{51}\\)) amounts to regrouping
digits.
The field element representation is oriented around the AVX2
`vpmuluqdq` instruction, which multiplies the low 32 bits of each
64-bit lane of each operand to produce a 64-bit result.
```text,no_run
(a1 ?? b1 ?? c1 ?? d1 ??)
(a2 ?? b2 ?? c2 ?? d2 ??)
(a1*a2 b1*b2 c1*c2 d1*d2)
```
To unpack 32-bit values into 64-bit lanes for use in multiplication
it would be convenient to use the `vpunpck[lh]dq` instructions,
which unpack and interleave the low and high 32-bit lanes of two
source vectors.
However, the AVX2 versions of these instructions are designed to
operate only within 128-bit lanes of the 256-bit vectors, so that
interleaving the low lanes of `(a0 b0 c0 d0 a1 b1 c1 d1)` with zero
gives `(a0 00 b0 00 a1 00 b1 00)`. Instead, we pre-shuffle the data
layout as `(a0 b0 a1 b1 c0 d0 c1 d1)` so that we can unpack the
"low" and "high" parts as
```text,no_run
(a0 00 b0 00 c0 00 d0 00)
(a1 00 b1 00 c1 00 d1 00)
```
The data layout for a vector of four field elements \\( (a,b,c,d)
\\) with limbs \\( a_0, a_1, \ldots, a_9 \\) is as `[u32x8; 5]` in
the form
```text,no_run
(a0 b0 a1 b1 c0 d0 c1 d1)
(a2 b2 a3 b3 c2 d2 c3 d3)
(a4 b4 a5 b5 c4 d4 c5 d5)
(a6 b6 a7 b7 c6 d6 c7 d7)
(a8 b8 a9 b9 c8 d8 c9 d9)
```
Since this breaks cleanly into two 128-bit lanes, it may be possible
to adapt it to 128-bit vector instructions such as NEON without too
much difficulty. Going the other direction, to extend this to AVX512,
we could either run two point operations in parallel in lower and upper
halves of the registers, or use 2-way parallelism within a field operation.
# Handling the Doubling Formulas
The non-parallel portion of the doubling formulas is
$$
\begin{aligned}
S\_5 &\gets S\_1 + S\_2 \\\\
S\_6 &\gets S\_1 - S\_2 \\\\
S\_7 &\gets 2S\_3 \\\\
S\_8 &\gets S\_7 + S\_6 = S\_1 + 2S\_3 - S\_2 \\\\
S\_9 &\gets S\_5 - S\_4 = S\_1 + S\_2 - S\_4
\end{aligned}
$$
Performing too many intermediate additions and subtractions grows
the bounds beyond what is allowed as input to multiplication,
forcing an extra carry pass. However, it is just possible to avoid
this by rearranging signs.
Assume that the bounds on the limbs of each field element are
parameterized by \\( b \in \mathbb R \\) representing the excess
bits, so that each limb is bounded by either
\\( 2\^{25+b} \\) or \\( 2\^{26+b} \\).
The multiplication routine requires that its inputs are bounded by
\\( b < 1.75 \\), in order to fit a multiplication by \\( 19 \\)
into 32 bits. Since \\( \lg 19 < 4.25 \\), \\( 19x < 2\^{32} \\)
when \\( x < 2\^{27.75} = 2\^{26 + 1.75} \\). However, this is only
required for one of the inputs; the other can grow up to \\( b < 2.5
\\).
Computing \\( (S\_5, S\_6, S\_8, S\_9 ) \\) as
$$
\begin{matrix}
& S\_1 & S\_1 & S\_1 & S\_1 \\\\
+& S\_2 & & & S\_2 \\\\
+& & & S\_3 & \\\\
+& & & S\_3 & \\\\
+& & 2p & 2p & 2p \\\\
-& & S\_2 & S\_2 & \\\\
-& & & & S\_4 \\\\
=& S\_5 & S\_6 & S\_8 & S\_9
\end{matrix}
$$
results in bit-excesses \\( (1.00, 1.59, 2.33, 2.00)\\) for
\\( (S\_5, S\_6, S\_8, S\_9 ) \\). The products we want to compute
are then
$$
\begin{aligned}
X\_3 &\gets S\_8 S\_9 \leftrightarrow (2.33, 2.00) \\\\
Y\_3 &\gets S\_5 S\_6 \leftrightarrow (1.00, 1.59) \\\\
Z\_3 &\gets S\_8 S\_6 \leftrightarrow (2.33, 1.59) \\\\
T\_3 &\gets S\_5 S\_9 \leftrightarrow (1.00, 2.00)
\end{aligned}
$$
which are too large. However, if we flip the sign of \\( S\_4 =
S\_0\^2 \\) during squaring, so that we output \\(S\_4' = -S\_4
\pmod p\\), then we can compute
$$
\begin{matrix}
& S\_1 & S\_1 & S\_1 & S\_1 \\\\
+& S\_2 & & & S\_2 \\\\
+& & & S\_3 & \\\\
+& & & S\_3 & \\\\
+& & & & S\_4' \\\\
+& & 2p & 2p & \\\\
-& & S\_2 & S\_2 & \\\\
=& S\_5 & S\_6 & S\_8 & S\_9
\end{matrix}
$$
resulting in bit-excesses \\( (1.00, 1.59, 2.33, 1.59)\\) for
\\( (S\_5, S\_6, S\_8, S\_9 ) \\). The products we want to compute
are then
$$
\begin{aligned}
X\_3 &\gets S\_8 S\_9 \leftrightarrow (2.33, 1.59) \\\\
Y\_3 &\gets S\_5 S\_6 \leftrightarrow (1.00, 1.59) \\\\
Z\_3 &\gets S\_8 S\_6 \leftrightarrow (2.33, 1.59) \\\\
T\_3 &\gets S\_5 S\_9 \leftrightarrow (1.00, 1.59)
\end{aligned}
$$
whose right-hand sides are all bounded with \\( b < 1.75 \\) and
whose left-hand sides are all bounded with \\( b < 2.5 \\).
# Comparison to non-vectorized formulas
HWCD also suggest using a mixed representation, passing between \\(
\mathbb P\^3 \\) "extended" coordinates and \\( \mathbb P\^2 \\)
"projective" coordinates, where doubling is slightly cheaper (saving
about \\(\mathbf 1M\\). This approach is used for the
non-vectorized `u32` and `u64` backends, and more
details on the different coordinate systems can be found in the
`curve_models` module documentation.
This optimization is not compatible with the parallel formulas, which are
therefore slightly less efficient when counting the total number of
field multiplications and squarings. In particular, vectorized doublings
are less efficient than serial doublings.
In addition, the parallel formulas can only use a \\( 32 \times 32
\rightarrow 64 \\)-bit integer multiplier, so the speedup from
vectorization must overcome the disadvantage of losing the \\( 64
\times 64 \rightarrow 128\\)-bit (serial) integer multiplier.
When compiling with AVX512VL, LLVM is able to use the extra
`ymm16..ymm31` registers to reduce register pressure, and avoid
spills during field multiplication. This gives a small but
noticeable speedup.
Another concern with AVX2 is that currently-available Intel processors
(particularly Skylake and Skylake-X microarchitectures) perform thermal
throttling when using wide vector instructions. For a mixed workload,
where point operations are interspersed with other tasks, this can
reduce overall performance. This probably means that this
implementation is not suitable for basic applications, like signatures,
but could still be worthwhile for complex applications, like
zero-knowledge proofs, which do enough work to make it worthwhile.
On AMD's Zen microarchitecture, thermal throttling is not a concern,
since AVX2 is implemented at half rate, so there is no penalty for mixed
workloads (but also no speedup).
[sandy2x]: https://eprint.iacr.org/2015/943.pdf
[avx2trac]: https://trac.torproject.org/projects/tor/ticket/8897#comment:28
[hwcd08]: https://www.iacr.org/archive/asiacrypt2008/53500329/53500329.pdf

3450
src/backend/avx2/constants.rs
View file

File diff suppressed because it is too large Load diff

19
src/backend/avx2/edwards.rs
View file

@ -22,7 +22,7 @@ use subtle::ConditionallyAssignable;
use subtle::Choice;
use edwards;
use scalar_mul::window::{LookupTable, OddLookupTable};
use scalar_mul::window::{LookupTable, NafLookupTable5, NafLookupTable8};
use traits::Identity;
@ -294,7 +294,7 @@ impl<'a> From<&'a edwards::EdwardsPoint> for LookupTable<CachedPoint> {
}
}
impl<'a> From<&'a edwards::EdwardsPoint> for OddLookupTable<CachedPoint> {
impl<'a> From<&'a edwards::EdwardsPoint> for NafLookupTable5<CachedPoint> {
fn from(point: &'a edwards::EdwardsPoint) -> Self {
let A = ExtendedPoint::from(*point);
let mut Ai = [CachedPoint::from(A); 8];
@ -303,7 +303,20 @@ impl<'a> From<&'a edwards::EdwardsPoint> for OddLookupTable<CachedPoint> {
Ai[i + 1] = (&A2 + &Ai[i]).into();
}
// Now Ai = [A, 3A, 5A, 7A, 9A, 11A, 13A, 15A]
OddLookupTable(Ai)
NafLookupTable5(Ai)
}
}
impl<'a> From<&'a edwards::EdwardsPoint> for NafLookupTable8<CachedPoint> {
fn from(point: &'a edwards::EdwardsPoint) -> Self {
let A = ExtendedPoint::from(*point);
let mut Ai = [CachedPoint::from(A); 64];
let A2 = A.double();
for i in 0..63 {
Ai[i + 1] = (&A2 + &Ai[i]).into();
}
// Now Ai = [A, 3A, 5A, 7A, 9A, 11A, 13A, 15A, ..., 127A]
NafLookupTable8(Ai)
}
}

467
src/backend/avx2/mod.rs
View file

@ -8,471 +8,8 @@
// - Isis Agora Lovecruft <isis@patternsinthevoid.net>
// - Henry de Valence <hdevalence@hdevalence.ca>
//! An implementation of group operations on the twisted Edwards form of
//! Curve25519, using AVX2 to implement the 4-way parallel formulas of
//! Hisil, Wong, Carter, and Dawson (HWCD).
//!
//! Their 2008 paper [_Twisted Edwards Curves Revisited_][hwcd08], which
//! introduced the extended coordinates used in other parts of `-dalek`,
//! also describes 4-way parallel formulas for point addition and
//! doubling:
//!
//! * a unified addition algorithm taking an effective \\(2\mathbf M +
//! 1\mathbf D\\);
//!
//! * a doubling algorithm taking an effective \\(1\mathbf M + 1\mathbf
//! S\\);
//!
//! * a dedicated (i.e., for distinct points) addition algorithm taking
//! an effective \\(2 \mathbf M \\).
//!
//! Here \\(\mathbf M\\) and \\(\mathbf S\\) represent the cost of
//! multiplication and squaring of generic field elements and \\(\mathbf
//! D\\) represents the cost of multiplication by a curve constant.
//!
//! Currently, this implementation uses only the first two algorithms.
//!
//! # Parallel formulas
//!
//! The doubling formula is presented in the HWCD paper as follows:
//!
//! | Cost | Processor 1 | Processor 2 | Processor 3 | Processor 4 |
//! |------------------|--------------------------------|--------------------------------|--------------------------------|--------------------------------|
//! | | idle | idle | idle | \\( R\_1 \gets X\_1 + Y\_1 \\) |
//! | \\(1\mathbf S\\) | \\( R\_2 \gets X\_1\^2 \\) | \\( R\_3 \gets Y\_1\^2 \\) | \\( R\_4 \gets Z\_1\^2 \\) | \\( R\_5 \gets R\_1\^2 \\) |
//! | | \\( R\_6 \gets R\_2 + R\_3 \\) | \\( R\_7 \gets R\_2 - R\_3 \\) | \\( R\_4 \gets 2 R\_4 \\) | idle |
//! | | idle | \\( R\_1 \gets R\_4 + R\_7 \\) | idle | \\( R\_2 \gets R\_6 - R\_5 \\) |
//! | \\(1\mathbf M\\) | \\( X\_3 \gets R\_1 R\_2 \\) | \\( Y\_3 \gets R\_6 R\_7 \\) | \\( T\_3 \gets R\_2 R\_6 \\) | \\( Z\_3 \gets R\_1 R\_7 \\) |
//!
//! and the unified addition algorithm is presented as follows:
//!
//! | Cost | Processor 1 | Processor 2 | Processor 3 | Processor 4 |
//! |------------------|--------------------------------|--------------------------------|--------------------------------|--------------------------------|
//! | | \\( R\_1 \gets Y\_1 - X\_1 \\) | \\( R\_2 \gets Y\_2 - X\_2 \\) | \\( R\_3 \gets Y\_1 + X\_1 \\) | \\( R\_4 \gets Y\_2 + X\_2 \\) |
//! | \\(1\mathbf M\\) | \\( R\_5 \gets R\_1 R\_2 \\) | \\( R\_6 \gets R\_3 R\_4 \\) | \\( R\_7 \gets T\_1 T\_2 \\) | \\( R\_8 \gets Z\_1 Z\_2 \\) |
//! | \\(1\mathbf D\\) | idle | idle | \\( R\_7 \gets k R\_7 \\) | \\( R\_8 \gets 2 R\_8 \\) |
//! | | \\( R\_1 \gets R\_6 - R\_5 \\) | \\( R\_2 \gets R\_8 - R\_7 \\) | \\( R\_3 \gets R\_8 + R\_7 \\) | \\( R\_4 \gets R\_6 + R\_5 \\) |
//! | \\(1\mathbf M\\) | \\( X\_3 \gets R\_1 R\_2 \\) | \\( Y\_3 \gets R\_3 R\_4 \\) | \\( T\_3 \gets R\_1 R\_4 \\) | \\( Z\_3 \gets R\_2 R\_3 \\) |
//!
//! Here \\( k = 2d \\) is a curve constant.
//!
//! # Implementation strategy
//!
//! For a software implementation, each "processor"'s operations are too
//! low-latency to parallelize across threads. However, the main cost
//! is in the multiplication and squaring steps, which share a single
//! instruction.
//!
//! Our strategy is to implement 4-wide multiplication and squaring
//! using one 64-bit AVX2 lane for each field element. Field elements
//! are represented in the usual way as 10 `u32` limbs in radix
//! \\(25.5\\) (i.e., alternating between \\(2\^{26}\\) for even limbs
//! and \\(2\^{25}\\) for odd limbs). This has the effect that passing
//! between the parallel 32-bit AVX2 representation and the serial
//! 64-bit representation amounts to regrouping digits.
//!
//! The addition and subtraction steps are done largely serially, using
//! masking to handle the instruction divergence. The remaining
//! obstacle to parallelism is the multiplication by the curve constant
//! \\(k = 2d\\). In the Curve25519 case, this is
//!
//! $$ k \equiv 2 \frac{-121665}{121666} \\ \equiv 16295367250680780974490674513165176452449235426866156013048779062215315747161 \pmod p. $$
//!
//! HWCD suggest parallelising this step by breaking \\(k\\) into four
//! parts as \\(k = k_0 + 2\^n k_1 + 2\^{2n} k_2 + 2\^{3n} k_3 \\) and
//! computing \\(k_i R_7 \\) in parallel. However, this would be
//! somewhat awkward in our case, since we would normally represent
//! \\(k\\) as \\( 10 \\) 32-bit limbs, and \\(10 \\) is not divisible
//! by \\(4\\), so we would need a specialized routine to perform a
//! vectorized multiplication by 64-bit constants.
//!
//! Instead, since we are working projectively, we can multiply
//! \\(R_7\\) by \\( -2\cdot 121665 \\) and multiply the other three
//! variables by \\(121666\\). This trick was suggested by Mike
//! Hamburg. Ignoring the sign for the moment, since
//! \\(2 \cdot 121666 < 2\^{18}\\), all these constants fit in 32 bits,
//! so (up to sign) this can be done in parallel as four multiplications
//! by small constants \\( (121666, 121666, 2\cdot 121665, 2\cdot 121666) \\).
//!
//! How do we handle the sign?
//! Since we're primarily interested in Ristretto performance, not
//! Curve25519 performance, we could alternately work on the
//! \\(4\\)-isogenous "IsoEd25519" curve, which has \\(d = 121665\\).
//! However, this would only save the negation step, since multiplying
//! one field element by a 32-bit constant is not much easier than
//! multiplying four field elements by 32-bit constants, and it would
//! prevent accelerating Curve25519, so we don't make this choice.
//! Instead, we just negate one lane, and move the \\(1 \mathbf D\\)
//! into precomputation (see below).
//!
//! The 4-wide formulas of the HWCD paper do not seem to have been
//! implemented using SIMD before. The HWCD paper also describes and
//! analyzes a 2-wide variant of the Montgomery ladder (for comparison
//! with parallel Edwards formulas); this strategy was used in 2015 by
//! Tung Chou's `sandy2x` implementation, which used a 2-wide field
//! implementation in 128-bit vector registers.
//!
//! Curiously, however, although the [`sandy2x` paper][sandy2x] also
//! implements Edwards arithmetic, and cites the HWCD paper, it doesn't
//! mention or discuss the parallel formulas from HWCD, or that the
//! 2-wide Montgomery formulas it uses were previously published there.
//! There is also a 2015 paper by Hernández and López on using AVX2 for
//! the X25519 Montgomery ladder, but neither the paper nor the code are
//! publicly available, and it apparently gives only a [slight
//! speedup][avx2trac], suggesting that it also overlooked the
//! HWCD formulas.
//!
//! HWCD also suggest using a mixed representation, passing between \\(
//! \mathbb P\^3 \\) "extended" coordinates and \\( \mathbb P\^2 \\)
//! "projective" coordinates, where doubling is slightly cheaper (saving
//! about \\(\mathbf 1M\\). This approach is used for the
//! non-vectorized `u32` and `u64` backends, and more
//! details on the different coordinate systems can be found in the
//! `curve_models` module documentation.
//!
//! This optimization is not compatible with the parallel formulas, which are
//! therefore slightly less efficient when counting the total number of
//! field multiplications and squarings. In particular, vectorized doublings
//! are less efficient than serial doublings.
//! In addition, the parallel formulas can only use a \\( 32 \times 32
//! \rightarrow 64 \\)-bit integer multiplier, so the speedup from
//! vectorization must overcome the disadvantage of losing the \\( 64
//! \times 64 \rightarrow 128\\)-bit (serial) integer multiplier.
//!
//! # Tweaked formulas
//!
//! After tweaking the formulas as described above, we obtain the
//! following. To avoid confusion with the original HWCD formulas,
//! temporary variables are named \\(S\\) instead of \\(R\\) and are in
//! static single-assignment (SSA) form.
//!
//! ## Addition
//!
//! To add points \\(P_1 = (X_1 : Y_1 : Z_1 : T_1) \\) and \\(P_2 = (X_2
//! : Y_2 : Z_2 : T_2 ) \\), we compute
//!
//! $$
//! \begin{aligned}
//! S\_0 &\gets Y\_1 - X\_1 \\\\
//! S\_1 &\gets Y\_1 + X\_1 \\\\
//! S\_2 &\gets Y\_2 - X\_2 \\\\
//! S\_3 &\gets Y\_2 + X\_2
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! S\_4 &\gets S\_0 S\_2 \\\\
//! S\_5 &\gets S\_1 S\_3 \\\\
//! S\_6 &\gets Z\_1 Z\_2 \\\\
//! S\_7 &\gets T\_1 T\_2
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! S\_8 &\gets S\_4 \cdot 121666 \\\\
//! S\_9 &\gets S\_5 \cdot 121666 \\\\
//! S\_{10} &\gets S\_6 \cdot 2 \cdot 121666 \\\\
//! S\_{11} &\gets S\_7 \cdot -2 \cdot 121665
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! S\_{12} &\gets S\_9 - S\_8 \\\\
//! S\_{13} &\gets S\_9 + S\_8 \\\\
//! S\_{14} &\gets S\_{10} - S\_{11} \\\\
//! S\_{15} &\gets S\_{10} + S\_{11}
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! X\_3 &\gets S\_{12} S\_{14} \\\\
//! Y\_3 &\gets S\_{15} S\_{13} \\\\
//! Z\_3 &\gets S\_{15} S\_{14} \\\\
//! T\_3 &\gets S\_{12} S\_{13}
//! \end{aligned}
//! $$
//!
//! to obtain \\( P\_3 = (X\_3 : Y\_3 : Z\_3 : T\_3) = P\_1 + P\_2 \\).
//!
//! ## Readdition
//!
//! If the point \\( P_2 = (X\_2 : Y\_2 : Z\_2 : T\_2) \\) is fixed, we can precompute
//!
//! $$
//! \begin{aligned}
//! S\_2 &\gets Y\_2 - X\_2 \\\\
//! S\_3 &\gets Y\_2 + X\_2
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! S\_2' &\gets S\_2 \cdot 121666 \\\\
//! S\_3' &\gets S\_3 \cdot 121666 \\\\
//! Z\_2' &\gets Z\_2 \cdot 2 \cdot 121666 \\\\
//! T\_2' &\gets T\_2 \cdot -2 \cdot 121665 \\\\
//! \end{aligned}
//! $$
//!
//! to obtain the `CachedPoint` \\( (S\_2', S\_3', Z\_2', T\_2') \\).
//! This precomputation is essentially the same as that suggested in
//! §3.1 of HWCD, with the difference that the multiplication by the curve
//! constant \\( -121665 / 121666 \\) is spread over all four
//! coordinates, to allow a vectorized computation of four
//! multiplications of small constants instead of a serial computation
//! of multiplication by a large constant.
//!
//! To perform readdition of \\(P_1 = (X_1 : Y_1 : Z_1 : T_1) \\) and
//! \\(P_2 = (S\_2', S\_3', Z\_2', T\_2') \\), we compute
//!
//! $$
//! \begin{aligned}
//! S\_0 &\gets Y\_1 - X\_1 \\\\
//! S\_1 &\gets Y\_1 + X\_1
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! S\_8 &\gets S\_0 S\_2' \\\\
//! S\_9 &\gets S\_1 S\_3' \\\\
//! S\_{10} &\gets Z\_1 Z\_2' \\\\
//! S\_{11} &\gets T\_1 T\_2'
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! S\_{12} &\gets S\_9 - S\_8 \\\\
//! S\_{13} &\gets S\_9 + S\_8 \\\\
//! S\_{14} &\gets S\_{10} - S\_{11} \\\\
//! S\_{15} &\gets S\_{10} + S\_{11}
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! X\_3 &\gets S\_{12} S\_{14} \\\\
//! Y\_3 &\gets S\_{15} S\_{13} \\\\
//! Z\_3 &\gets S\_{15} S\_{14} \\\\
//! T\_3 &\gets S\_{12} S\_{13}
//! \end{aligned}
//! $$
//!
//! to obtain \\( P\_3 = (X\_3 : Y\_3 : Z\_3 : T\_3) = P\_1 + P\_2 \\).
//!
//! Compared to the addition formulas above, this saves \\( 1\mathbf D \\).
//!
//! ## Doubling
//!
//! To double a point \\( P = (X\_1 : Y\_1 : Z\_1 : T\_1) \\), we compute
//!
//! $$ S\_0 \gets X\_1 + Y\_1 $$
//!
//! $$
//! \begin{aligned}
//! S\_1 &\gets X\_1\^2 \\\\
//! S\_2 &\gets Y\_1\^2 \\\\
//! S\_3 &\gets Z\_1\^2 \\\\
//! S\_4 &\gets S\_0\^2
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! S\_5 &\gets S\_1 + S\_2 \\\\
//! S\_6 &\gets S\_1 - S\_2 \\\\
//! S\_7 &\gets 2S\_3 \\\\
//! S\_8 &\gets S\_7 + S\_6 = S\_1 + 2S\_3 - S\_2 \\\\
//! S\_9 &\gets S\_5 - S\_4 = S\_1 + S\_2 - S\_4
//! \end{aligned}
//! $$
//!
//! $$
//! \begin{aligned}
//! X\_3 &\gets S\_8 S\_9 \\\\
//! Y\_3 &\gets S\_5 S\_6 \\\\
//! Z\_3 &\gets S\_8 S\_6 \\\\
//! T\_3 &\gets S\_5 S\_9
//! \end{aligned}
//! $$
//!
//! to obtain \\( P\_3 = (X\_3 : Y\_3 : Z\_3 : T\_3) = [2]P\_1 \\).
//!
//! Performing too many intermediate additions and subtractions grows
//! the bounds beyond what is allowed as input to multiplication,
//! forcing an extra carry pass. However, it is just possible to avoid
//! this by rearranging signs.
//!
//! Assume that the bounds on the limbs of each field element are
//! parameterized by \\( b \in \mathbb R \\) representing the excess
//! bits, so that each limb is bounded by either \\( 2\^{25} \\) or \\(
//! 2\^{26} \\).
//!
//! The multiplication routine requires that its inputs are bounded by
//! \\( b < 1.75 \\), in order to fit a multiplication by \\( 19 \\)
//! into 32 bits. Since \\( \lg 19 < 4.25 \\), \\( 19x < 2\^{32} \\)
//! when \\( x < 2\^{27.75} = 2\^{26 + 1.75} \\). However, this is only
//! required for one of the inputs; the other can grow up to \\( b < 2.5
//! \\).
//!
//! Computing \\( (S\_5, S\_6, S\_8, S\_9 ) \\) as
//!
//! $$
//! \begin{matrix}
//! & S\_1 & S\_1 & S\_1 & S\_1 \\\\
//! +& S\_2 & & & S\_2 \\\\
//! +& & & S\_3 & \\\\
//! +& & & S\_3 & \\\\
//! +& & 2p & 2p & 2p \\\\
//! -& & S\_2 & S\_2 & \\\\
//! -& & & & S\_4 \\\\
//! =& S\_5 & S\_6 & S\_8 & S\_9
//! \end{matrix}
//! $$
//!
//! results in bit-excesses \\( (1.00, 1.59, 2.33, 2.00)\\) for
//! \\( (S\_5, S\_6, S\_8, S\_9 ) \\). The products we want to compute
//! are then
//!
//! $$
//! \begin{aligned}
//! X\_3 &\gets S\_8 S\_9 \leftrightarrow (2.33, 2.00) \\\\
//! Y\_3 &\gets S\_5 S\_6 \leftrightarrow (1.00, 1.59) \\\\
//! Z\_3 &\gets S\_8 S\_6 \leftrightarrow (2.33, 1.59) \\\\
//! T\_3 &\gets S\_5 S\_9 \leftrightarrow (1.00, 2.00)
//! \end{aligned}
//! $$
//!
//! which are too large. However, if we flip the sign of \\( S\_4 =
//! S\_0\^2 \\) during squaring, so that we output \\(S\_4' = -S\_4
//! \pmod p\\), then we can compute
//!
//! $$
//! \begin{matrix}
//! & S\_1 & S\_1 & S\_1 & S\_1 \\\\
//! +& S\_2 & & & S\_2 \\\\
//! +& & & S\_3 & \\\\
//! +& & & S\_3 & \\\\
//! +& & & & S\_4' \\\\
//! +& & 2p & 2p & \\\\
//! -& & S\_2 & S\_2 & \\\\
//! =& S\_5 & S\_6 & S\_8 & S\_9
//! \end{matrix}
//! $$
//!
//! resulting in bit-excesses \\( (1.00, 1.59, 2.33, 1.59)\\) for
//! \\( (S\_5, S\_6, S\_8, S\_9 ) \\). The products we want to compute
//! are then
//!
//! $$
//! \begin{aligned}
//! X\_3 &\gets S\_8 S\_9 \leftrightarrow (2.33, 1.59) \\\\
//! Y\_3 &\gets S\_5 S\_6 \leftrightarrow (1.00, 1.59) \\\\
//! Z\_3 &\gets S\_8 S\_6 \leftrightarrow (2.33, 1.59) \\\\
//! T\_3 &\gets S\_5 S\_9 \leftrightarrow (1.00, 1.59)
//! \end{aligned}
//! $$
//!
//! whose right-hand sides are all bounded with \\( b < 1.75 \\) and
//! whose left-hand sides are all bounded with \\( b < 2.5 \\).
//!
//! # Field element representation
//!
//! The field element representation is oriented around the AVX2
//! `vpmuluqdq` instruction, which multiplies the low 32 bits of each
//! 64-bit lane of each operand to produce a 64-bit result.
//!
//! ```text,no_run
//! (a1 ?? b1 ?? c1 ?? d1 ??)
//! (a2 ?? b2 ?? c2 ?? d2 ??)
//!
//! (a1*a2 b1*b2 c1*c2 d1*d2)
//! ```
//!
//! To unpack 32-bit values into 64-bit lanes for use in multiplication
//! it would be convenient to use the `vpunpck[lh]dq` instructions,
//! which unpack and interleave the low and high 32-bit lanes of two
//! source vectors.
//! However, the AVX2 versions of these instructions are designed to
//! operate only within 128-bit lanes of the 256-bit vectors, so that
//! interleaving the low lanes of `(a0 b0 c0 d0 a1 b1 c1 d1)` with zero
//! gives `(a0 00 b0 00 a1 00 b1 00)`. Instead, we pre-shuffle the data
//! layout as `(a0 b0 a1 b1 c0 d0 c1 d1)` so that we can unpack the
//! "low" and "high" parts as
//!
//! ```text,no_run
//! (a0 00 b0 00 c0 00 d0 00)
//! (a1 00 b1 00 c1 00 d1 00)
//! ```
//!
//! The data layout for a vector of four field elements \\( (a,b,c,d)
//! \\) with limbs \\( a_0, a_1, \ldots, a_9 \\) is as `[u32x8; 5]` in
//! the form
//!
//! ```text,no_run
//! (a0 b0 a1 b1 c0 d0 c1 d1)
//! (a2 b2 a3 b3 c2 d2 c3 d3)
//! (a4 b4 a5 b5 c4 d4 c5 d5)
//! (a6 b6 a7 b7 c6 d6 c7 d7)
//! (a8 b8 a9 b9 c8 d8 c9 d9)
//! ```
//!
//! Since this breaks cleanly into two 128-bit lanes, it may be possible
//! to adapt it to 128-bit vector instructions such as NEON without too
//! much difficulty.
//!
//! Going the other direction, to extend this to AVX512, we could either
//! run two point operations in parallel in lower and upper halves of
//! the registers, or use 2-way parallelism within a field operation.
//!
//! We don't attempt to use AVX2 for serial field element computations
//! such as inversion, since wherever we have AVX2 we also have `mulx`.
//! However, it might be useful for batched inverse square-root
//! computations, which can't be batched in the same way inversions can.
//!
//! # Implementation details
//!
//! The implementation uses the unstable `stdsimd` crate to provide AVX2
//! intrinsics, and the code is not yet cleanly factored between the
//! field element parts and the point parts.
//!
//! When compiling with AVX512VL, LLVM is able to use the extra
//! `ymm16..ymm31` registers to reduce register pressure, and avoid
//! spills during field multiplication. This gives a small but
//! noticeable speedup.
//!
//! The addition and subtraction steps involve masking, to apply
//! operations to a single lane of the vector. AVX512VL extends the
//! predication features of AVX512 to AVX2 code and would probably be
//! beneficial. Unfortunately, LLVM is currently unable to lower `op +
//! blend` into an AVX512VL masked operation. However, the explicitly
//! masked versions of the intrinsics seem to produce the same LLVM IR
//! as an `op + blend`, so hopefully this will improve as the AVX512
//! support in LLVM improves.
//!
//! When used for constant-time variable-base scalar multiplication,
//! this strategy (using AVX2) gives a significant speedup over the
//! serial implementation (using the \\(64 \times 64\\) multiplier) of
//! approximately 1.6x for Skylake-X with `target_cpu=skylake` (using AVX2), of
//! approximately 1.8x for Skylake-X with `target_cpu=skylake-avx512` (using the extra
//! `ymm16..ymm31` registers from AVX512VL), and of approximately 1.0x
//! for Ryzen (which implements AVX2 at half rate).
//!
//! When used for variable-time double-base scalar multiplication
//! \\( aA + bB \\) for fixed \\(B\\) (as in, e.g., signature verification),
//! this strategy provides a 1.4x speedup on Skylake-X over the same
//! operation as implemented in `ed25519-donna`, the fastest
//! production-quality Ed25519 implementation.
//!
//! [sandy2x]: https://eprint.iacr.org/2015/943.pdf
//! [avx2trac]: https://trac.torproject.org/projects/tor/ticket/8897#comment:28
//! [hwcd08]: https://www.iacr.org/archive/asiacrypt2008/53500329/53500329.pdf
// See the comment above the ristretto::notes module.
#![cfg_attr(all(feature = "nightly", feature="precomputed_tables"), doc(include = "../docs/avx2-notes.md"))]
pub(crate) mod field;

8
src/backend/avx2/scalar_mul/vartime_double_base.rs
View file

@ -12,14 +12,14 @@
use traits::Identity;
use scalar::Scalar;
use edwards::EdwardsPoint;
use scalar_mul::window::OddLookupTable;
use scalar_mul::window::NafLookupTable5;
use backend::avx2::edwards::{CachedPoint, ExtendedPoint};
use backend::avx2::constants::BASEPOINT_ODD_LOOKUP_TABLE;
/// Compute \\(aA + bB\\) in variable time, where \\(B\\) is the Ed25519 basepoint.
pub fn mul(a: &Scalar, A: &EdwardsPoint, b: &Scalar) -> EdwardsPoint {
let a_naf = a.non_adjacent_form();
let b_naf = b.non_adjacent_form();
let a_naf = a.non_adjacent_form(5);
let b_naf = b.non_adjacent_form(8);
// Find starting index
let mut i: usize = 255;
@ -30,7 +30,7 @@ pub fn mul(a: &Scalar, A: &EdwardsPoint, b: &Scalar) -> EdwardsPoint {
}
}
let table_A = OddLookupTable::<CachedPoint>::from(A);
let table_A = NafLookupTable5::<CachedPoint>::from(A);
let table_B = &BASEPOINT_ODD_LOOKUP_TABLE;
let mut Q = ExtendedPoint::identity();

6
src/backend/avx2/scalar_mul/vartime_straus.rs
View file

@ -14,7 +14,7 @@ use core::borrow::Borrow;
use traits::Identity;
use scalar::Scalar;
use edwards::EdwardsPoint;
use scalar_mul::window::OddLookupTable;
use scalar_mul::window::NafLookupTable5;
use backend::avx2::edwards::{CachedPoint, ExtendedPoint};
/// Perform variable-time, variable-base scalar multiplication.
@ -27,11 +27,11 @@ where
{
let nafs: Vec<_> = scalars
.into_iter()
.map(|c| c.borrow().non_adjacent_form())
.map(|c| c.borrow().non_adjacent_form(5))
.collect();
let lookup_tables: Vec<_> = points
.into_iter()
.map(|point| OddLookupTable::<CachedPoint>::from(point.borrow()))
.map(|point| NafLookupTable5::<CachedPoint>::from(point.borrow()))
.collect();
let mut Q = ExtendedPoint::identity();

1
src/backend/mod.rs
View file

@ -27,7 +27,6 @@ pub mod u32;
#[cfg(feature="radix_51")]
pub mod u64;
/// Code using AVX2.
#[cfg(all(feature="nightly", all(feature="avx2_backend", target_feature="avx2")))]
pub mod avx2;

2
src/lib.rs
View file

@ -44,6 +44,8 @@ extern crate alloc;
extern crate clear_on_drop;
extern crate byteorder;
// The `Digest` trait is implemented using `generic_array`, so we need it
// too. Hopefully we can eliminate `generic_array` from `Digest` once const
// generics land.

2
src/ristretto.rs
View file

@ -159,6 +159,8 @@
// generating the lookup tables (in which case we're relative to the
// location of build.rs, not lib.rs, so the markdown file appears
// missing).
//
// This hack is also used in the avx2 notes.
#[cfg_attr(all(feature = "nightly", feature="precomputed_tables"), doc(include = "../docs/ristretto-notes.md"))]
mod notes {
}

154
src/scalar.rs
View file

@ -80,6 +80,7 @@ pub struct Scalar {
///
/// The integer representing this scalar must be bounded above by \\(2\^{255}\\), or equivalently the high bit of `bytes[31]` must be zero.
///
/// This ensures that there is room for a carry bit when computing a NAF representation.
// XXX This is pub(crate) so we can write literal constants. If const fns were stable, we could make the Scalar constructors const fns and use those instead.
pub(crate) bytes: [u8; 32],
}
@ -493,51 +494,130 @@ impl Scalar {
bits
}
/// Compute a width-5 "Non-Adjacent Form" of this scalar.
/// Compute a width-\\(w\\) "Non-Adjacent Form" of this scalar.
///
/// A width-\\(w\\) NAF of a positive integer \\(k\\) is an expression
/// $$
/// k = \sum_{i=0}\^n k\_i 2\^i,
/// k = \sum_{i=0}\^m n\_i 2\^i,
/// $$
/// where each nonzero
/// coefficient \\(k\_i\\) is odd and bounded by \\(|k\_i| < 2\^{w-1}\\),
/// \\(k\_{n-1}\\) is nonzero, and at most one of any \\(w\\) consecutive
/// coefficient \\(n\_i\\) is odd and bounded by \\(|n\_i| < 2\^{w-1}\\),
/// \\(n\_{m-1}\\) is nonzero, and at most one of any \\(w\\) consecutive
/// coefficients is nonzero. (Hankerson, Menezes, Vanstone; def 3.32).
///
/// The length of the NAF is at most one more than the length of
/// the binary representation of \\(k\\). This is why the
/// `Scalar` type maintains an invariant that the top bit is
/// \\(0\\), so that the NAF of a scalar has at most 256 digits.
///
/// Intuitively, this is like a binary expansion, except that we
/// allow some coefficients to grow up to \\(2\^{w-1}\\) so that the
/// nonzero coefficients are as sparse as possible.
pub(crate) fn non_adjacent_form(&self) -> [i8; 256] {
// Step 1: write out bits of the scalar
let mut naf = self.bits();
/// allow some coefficients to grow in magnitude up to
/// \\(2\^{w-1}\\) so that the nonzero coefficients are as sparse
/// as possible.
///
/// When doing scalar multiplication, we can then use a lookup
/// table of precomputed multiples of a point to add the nonzero
/// terms \\( k_i P \\). Using signed digits cuts the table size
/// in half, and using odd digits cuts the table size in half
/// again.
///
/// To compute a \\(w\\)-NAF, we use a modification of Algorithm 3.35 of HMV:
///
/// 1. \\( i \gets 0 \\)
/// 2. While \\( k \ge 1 \\):
/// 1. If \\(k\\) is odd, \\( n_i \gets k \operatorname{mods} 2^w \\), \\( k \gets k - n_i \\).
/// 2. If \\(k\\) is even, \\( n_i \gets 0 \\).
/// 3. \\( k \gets k / 2 \\), \\( i \gets i + 1 \\).
/// 3. Return \\( n_0, n_1, ... , \\)
///
/// Here \\( \bar x = x \operatorname{mods} 2^w \\) means the
/// \\( \bar x \\) with \\( \bar x \equiv x \pmod{2^w} \\) and
/// \\( -2^{w-1} \leq \bar x < 2^w \\).
///
/// We implement this by scanning across the bits of \\(k\\) from
/// least-significant bit to most-significant-bit.
/// Write the bits of \\(k\\) as
/// $$
/// k = \sum\_{i=0}\^m k\_i 2^i,
/// $$
/// and split the sum as
/// $$
/// k = \sum\_{i=0}^{w-1} k\_i 2^i + 2^w \sum\_{i=0} k\_{i+w} 2^i
/// $$
/// where the first part is \\( k \mod 2^w \\).
///
/// If \\( k \mod 2^w\\) is odd, and \\( k \mod 2^w < 2^{w-1} \\), then we emit
/// \\( n_0 = k \mod 2^w \\). Instead of computing
/// \\( k - n_0 \\), we just advance \\(w\\) bits and reindex.
///
/// If \\( k \mod 2^w\\) is odd, and \\( k \mod 2^w \ge 2^{w-1} \\), then
/// \\( n_0 = k \operatorname{mods} 2^w = k \mod 2^w - 2^w \\).
/// The quantity \\( k - n_0 \\) is
/// $$
/// \begin{aligned}
/// k - n_0 &= \sum\_{i=0}^{w-1} k\_i 2^i + 2^w \sum\_{i=0} k\_{i+w} 2^i
/// - \sum\_{i=0}^{w-1} k\_i 2^i + 2^w \\\\
/// &= 2^w + 2^w \sum\_{i=0} k\_{i+w} 2^i
/// \end{aligned}
/// $$
/// so instead of computing the subtraction, we can set a carry
/// bit, advance \\(w\\) bits, and reindex.
///
/// If \\( k \mod 2^w\\) is even, we emit \\(0\\), advance 1 bit
/// and reindex. In fact, by setting all digits to \\(0\\)
/// initially, we don't need to emit anything.
pub(crate) fn non_adjacent_form(&self, w: usize) -> [i8; 256] {
// required by the NAF definition
debug_assert!( w >= 2 );
// required so that the NAF digits fit in i8
debug_assert!( w <= 8 );
// Step 2: zero coefficients by carrying them upwards or downwards
'bits: for i in 0..256 {
if naf[i] == 0 { continue 'bits; }
'window: for b in 1..6 {
if i+b >= 256 { break 'window; }
if naf[i+b] == 0 { continue 'window; }
let potential_carry = naf[i+b] << b;
if naf[i+b] + potential_carry <= 15 {
// Eliminate naf[i+b] by carrying its value onto naf[i]
naf[i] += potential_carry;
naf[i+b] = 0;
} else if naf[i+b] - potential_carry >= -15 {
// Eliminate naf[i+b] by carrying its value upwards.
naf[i] -= potential_carry; // Subtract 2^(i+b)
'carry: for k in i+b..256 {
if naf[k] != 0 {
// Since naf[k] = 0 or 1 for k > i, naf[k] == 1.
naf[k] = 0; // Subtract 2^k
} else {
// By now we have subtracted 2^k =
// 2^(i+b) + 2^(i+b) + 2^(i+b+1) + ... + 2^(k-1).
naf[k] = 1; // Add back 2^k.
break 'carry;
}
}
}
use byteorder::{ByteOrder, LittleEndian};
let mut naf = [0i8; 256];
let mut x_u64 = [0u64; 5];
LittleEndian::read_u64_into(&self.bytes, &mut x_u64[0..4]);
let width = 1 << w;
let window_mask = width - 1;
let mut pos = 0;
let mut carry = 0;
while pos < 256 {
// Construct a buffer of bits of the scalar, starting at bit `pos`
let u64_idx = pos / 64;
let bit_idx = pos % 64;
let bit_buf: u64;
if bit_idx < 64 - w {
// This window's bits are contained in a single u64
bit_buf = x_u64[u64_idx] >> bit_idx;
} else {
// Combine the current u64's bits with the bits from the next u64
bit_buf = (x_u64[u64_idx] >> bit_idx) | (x_u64[1+u64_idx] << (64 - bit_idx));
}
// Add the carry into the current window
let window = carry + (bit_buf & window_mask);
if window & 1 == 0 {
// If the window value is even, preserve the carry and continue.
// Why is the carry preserved?
// If carry == 0 and window & 1 == 0, then the next carry should be 0
// If carry == 1 and window & 1 == 0, then bit_buf & 1 == 1 so the next carry should be 1
pos += 1;
continue;
}
if window < width/2 {
carry = 0;
naf[pos] = window as i8;
} else {
carry = 1;
naf[pos] = (window as i8) - (width as i8);
}
pos += w;
}
naf
@ -548,7 +628,7 @@ impl Scalar {
/// $$
/// a = a\_0 + a\_1 16\^1 + \cdots + a_{63} 16\^{63},
/// $$
/// with \\(-8 \leq a_i < 8\\) for \\(0 \leq i < 63\\) and \\(-8 \leq a_63 \leq 8\\).
/// with \\(-8 \leq a_i < 8\\) for \\(0 \leq i < 63\\) and \\(-8 \leq a_{63} \leq 8\\).
pub(crate) fn to_radix_16(&self) -> [i8; 64] {
debug_assert!(self[31] <= 127);
let mut output = [0i8; 64];
@ -789,7 +869,7 @@ mod test {
#[test]
fn non_adjacent_form() {
let naf = A_SCALAR.non_adjacent_form();
let naf = A_SCALAR.non_adjacent_form(5);
for i in 0..256 {
assert_eq!(naf[i], A_NAF[i]);
}

8
src/scalar_mul/vartime_double_base.rs
View file

@ -14,12 +14,12 @@ use traits::Identity;
use scalar::Scalar;
use edwards::EdwardsPoint;
use curve_models::{ProjectiveNielsPoint, ProjectivePoint};
use scalar_mul::window::OddLookupTable;
use scalar_mul::window::NafLookupTable5;
/// Compute \\(aA + bB\\) in variable time, where \\(B\\) is the Ed25519 basepoint.
pub fn mul(a: &Scalar, A: &EdwardsPoint, b: &Scalar) -> EdwardsPoint {
let a_naf = a.non_adjacent_form();
let b_naf = b.non_adjacent_form();
let a_naf = a.non_adjacent_form(5);
let b_naf = b.non_adjacent_form(8);
// Find starting index
let mut i: usize = 255;
@ -30,7 +30,7 @@ pub fn mul(a: &Scalar, A: &EdwardsPoint, b: &Scalar) -> EdwardsPoint {
}
}
let table_A = OddLookupTable::<ProjectiveNielsPoint>::from(A);
let table_A = NafLookupTable5::<ProjectiveNielsPoint>::from(A);
let table_B = &constants::AFFINE_ODD_MULTIPLES_OF_BASEPOINT;
let mut r = ProjectivePoint::identity();

6
src/scalar_mul/vartime_straus.rs
View file

@ -15,7 +15,7 @@ use traits::Identity;
use scalar::Scalar;
use edwards::EdwardsPoint;
use curve_models::{CompletedPoint, ProjectivePoint, ProjectiveNielsPoint};
use scalar_mul::window::OddLookupTable;
use scalar_mul::window::NafLookupTable5;
/// Perform variable-time, variable-base scalar multiplication.
pub(crate) fn multiscalar_mul<I, J>(scalars: I, points: J) -> EdwardsPoint
@ -27,11 +27,11 @@ where
{
let nafs: Vec<_> = scalars
.into_iter()
.map(|c| c.borrow().non_adjacent_form())
.map(|c| c.borrow().non_adjacent_form(5))
.collect();
let lookup_tables: Vec<_> = points
.into_iter()
.map(|P| OddLookupTable::<ProjectiveNielsPoint>::from(P.borrow()))
.map(|P| NafLookupTable5::<ProjectiveNielsPoint>::from(P.borrow()))
.collect();
let mut r = ProjectivePoint::identity();

63
src/scalar_mul/window.rs
View file

@ -122,9 +122,9 @@ impl<'a> From<&'a EdwardsPoint> for LookupTable<AffineNielsPoint> {
/// Holds odd multiples 1A, 3A, ..., 15A of a point A.
#[derive(Copy, Clone)]
pub(crate) struct OddLookupTable<T>(pub(crate) [T; 8]);
pub(crate) struct NafLookupTable5<T>(pub(crate) [T; 8]);
impl<T: Copy> OddLookupTable<T> {
impl<T: Copy> NafLookupTable5<T> {
/// Given public, odd \\( x \\) with \\( 0 < x < 2^4 \\), return \\(xA\\).
pub fn select(&self, x: usize) -> T {
debug_assert_eq!(x & 1, 1);
@ -134,13 +134,13 @@ impl<T: Copy> OddLookupTable<T> {
}
}
impl<T: Debug> Debug for OddLookupTable<T> {
impl<T: Debug> Debug for NafLookupTable5<T> {
fn fmt(&self, f: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
write!(f, "OddLookupTable({:?})", self.0)
write!(f, "NafLookupTable5({:?})", self.0)
}
}
impl<'a> From<&'a EdwardsPoint> for OddLookupTable<ProjectiveNielsPoint> {
impl<'a> From<&'a EdwardsPoint> for NafLookupTable5<ProjectiveNielsPoint> {
fn from(A: &'a EdwardsPoint) -> Self {
let mut Ai = [A.to_projective_niels(); 8];
let A2 = A.double();
@ -148,11 +148,11 @@ impl<'a> From<&'a EdwardsPoint> for OddLookupTable<ProjectiveNielsPoint> {
Ai[i + 1] = (&A2 + &Ai[i]).to_extended().to_projective_niels();
}
// Now Ai = [A, 3A, 5A, 7A, 9A, 11A, 13A, 15A]
OddLookupTable(Ai)
NafLookupTable5(Ai)
}
}
impl<'a> From<&'a EdwardsPoint> for OddLookupTable<AffineNielsPoint> {
impl<'a> From<&'a EdwardsPoint> for NafLookupTable5<AffineNielsPoint> {
fn from(A: &'a EdwardsPoint) -> Self {
let mut Ai = [A.to_affine_niels(); 8];
let A2 = A.double();
@ -160,6 +160,53 @@ impl<'a> From<&'a EdwardsPoint> for OddLookupTable<AffineNielsPoint> {
Ai[i + 1] = (&A2 + &Ai[i]).to_extended().to_affine_niels();
}
// Now Ai = [A, 3A, 5A, 7A, 9A, 11A, 13A, 15A]
OddLookupTable(Ai)
NafLookupTable5(Ai)
}
}
/// Holds stuff up to 8.
#[derive(Copy, Clone)]
pub(crate) struct NafLookupTable8<T>(pub(crate) [T; 64]);
impl<T: Copy> NafLookupTable8<T> {
pub fn select(&self, x: usize) -> T {
debug_assert_eq!(x & 1, 1);
debug_assert!(x < 256);
self.0[x / 2]
}
}
impl<T: Debug> Debug for NafLookupTable8<T> {
fn fmt(&self, f: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
write!(f, "NafLookupTable8([\n")?;
for i in 0..64 {
write!(f, "\t{:?},\n", &self.0[i])?;
}
write!(f, "])")
}
}
impl<'a> From<&'a EdwardsPoint> for NafLookupTable8<ProjectiveNielsPoint> {
fn from(A: &'a EdwardsPoint) -> Self {
let mut Ai = [A.to_projective_niels(); 64];
let A2 = A.double();
for i in 0..63 {
Ai[i + 1] = (&A2 + &Ai[i]).to_extended().to_projective_niels();
}
// Now Ai = [A, 3A, 5A, 7A, 9A, 11A, 13A, 15A, ..., 127A]
NafLookupTable8(Ai)
}
}
impl<'a> From<&'a EdwardsPoint> for NafLookupTable8<AffineNielsPoint> {
fn from(A: &'a EdwardsPoint) -> Self {
let mut Ai = [A.to_affine_niels(); 64];
let A2 = A.double();
for i in 0..63 {
Ai[i + 1] = (&A2 + &Ai[i]).to_extended().to_affine_niels();
}
// Now Ai = [A, 3A, 5A, 7A, 9A, 11A, 13A, 15A, ..., 127A]
NafLookupTable8(Ai)
}
}