01-29-2020, 03:32 PM
(This post was last modified: 01-29-2020, 03:43 PM by derlange2k.)
(01-29-2020, 03:12 PM)philsmd Wrote: so it seems the only check is that the 32 decrypted bytes are base58 chars and the first needs to start with either L, K, 5 or Q.
I think that is approximately a chance of (58^32) / (256^32) .... it's not too bad, but could still result in rare false positives (see https://github.com/hashcat/hashcat/commi...9d8e38b69c , here we have "only" MD5, so it should be very fast... which is bad if you try very hard to reduce false positives)
Isn't there also a checksum involved with those keys or are they just random bytes converted to base58 ? Maybe not the full data needed for a checksum is within the output of multibit2john or btcrecover.
I really appreciate your answers, philsmd, thank you.
Well, i'm not too deep into this, but as far as i know, there is no checksum involved, it is random bytes.
btcreover reports the false positive also in the README:
Code:
Warning: Using the extract-multibit-privkey.py script on a MultiBit Classic key file, as described below, can lead to false positives. A false positive occurs when btcrecover reports that it has found the password, but is mistaken—the password which it displays may not be correct.
Would it be possible to integrate it in hashcat? Running it with GPU power would be very faster, i guess.