Previously, we were checking that the highest 3 bits were unset, which still
leaves 2^253 - 2^252 + 27742317777372353535851937790883648493 potential scalars
for the `s` component of a signature which are not strictly mod \ell.
This change fixes that.
Note: This change makes ed25519-dalek incompatible with ed25519-donna in that
some signatures produced by donna will be verifiable by donna but NOT VERIFIABLE
by dalek. On the other hand, libsodium exports a -DED25519_COMPAT feature,
which when enabled, means it is compatible with dalek with the
`legacy_compatibility` feature disabled. Otherwise, libsodium's behaviour is
identical to the behaviour enabled by default in this patch.
* ADD new "batch" feature for feature-gating ed25519 batch verification; off by
default. The "batch" feature is the only thing which depends on all of the
`rand` crate, since it requires the functionality of `rand::thread_rng()`.
Without batch verification, the rest of ed25519-dalek only depends on
`rand_os` and `rand_core`.
This implements https://github.com/dalek-cryptography/ed25519-dalek/issues/64
You can still choose the "prehash" algorithm, as long as it has 64 bytes of
output. Otherwise, everything is hardcoded to use sha2::Sha512. To use a
different implementation you'll need a [patch.crates-io] section in cargo
config.
This caches the public key internally so that we effectively get a free
speedup on key reuse in regular signature verification, similar to that in
batch verification. (However, this also "speeds up"¹ batch verifications.)
¹ Less of a speed up than moving the computation elsewhere, but the speed up
on reuse still also applies to key reuse for batch verification.
Unfortunately the serialised size is likely never going to be the same
as the type's size in memory, as most serialisation formats define
additional headers for parsing safety reasons, such as buffer lengths
and type information.
