Topic: BitcoinSpinner - page 3. (Read 55544 times)

This is an important argument. It should be noted, however, that it is relevant if private key is in the raw, 32-byte form. If it is, the attacker has no idea whether he got the right passphrase until he performs ECDSA to create the public key, then ripemd160(sha256()) to create the address, and then search the blockchain for the address. That's a lot of work for each try, and only when you get lucky can you start hoping that there are unspent outputs.

In case of the usual WIF-encoded private keys, it seems easier because of the checksum. First of all, the brute-force attacker checks if candidate begins with a "5". Next, she converts it to hex, and checks if last four bytes are sha256(sha256()) of the remainder. If not, move on. If yes, only then search the blockchain. This eliminates most of slow steps related to blockchain search.

Does this make sense? How does computational burden compare between all the hashing and checking the blockchain in the above examples?

The actual JPEG would not be encrypted. The private key is encrypted and then turned into a Base58 encoded string which is present as text and a QR code in the JPG. This way you can easily and safely print it out using your computer or whatever.
Before Base58 encoding a short byte header will be added (magic byes) which allows the wallet to detect that this is an encrypted private key.

Regarding the passphrase:

Very few people can remember a strong passphrase that cannot be brute forced (I for one can't). We have already seen brute forced brainwallets, and IMO brainwallets are a generally bad idea: http://www.reddit.com/r/Bitcoin/comments/1b8yde/be_careful_with_brain_wallets_there_are_people/ and http://www.reddit.com/r/Bitcoin/comments/1j9p2d/blockchaininfo_unauthorized_transactionhow_could/

The thing is that many people think that their password is safe as they use something of similar size/complexity on web-sites. However, on a web-site the attacker cannot really brute force it until he has access to the encrypted password file or a hash of the password (maybe with some seed). Without this the hacker is left with a few attempts a second (through the web-page login), with the risk of locking the account he tries to gain access to. With brainwallets the attacker can start brute forcing  with trillions of attempts a second just by looking at the blockchain. (or in the case of a paper backup, once he has access to the encrypted private key).
I really want Mycelium users to use safe and verifiable mechanisms that do not lure them into using something that they think is safe while it is not.

To have something as strong as our private key need 128 bits of entropy. That is a very long and very complex passphrase. The average user would need it generated for him and put on paper.

Sorry for the rant

This is certainly true if you encrypt a JPG image, as a cracking program can easily check whether a brute-force result yields a valid JPG file.

It may be much more difficult with just the text of the key, because that looks like gibberish anyway. Even with a relatively short password, many brute-force attempts may yield some similar gibberish, so the cracking program cannot discern the valid key from other wrong results with wrong passwords.

But anyway, the password should not be too short.


Yes, sounds very good to me. I am still not sure how useful it would be in the real world, how many users would actually use it, etc.

I would also tend to offer a passphrase entered by the user, because there are some people who can remember it. That would protect against theft of the paper wallet.

(For example, I have a method of constructing passwords by taking a few letters from the name of the object, like from a domain name or from "Mycelium", and encrypting them mentally, before adding some static salt, which I can remember, because it is always the same. Otherwise my poor memory could never cope with the many passwords I have to remember. But that is another matter.)

Wouldn't Wuala be an option for that (if you trust LaCie, that is). https://www.wuala.com/

They got an Android app too. So, you could have a "Share" or "Send to" option within Mycelium that would send the key info straight to Wuala.

Interesting idea.

One of the current export features allows you to export directly from a phone to a printer with no intermediate computer. Demo: http://www.youtube.com/watch?v=W7V2myIwAuE
So if you have a trusted phone and printer that accepts SD-cards, this is a very viable solution.

As you say, passwords can be forgotten.  Also, passwords have to be strong to have any real effect (unfortunately making them easier to forget).
Therefore the best solution for encrypted export I have seen is this:
The wallet exports a JPG image which contains the encrypted private key both as text and a QR-code (also contains bitcoin address, label etc). The encryption key is derived from a passphrase. The passphrase is automatically generated and contains enough entropy to make brute force unfeasible.  The JPG goes to the SD-card, an email, dropbox, or whatever. The passphrase is only displayed on the device once during export.

The user has to write the passphrase down, as it is impossible to remember. This can be on a printout of the JPG or on something else.
We can add a "Verify Export" feature that allows you to verify that your key can be imported, keys that have been verified get tagged.
We can add a feature that nags you as long as you have not verified all your keys.

This is a still unripe idea, but I'll mention it here, just in case somebody can improve it to make it really useful.

I was trying to create a private key backup and was worried to let the file with the private key wander through insecure communications channels and systems like Windows computers.

So I found a ZIP archiver that can encrypt and zipped and encrypted the file right on the phone. Now I can move and store the file through insecure channels and on insecure machines.

An example could be that you have a safe phone and a safe computer with a printer, but no safe connection between the two. Another example is safe storage of the backup on an unsafe computer. You would never decrypt your backup on that unsafe computer, but you could move it back to a safe phone and decrypt it only there. (A safe phone could be a factory-reset phone with only Mycelium and a ZIP archiver app on it.)

Remaining problems are, obviously:

• You have to remember the encryption key safely.
• The ZIP archiver program could steal the key.

I used ZArchiver, which is apparently the most powerful ZIP archiver for Android. My reasoning is that nobody writes a powerful first-class archiver only to embed a virus in it. But, of course, a residual risk always remains.

In theory, Mycelium itself could contain an encrypting ZIP archiver or some other encrypting software, if the idea holds any water.

I'm putting this out here for discussion, in case there is any interest and I have not overlooked some fundamental counter-indication.

No. If you are rooted orbot can route any app through Tor. With this feature built-in also non-rooted users can enjoy orbot/mycelium together.

Is rooting necessary in order to route Mycelium traffic through Orbot?

v0.7.4 pushed to the beta channel, should be online by now.

improved send dialog
support for socks proxies (for example orbot)
fading qr code for improved readability in low-light scenarios
freshly mined coins are now spendable according to standard rules (120 blocks)
manual address entry for desperate people.

please try out all the features and tell us how you like them.

as usual, to get the latest build, join this group https://plus.google.com/u/0/communities/102264813364583686576 and enable testing at https://play.google.com/apps/testing/com.mycelium.wallet

this time there is no direct download from mycelium.com, will follow for the main channel release

sha1: c547c29162d47b298ec5ef3c5c7f61ac97e63ef8

Next version will feature a new "Send" wizard, where you manage the receiving address and amount to send from the same screen. This allows you to specify the amount before you enter the receiver. Also, if your clipboard contains a number you can paste it when specifying the amount to send.
All in all this should make the wallet much better in local p2p exchange scenarios, where the amount being bargained (and often calculated in an external app) can be specified (possibly pasted) before the receiving address is scanned. Our feedback tells us that the amount is the important thing, while the address is just a means to an end.

The next version will probably hit the Mycelium Beta Testers group later today.

yes
no

Edit: Breathing the air around you is not totally safe neither.

Was that android random generator vulnerability or whatever it was fixed?
Is it totally safe to use Mycelium now?

Interesting. Unfortunately it apparently requires root access to enforce its firewall rules. Root access enables it to attack the wallet
For high security I would still prefer a cheap dedicated device which only runs Mycelium.

It is always good with some inspiration.

--> droidwall

And BitSafe.

Don't know if this would help: https://bitpay.com/bitcoin-exchange-rates

And Trezor.

I know, I know. But I think it needs to be repeated from time to time when somebody appears to have missed it. I think we are blowing into the same horn.

hgmichna, I believe we have discussed this before, so instead of repeating myself let me quote myself (isn't that the same ):


I might add: Only use you daily phone for what you are prepared to loose. Bitcoins on your phone it is like cash in your pants (with a PIN).