<p>If you know which three characters are modified, you can find the correct input in 57³ = 185,193 attempts.</p>
<p>If you are looking at a 52 character string where each position can express as one of 58 different characters (base58), trying all combinations that <em>modify</em> this string in exactly three different positions would be calculated as follows.</p>
<p>Picking exactly three positions out of 52 would be modeled as an unordered sampling without replacement and we can calculate the 3-combinations of a 52-element set as a binomial coefficient of 52 over 3:</p>
<pre><code>52! / (3!×(52-3)!) = 52!/(6×49!) = 52×51×50/6 = 52×17×25 = 22,100
</code></pre>
<p>In each of these 22,100 combinations of positions in the string, we would need to <em>modify</em> all three positions, and they can each take 57 alternative expressions than the original input. Therefore, there would only be fewer than 4.1 billion alternative input strings for us to test (4,092,765,300 to be exact).</p>
<p>Let’s apply that we know how the encoding works in addition, though. We are looking at a wallet import format (WIF) string which uses <em>base58check</em>. If I’m not mistaken, in its 52 characters, it encodes a 1-byte prefix, a 32-byte data portion, and a 4-byte checksum.</p>
<p>This yields the following additional restrictions:</p>
<ul>
<li>The first character must either be K, L, or 5</li>
<li>The last eight bytes are a checksum calculated from the data. If I’m not mistaken, the checksum should contribute to the last six characters, and the last five characters entirely depend on the checksum.</li>
</ul>
<p>This means that only 46 characters contribute to the data portion of the WIF string. If the first character is modified, it can only take two alternative expressions, and then there can be 0–2 changes in the data part. If the first character is correct, there can be 0–3 changes in the data part. We can model the optionality of a data character being modified by selecting 3 positions and allowing all 58 expressions. This will cause us to repeat the original string 15,180 times, but that’s not gonna slow us down much.</p>
<p>Picking two positions in the data part yields a mere 46!/(2!(46-2)!) = 1035 combinations. Each of the positions can take 58 expressions. With the two alternative values for the prefix character, we have to try only</p>
<pre><code>2 × 1035 × 58² = 6,963,480
</code></pre>
<p>inputs to cover the case of a change in the prefix. Assuming a correct prefix and up to three changes in the data part, there are (46!/(3!(46-3)!) = 15,180 combinations of positions to check that can each take 58 different expressions, which leaves us with another</p>
<pre><code>15,180 × 58³ = 2,961,800,160
</code></pre>
<p>possible inputs.</p>
<p>So, if you know that your string is modified in up to three places, you can find your original WIF in fewer than 3 billion attempts.</p>
<p>I’d guess that this translates to about two days of computation on a single core. If this is being considered as an additional security measure to obfuscate a backup, I would recommend using a different approach, since the footgun potential may outweigh the additional security.</p>

CC BY-SA 4.0
2024-09-05T21:46:43.470Z
Thank you for the explanation!

Basically, with 3 incorrect chars, we get almost 3 billion possible inputs, from which only 1 would be correct.


But if we have 4 incorrect chars this time, and apply the exact formula you did (to 46 char), we would get:

163,185 x 58⁴ = 1,846,682,399,760 (1.8Tn)
R R
CC BY-SA 4.0
2024-09-05T21:47:14.567Z
With 3 incorrect chars, we have 3 billion different private keys.
With 4 incorrect chars, we have almost 2 Trillion private keys.

The numbers grew exponentially, thus making it less likely for someone to find them.
R R
CC BY-SA 4.0
2024-09-05T21:47:34.933Z
Another fact that we must take in consideration is that you cannot even open a text file that big which contains all those possibilities.
Not to mention you wouldn't be able to import them into a wallet like Electrum for example, as it won't be able to process such a huge list.
R R
CC BY-SA 4.0
2024-09-06T04:16:24.927Z
Checksum in base58check is 4 bytes; WIF is either (now rare) 1prefix'80'+32 + 4 -> 51 char beginning '5H' through '5K' or (now usual) 1prefix'80' + 32 + 1flag'01' + 4 -> 52 char beginning 'Kw' through 'L5'. But I don't think this affects your result.
dave_thompson_085
CC BY-SA 4.0
2024-09-06T14:27:33.990Z
Ah yes, it’s a 4-byte checksum. Thanks for catching that. When you said that I was looking at it and realized: oh yeah, how would five or six letters out of 52 be enough to encode 8 bytes out of 41? :D
Murch
CC BY-SA 4.0
2024-09-06T18:29:11.357Z
Well, with 4 incorrect chars we get almost 2 Trillion different private keys that we still have to test, from which only 1 is the correct private key. This is hard to check even for a cracker, so this should be pretty safu.
R R
CC BY-SA 4.0
2024-09-05T18:31:08.577Z
2024-09-06T14:26:35.893Z
2024-09-06T14:26:35.893Z
Murch
<p>I am giving the following (masked) BTC Private Key:</p>
<p><strong>L2nBmWGfAH5Vf9re41VhG6BgPx25rxqGmkbaPtG14jAPtBUzhQab</strong></p>
<p>What I can tell you is that the key above has 3 incorrect characters in it at different random spots. The incorrect 3 characters can be either the same letter or different, in both UPPER or lowercase.</p>
<p><strong>But let's assume all 3 chars are the same letter in the same case (eg. A A A)</strong></p>
<p>The alphabet has 26 letters with each having both uppercase and lowercase forms.</p>
<p>Considering that, we also know that the key is 52-char long.</p>
<p>What are the chances of someone cracking the key and successfully find the correct letters missing in it?</p>
<p>What calculations and permutations do we have to do ?</p>
<p><strong>26x26x26...x26 , 52 times ?</strong></p>
<p>If the exact location of the incorrect letters was known, I guess the calculations were much easier.</p>
<p>But in this case, the exact locations are secret because I try to understand how many permutations/chances are required to do, to find them.</p>
<p>How is it done? Is it even possible to crack the incorrect 3 missing letters or not?</p>
<p>Thanks</p>
<p>P.S -Forgot to mention, I own the full correct Private Key, I know what the missing chars are and where. I just wanted to clarify, I'm not trying to crack anybody's key. Plus the address is empty. I just want to know what are the chances of someone cracking the format and what the formula would be.</p>

<wallet><address><private-key>
Find missing/masked characters from Bitcoin Private Key without knowing their location
R R
# Find missing/masked characters from Bitcoin Private Key without knowing their location

(Asked by: username_0 on 2024-09-04)

I am giving the following (masked) BTC Private Key:

**L2nBmWGfAH5Vf9re41VhG6BgPx25rxqGmkbaPtG14jAPtBUzhQab**

What I can tell you is that the key above has 3 incorrect characters in it at different random spots. The incorrect 3 characters can be either the same letter or different, in both UPPER or lowercase.

**But let's assume all 3 chars are the same letter in the same case (eg. A A A)**

The alphabet has 26 letters with each having both uppercase and lowercase forms.

Considering that, we also know that the key is 52-char long.

What are the chances of someone cracking the key and successfully find the correct letters missing in it?

What calculations and permutations do we have to do ?

**26x26x26...x26 , 52 times ?**

If the exact location of the incorrect letters was known, I guess the calculations were much easier.

But in this case, the exact locations are secret because I try to understand how many permutations/chances are required to do, to find them.

How is it done? Is it even possible to crack the incorrect 3 missing letters or not?

Thanks

P.S -Forgot to mention, I own the full correct Private Key, I know what the missing chars are and where. I just wanted to clarify, I'm not trying to crack anybody's key. Plus the address is empty. I just want to know what are the chances of someone cracking the format and what the formula would be.

**Tags:** wallet, address, private-key


---

## 1 answers

### Answer by username_1 on 2024-09-05. Score: 1 | Accepted answer

If you know which three characters are modified, you can find the correct input in 57³ = 185,193 attempts.

If you are looking at a 52 character string where each position can express as one of 58 different characters (base58), trying all combinations that *modify* this string in exactly three different positions would be calculated as follows.

Picking exactly three positions out of 52 would be modeled as an unordered sampling without replacement and we can calculate the 3-combinations of a 52-element set as a binomial coefficient of 52 over 3:

```
52! / (3!×(52-3)!) = 52!/(6×49!) = 52×51×50/6 = 52×17×25 = 22,100

```

In each of these 22,100 combinations of positions in the string, we would need to *modify* all three positions, and they can each take 57 alternative expressions than the original input. Therefore, there would only be fewer than 4.1 billion alternative input strings for us to test (4,092,765,300 to be exact).

Let’s apply that we know how the encoding works in addition, though. We are looking at a wallet import format (WIF) string which uses *base58check*. If I’m not mistaken, in its 52 characters, it encodes a 1-byte prefix, a 32-byte data portion, and a 4-byte checksum.

This yields the following additional restrictions:

* The first character must either be K, L, or 5
* The last eight bytes are a checksum calculated from the data. If I’m not mistaken, the checksum should contribute to the last six characters, and the last five characters entirely depend on the checksum.

This means that only 46 characters contribute to the data portion of the WIF string. If the first character is modified, it can only take two alternative expressions, and then there can be 0–2 changes in the data part. If the first character is correct, there can be 0–3 changes in the data part. We can model the optionality of a data character being modified by selecting 3 positions and allowing all 58 expressions. This will cause us to repeat the original string 15,180 times, but that’s not gonna slow us down much.

Picking two positions in the data part yields a mere 46!/(2!(46-2)!) = 1035 combinations. Each of the positions can take 58 expressions. With the two alternative values for the prefix character, we have to try only

```
2 × 1035 × 58² = 6,963,480

```

inputs to cover the case of a change in the prefix. Assuming a correct prefix and up to three changes in the data part, there are (46!/(3!(46-3)!) = 15,180 combinations of positions to check that can each take 58 different expressions, which leaves us with another

```
15,180 × 58³ = 2,961,800,160

```

possible inputs.

So, if you know that your string is modified in up to three places, you can find your original WIF in fewer than 3 billion attempts.

I’d guess that this translates to about two days of computation on a single core. If this is being considered as an additional security measure to obfuscate a backup, I would recommend using a different approach, since the footgun potential may outweigh the additional security.

> **Comments:**
> **username_0**: Thank you for the explanation!  Basically, with 3 incorrect chars, we get almost 3 billion possible inputs, from which only 1 would be correct.   But if we have 4 incorrect chars this time, and apply the exact formula you did (to 46 char), we would get:  163,185 x 58⁴ = 1,846,682,399,760 (1.8Tn)  
> **username_0**: With 3 incorrect chars, we have 3 billion different private keys. With 4 incorrect chars, we have almost 2 Trillion private keys.  The numbers grew exponentially, thus making it less likely for someone to find them.  
> **username_0**: Another fact that we must take in consideration is that you cannot even open a text file that big which contains all those possibilities. Not to mention you wouldn't be able to import them into a wallet like Electrum for example, as it won't be able to process such a huge list.  
> **username_2**: Checksum in base58check is 4 bytes; WIF is either (now rare) 1prefix'80'+32 + 4 -> 51 char beginning '5H' through '5K' or (now usual) 1prefix'80' + 32 + 1flag'01' + 4 -> 52 char beginning 'Kw' through 'L5'. But I don't think this affects your result.  
> **username_1**: Ah yes, it’s a 4-byte checksum. Thanks for catching that. When you said that I was looking at it and realized: oh yeah, how would five or six letters out of 52 be enough to encode 8 bytes out of 41? :D  
> **username_0**: Well, with 4 incorrect chars we get almost 2 Trillion different private keys that we still have to test, from which only 1 is the correct private key. This is hard to check even for a cracker, so this should be pretty safu.  

---

