Topic: Creating a wallet on Linux and importing it on Android (Read 1181 times)
Thanks. I can confirm the openssl developers have never added an iteration count to the "enc" format. I saw a patch floating around, but it never got committed.
I am using the following steps to create from scratch a wallet on a (secure, offline) Linux machine that can be later imported by Bitcoin Wallet's "restore wallet" feature:
I can think a few details that are important to get right:
Are there any pitfalls to think of? Is it expected that all future versions of Bitcoin Wallet should be able to import wallet.enc?
By the way, Andreas: there seems to be an assumption in Crypto.java that iterative hashing is used when backing up the wallet, but this is false. The "openssl enc" format does not support iterative hashing.
- Using bitcoinj's wallet-tool utility from the current github master branch: $ wallet-tool --wallet=wallet create
- I want to know the first address where it can receive coins so: $ wallet-tool --wallet=wallet current-receive-addr
- Encrypt it: $ openssl enc -e -aes-256-cbc -base64
wallet.enc && rm wallet
I can think a few details that are important to get right:
- Use a recent version of bitcoinj. Older ones produce wallets that are not BIP32-compliant deterministic wallets.
- Make sure to use a strong password for encryption that is equivalent to at least approx. 80 bits of entropy, because "openssl enc" does not use iterated hashing to compute the key & IV. For example a random lowercase alphanumeric password should be at least 16-character long (eg. "9n0y27xhq3k2h7f8" is ~83 bits of entropy).
Are there any pitfalls to think of? Is it expected that all future versions of Bitcoin Wallet should be able to import wallet.enc?
By the way, Andreas: there seems to be an assumption in Crypto.java that iterative hashing is used when backing up the wallet, but this is false. The "openssl enc" format does not support iterative hashing.
Jump to: