BitcoinSpinner

[hgmichna]

Cold storage is fine …

Cold storage does not create security. It only makes it a little bit more difficult for a Trojan to grab the private key. It does not deter malware programmers—it merely challenges them. Perhaps it attracts them.

It is probably better to prevent malware in the first place, but that is also difficult. Essentially you should not keep large amounts on a phone, and if you do, keep all other software and updates to the absolute minimum.

I am hoping for a separate piece of dedicated hardware to keep the private key in and to do any signing, with an observable, minimal data channel to the phone or computer that does the external communications. We don't have that yet, it is a hope for the future.

[Jan]

Cold storage is fine …

Cold storage does not create security. It only makes it a little bit more difficult for a Trojan to grab the private key. It does not deter malware programmers—it merely challenges them. Perhaps it attracts them.

It is probably better to prevent malware in the first place, but that is also difficult. Essentially you should not keep large amounts on a phone, and if you do, keep all other software and updates to the absolute minimum.

I am hoping for a separate piece of dedicated hardware to keep the private key in and to do any signing, with an observable, minimal data channel to the phone or computer that does the external communications. We don't have that yet, it is a hope for the future.

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

If you use Mycelium for large amounts I suggest that you use a dedicated device for optimal security. Personally I use an old second hand Android 2.2, which I got for free, and which I nuked to factory defaults, installed cyanogenmod, no SIM, and only installed mycelium. I keep the device in my safe along with paper backups. Whenever I want to "load up" my spending wallet on my daily phone I use the Cold Storage feature.

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).

[hgmichna]

… I believe we have discussed this before, …

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.

[niko]

I am hoping for a separate piece of dedicated hardware to keep the private key in and to do any signing, with an observable, minimal data channel to the phone or computer that does the external communications. We don't have that yet, it is a hope for the future.

I believe you've just described Armory offline.

And Trezor.

[Rassah]

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

[Rassah]

I am hoping for a separate piece of dedicated hardware to keep the private key in and to do any signing, with an observable, minimal data channel to the phone or computer that does the external communications. We don't have that yet, it is a hope for the future.

I believe you've just described Armory offline.

And Trezor.

And BitSafe.

[phelix]

Not sure if this got clear here:
Of course other apps can access the clipboard and if they request it in the manifest (the user gets warned about that) also to the sdcard.
Users should be aware that it is as easy as 3 lines of code to get any app to wake up whenever anybody puts anything into the clipboard.
Such an app can then parse and granted it has internet access, send the private key home.

--> droidwall

[Jan]

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

It is always good with some inspiration.

[Jan]

Not sure if this got clear here:
Of course other apps can access the clipboard and if they request it in the manifest (the user gets warned about that) also to the sdcard.
Users should be aware that it is as easy as 3 lines of code to get any app to wake up whenever anybody puts anything into the clipboard.
Such an app can then parse and granted it has internet access, send the private key home.

--> droidwall

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.

[vitalemontea]

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

[giszmo]

Was that android random generator vulnerability or whatever it was fixed?

yes

Is it totally safe to use Mycelium now?

no

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

[Jan]

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.

[apetersson]

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

[niko]

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

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

[apetersson]

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

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.

[hgmichna]

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.

[Jan]

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.

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.

[Newar]

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.

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.

[hgmichna]

Also, passwords have to be strong to have any real effect (unfortunately making them easier to forget).

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.

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.

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.)

[Jan]

Also, passwords have to be strong to have any real effect (unfortunately making them easier to forget).

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.

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.

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.)

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