trezor/trezor-crypto

:lock: Don't use this repo, use the new monorepo instead:

trezor-crypto

Heavily optimized cryptography algorithms for embedded devices.

These include:

• AES/Rijndael encryption/decryption
• Big Number (256 bit) Arithmetics
• BIP32 Hierarchical Deterministic Wallets
• BIP39 Mnemonic code
• ECDSA signing/verifying (supports secp256k1 and nist256p1 curves, uses RFC6979 for deterministic signatures)
• ECDSA public key derivation
• Base32 (RFC4648 and custom alphabets)
• Base58 address representation
• Ed25519 signing/verifying (also SHA3 and Keccak variants)
• ECDH using secp256k1, nist256p1 and Curve25519
• HMAC-SHA256 and HMAC-SHA512
• PBKDF2
• RIPEMD-160
• SHA1
• SHA2-256/SHA2-512
• SHA3/Keccak
• BLAKE2s/BLAKE2b
• Chacha20-Poly1305
• unit tests (using Check - check.sf.net; in test_check.c)
• tests against OpenSSL (in test_openssl.c)
• integrated Wycheproof tests

Distibuted under MIT License.

Some parts of the library come from external sources:

• AES: https://github.com/BrianGladman/aes
• Base58: https://github.com/luke-jr/libbase58
• BLAKE2s/BLAKE2b: https://github.com/BLAKE2/BLAKE2
• RIPEMD-160: https://github.com/ARMmbed/mbedtls
• SHA1/SHA2: http://www.aarongifford.com/computers/sha.html
• SHA3: https://github.com/rhash/RHash
• Curve25519: https://github.com/agl/curve25519-donna
• Ed25519: https://github.com/floodyberry/ed25519-donna
• Chacha20: https://github.com/wg/c20p1305
• Poly1305: https://github.com/floodyberry/poly1305-donna

trezor-crypto's Issues

Possible inconsistency in deterministic ECDSA signature computation

Hello,
I am working on a project, where I want to sign a hash with nist256p1 curve. I have three implementations:

Java - using BouncyCastle with SHA256withECDDSA scheme
Javascript - using elliptic.js with p256 curve
Trezor - using nist256p1 curve

All three implementations are producing correct signatures validable with other implementations. The problem is that for some inputs, the Trezor is producing different signatures (only S component is different).

I am not able to debug the code myself, so I am at least attaching input data, which is producing different results:

hash to sign: ba01d28a1e5b51f66df62d36c478e993c35f4509dbfc590783d759f173921c3d
private key: 2a400b882757e616ed238d0d289884544542f33407d26b01b53964d3a768539e
java/javascript signature: 7da1b8268e1272d7471eef58fa0884108073c09d5efdae0143da5d281019682ea5ea9d0d289b7b15fc861c01418fda56642be628560fe4d7ccdede930e620b5d

trezor signature without first byte: 7da1b8268e1272d7471eef58fa0884108073c09d5efdae0143da5d281019682e5a1562f1d76484eb0379e3febe7025a958bb14855107b9ad26daec2fee0119f4

The signing code is:
signature = nist256p1.sign(privateKey, hash, False)
signature = signature[1:65]

MEMSET_BZERO optimized out for automatic variables

GCC optimizes out the memset call for automatic variables, such as

trezor-crypto/bip39.c

Lines 66 to 69 in 8d8bc9c

	uint8_t data[32];
	random_buffer(data, 32);
	const uint16_t *r = mnemonic_from_data_indexes(data, strength / 8);
	MEMSET_BZERO(data, sizeof(data));

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.

Is secp256r1 supported by TrezorCrypto?

Some crypto (e.g. Elastos) uses secp256r1 for transaction signing

ECDH?

This isn't an issue, just curious if anyone has considered adding ECDH support alongside ECDSA? (at a glance it should be pretty straight forward, I may give it a try if nobody else has yet)

Unknown type name 'namespace'

Hi,
I had your library installed and it worked fine. Now for some reason I get an error "Unknown type name 'namespace'" in config.h line 97. Any Idea why this would happen? I'm using xcode 9.3 with swift 4

Cheers,
K

bip39bruteforce example addresses are recognized as invalid

I tried to use the example addresses which are listed in the source code of bip39bruteforce, but they are "invalid":

$ ./bip39bruteforce 1JAd7XCBzGudGpJQSDSfpmJhiygtLQWaGL
"1JAd7XCBzGudGpJQSDSfpmJhiygtLQWaGL" is not a valid address
$ ./bip39bruteforce 1N3uJ5AU3FTYQ1ZQgTMtYmgSvMBmQiGVBS
"1N3uJ5AU3FTYQ1ZQgTMtYmgSvMBmQiGVBS" is not a valid address

on macOS 10.13.4 compiled with Apple LLVM version 9.1.0 (clang-902.0.39.1)

Trezor stuks on signing transaction - sending BSV anywhere

ECDSA signing

How do I generate the Recovery ID? Ethereum transactions uses v,r,s values how do I generate the value v ?

is there any tests written on this could you please advice and share the line of code ?

Does someone test the hdnode_sign_digest() or ecdsa_sign_digest() function?

I want to know how to check the signature results?

I gets digest form double sha256 with unsigned raw transaction:
Raw transaction: 0100000001378f5c393a37fddeed1dda87ba68d3454e0fa07ca5851243ed708aeb97d240ab010000001976a9142acf413628545d90a926879112579ca1d19f34c688acffffffff0240420f00000000001976a9140a404ac33a7a75a39230cfb07f370650ce35f7c488ac37236500000000001976a914e62c3bdb842e0e9052bee9c22b3d7a8525bb95b688ac00000000

Digest: 83bfba9121294d30dd9c0a698f1f1ec0f30071cccaf11eee6df0b4cdf926040c

after import privatekey and convert signature to der by ecdsa_sig_to_der() function,
I got this: 304502205ecbe4d1a6330a44c8f7ef951d4bf165e6c6b721efada985fb41661bc6e7fd6c022100ade701d4d500304932687867112a946c3a7cbced9d8b1f60751e56173b1c125801

and add this DER message to transaction, I get the signed transaction: 0100000001378f5c393a37fddeed1dda87ba68d3454e0fa07ca5851243ed708aeb97d240ab010000006b48304502205ecbe4d1a6330a44c8f7ef951d4bf165e6c6b721efada985fb41661bc6e7fd6c022100ade701d4d500304932687867112a946c3a7cbced9d8b1f60751e56173b1c1258012102534fd869124dff1cc99c430b97a5b6817b1f8343ce1e1de3ff71d4a3fc6c1592ffffffff0240420f00000000001976a9140a404ac33a7a75a39230cfb07f370650ce35f7c488ac37236500000000001976a914e62c3bdb842e0e9052bee9c22b3d7a8525bb95b688ac00000000

Broadcast this signed transaction to bitcoin test-net in this website: https://coinb.in/#broadcast
and it shows Missing inputs error.

what's wrong with this?

Concern about ecdsa_sign_double()

At line 365-66 of ecdsa.c, if the S value is greater than N/2, you negate S as per BIP 62. However, if I'm understanding that BIP correctly, doing so is not standard yet, although it will be with the next release of bitcoind for v3 transactions. Am I wrong about this BIP, or is this part of ecdsa_sign_double not on the Trezor device? Obviously, there are Trezors generating valid, standard transactions in production, so I'm probably wrong, especially since the lines in question predate that BIP. Thanks in advance!

Side channel issues

According to nullc on reddit (http://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/cnip3wx):

That code may be too slow for the non-static parts of our test to be very effective, as seems to be doing all operations with affine coordinates. Though it appears to be focused on signing and signing is less critical because it can be validated and (in the case of Bitcoin applications) is validated before transmission (and I suppose the host not the device is doing most of the pubkey generation). Independent of the testing, the code you linked to appears to be have a very large timing and power sidechannel-- e.g. timing alone should directly read out the hamming weight of the DSA nonce, even worse than OpenSSL. (and seems to have fairly little testing the repository?). I wouldn't advise using it in any place where that potentially mattered.

bitcoin miner detected in qt wallet

My AV (Sophos) detected a bitcoin miner in the qt wallet install file.

Any comments please?

[bip32] array size of public_key is 33 but the size of uncompressed key is 64

in bip32.h, public key size is 33, uint8_t public_key[33]; as following,

typedef struct {
	uint32_t depth;
	uint32_t child_num;
	uint8_t chain_code[32];

	uint8_t private_key[32];
	uint8_t private_key_extension[32];

	uint8_t public_key[33];
	const curve_info *curve;
} HDNode;

If we follow the following path,
hdnode_get_address -- > ecdsa_get_address --> ecdsa_get_address_raw --> ecdsa_get_pubkeyhash

// function ecdsa_get_pubkeyhash
	if (pub_key[0] == 0x04) {  // uncompressed format
		hasher_Raw(hasher_pubkey, pub_key, 65, h);
	}

the input public key of ecdsa_get_address is node->public_key which is 33 bytes, but in the above case, memory out of 33 bytes (index of 33 to 63) may be touched. It may cause program crash...

It didn't support iOS10 or lower?

Mnemonic -> Ext Key Problem: Usage error or compiler issue.

Hi, I know this is a deprecated library, but I have some legacy code being supported. In converting a mnemonic phrase to an ext key pair, I am able to successfully create a seed and root key, but in creating the m/0' extended key pair, I get a value that does not match expectations. I have pared down the code to the fragment below; am I using the library improperly, or perhaps have I miscompiled with improper flags?

    const char* mnemonic = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about";
    const char* passphrase = "";
    uint8_t seed[SEED_LEN];

    // generate seed: this creates a value that matches expectations.
    mnemonic_to_seed(mnemonic, passphrase, seed, 0);

    char rootkey[KEYLEN], extprivkey[KEYLEN], extpubkey[KEYLEN];
    uint32_t fingerprint = 0;
    HDNode node;

    // generate master node: creates a value that matches expectations
    hdnode_from_seed(seed, 64, SECP256K1_NAME, &node);
    hdnode_fill_public_key(&node);

    // extract node root key
    hdnode_serialize_private(&node, fingerprint, VERSION_PRIVATE, rootkey, sizeof(rootkey));

    // generate m/0' ext key pair.
    hdnode_private_ckd_prime(&node, 0);
    hdnode_fill_public_key(&node);

    // private & public key buffers do NOT match expected value.
    hdnode_serialize_private(&node, fingerprint, VERSION_PRIVATE, extprivkey, sizeof(extprivkey));
    hdnode_serialize_public(&node, fingerprint, VERSION_PUBLIC, extpubkey, sizeof(extpubkey));

Edit: Adding output.
Ext Private Key generated: xprv9tu9RdvSZ2FH6WseyBa1Kcbi7v9VteFDou2GDKGuSApf8Q55p47noHAjQ4qRWyLBBykBHBoy5oepeHMFshu7rahxbjRWrAJnikYytMrwAd1
Expected Value (from IanColeman.io/Bip39): xprv9ukW2Usuz4v7Yd2EC4vNXaMckdsEdgBA9n7MQbqMJbW9FuHDWWjDwzEM2h6XmFnrzX7JVmfcNWMEVoRauU6hQpbokqPPNTbdycW9fHSPYyF

bip39 support multi-languages

English is not enough
how about Chinese, Japanese, French ...
I think must refactor code.

Improper naming of a signature recovery function.

The ecdsa_verify_digest_recover(...) function only recovers an address from a signature and a hash, and does not verify it.
The name is is misleading and could be wrongly used IMO.

trezor-crypto/ecdsa.c

Line 1028 in 9c2cfb0

int ecdsa_verify_digest_recover(const ecdsa_curve *curve, uint8_t *pub_key, const uint8_t *sig, const uint8_t *digest, int recid)

bip39 entropy vector too short for strength > 128

in bip39.c
const char *mnemonic_generate(int strength)

allocates 16 bytes for entropy irrespective of the strength, this likely leads to array index out of bounds if strength > 128 in const char *mnemonic_from_data(const uint8_t *data, int len)

Add integer and faux division support to bn_format

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

Support (de)Serialization of BIP32 HD Nodes as per the BIP32 spec

Cannot find a function that uses public key to encrypt a certain message

i want a function that takes (public key , message to be encrypted, buffer contains encrypted message)

is their a function like that in your library

trezor sig can't pass etherscan verification

https://www.myetherwallet.com/signmsg.html

use trezor to sign message via myetherwallet.
it will fail on https://etherscan.io/tokenupdateverifysig.

UndefinedBehaviorSanitizer Results

See trezor/trezor-mcu#279

bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:155:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bip32.c:171:27: runtime error: left shift of 190 by 24 places cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bip32.c:171:27: runtime error: left shift of 189 by 24 places cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bip32.c:171:27: runtime error: left shift of 190 by 24 places cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bip32.c:171:27: runtime error: left shift of 148 by 24 places cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bip32.c:171:27: runtime error: left shift of 190 by 24 places cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
ed25519-donna/curve25519-donna-32bit.c:410:8: runtime error: load of misaligned address 0x7ffe1434a239 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
0x7ffe1434a239: note: pointer points here
 1f 33 32  40 d1 d5 c3 64 32 2c 41  11 af 1c 90 ed a6 8f b6  64 98 4b 76 e2 e7 63 7e  da f5 e9 81 da
              ^ 
ed25519-donna/curve25519-donna-32bit.c:411:8: runtime error: load of misaligned address 0x7ffe1434a23d for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
0x7ffe1434a23d: note: pointer points here
 d1 d5 c3 64 32 2c 41  11 af 1c 90 ed a6 8f b6  64 98 4b 76 e2 e7 63 7e  da f5 e9 81 da fc 5a bf  6b
             ^ 
ed25519-donna/curve25519-donna-32bit.c:412:8: runtime error: load of misaligned address 0x7ffe1434a241 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
0x7ffe1434a241: note: pointer points here
 32 2c 41  11 af 1c 90 ed a6 8f b6  64 98 4b 76 e2 e7 63 7e  da f5 e9 81 da fc 5a bf  6b 00 00 00 00
              ^ 
ed25519-donna/curve25519-donna-32bit.c:413:8: runtime error: load of misaligned address 0x7ffe1434a245 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
0x7ffe1434a245: note: pointer points here
 af 1c 90 ed a6 8f b6  64 98 4b 76 e2 e7 63 7e  da f5 e9 81 da fc 5a bf  6b 00 00 00 00 00 00 00  b0
             ^ 
ed25519-donna/curve25519-donna-32bit.c:414:8: runtime error: load of misaligned address 0x7ffe1434a249 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
0x7ffe1434a249: note: pointer points here
 a6 8f b6  64 98 4b 76 e2 e7 63 7e  da f5 e9 81 da fc 5a bf  6b 00 00 00 00 00 00 00  b0 cb 15 d5 d8
              ^ 
ed25519-donna/curve25519-donna-32bit.c:415:8: runtime error: load of misaligned address 0x7ffe1434a24d for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
0x7ffe1434a24d: note: pointer points here
 98 4b 76 e2 e7 63 7e  da f5 e9 81 da fc 5a bf  6b 00 00 00 00 00 00 00  b0 cb 15 d5 d8 55 00 00  00
             ^ 
ed25519-donna/curve25519-donna-32bit.c:416:8: runtime error: load of misaligned address 0x7ffe1434a251 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
0x7ffe1434a251: note: pointer points here
 e7 63 7e  da f5 e9 81 da fc 5a bf  6b 00 00 00 00 00 00 00  b0 cb 15 d5 d8 55 00 00  00 00 00 00 00
              ^ 
ed25519-donna/curve25519-donna-32bit.c:417:8: runtime error: load of misaligned address 0x7ffe1434a255 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
0x7ffe1434a255: note: pointer points here
 f5 e9 81 da fc 5a bf  6b 00 00 00 00 00 00 00  b0 cb 15 d5 d8 55 00 00  00 00 00 00 00 00 00 00  4c
             ^ 
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bip32.c:171:27: runtime error: left shift of 188 by 24 places cannot be represented in type 'int'
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
sha2.c:469:8: runtime error: load of misaligned address 0x55d8d4f0d767 for type 'const sha2_word32' (aka 'const unsigned int'), which requires 4 byte alignment
0x55d8d4f0d767: note: pointer points here
 31 36 46 00 30  31 32 33 34 35 36 37 30  31 32 33 34 35 36 37 30  31 32 33 34 35 36 37 30  31 32 33
             ^ 
sha2.c:471:3: runtime error: load of misaligned address 0x55d8d4f0d767 for type 'const sha2_word32' (aka 'const unsigned int'), which requires 4 byte alignment
0x55d8d4f0d767: note: pointer points here
 31 36 46 00 30  31 32 33 34 35 36 37 30  31 32 33 34 35 36 37 30  31 32 33 34 35 36 37 30  31 32 33
             ^ 
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
test_check.c:3031:30: runtime error: left shift of 9 by 28 places cannot be represented in type 'int'
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
test_check.c:3031:30: runtime error: left shift of 9 by 28 places cannot be represented in type 'int'
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:843:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
bignum.c:843:28: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
bignum.c:120:15: runtime error: shift exponent 32 is too large for 32-bit type 'uint32_t' (aka 'unsigned int')
nem.c:217:11: runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
nem.c:547:11: runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
nem.c:295:11: runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
nem.c:324:11: runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
nem.c:364:11: runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
nem.c:423:11: runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
nem.c:509:11: runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
nem.c:547:11: runtime error: left shift of 152 by 24 places cannot be represented in type 'int'
address.c:53:45: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'

How can i use AES with trezor

Hi All,
I am new to trezor, I would like to use AES encryption for my keys stored in trezor. Is it possible?
Is there any documentation available how trezor handles keys?

Regards
Lakshmikanth

Why is this compiled by default with -0s -g

Compiling with -O3 instead cuts running time by 27% for me,
it should at least be a build option.
I don't mind fixing that BTW.

Trezor-crypto Documentation

Hi Guyz,
Is there by any chance guyz you will be providing a documentation for the trezor-crypto library(functionalities&methods)? the library is really neat and well implemented, and I am studying it to see if I can integrate it in my current embedded crypto project, I am trying to go along with the examples, but I think it will be better if there's a simple documentation explaining the supported functionalities of the library along with each method.
Thanks,

rand.c WIN32 code path

I've noticed that you use srand(time(NULL)) before each random32,
this is not a good idea as time() it has a granularity of 1 second (!!!!) so it's very likely
that a sequence of random32 calls generates the same pseudo-random numbers...
Also, using rand() on Windows means naive LCG.
This very unsafe IMHO.

I'm wondering - why not replace it with CryptoAPI's CryptGenRandom?

Support schnorr signature

Hi

Any plan to support schnorr signature? some blockchains (e.g. Zilliqa) use it. There are some implementations using openssl, I wonder if trezor-crypto can support it too

Thanks

AddressSanitizer Results

=================================================================
==12714==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffeb5e4141f at pc 0x557118e3a63e bp 0x7ffeb5e411c0 sp 0x7ffeb5e40970
READ of size 22 at 0x7ffeb5e4141f thread T0
    #0 0x557118e3a63d in __asan_memcpy (test_check+0x15863d)
    #1 0x557118f64f97 in sha256_Update sha2.c:916:3
    #2 0x557118f6dfa9 in hasher_Update hasher.c:45:3
    #3 0x557118f6dfa9 in hasher_Raw hasher.c:73
    #4 0x557118f585ac in b58check base58.c:133:2
    #5 0x557118f585ac in base58_decode_check base58.c:218
    #6 0x557118f4a0dc in ecdsa_address_decode ecdsa.c:951:9
    #7 0x557118ee9ad8 in test_address_decode test_check.c:2954:8
    #8 0x7f64fb7b4cb7 in srunner_run_tagged (/usr/lib/libcheck.so.0+0x5cb7)
    #9 0x557118f29bdf in main test_check.c:4626:2
    #10 0x7f64fa88af49 in __libc_start_main (/usr/lib/libc.so.6+0x20f49)
    #11 0x557118d90b49 in _start (test_check+0xaeb49)

Address 0x7ffeb5e4141f is located in stack of thread T0 at offset 447 in frame
    #0 0x557118f6de2f in hasher_Raw hasher.c:69

  This frame has 1 object(s):
    [32, 168) 'hasher' (line 70) <== Memory access at offset 447 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow (test_check+0x15863d) in __asan_memcpy
Shadow bytes around the buggy address:
  0x100056bc0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056bc0240: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x100056bc0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056bc0260: 00 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00
  0x100056bc0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100056bc0280: ca ca ca[ca]00 00 00 01 cb cb cb cb f1 f1 f1 f1
  0x100056bc0290: 00 00 00 00 f2 f2 f2 f2 00 f3 f3 f3 00 00 00 00
  0x100056bc02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056bc02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056bc02c0: f1 f1 f1 f1 00 00 00 00 00 04 f2 f2 f2 f2 f8 f8
  0x100056bc02d0: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==12714==ABORTING

Archive this repository

Maybe would be good to mark this repository as an archive to make it more clear to new developers that the codebase is moved and no longer accepting PRs.

HD node from xpub

Please advice the usage of hdnode_from_xpub function on bip32 is there any tests thats related to this function ?

Question: AES instruction set

I see you don't support the AES instruction set if it's the right cpu, is it because you guys work with a different architecture?

random32 vs. random_buffer

Looks like recent commits have picked random32() as the lowest common denominator for generating randomness.

That's ok, but in my case, I would rather base things on random_buffer() due to the way bits are generated on my platform.

IMHO, both functions should be available for override or customization, and probably random_buffer should be the more basic once. On the one hand, it's easy to ask for a 4-byte random buffer, but building a byte string from a number of calls to a 32-bit function has the potential for bugs.

Alternatively, marking random_buffer() with weak linkage would solve my needs.

[Support] Need guideline and building unitTest for osx

Dear team,
We love your work, please help support us on how to build current unitTest for bip32 (available in sourcecode). We tried building but still got below error.
Many thanks
John

How Base58 encoding algorithm works?

I'm trying to understand your implementation of the Base58 encoding algorithm:

bool b58enc(char *b58, size_t *b58sz, const void *data, size_t binsz)
{
    const uint8_t *bin = data;
    int carry;
    ssize_t i, j, high, zcount = 0;
    size_t size;

    while (zcount < (ssize_t)binsz && !bin[zcount])
	    ++zcount;

    size = (binsz - zcount) * 138 / 100 + 1;
    uint8_t buf[size];
    memset(buf, 0, size);

    for (i = zcount, high = size - 1; i < (ssize_t)binsz; ++i, high = j)
    {
	    for (carry = bin[i], j = size - 1; (j > high) || carry; --j)
	    {
		    carry += 256 * buf[j];
		    buf[j] = carry % 58;
		    carry /= 58;
	    }
    }

    for (j = 0; j < (ssize_t)size && !buf[j]; ++j);

    if (*b58sz <= zcount + size - j)
    {
	    *b58sz = zcount + size - j + 1;
	    return false;
    }

    if (zcount)
	    memset(b58, '1', zcount);
    for (i = zcount; j < (ssize_t)size; ++i, ++j)
	    b58[i] = b58digits_ordered[buf[j]];
    b58[i] = '\0';
    *b58sz = i + 1;

    return true;
}

In particular I do not understand these lines:

• size = (binsz - zcount) * 138 / 100 + 1;
• carry += 256 * buf[j];

what do they precisely do? Thanks for sharing your code

ecdsa point_multiply overread bug?

        for (i = 62; i >= 0; i--) {
                // sign = sign(a[i+1])  (0xffffffff for negative, 0 for positive)
                // invariant jres = (-1)^sign sum_{j=i+1..63} (a[j] * 16^{j-i-1} * p)

                point_jacobian_double(&jres, curve);
                point_jacobian_double(&jres, curve);
                point_jacobian_double(&jres, curve);
                point_jacobian_double(&jres, curve);

                // get lowest 5 bits of a >> (i*4).
                pos = i*4/30; shift = i*4 % 30;
                bits = (a.val[pos+1]<<(30-shift) | a.val[pos] >> shift) & 31;

On the first iteration (i = 62) it tries to access a.val[9], which is out of bounds. ((62 * 4 / 30) + 1).

secret sanitization

mnemonic_from_data()s interface prevents cleaning up secrets in RAM after it has done the conversion, since it returns a const char * into a static buffer.

trezor-crypto/bip39.c

Line 73 in c34e8ab

const char *mnemonic_from_data(const uint8_t *data, int len)

trezor-crypto/bip39.c

Line 88 in c34e8ab

static CONFIDENTIAL char mnemo[24 * 10];

While it does mark the memory CONFIDENTIAL, it would be better if the caller could zero it at its earliest convenience. A couple of options I see:

1. Make it take in working buffer, so the caller can clear it itself.
2. Make it return a char * so the contents can get memzero(foo, strlen(foo))-ed as necessary.
3. If data argument is null, memzero the buffer.
4. Cast away the const (gross).

Which is preferable to you? I'm happy to submit PR(s).

Returning pointers to static memory in bip39.c

In bip39.c, functionsmnemonic_from_data() and mnemonic_from_data_indexes() return a pointer to static memory. This is bad for two reasons:

• the static memory, at maximum possible size, is allocated forever, even if I never call the function
• the caller may not know there is a hidden shared buffer between calls, and that can lead to some really nasty bugs, depending on the lifetime of the returned pointer in the caller's code.

I think these two function should be changed so that the output value is an argument (as a pointer). It's an API change though.

buffer overflow [UPDATE]: My bad. Other problem: python wrapper can't open random file.

Hi, I tried to run the python wrapper and got a segfault. I dug deep into what's causing it, and found that
there's a buffer overflow in ecdsa.c in scalar_multiply function

    for (j = 0; j < 8; j++) {
        a.val[j] = (a.val[j] >> 4) | ((a.val[j + 1] & 0xf) << 26);
    }

but a.val[9] is out of bounds. I'm not sure yet what's supposed to be there but it's not that.

SHA1 Algorithm

This is a requirement for OpenPGP support

An implementation can be found at http://www.aarongifford.com/computers/sha2-1.1-ALPHA.tgz

Note for porting (from http://www.aarongifford.com/computers/sha.html)

The latest version is 1.1 adds SHA-1 and SHA-224 functionality. However, the new version does consolidate the SHAxxx_CTX data structure into a single SHA_CTX structure (union), which means a minor, quick edit to anything interfacing with the implementation using the 1.0 style interface.

Who wants to take this up?

/cc @prusnak @jhoenicke

Signature Message Verification Failed

Hi, apparently this is a know issue with Trezor? But the related previous call was closed without resolution.

What is the plan to resolve this as it a a major stumbling block in functionality. I (and others) cannot confirm ownership of our addresses (https://etherscan.io/verifysig) and so cant engage with specific project! https://www.napoleonx.ai/

What is the plan and timeline to resolve this? How can we help??

ECIES Support

Can we get ECIES support for encryption/decryption?