Recover Your Scrambled Electrum Seed - BTCRecover

[Lucius]

I was aware that there are tools that can help in the event that someone intentionally or accidentally mixed the seed words, but I have to admit, I didn't know it was pretty easy to do that. When I say "easy" I mean what is shown in the video - with obviously slightly stronger machines, but in case of Electrum 12 words BIP39 seed it can be done is some 4+ hours with some mid-range CPU.

The whole thing is interesting to me from the perspective of those who deliberately mix words in case their backup is stolen, which according to the author of this video makes no sense. How much this procedure actually depends on how many words have swapped places, in the sense that it may take 2 minutes or 5 hours or more?

The author also emphasizes that it is now possible to recover Electrum SegWit seed, which is hopefully good news for some who have played with their words.

All this is of course possible with the program btcrecover : https://github.com/gurnec/btcrecover

[jackg]

12 word mnemonics have 479001600 permutations (different orders if they're jumbled) which is at the sweetspot for what standard computers are able to handle (mid range cpus and no gpus - within a couple of seconds but btc recover requires io to check addresses or a wallet file and the obvious hashing operations).

There are then  620448401733239439360000 permutations in a 24 word seed which is probably almost impossible to crack if they're trying every permutation... You could try moving some in certain places to make the operation faster (I. E. switching neighbours or moving words in sets of 3 or 2 instead). I'm assuming seed cracking hardware matches password cracking ones of around 24GHz (8GPUs) - but we're talking millions of gpus to get through this in a reasonable time if my calculations are right.

If you've run a vanity address generator then there's an exit when a word is found so the time difference in solving some words will come from that and the complexity of the algorithm to produce the merkle route.

Electrum seeds were also different sizes in the past with a mean distribution around 12.. I've had 8-13 word seeds in the past from the standard install of the wallet.

[HCP]

The whole thing is interesting to me from the perspective of those who deliberately mix words in case their backup is stolen, which according to the author of this video makes no sense.

An interesting video for sure... it demonstrates the futility of using this "system" to try and obfuscate your seed words. However, there are a couple of caveats that do need to be noted...

Aside from knowing the 12 words... you also need to know:

1. The wallet that was being used
2. The coin-type that was being used
3. An address from the wallet
4. A rough idea of the index# of that address

He kind of glosses over the fact that if the address you have is not one of the earlier addresses (ie. index < 10), then the time required to find the correct combination can increase quite significantly.

The creation of the seed permutations themselves is trivial... you're simply rearranging 12 'tokens' and, as jackg pointed out, with 12 words you only have 479,001,600 possible permutations.

The "heavy lifting" is the part where you need to take those 12 words, convert them to binary to form the seed, then generating X number of private keys, then derive the public key/address from those private keys and then compare that with the example address you have provided.

I wonder what the effect on his "ETAs" would be, if part of your strategy (in addition to scrambling your seed) was to start using addresses at say index 10, or index 20... or index 100?

[o_e_l_e_o]

I wonder what the effect on his "ETAs" would be, if part of your strategy (in addition to scrambling your seed) was to start using addresses at say index 10, or index 20... or index 100?

If you were to simply "start" using addresses at index 100 as you say, it wouldn't make any difference, as you don't need to derive all the keys in between index 0 and the index you are interested in. The process for generating a child private key simply takes your parent public key, your parent chain code, and the index you are interested in, and hashes them together, before adding the left 256 bits (modulo n) to your parent private key. You can derive index 100 (or 100,000, or 2 billion), just as quickly as you can derive index 0. If, for example, you thought your address was around index 100, then you could search your addresses 90-110 just as quickly as you could search 0-20.

The issue would be if you had no idea what your address index is and you needed to derive every address from 0-100.

[HCP]

The issue would be if you had no idea what your address index is and you needed to derive every address from 0-100.

That's what I'm saying... if I know that I've started from 100, but no-one else does... they would need to derive everything.

My comment wasn't relating to me recovering my own seed, but in the strategy of scrambling a seed to further protect it from discovery by a 3rd party. If they have no idea what index your used addresses start at, then they're going to have to derive all of them.

[pooya87]

My comment wasn't relating to me recovering my own seed, but in the strategy of scrambling a seed to further protect it from discovery by a 3rd party. If they have no idea what index your used addresses start at, then they're going to have to derive all of them.

if "protection" is the goal then a proper encryption method must be used, something such as AES-256 with a strong password. everything else will be inferior and could even give a false sense of security while not providing any security whatsoever.

[Lucius]

The "heavy lifting" is the part where you need to take those 12 words, convert them to binary to form the seed, then generating X number of private keys, then derive the public key/address from those private keys and then compare that with the example address you have provided.
I wonder what the effect on his "ETAs" would be, if part of your strategy (in addition to scrambling your seed) was to start using addresses at say index 10, or index 20... or index 100?

The video is interesting, but as I thought, things aren't quite as simple as they are presented. But if one were to be in a situation of having mixed seed words, and all the relevant information, I believe it would not matter too much whether it would take 5 hours, 5 minutes or 5 days. Of course, it doesn't all depend on the degree of intricacy of how seed is scrambled, but also about the type of CPU and other computer components.

What is definitely true is the fact that one should not rely solely on word place replacement as only security measure, encryption or divide them into 2-3 separate parts has far greater security.

[keychainX]

The "heavy lifting" is the part where you need to take those 12 words, convert them to binary to form the seed, then generating X number of private keys, then derive the public key/address from those private keys and then compare that with the example address you have provided.
I wonder what the effect on his "ETAs" would be, if part of your strategy (in addition to scrambling your seed) was to start using addresses at say index 10, or index 20... or index 100?

The video is interesting, but as I thought, things aren't quite as simple as they are presented. But if one were to be in a situation of having mixed seed words, and all the relevant information, I believe it would not matter too much whether it would take 5 hours, 5 minutes or 5 days. Of course, it doesn't all depend on the degree of intricacy of how seed is scrambled, but also about the type of CPU and other computer components.

What is definitely true is the fact that one should not rely solely on word place replacement as only security measure, encryption or divide them into 2-3 separate parts has far greater security.

we have a gpu version for checking 12words , all possible permutations on a 10 x 1080Ti rig takes approximately 75 hours to check all possible permutations.

[HCP]

we have a gpu version for checking 12words , all possible permutations on a 10 x 1080Ti rig takes approximately 75 hours to check all possible permutations.

Out of curiosity, what does that actually "check" to determine validity?

Does it just check the first X addresses generated? if so, is "x" configurable and does a higher number like 20 or 100 cause a significant increase in time required?

[keychainX]

we have a gpu version for checking 12words , all possible permutations on a 10 x 1080Ti rig takes approximately 75 hours to check all possible permutations.

Out of curiosity, what does that actually "check" to determine validity?

Does it just check the first X addresses generated? if so, is "x" configurable and does a higher number like 20 or 100 cause a significant increase in time required?

it has several parameters.

1) choose your coin/type i.e. ethereum, bitcoin legacy, bitcoin segwit etc.
2) choose your derivation path (i.e. trezor,ledger, blockchain.com etc)
3) choose how deep you want to go so lets say for m/44'/0'/0-1'/0-1/0-9 or m/44'/0'/0'/0/0-1 the difference would be about 20% in speed.
4) choose any number of target address (eth or btc) so if we know the wallet has received 5 different address it would search those without speed loss

/KX

[Pmalek]

@Lucius
Sorry for bumping this thread, but I had it bookmarked and I was going through my bookmarks while searching for something. Your OP suggests using https://github.com/gurnec/btcrecover. That is a recommended software, but the only problem is that it hasn't been updated since December 2017. I am not sure if it is still as effective as it could be with the new Electrum versions.

I have often seen users recommend https://github.com/3rdIteration/btcrecover as a great alternative.
It's is getting regularly updated (the last one was 3 days ago) and it might be more effective nowadays.

Edit: I just noticed that in the video, the narrator suggests using https://github.com/3rdIteration/btcrecover as well, and also mentions that the original btcrecover tool is outdated. Maybe you can update it to show the new link as well.