Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 192. (Read 966173 times)

Unfortunately I can't see any difference, it looks like before , no instructions even after reload.

I've just posted more details about AES support in Trezor to our trezor-dev mailing list: https://groups.google.com/forum/#!forum/trezor-dev . All developers are welcome to join!

Please go to mytrezor.com and follow on-screen instructions.

Hi, what is the recommended way of updating FW?

New Trezor firmware 1.1.0 has been released, update is optional as there're no security fixes.

Thanks to community feedback we've just done few minor UI changes, cleaned the code and fixed some bugs about handling inputs coming from multisig addresses. We've also added the possibility of encrypting/decrypting key-value pairs using AES, although myTREZOR does not support it yet. However some cool features in myTREZOR using key-value AES encryption will be announced soon :-).

That's why we would love to setup a deterministic build environment using Vagrant or Docker. So independent "builders" can easily run it and confirm that the signed distributed binary comes really from the published source which can be audited. Currently other tasks have higher priority, though.

Let me be clear here. I'm talking about ALL wallets, not just Trezor. Using above techniques, you can have deterministic signatures, that comply with RFC6979 most of the time and when they don't they leak your seed. You will not detect is, because the only test you actually do is to check whether it is deterministic, not whether it is RFC6979 compliant (i.e. equality across multiple runs). You can sell or spread your hardware/software wallet for a while while collecting the keys and when competition crushes you eventually, then you can use all those seeds you collected to clear their wallets and fly to Carribean.

I'm not saying that this is Trezor guys intention. I'm just saying that if this was any wallet maker intention it would be EXTREMELLY difficult to find. It is easy to prove it from code, but I disagree that it is simple to prove in blackbox testing. It depends on your luck. From this perspective I really like this initiative of signing the build by third parties. If only everybody did this. But still there are problems like the bootloader that is not signed by anyone etc.

You see, proving that you are not evil is difficult. In a sense, it is similar to using random K in signatures. In the code it is easy to see whether the number comes from the HW rng that is on the chip (much simpler than checking your RFC6979 implementation). But it is impossible to prove this from the generated signature.

All these attack vectors are actually very easy to find in source code or even by blackbox testing. We're preparing deterministic build environment for Trezor firmware, so then any interested developer will be able to read sources, build them and compare hash with hash of signed firmware release by SatoshiLabs. Then he can publish on his website (and sign with his gpg key) that he agreed that our binary distribution does what it is supposed to do.

Actually we would like to have a network of independent code reviewers, who will read our commits and sign every stable release. Then it will be extremely hard to prepare any attack even by us. If anybody here is interested in such job, please email to [email protected].

thanks for your answer.

let me comment on the items in your list while thinking of RFC6979 compliance testing (assuming it's possible and done by at least some):


RFC6979 non-compliance can be detected with any single transaction above 10 BTC (there are going to be many of these, because "change")  


RFC6979 compliance test will result in: FAIL (or am I wrong here? not sure)


even if they only leak the seed in a low percentage of transactions, there is risk of detection by RFC6979 compliance test. Once detected, shit hits fan and it's over for them. Risk too high for reward (at least compared to when using random k)


Since all of above are weak approaches, this one is also weak.


In my opinion it's not. True random k cannot be checked for at all. It's easy to slowly leak the seed (bit by bit if need be, or completely in one go XORed with or encrypted to attacker secret) in the "random" numbers without anyone being able to prove it. (just noticed XOR would be a bad idea since it would enable "freeloaders")

Storage is part of "Bitcoin" in the broader sense.

There are million of ways how wallet devs (including trezor devs) can leak your seed. Some quick ideas:

1. Use above when the amount is above 10BTC (you don't care about poor guys anyway).
2. Use only last 16bits of RFC6979 and xor this with seed. This way k is still deterministic, but easy to break.
3. Leak the seed in 1000th transaction (or milionth...)
4. Leak the seed with some particular transaction. I.e. if the amount mod 97 is 32, leak the seed.
5. Leak the seed with the special, undocumented command in the interface.
6. Combine some of above or invent your own.

In my opinion, the true random k is a better option than RFC6979, but some devs don't even know how to generate random numbers and they still write wallets to store your money....

It will/does not change bitcoin security .. its just a way to store your money securely

Looking forward to it's release! Hope this will change bitcoin security

Haha, good point!

Yes, and that's why I thanked you for your suggestion .

I had noticed that the potential attack I was talking about was misunderstood by some. Sorry for repeating myself and reordering your answers.

BTW: Don't you need some sleep? You've been up until at least 3 last night and going at it again already? Well, good morning

Right. That's why I continued with the comment and suggested the check against other BIP39+BIP44+RFC6979 implementations (which currently might be just Wallet32 or at least very close to it).

Thanks, stick, for that description / suggestion. I will try this once I get my plastic trezors (I have my metal one in "productive" use now and don't want to fiddle with it).


Seeing they are deterministic isn't an indication against you potentially leeking seeds through the k value, is it? Even if you leaked seeds like that, signatures could still be deterministic.

Btw: thanks again for an awesome product, I can't wait to give some plastics away to friends, who I can then finally offer a good method to store their BTC.

I think you're wrong: the idea could be for the trezor devs to use k = in order to leak the seeds of people to the blockchain, visible only to them, of course.

It's a potential attack by the trezor devs, not just anyone.

so... 3 to 7 weeks. Good news everyone!

The seed is "compromised" in a sense that some information about it is revealed. But the seed is not revealed itself. That is the whole reason to use HMAC in keys derivation. There is no known method to derive other siblink private keys in the deterministic wallets, i.e. no way to steal BTC. You can derive children nodes in the hierarchy, but those are not used for anything.