Commit graph

10 commits

Author SHA1 Message Date
Henry de Valence
6eb876f3cb Fix doctests (missed during merge) 2018-07-20 11:50:42 -07:00
Henry de Valence
bb50700d77
Merge pull request #163 from hdevalence/fallible-multiscalar-mul
Allow Options in the VartimeMultiscalarMul trait
2018-07-20 11:28:19 -07:00
Henry de Valence
1e74cb3e56 Replace Scalar::from_u64 with From impls
Unfortunately, Rust selects `i32` as the type for an integer literal
when the literal has no other type constraints.  This means that someone
cannot write `Scalar::from(1)`, as Rust will choose `i32` as the type for
`1`, and we don't `impl From<i32> for Scalar`.

We could implement `From` conversions for signed integers, but since
`Scalar` operations should be constant-time by default, this would
require us to extract the sign bit of the integer and use it to
conditionally select between the positive and negative of Scalar
constructed from the value bits.  This is more expensive than the
unsigned operation, and I don't think it's what anyone really wants.

Making API consumers specify that their literals are unsigned is
slightly annoying, but better than the above alternative.

It would also be nice to change `Scalar::from_hash` to be
`impl<D: Digest<OutputSize = U64>> From<D> for Scalar`,
but this isn't currently allowed by Rust (since that `impl` "could"
conflict with the `impl From<u8>` if someone decided that `u8` should
`impl Digest`).
2018-07-19 08:39:09 -07:00
Henry de Valence
b4db0afe18 Allow Options in the VartimeMultiscalarMul trait
This changes the primary function for the `VartimeMultiscalarMul` trait
to an `optional_multiscalar_mul` trait that accepts
`Option<Self::Point>` (and returns `None` if any input points are
`None`).

The existing `vartime_multiscalar_mul` is changed to be a wrapper around
this function to avoid code duplication.  This may result in an
extra copy of each input point, but that cost is probably not
significant compared to the cost of the multiscalar multiplication.

The motivation is to allow performing multiscalar multiplications with
inline decompression.  Currently, API consumers have to allocate
temporary buffers for all of their points, decompress into those
buffers, then pass (iterators over) those buffers into the multiscalar
multiplication code, which then creates new buffers for lookup tables.
2018-07-17 08:19:48 -07:00
Henry de Valence
7bbf7495b0 Change VartimeMultiscalarMul docs to use vartime_ 2018-07-16 22:54:45 -07:00
Isis Lovecruft
f43f4f9770
Update year in copyright notices to 2018. 2018-07-05 00:30:27 +00:00
Henry de Valence
e3bf9b0213 Add MultiscalarMul and VartimeMultiscalarMul traits.
These traits have the same interface, but with different names, so that it's
not possible to use them interchangeably.  (Constant-time and variable-time
routines should not be used interchangeably).

This commit changes the external API to use these traits, replacing
```
edwards::multiscalar_mul
edwards::vartime::multiscalar_mul
```
with
```
EdwardsPoint::multiscalar_mul (as an impl)
EdwardsPoint::vartime_multiscalar_mul (as an impl)
```
and similarly for Ristretto.

Refactoring the backend is for a later commit.

Multiscalar multiplication with precomputation is for a later commit.

The `edwards::vartime` module is retained since it's used for
`vartime_double_base_scalar_mul`.

It should be subsumed into the precomputation API in a later commit.
2018-05-15 11:33:38 -07:00
Henry de Valence
792ac0775e Change to the updated subtle API. 2018-03-22 11:13:26 -07:00
Henry de Valence
a3f53c9134 Refactor select_precomputed_point into a LookupTable struct.
Originally this was for hygiene, so that we could erase points from
heap-allocated memory in multiscalar_mult, but it ends up providing a cleaner
API for scalar multiplication.

It's kept inside curve_models for now, but it could go somewhere else if that's a better place.
2017-12-07 12:46:57 -08:00
Henry de Valence
8d0808a077 Split internal curve models into a private submodule 2017-11-16 17:34:28 -08:00