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