Mycelium Bitcoin Wallet

[Jan]

There Mycelium currently does not get market rates from Bitstamp.
Bitstamp did some kind of upgrade yesterday. We are working on it.

Fixed

[1715573333]

1715573333

[1715573333]

1715573333

[1715573333]

1715573333

[1715573333]

1715573333

[1715573333]

1715573333

[Stephen Gornick]

Now that BitAddress supports BIP38 encrypted wallets, would you consider adding support for this in the cold storage spend feature?

[Bitalo_Maciej]

Props to Mycelium author for being having of not-so-many Bitcoin wallets that support sending funds to P2SH (e.g. multisignature) addresses. It's a shame that most Android/iOS wallets don't support this feature.

[apetersson]

Now that BitAddress supports BIP38 encrypted wallets, would you consider adding support for this in the cold storage spend feature?

YES.
We will support that, BUT be warned, BIP38 generation takes a huge amount of memory and cpu time. one spend can take as long as 5 minutes.

in order to make that more smooth, Jan developed a slightly relaxed scheme of encrypted wallet that will become the default export format (2-factor, with fixed-length)

for moer details, see our beta group on google+

[Jan]

Now that BitAddress supports BIP38 encrypted wallets, would you consider adding support for this in the cold storage spend feature?

I implemented BIP38 support a few weeks back, including unit tests, but it is not in the wallet. I am not that fond of BIP38.

The scrypt parameters of BIP38 are not final. From the spec: "n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)"
As far as I remember (from the forum, the wiki or where ever) the parameters were chosen so that the key stretching can be done on a computer in one or two seconds. This is IMO not a good practice when choosing parameters. I would rather base it on password strength and real-life brute-force attempt measurements, which I happened to find in this presentation from the author of scrypt.

The important thing is that you have to take the strength of your password into consideration when choosing parameters. I would much rather see a standard where the parameters are not set in stone (part of the output), OR even better a standard where the password has a guaranteed amount of entropy: password generated by the computer rather than a human. <-- this is important, humans are notoriously bad at creating secure passwords.

Running BIP38 with the suggested parameters on my android phone takes 388 seconds, or 6 minutes and 28 seconds, which is impractical. Instead I would like an implementation to provide guaranteed password entropy, and then stretch it with parameters that are practical to run within reasonable time while still making it take astronomical time to brute force. This is what I did, and it is part of the upcoming release of the Mycelium wallet. Whenever you make a backup a PDF is generated which for each private key has a QR code that contains an encrypted private key, where the password is 15 characters and generated by /dev/urandom (70 bits).

Here is a sample generated for testnet: https://www.dropbox.com/s/lme32phibry6kx9/mycelium-backup-10-24-13-4.16-PM.pdf


From our FAQ (not published yet):

Scrypt allows you to use a technique called key stretching to make a brute force attacker spend astronomical resources on CPU, memory, and time to launch a successful attack. The over all principle is that you can make passphrases equally secure by reducing the entropy while increasing the effort of the attacker for each attempt at brute forcing it.
In this paper the author of SCrypt estimates the cost of a successful attack based on SCrypt parameters r=8, p=1, N=16384 to be $43B if the password is 10 characters using 95 printable characters, when spending one year on the attack. We believe that these parameters have a reasonable safety margin for fairly large amounts of bitcoins. Because we don't use 95 different characters but 26 we have chosen the length of the passphrase to be 15 rather than 10. This makes sure that we have more entropy than what the calculations in the paper are based upon (26^15 > 95^10). An important point is that the passphrase is not chosen by the user, but generated by the device based on /dev/urandom. This allows us to reason about the strength of the passphrase.
Our own calculations indicate that you can make one SCrypt guess every 140 milliseconds on a standard PC using one 2.6 GHz CPU core. Since there are 26^15 possible passwords it will take a botnet of 1.000.000 computers with 4 cores each more than one million years to brute force a password. (26^15*140/1000/60/60/24/365/1000000/4)

[Jan]

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.

[nkuttler]

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.

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.

[btcdrak]

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.

[Jan]

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.

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.

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.

[Jan]

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.

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.

[btcdrak]

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.

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.

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/

[Jan]

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.

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.

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/

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.

[btcdrak]

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/

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.

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

[westkybitcoins]

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.

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.

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.

[ffe]

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?

[btcdrak]

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?

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.

[Jan]

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.

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.

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.

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.

[Jan]

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.

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.

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.

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.

I keep getting the 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.

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

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?

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.

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

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.

[btcdrak]

I keep getting the 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.

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

Yes. I would like to say, for my support of diceware, I do not agree that brainwallets are a good idea. What I've been saying is when you are encrypting something, Diceware provides a human memorizable way of having high entropy passwords. I'm not talking about generating private keys with human memorizable anything. So long as you can trust the PRNG.

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

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.

But we are not talking about creating brainwallets. We are talking about encrypting an already existing private key using stretching.

Why not implement a diceware list that you choose for the encrypted password: you could give the option to use diceware or not. Mycelium Wallet still gets the choose the entropy and prevent "clever" users from entering an arbitrary passphrase. Now you have the best of both worlds.

[prof7bit]

Two more requests and then it will be (almost) perfect:

* Please update the German localization (its horrible currently. can't recommend it to new users in that form)
* Please make the option to backup the key(s) more prominent / more obvious for newcomers and as simple and foolproof as possible, not nested 3 levels deep and hidden and not restricted only to one key at a time and only to "external drives" (what is this in the context of a mobile phone anyways? I would have expected to be able to store a password protected backup on the SD-Card and also the option to send it with email (and other apps that implement "send to"))

Otherwise its really a great wallet. Especially I love the option to scan paper wallets. But unfortunately thats all it can be used for currently without a working key backup mechanism.