But there is no easy way to make sure that the software that they are checking is what is stored in the device, is there?
We prepared a deterministic build environment, so it's easy to compile the firmware from source and produce bit identical binary to ours and compare them (or their hashes). We'll prepare more materials about how to check this/participate in the signing on the next firmware update. |
|
|
|
I'm not sure if Trezor supports it already, but shouldn't the payment protocol solve that particular problem?
Yes, it does solve it. Payment protocol is planned for the future TREZOR releases. |
|
|
|
Is it possible to use Trezor from an android phone?
Not yet. There is a library that allows Android app to communicate with TREZOR here: https://github.com/trezor/trezor-android and BitcoinJ people are working on adding necessary stuff (BIP39, BIP44) to their library so we'll have everything needed to build a TREZOR App for Android. |
|
|
|
good job, I was hoping for the (beer-proof) black one though
The "First Edition" engraving looks SO much better on white one. |
|
|
|
My thought was that you guys might want to collaborate to standardise the way everyone uses the Trezor
We'll address this in the upcoming SLIP document. SLIP stands for SatoshiLabs Improvement Proposal and it will be a repo for specifications which are not suitable for inclusion into BIP repository for various reasons. My current idea is to follow BIP-0043 and set the deterministic hierarchy path to m/N'/a'/b'/c'/d' where N will be the spec number and a,b,c,d are values derived from hash(domain_name) so each domain will get different key automatically. (BitId and BitAuth don't deal with automatic assigning of keys from deterministic pool at all and assume that user will do that manually, which is very clumsy and non-intuitive resulting in reuse of login keys similar to password reuse we see today). |
|
|
|
860k tries per second per core here (Intel(R) Core(TM) i5 CPU @ 2.67GHz) but I'd guess it could be improved if written entirely in C, or even better in OpenCL....
I don't think that GPU can beat CPU with AES-NI. |
|
|
|
Now stuck at "ImportError: cannot import name enum_type_wrapper"... maybe my protobuf is too old.
Protobuf has to be version >= 2.5.0. Also please move devel discussion to the mentioned list. Forum is horrible for more complex discussions because of the missing threads. |
|
|
|
Just had one question. Think it'd be possible to investigate integrating FrozenBit into it?
Wrong question. It should read "Would it be possible to integrate TREZOR into FrozenBit?" and the answer is Yes. :-) |
|
|
|
UPDATE: It is working - it seems to take a lot longer than 15min.
"Venue data are updated every hour." - it's written on the site. |
|
|
|
Email as a tech support communication methodology is piss-poor
Support email is tied to our ticket system, so don't worry about it ... |
|
|
|
I've identified a bug in the trezor environment and hopefully the developers will be listening and fixing...
Please use email support@bitcointrezor.com for reporting issues. Things reported here tend to get lost because of high signal-noise ratio. Thank you. |
|
|
|
The Trezor firmware upgrade procedure is not handicap friendly. You may be thinking so what, but consider you may find yourself likewise one day, you know, the day you start hating the world?
Could you be please more specific? Do you mean that it is hard to press both buttons at once, or something else? |
|
|
|
But it is impossible to prove this from the generated signature.
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. |
|
|
|
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  Haha, good point!  |
|
|
|
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.
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). |
|
|
|
is this already launched?
what's the price?
It will be launched in July. Price will be announced then. |
|
|
|
I have a question (to devs or anyone else): I read trezor uses RFC6979 deterministic ecdsa signatures to prevent leaking of seed or any other private data through the "random" number used in non-deterministic signatures. I read that hereIs there an easy way to check wether this is true by looking at a transaction signed by trezor? You can easily see that the signatures produced by TREZOR are deterministic, because they produce same result for same combination of private key/message (that's what we use in unit testing afterall ...) I am not sure if BitcoinJ uses deterministic signatures by default and if they use the same pseudorandom function as described in RFC6979, but if both are true you can try importing TREZOR's seed into Wallet32 and see if they produce the same signatures for the same combination of privkey/message. |
|
|
|
So I could generate the root-seed for the account#1 and use the resulting priv key as new root-key?
can I strip a part of the tree by deriving the privkey of one account and feeding it to some BIP32 enabled wallet to 'share' the subkeys?
You understand my question? I'd like to use 'account#1' for daily stuff on my phone and still have phone+trezor synced!
It is possible to generate seed in TREZOR, load recovery words into software that supports BIP39+BIP44 on an offline computer, and let the software generate xprv key for first account. Then import this xprv key into Wallet32. At the moment it is a theoretical thing, because all these processes are not very easy to do yet and you have to trust your offline computer that does the computation. Once this process is easy we might offer this a feature for advanced users, but we don't want beginners to enter private seed anywhere, because of the security implications. |
|
|
|
|
Show Posts
