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.
