Topic: Mycelium Bitcoin Wallet - page 119. (Read 586360 times)

I agree. However,
We don't necessarily know the strength of the private key. The user can import arbitrary private keys.
We don't know how secure the user's email/dropbox/printer-app is (or whatever app user chooses to share the encrypted backup with).
Therefore we want a mechanism where we can reason about the strength of the password and give reasonable protection against brute force attacks.

Correct. But there are two problems, which make BIP38 cumbersome to use for our purpose.
1. With BIP38 you have to do the scrypt stretching for every key, as the input depends of the checksum of the bitcoin address of the private key you wish to encrypt. So when  exporting 10 keys you have to do 10 VERY heavy scrypt operations
2. The scrypt parameters for BIP38 are hardcoded and unfeasible to use on an many android devices. The paper mentions that they are subject to consensus, but  the ones who have BIP38 support have just gone ahead and used them as they are. So once can argue that consensus is there. The problem however is that they were chosen so they take 1-2 seconds on standard computer (cannot remember the reference to that, but it is in one of the many threads on the forum). Which is a strange way of setting security parameters. On one of my android devices BIP38 takes 6 minutes and 28 seconds to execute. If you couple that with the above and want to export just 10 keys, it will take more than an hour.

Instead we use a mechanism that resembles BIP38, but which does not require you to run scrypt for each key, and where scrypt parameters are parametrized as part of the output. This way we can configure the scrypt strength according to the password strength.

Correct. Unlike brain wallets, you can only brute force the password once you have obtained the encrypted backup.

Partly covered above. The password is basically there to protect our users from using unsafe transport from the app to the printer. Whether you write the password on the printout or somewhere else is entirely up to you. The backup mechanism is meant for having a secure and verifiable backup of your private keys.
If you want to protect yourself against a pickpocket you could very well use a BIP38 backup with a weak password. We are likely to add support for cold storage spending using BIP38 fairly soon.

Because many people who consider themselves clever use weak passwords. If someone looses his coins because he uses "correct horse battery staple" as his password it is going to fall back on the Mycelium developers.

Thanks.

With 70 bits and our current scrypt parameters we have a very large safety margin. The author of scrypt argues in this presentation that brute forcing on a 65 bit password would cost $43B using custom made semiconductor hardware. My own calculations estimate that bot-net of 1.000.000 standard desktop computers with 4 cores each will spend more than a million years brute-forcing a 70 bit passphrase.

I agree that increasing the password to 20 characters will be more secure, so will 25 characters, but it will also get less convenient and more cumbersome. In the end it is a matter of finding the sweet spot where baking a backup is convenient AND secure against feasible attacks. Many more coins have been lost due to missing backups than to theft.
Have in mind that what we are doing in 1.0 is a two factor backup. You need both the encrypted backup before you can start brute forcing the password. So the private keys are not generated from the password.

Quite well said. The other thing is a human memorizable password has the following entropy (using Diceware)

four words 51.6 bits;
five-word entropy of at least 64.6 bits;
six words have 77.5 bits;
seven words 90.4 bits;
eight words 103 bits.

That means that are human memorizable, easy to type and have a higher entropy than your 70 bits. And BIP38 solves the problems of brute force of course with stretching. I also want my wallets to be safe from say the phone being confiscated by government and then the bitcoin confiscated. The private key needs to be encrypted on the device so it cannot be recovered using forensic tools. That's really important.

I keep getting the feeling you guys are ignoring the threat difference between putting a human memorable password generated key on the block chain and just protecting a STONG machine generated secret key with a human memorable password so it can be stored in your pocket, on your phone, or in your dropbox folder.

"A key on the block chain shall never be sourced from a human memorable password" is a good rule, I agree.

"A STRONG secret key on paper in your pocked shall never be protected by a human memorable password" is not a good rule. It is way-overkill against the threats your piece of paper or your personal dropbox folder is subject to.

BIP38 is a perfectly reasonable tool to protect STRONG keys that are in your possession. You can even use it with 70 bit strength passwords you generate using Diceware that you endeavor to memorize.

Secret keys derived from 70 bit passwords that you can write down are in my opinion marginal when placed on the block chain where they are begging people to take a crack at them with the best crackers the world has to offer. In Mycelium I hope this is not done.

I don't know the design details, but I hope in Mycelium the idea is to cover a STRONG key with 70 bit passwords. In that case I don't understand the objection to BIP38. It does exactly the same thing.

I assume the objection is that a user with BIP38 can select a weak human password. But if he is just protecting himself against a random pickpocket then that is a valid decision by the user. Why restrict him? Why force him to write down the 70 bit password on a piece of paper that he will loose to that same pickpocket?

We already have an "advanced user" mode. Why not let the users do what they think is best?

Just looked over the PDF. That output looks really, really nice. My decision to continue promoting Mycelium to bitcoin newbies is further vindicated.

One thought, though. Fifteen random uppercase letters is around 70 bits of entropy. Since we'll have to write these letters down anyway, is there any chance that the number of letters could be bumped up to 20? That'll be over 90 bits of entropy, which should be good for a couple of decades worth of processing power increases. That would be great for archival purposes.

Sure, but did you read what diceware is? You do not create passwords with random letters(upper and lower case) with symbols.
You use real dice to generate random 6 digit number which you use to look up words on a list (http://world.std.com/~reinhold/diceware.wordlist.asc). Repeat this for as many words as you need (6 or 7): that is the best randomness you have. Better than any PRNG.
The word list becomes the  passphrase of x words. e.g. "horse dog staple kneecap house" this solves the following:

1. humans are terrible at generating entropy
2. hard to remember random passwords with upper/lower/symbols
3. not difficult to to key in because they are normal words and you can easily text on a phone

Maybe you have a clever scheme for remembering a long password, but I cannot let my users depend on that. Humans are in general notoriously bad at producing random data, and even worse at remembering it. Encouraging ordinary people to use brain wallets is a very poor idea in my mind.
With the approach we have chosen we can reason about the strength of the passwords, and argue for a lower bound for the amount of work a brute force attack requires. No amount of jokes will convince me otherwise.

That said, we are considering to have support for importing BIP38 keys, and do cold storage spending from them.

Diceware passphrases are extremely secure and you can get more entropy than 70bits without it being hard to remember at all. Read about it here: http://world.std.com/~reinhold/diceware.html

Someonne even made a joke about it: http://xkcd.com/936/

Here are the problems:
 - If you can remember a password it is probably not strong enough.
 - If you forget your password you loose your coins.
 - Entering a password that is secure is a pain, especially on android devices.

Therefore we are adding something else in the upcoming 1.0:
Export a PDF document to dropbox, gmail or whatever your device has installed. The PDF document contains QR-codes, one for each private key, but where the data is encrypted with a device-generated 15-character password (70 bits). The password is stretched using scrypt to form a 256-bit AES encryptionkey. The length of the password forces you to write down so you don't forget it. The length of the password combined with key stretching makes it proof against brute-force attacks. Mycelium will keep on nagging you until you have both exported AND imported all your keys (this is really to help you not loose your coins)

You can already try it out in the testnet version, here is a sample of the output: https://www.dropbox.com/s/x13chg7tmuvqqzi/mycelium-backup-11-11-13-2.05-PM.pdf

Here is the testnet version: https://play.google.com/store/apps/details?id=com.mycelium.testnetwallet&hl=en

Feedback welcome.

Great!
The prodnet version will be available to beta testers within hopefully one or two days. You can join the Google+ group (Mycelium Beta Testers) if you would like to help out with testing.

Not thinking of BIP38, are the wallets stored on the device in an encrypted format? I would seem like we need a feature similar to Bitcoin-Qt where the wallet file is encrypted with a password. That could be fast AES encryption and you unlock it with a password. The pin protection just protects against causal use.
Even not thinking about BIP38, one should be able to backups in AES encrypted form too.

Yes, it took quite a while on my ancient (2.3) android device, but I don't think that matters a lot? Maybe you could add a little warning about CPU usage and battery life if that is a concern.

Btw, love the testnet client and can't wait for the normal client to be upgraded.

I might add that it still takes 44 seconds to stretch the key on my low-end android device with the parameters we have selected.