Will Android clients ever support encrypted QR codes? (for paper wallets)

[Tacticat]

Since there are several developers around here, I thought I might ask the following question:

Is there any way that android (smartphone) clients ever accept scanning AES 128 encrypted QR codes?

I love using a paper wallet, but I don't deem it safe to print my private key in plain text (plain QR code). It would be amazing if I could print an encrypted version and then use it with my favourite client.

The client would scan the encrypted key via QR code and prompt me to type my passphrase in order to decrypt it and allow me to send Bitcoins.

Other interesting options are that the client inmediately forgets the passphrase so that I have to type it / confirm each transaction,  that it allows me to specify a certain amount of time I want it to remember it or that the key is imported to my wallet.

This would be a very interesting solution for paper-wallet users. Just scan it, type the passphrase and send the bitcoins without having to store it on any device.

Any way this could be possible in near future?
Thanks!

[Mike Hearn]

Jim is working on encrypted wallet support for MultiBit. Once he contributes the code back to bitcoinj, it will become available for Andreas to integrate into Bitcoin Wallet. So I think the answer is yes, at some point at least one Android wallet will support that.

However, it's not a great idea to be sharing wallets between different devices like that. If the devices get out of sync it's easy to accidentally create double spends. Also if your  phone is stolen and unlocked by the thief, it may be possible for him to steal all your money. If you send small amounts of "everyday money" to your phone in a regular payment, this is no longer an issue.

[Tacticat]

Thanks for the reply, but I think I didn't explain myself properly. I'm sorry.

Let me please explain the idea again:

1. I got QR code printed on paper. (or plastic, like a credit card )
This QR code is an encrypted private key.

2. I scan the QR code and input passphrase to decrypt the key and send bitcoins.

3. Phone never stores key.
If I lose the phone there is no risk.

If I lose the paper QR code, an atacker can't decrypt it unless I've chosen a weak passphrase.

[Mike Hearn]

I see. Yes Jims work should lay the foundation for that.

[Tacticat]

Thank you!

[Nyhm]

Jim's work to bring proper key encryption to MMultiBit/bitcoinj is going to be awesome. Until that work is complete, I've considered implementing a more heavy-handed interim approach: Require a passphrase at application start, then use a symmetric cipher (AES) to simply encrypt the wallet file stream.

Would this be at all a worthwhile endeavor, or just wait for Jim's more featureful approach?

Clarification: I could do this in application logic, and/or bitcoinj. I've investigated bitcoinj, and would need a slight augmentation to also use wallet auto-save (pass in a stream factory along with the file name).

[jim618]

Hi Nym,

It is veering off topic but to answer your post...

Encrypting the whole wallet would certainly work - you could use the org.multibit.crypto.EncrypterDecrypterAESScrypt to do it.

The disadvantage is that you would not be able to do the 'routine' things like adding new transactions as they come from the network without the passphrase ( as everything is encrypted). I've gone with the approach if just encrypting the private keys - same as bitcoind - so that you just need the passphrase for sends and key management.

You could combine the two approaches - for instance the blockchain.info double encrypted backups have the private keys encrypted with AES and then the whole JSON structure is encrypted with another password to make it opaque.

[Nyhm]

Hi Nym,

It is veering off topic but to answer your post...

Encrypting the whole wallet would certainly work - you could use the org.multibit.crypto.EncrypterDecrypterAESScrypt to do it.

The disadvantage is that you would not be able to do the 'routine' things like adding new transactions as they come from the network without the passphrase ( as everything is encrypted). I've gone with the approach if just encrypting the private keys - same as bitcoind - so that you just need the passphrase for sends and key management.

You could combine the two approaches - for instance the blockchain.info double encrypted backups have the private keys encrypted with AES and then the whole JSON structure is encrypted with another password to make it opaque.

Thanks for your reply Jim - My thoughts exactly. Regarding Android clients (on topic), I was curious if an alternative approach to your (pending, proper) solution would be useful for Android wallet developers.

I may be implementing my simpler approach for the SatoshiRoller  app (using cipher streams).

[Andreas Schildbach]

Thanks for your reply Jim - My thoughts exactly. Regarding Android clients (on topic), I was curious if an alternative approach to your (pending, proper) solution would be useful for Android wallet developers.

I may be implementing my simpler approach for the SatoshiRoller  app (using cipher streams).

It would be only of limited use. Bitcoin Wallet updates the blockchain in the background, while the app is not "running". It would need to ask for a passphrase just for that.

[etotheipi]

I have had multiple users request this in Armory.  My response is controversial, but I want to throw it out there as food for thought, and you can ignore it if you don't like it:

If you have an encrypted wallet and all your backups are encrypted as well, including encrypted paper backups -- you have a brain-wallet.  Not exactly a brain-wallet, just all the downsides of brain-wallets.  You are at significant risk of losing your coins no matter how good you think you are.  Either because you forget your encryption passphrase because you only used it once five years earlier when you made the backup, or because you get hit by a bus and take the passphrase (and BTC) to your grave with you.  If the encryption is implemented properly, the backup will be useless without the passphrase.

I have no problem with having encrypted backups in addition to an unencrypted backup stored somewhere secure such as a safe or safe-deposit box.  But I think if the option is there, a lot of users will make 100% of their backups encrypted, and a lot of BTC will be permanently lost.
 

[Nyhm]

EDIT: Now that I'm somewhat more well-rested, I see that I misinterpreted the purpose of this thread in my original response (as noted by Jim). Plowing ahead, nonetheless:

Thanks for your reply Jim - My thoughts exactly. Regarding Android clients (on topic), I was curious if an alternative approach to your (pending, proper) solution would be useful for Android wallet developers.

I may be implementing my simpler approach for the SatoshiRoller  app (using cipher streams).

It would be only of limited use. Bitcoin Wallet updates the blockchain in the background, while the app is not "running". It would need to ask for a passphrase just for that.

Yes, it's true that to even launch the app (to sync block chain and see balance), the user would have to supply the passphrase. That's where Jim's implementation will be much more capable (only requiring passphrase for private key operations). For a high-security environment, you'd want the passphrase/cypher_key to be wiped from memory as soon as possible. For a medium-security environment, the passphrase/cyper_key could be entered at startup, then remain in memory for the duration of the session. No-passphrase operation could be offered to users for low-security applications.

I have had multiple users request this in Armory.  My response is controversial, but I want to throw it out there as food for thought, and you can ignore it if you don't like it:

If you have an encrypted wallet and all your backups are encrypted as well, including encrypted paper backups -- you have a brain-wallet.  Not exactly a brain-wallet, just all the downsides of brain-wallets.  You are at significant risk of losing your coins no matter how good you think you are.  Either because you forget your encryption passphrase because you only used it once five years earlier when you made the backup, or because you get hit by a bus and take the passphrase (and BTC) to your grave with you.  If the encryption is implemented properly, the backup will be useless without the passphrase.

I have no problem with having encrypted backups in addition to an unencrypted backup stored somewhere secure such as a safe or safe-deposit box.  But I think if the option is there, a lot of users will make 100% of their backups encrypted, and a lot of BTC will be permanently lost.

Along with the above statement, this decision is based more on the nature of your expected user base. If you target tech-savvy users, then they can be offered more options and be expected to understand the ramifications of their decisions. If the intended audience is non-technical end-users, then reliability/recovery might be most important. I suspect that Armory is the former.