original PR: https://github.com/trezor/trezor-crypto/pull/162

• basic crypto in ed25519 (ge, fe, sc) missing from the trezor-crypto, required for Monero.
• Monero specific functions (e.g., sub-address computation, Pedersen commitments, base58 block-based, hash_to_scalar, hash_to_point, derivation to scalar)
• serialization routines - simple variable sized integer serialization
• memory optimized range proof, Borromean.
• tests - should be covered pretty well.

This PR is for adding Cardano currency support and is intended to merge with https://github.com/trezor/trezor-core/pull/250

For the support of Cardano currency was required to add cardano-specific ed25519 crypto support. The crypto code is based on cardano-crypto and cardano-sl - official Cardano repos.

We are NOT official developers of Cardano, however we are developers of www.cardanolite.com

Standard decred software uses Bitcoin seed instead of Decred seed as the bip32 master key[1][2].

Ideally, trezor should use the same master key as standard decred software to allow better interoperability; in particular to allow users to import their trezor seed (after a small conversion) into standard decred software.

While this breaks any existing decred trezor wallets, no software has been officially released to allow using decred with trezor. Neither trezor web wallet nor any decred wallet has been released to the general public yet. We can also provide a recovery path for any outstanding trezor users that might have already used the recently released firmware 1.6.2 with mainnet decred coins.

We'll need to have this fix applied then wait for the next round of firmware updates to be released before releasing official decred wallets with trezor support.

[1] https://github.com/decred/dcrd/blob/master/hdkeychain/extendedkey.go#L97 [2] https://github.com/decred/dcrd/blob/master/hdkeychain/extendedkey.go#L464

PR that came from the discussion with @onvej-sl in https://github.com/trezor/trezor-crypto/pull/169

Requires rebasing on top of the master and merging https://github.com/trezor/trezor-crypto/pull/171 and https://github.com/trezor/trezor-crypto/pull/172 first.

Two new operations on ed25519 scalar values (modulo m) were added:

• -x mod m
• x-y mod m

I need this for Monero implementation. I am working another few which I will PR as they are finished and tested.

GCC optimizes out the memset call for automatic variables, such as https://github.com/trezor/trezor-crypto/blob/8d8bc9c762b504ee8c66f94d93600d417d92841e/bip39.c#L66-L69

Using volatile does not solve the issue because memset discards the qualifier.

One possible solution would be to define MEMSET_BZERO as explicit_bzero from Newlib in the firmware. Or we could implement our own version so other dependent projects benefit from it. It is simply a call to memset(buffer, 0, size) but the compiler will not optimize it out.

• Add Ed25519 variants (_sha3 and _keccak)
• Enable USE_KECCAK by default
• Added DONNA_UNUSED to ed25519.h for curve25519_scalar_product & expand256_modm (-Werror=unused-function)
• Added Ruby script to import test vectors from https://github.com/NemProject/nem-test-vectors
• Added test vectors for Keccak-256
• Added test vectors for Ed25519-Keccak
• Added ed25519_sha3_info and ed25519_keccak_info curves for BIP32 and BIP39
• Constant time verification of ed25519_keccak using #96

Add support for formatting as integers (e.g. no decimal point - I think a negative decimals works for this, but I'm not sure if that's an intentional part of the API) and division by a power of 10 while maintaining the decimals.

Also a flag to force trailing zeroes would be useful. I think the best way to implement this would be adding divisor for the faux division and trailing for the trailing zeroes. Making the decimals functionality explicit should do for the integer formatting.

I implemented a workaround in trezor/trezor-mcu#196 but ideally this should become functionality of bn_format

I'm not completely happy with this pull request, but I opened it to be able to discuss this. This pull request changes the API and needs more changes to trezor-mcu to work, see the corresponding pull request trezor/trezor-mcu#97.

The goal of this pull request is to reduce the number of times we compute the public key. This is both for performance reasons and to reduce the side-channel risk. I'm confident that the current implementation is side-channel resistant but if we can avoid computing a public key, we should avoid it. For example for u2f we currently compute 10 public keys, including the master public key for the nist256p hierarchy. With this patch u2f only computes the R value of the signature from the private nonce.

Things I'm not happy with:

• Most functions on hdnode are no longer const, since they may write the public key to the hdnode.
• The previous point is especially true for ed25519 sign, which needs the public key.
• The hdnode becomes stateful. If we compute a hdnode, then use a function that needs the public key and then access the public key, it works. If we later remove the function, the public key would be zero, which is a hard to find bug.
• The unit tests don't test the statefulness of hdnode.
• We now set the first byte of the 33 byte ed25519 public key to 1, to mark the presence of the public key. Currently the Trezor API sets it to 0. (Officially, an ed25519 public key is 32 byte).

The public key is always 33 byte. NIST and SECP public keys use the usual 02/03 prefix byte to mark even/odd compressed public key. ed25519 instead uses a 01 prefix, just to distinguish unset public key.

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.

Decred specific crypto functions

/cc @saleemrashid - could you please review this code and recommend a better way to generalize decred_get_address, decred_message_sign and decred_message_verify?