This allows us to finely control when to use a single hash or a double hash in
various places. For example, Bitcoin signatures use double SHA256, but Decred
signatures use a single BLAKE256. However, both use double hashes for Base58.
Signing uses the bn_inverse function that is prone to side-channel
attacks. We randomize its argument by multiplying it with a random
non-zero number. At the end we multiply again by the same number to
cancel it out.
Changed get_k_random to take the prime range as a second argument and
to return a non-zero number. This function was previously only used
for (non-rfc6979) signing and is now used for side-channel protection.
This adds an is_canonic parameter to all sign functions. This is a
callback that determines if a signature corresponds to some coin
specific rules. It is used, e. g., by ethereum (where the recovery
byte must be 0 or 1, and not 2 or 3) and or steem signatures (which
require both r and s to be between 2^248 and 2^255).
This also separates the initialization and the step function of the
random number generator, making it easy to restart the signature
process with the next random number.
The new name of the function is `hdnode_get_ethereum_address`
and it gets a hdnode as input as opposed to a public key. This
also avoids first computing the compressed public key and then
uncompressing it.
Test cases were adapted to work with new function. The test-vectors
are the same as for bip32 and independently checked with an adhoc
python implementation.
Moved the code from Trezor firmware to here for recovering the public key
when verifying a bitcoin message. Fixed the signing and verification for
the unlikely case the r value overflows.
* Split ecdsa_curve into curve_info and ecdsa_curve to support bip32 on
curves that don't have a ecdsa_curve.
* Don't fail in key derivation but retry with a new hash.
* Adapted test case accordingly
