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

just a small post to let you know my USB cable died today. I tried a different one and my Trezor is still ok.

(thanks for replying to our e-mail. We will reply in a few days)

There is no limit for the number of "hidden volumes". Trezor does not keep their list. It just can recover all those account addresses  when you enter that particular passphrase again. I don't understand the "no-passphrase entry" question. Can you please rephrase it? You have two options for setup: You either create 1. passphrase protected Trezor or 2. Trezor without passphrases. In the latter, you will never be prompted for passphrases. What does "no access to anything when a passphrase is not entered" mean? You are able to store your BTC on Trezor in second setup (without passphrases) as well.

Back to the original question:
"Is this just as secure as a paper wallet?" No. It cannot be. However it's much more useful, because from this wallet you can actually spend. It's also very easy to use. Creating a really secure paper wallet is difficult. Setting up and using Trezor is easy.

"requires you the manufacturer to actually have access to the private keys" This statement is dead wrong. In many services out there, the main premise is that end user cannot keep his private keys secure, thus he should keep it with some online service that will take care of security. This creates just another issue for the user, because he now has to keep his service credentials secure and he has to trust the service provider so he is in even more difficult situation. Trezor is different. It lets you own your private keys without manufacturer knowing anything about you. In theory, Satoshi Labs can recover your seed from the device if the device is still working and they have physical access to it. But that is only if you are not using passphrases and give them the device and they actually want to recover your seed.

Without the physical access to the hardware, there is only a single way manufacturer could get your keys: backdoor. There is a catch though. If your bitcoins are stolen by a malware or a hacker, then you are just screwed. If your btc is stolen by an open software, open hardware backdoored device, then you can sue somebody. I assume their liability for a software bug is at the zero level. Their liability for a money stealing backdoors is a complete different story. That is fraud and you can sue it everywhere in the world.

Also, your statement that checking the software is not viable in practice is wrong. They use deterministic build so everybody can check that the software is what it is supposed to be. Also, the software is single purpose, thus small, thus verifiable for backdoors.

Correct. Since firmware 1.2.1 there is a message called ClearSession that forces TREZOR to "forget" cached PIN and passphrase. The idea is that client sends this message after few minutes of user inactivity or when a screensaver kicks in or when a screen is locked.

Seems interesting, will be adding this to my wishlist.

The hardware can be checked by feeding it known inputs and checking that the output matches what's expected.

Their build process is deterministic, so you can in fact check that the signed binary matches the open source code. It is also not true that every individual has to check the code every time there is a release, it can be done on an ongoing basis by a community of semi-trusted individuals.

You're really reaching, aren't you? What's your angle here exactly?

Checking the hardware is viable only with sophisticated lab equipment.  To check the software, someone whould have to carefully check the source code (at every release) for malicious backdoors or weaknesses, and then the client would have to check that the compiled firmware that he is loading, duly signed by the manufacturer,  matches that source code.  Obviously neither is viable in practice, except after the fact.

Got my Trezor today.

I have successfully set up the multi-passphrase encryption structure.

It appears that every time that I access the Trezor, I have an opportunity to create a new hidden volume.  Out of curiosity, is there a limit to the number of volumes?  If I reach the limit, how will the Trezor behave when a new volume is attempted to be made.

My real question is about the no-passphrase entry.  I tried it, and it appears that I have no access to anything when a passphrase is not entered.  I recall reading somewhere about different behavior based on whether a passphrase box is checked.  Does anyone have any clarity on pitfalls to watch out for?

Overall, I'm very impressed with the Trezor!

Hm, just searched a bit in the firmware code.

Couldn't find anything about a timeout.

But there's a "session_clear()" function which clears the PIN, cached root node and cached passphrase. There's also an accompanying protocol message to invoke it. Maybe it's the wallets responsibility to clear the session via this message.

It's the same with myTrezor, I believe the Trezor caches the PIN for some period of time or until it's unplugged, I'm not sure which.

I just realized I had very bad security practices involving the trezor:

I use it with electrum (don't do this yet, it's not for the faint of heart, wait for electrum release 2.0).

I just leave my wallet (electrum) open with the trezor plugged in. That's a bad idea.

For some reason I assumed the PIN would be asked every time. But it seems the trezor will remember passphrase and pin auth, so anybody could walk up to my computer and make a transaction without knowing password or PIN.

So note to self: always unplug the trezor when done, especially when having entered the PIN.

Suggestion/question: could the trezor have a timeout on the PIN and re-ask after it has elapsed? Same for passphrase.

Well, if the manufacturer of a hardware wanted to get the client's keys, they could do it very easily. 

If you use a special-purpose hardware to store your keys, you have to trust the manufacturer.  I see no way around it.

Hi, stick!

Can you answer what do you plan with same problem?
I described it into 113th page. But i didn't find your answer. But it can be very seriously


Here is only my fix now: path not BIP32 but path of BIP44
This problem can occur not only with infected computer but by using middle man attack in any part of routing.

And other user already asked you about this after my post:


Please don't suggest import xpub to other device. xpub key to be showed by mytrezor.com too so if computer was infected or there middle man attack the xpub key can be changed too. So i think you should add the check option for receiving addresses right in the Trezor.

If you think well, now there is no reliable way to trust and verify addresses for receiving money. Is not it so?

The keys are generated using entropy from the trezor plus entropy from the computer you plug into.  There's no way for the manufacturer to know your keys.

A bit too complicated for us non-developers.  Hopefully a more consumer-friendly summary will be maintained someday.

Is this just as secure as a paper wallet? I should imagine it isn't because it requires you the manufacturer to actually have access to the private keys?

Probably now what you would expect, but Github has nice commit history: https://github.com/trezor/trezor-mcu (firmware) + https://github.com/trezor/webwallet (mytrezor)

Is there a place online that has the history and details of myTREZOR.com and firmware updates?

Sorry to bother you here guys, but can you please look into my e-mail concerning a bulk purchase of 100 trezor devices? I am organizing a Bitcoin congress and we would like to be able to sell a Trezor Device to the people who show up. Most of them are not tech savvy and in one of the sessions we will be explaining the different wallet options. We would like to explain them how the Trezor works and I guess a lot of them will want to buy one.

Sorry for posting it here. I know you are busy, but the event takes place at the end of september. So we would like to know if it will be possible to have them delivered before that deadline.

We'd need to update the firmware to extend the API to allow this change. I noted that in my Trello board and once we ship this feature via a version update then we can add it to myTREZOR.