Although I sympathize with your frustrations, you should realize that the BlockChain.info folk are trying to improve their security for the benefit of all of their users. There's absolutely no reason to believe that there are any malevolent intentions in their recent changes.

BC.i doesn't have the best security track record (and if you'd like to "jump ship" to a more modern alternative, e.g. an online multisig wallet, I'd have no objections), but the fact that they're trying to improve is overall a good thing.

The encryption for the wallet backup is AES-256, which is nice and strong. The entire wallet is encrypted (including the public keys, addresses, and transactions). The key derivation function used is rather weak, it's basically 3 MD5's. This means that the wallet backups aren't resistant to brute-forcing attacks (compared to say Bitcoin Core, Armory, or GreenAddress.it's PIN), so using good/long passwords is advised if you plan on storing them anywhere online. (Presumably the choice of KDF was to make it compatible with openssl's command-line tool for decryption).

The PIN encrypts the private keys (and the seed), but not the public keys/addresses. These encrypted keys are part of the wallet backup, so you need both the wallet backup password and the PIN to perform a restore and then spend any funds.

It should be noted that enabling the PIN option does not encrypt the initial on-device backups made shortly after install. This means that malicious apps which have root access can gain access to your private keys, even after you set a PIN. This is not a problem on an unrootable device, and at the moment it's not a problem on a rooted device as long as you don't give root(/SuperSU/SuperUser) access to any questionable apps, however malware will continue to become more sophisticated, so this may one day be a problem... (to be fair, a malicious app that acquires root access could find other ways to eventually access your private keys even if they were encrypted, so encrypting them may not help much anyways).

Edited to add: regarding that last paragraph, it is a problem if you lose your phone, and if it's rootable (as many Android phones are). A PIN would not protect your funds from a knowledgeable thief in this particular case, but hopefully nobody stores large quantity of bitcoin on their phone....

To both aliveonearth and findftp:

Blockchain.info has been somewhat improving their (formerly very lax) security as of late (make no mistake: this is a very welcome change!), so it's not surprising that the Python one-liner isn't working. The wallet format hasn't changed (not enough to affect btcrecover, but the defaults have changed enough to affect JtR). On the other hand they are being more strict about who(/what) can and can't download the encrypted wallet files.

If you already have a wallet.aes.json file, btcrecover will still work.

If you don't, getting the wallet.aes.json file might be more difficult (and may be impossible if you don't have access to the email address associated with the BC.i account).

I'll post back here once I have more info (probably not for a day or two though).

btcrecover, which I mentioned above, does support GPU-accelerated password searches for wallet.dat files (or for dumpwallet.py files like you also partially posted above).

It's still pretty unclear (to me anyways) if this is a password you remember most of, or if it's a KeePass or similar password which you don't have any of. If it's the latter, and if it's a complex as you've stated, than there's absolutely zero chance you'll ever be able to recover it without recovering it from KeePass.

Here's a link to the time it would take to brute-force a random 30-character long password (upper + lower + digits) using 4 high-end GPUs.

There are some options available that may help.

This thread has a lot of good info in it, you may want to take a look.

btcrecover is a tool that can help you recover your password, if you remember enough about it. The Quick Start is here. It's not necessarily the easiest to get configured and running, but it is free and open source (FYI I'm biased... I'm the author of that tool, let me know if you have any questions about it).

There are also a few individuals in the Services section that are willing to help for a fee, you may want to search over there too (and also search around for their reputations; there are some with some good past history).

It's pretty hard to say... it seems pretty likely that Linux's and BSDs' CSPRNGs for the most part have a lot of randomness from the environment to use. Of course it's much harder to predict when it comes to closed-source implementations (Microsoft, Intel).

Why use OPs method unmodified when simple changes remove the bias (or when alternatives exist with no bias)?

Well, I thought the whole point was to replace a potentially faulty OS-provided CSPRNG with true entropy that has near-perfect uniformity.

I don't really see the point with replacing it with one that has obvious bias (even if it's not a lot of bias). In other words, an OS-provided CSPRNG, especially if it's an open-source one, is probably better than any method that definitely has some bias (and it's not like removing that bias is all that hard).

edited to add- practically speaking I think you're right in that it probably doesn't matter, but I'm no cryptographer, so I'd personally prefer to err on the side of safety and not use a method that introduces bias...

I don't understand what you're asking.... (edited- sorry that I called OP's method yours, my mistake)

In case you don't realize this, Electrum's seed isn't a sequence of words, it's actually a sequence of 16 bytes. When you ask Electrum for the current wallet's seed, it takes its binary seed of 16 bytes, and converts it to the sequence of words (the mnemonic) you see for convenience. Likewise when you restore a seed, it immediately converts the mnemonic back to the original 16 bytes, and saves that to the wallet.

The source of the bias is that some mnemonic sequences (like the example I gave above) convert to the same internal 16 seed bytes, and therefore generate the same list of addresses. These internal seeds are more likely to be created by you algorithm unless you "throw out" the extras using the steps from this post above. Am I being any more clear now?

As the redditor eventually figured out, it's vulnerable to modulo bias (even after the improvement, albeit less so). Using a truncated SHA-256 of enough truly random data (e.g. 50 dice rolls or a deck of cards (at least the first 25 cards cards of a very well shuffled deck)) as the initial seed would eliminate any bias (at least any predictable bias, so long as SHA-256 isn't broken, and if it were there'd be much bigger Bitcoin problems).

More concretely, I'd do this (25+ cards seem easier to me than 50+ dice rolls, but pick your poison...)

  1. Shuffle a deck of cards very well.
  2. Record at least the first 25 cards in the deck, e.g. if the first three are king of spades, 9 of diamonds, and ten of hearts, you'd have: ks9dth
  3. Plug your random data into this one-liner in Linux (assuming you have Electrum installed):

I did, but it was a bit vague...

This mnemonic: "weary weapon unseen like like like like like like like like like" and this one: "sister glide dude near muse sent like like like like like like" both produce the same binary seed (which is this in hex: 0x1003ca7a7000000000000000000000000) and they both produce the same address list (starting with 17A2fgCpcKEbg7CbfiJwAb8sjdEzUWD2y2). Feel free to try restoring both. That means that this address list is two times more likely to be created via your method. If you follow those three steps I mentioned, you eliminate this bias.

4/1000 number comes from this: (# of mnemonic permutations / # of binary seeds) - 1 == (1626^12 / 2^128) - 1 == about 4/1000. So about 4 in 1000 mnemonics correspond to two binary seeds / two address lists.

edited to add: it's much like your REROLL lines. When Electrum goes from a mnemonic to a binary seed, instead of choosing to REROLL (and declare the mnemonic invalid) when it hits a duplicate, it just "rolls over" to the next binary seed instead (via modulus math, it's like saying your NR 1627 would be "like" instead of "REROLL").

When Electrum creates a seed, it starts from the binary seed (one of 2^128), and creates the mnemonic from it, so it doesn't introduce any bias when creating a seed (assuming its CSRNG is good of course).


Fair enough, but in my experience (not IMO, but rather what I think most people believe them to be) the defining feature of a brainwallet is something human-created and possible to remember (which leads to poor entropy and danger). I have no trouble with a randomly-created brainwallet such as yours, though.

Definitely not Armory unless your wallet.dat file is older than April 2012.... (most wallet software has moved to compressed public keys except for Armory).

This looks pretty good, but it has a couple of issues...

First, you need a deterministic way to decide which die is #1, which is #2, etc. For example, you could roll them each one at a time, or you could use six different colored dice with each color always representing the same die #, or you could just always read the dice from left-most to right-most however they happen to fall (easy to do objectively if you have Travel Yahtzee). If you don't have some such deterministic method, you will almost certainly introduce bias as you read off the dice in your own personal order.

Second, although your method does create a uniformly distributed mnemonic (sequence of 12 words), a uniformly distributed mnemonic does not produce a uniformly distributed binary seed. That's because about 4 out of every 1000 seeds can be represented by two different mnemonic sequences even though they result in the same list of addresses & keys. To avoid this without changing your method much, you need to:

  1. Create a new wallet from the randomly created word sequence.
  2. Retrieve the seed (from the Wallet menu).
  3. If the word sequence you generated is different from the one you checked in step 2, discard the wallet and start from scratch.

There's a less than 0.4% chance you'll need to do this. If you don't believe that this can happen, restore any wallet whose seed starts with "weary weapon unseen" (and then any 9 words from the list), and you'll see that the seed you later retrieve differs from the one you restored.

Finally... please don't call it a brainwallet. A brainwallet is something that's easy to remember, and typically has very little entropy (bad). Your method has plenty of entropy (good), and is definitely not in the same category as a brainwallet. There are quicker methods, but your method is simple and transparent which I like.

See over here, in particular the posts by DeathAndTaxes and the ones that mention TitaniumBackup (root only).

Unfortunately, it's not that simple (and it's a bit misleading IMO).

When you log into Blockchain.info (even if you use good 2FA such as Yubikey), the private keys for your wallet are sent to your computer. This means that your computer (and any decent malware that's running on it) has access to those private keys, and can use them to relieve you of any funds.

By default, Blockchain.info doesn't save those private keys to disk (if you have 2FA enabled), and that does protect you against stupid malware, but it remains much less secure than per-transaction 2FA used by multisig wallets (where only a portion of the necessary key material is ever on your computer and available for malware to abuse).

Not to put too fine a point on it, but blockchain.info doesn't support any (decent) 2FA.

Logon-only 2FA (such as supported by Blockchain.info) does help protect against online password brute-forcing attacks, but it does practically nothing to help protect against malware (e.g. keyloggers), which seem to be the more ominous threat.

Per-transaction 2FA (such as supported by GreenAddress.it and BitGo.com) means that each transaction that sends bitcoin out of your wallet must use a new 2FA code. This type of 2FA offers very effective protection against malware (although it's not necessarily perfect).

You should keep all this in mind when weighing your wallet options....

I've been bugged once or twice to create a thread in Tech Support for it so it's easier to find... I should, and I will one of these days :-)

If you think there's a chance you have you're password wrong (e.g. a typo) you could try a brute forcing tool. btcrecover supports Electrum-LTC, it might be of some help.

Ignore that, I didn't read the OP very well, and it probably won't help any.

There are also open source (free) solutions. btcrecover is one, although it's more difficult to use...

If your wallet is protected by a password that you type in, than a keylogger can grab it -- there's no way to protect against this. If you're worried about malware and keyloggers, you should be looking at solutions that aren't simply password-based, e.g.:

1. Web-based multisig wallets with two factor authentication, e.g. Greenaddress.it or BitGo.com.
2. Desktop-based multisig wallets, e.g. Armory or mSIGNA (and another trusted individual running the same).
3. Cold storage solutions, e.g. Electrum or Armory.
4. Hardware wallets, e.g. Trezor or Ledger (a.k.a. HW.1).

(Of course, each of these also has its downsides.)


The seed is enough.

The decryption part isn't too hard because you can use the fairly standard openssl command-line tool, however starting with version 3.47 the decrypted format changed from a text file containing WIF-style privkeys to a Google Protocol Buffer format. There are some advantages to the new format, and there's plenty of documentation on Google protobuf, however until someone writes some software to handle the new format, it's not particularly easy to deal with.