This is useful for programs/protocol which can do some heuristics or
learning-based approach towards optimising the table size based on the number of
uses of e.g. a public key, the second basepoint in a Pedersen commitment, etc.,
i.e. the first time a public key is used to verify a signature, the usual
variable-time basepoint multiscalar multiplication is used, however after 1000
verifications, the table size is upgraded, and again after 10000 verifications,
etc.
This implements a macro for implementing the BasepointTable trait, and
uses the macro to create basepoint table types. The default table
still uses radix-16 representation and is ~30KB in size. The new
table types, and their memory usage and additions required per
basepoint multiplication are:
* `EdwardsBasepointTableRadix64`: ~120KB, 43 additions
* `EdwardsBasepointTableRadix128`: ~240KB, 37 additions
* `EdwardsBasepointTableRadix256`: ~480KB, 32 additions
The functionality we were using is now contained in the `rand_core` crate, which
we already depend upon. As far as testing code goes, only benchmarks still
depend upon `rand`, as they use `thread_rng`.
We due this in lieu of implementing `TryFrom` to allow for API
consumers to use the `?` operator to convert potential `None`s into
their own `Result<T, CustomError>` types for better error handling
with less boilerplate.
Note that this is a breaking API change.
This test is no longer necessary as it originally had a possibility of
failure due to the original implementation of the invsqrt() function
in the decompression algorithm. The failure with the current API is
nonexistent.
* FIXES#288.
Of these only `rand_core` is included in the public API; regardless of `rand`
semver tricks, this is a breaking API change, but the major version is already
bumped to include the Serde serialization fixes.
By default, Cargo treats version specifiers as semver-compatible ranges, so the
version specifiers we include should only have the components that are actually
meaningful, e.g., "1" instead of "1.0.0" (which actually means "1").
`zeroize` is WASM-friendly as it has no dependencies on C compilers.
Instead uses Rust's own volatile write semantics and compiler fences to
ensure zeroization is not elided by the compiler.
