Any idea if this would be much faster on a GPU?(MD5 x3 + AES decrypt)
#4
(05-28-2017, 04:49 PM)philsmd Wrote: yeah, OpenCL support might make sense.

But there are some questions still open:
- what about the lenght of the data, is 1 block enough ?
- you need way better means to determine if the decryption was successfull, not just a test for a single byte (0x35 == "5"), this will produce way too many false postitives, there must be some other important/hard-coded etc data within the decrypted data, or?
- is it really worth the effort? as far as I understood, you only have 1 single "hash" that you need to crack... maybe it is better to try to remember the password and maybe generate some very specific dictionaries (small ones, for instance with the help of hashcat-utils etc) that you use as input to your rust code?
- it's also very important that you carefully test that you got the algorithm correct (yeah, also your rust code etc) with some additional test vectors that you should generate with the tool that was used to generate the encrypted data (the JS library)

Verified several tests
I've created several encryptions with the JS library and verified correct decryption on my Rust port. The library claims to be OpenSSL compatible(the MD5 hashing part is in their OpenSSLKey function), but this doesn't seem to be the case anymore, It is about 2 years old since last commit, perhaps recent openSSL versions broke that.

Worth the effort?
The effort is worth about $1k USD atm, it contains a small amount of BTC I stored in web service 4 years ago. That value is likely to increase over time, but so is computation power where I could attempt it then provided the service hasn't disappeared. I've attempted many passwords that I'd assume it should have been, I also located one on my old HDD mapped to the service in keepass db, but that may have been for the account itself which I have since reset. I could most definitely put together a wordlist of likely candidates and have a hashcat tool mutate variations for my Rust code to try.

Determining correctness of decrypted content
The service which uses the JS library has a decrypt button to enter your passphrase, it'll return "invalid password"  (due to a padding error during decryption iirc) or the decrypted data.

It mentions that valid decrypted data starts with a 5. I tried to look the source of that up on their site but it's concerningly down(cloudflare), the service has had many issues over the years and storing bitcoin there wasn't the best idea Smile

According to this reddit thread , private keys starting with 5 are uncompressed. Another comment also provides more details here:

Quote:The network byte is the first byte of input to base58 encoder.
For uncompressed keys the input is always 1 network byte (0x80) followed by 32-byte secret exponent, followed by a 4-byte checksum. For compressed keys there is an extra byte of 0x01 between the exponent and the checksum.
The prefixes '5', 'K' or 'L' are the result of the aforementioned constraints on the input data. If you plug in all 0x00 or all 0xff in the 32-byte exponent and convert it to base58, you will see that the private key must start with '5H...5K' for uncompressed and 'Kw...L5' for compressed.

Seems to be known as WIF(Wallet Import Format)? So the **starting two bytes is between 5H and 5K** of a base58 string.

Length of data, Is 1 block enouogh?
I'm not sure what you're referring to here. The base64 string decodes to 80 bytes. The first 8 don't matter, the next 8 is the salt, the rest is the encrypted data leaving 56 bytes.

---

So should I attempt this with hashcat? I guess I start with the source for hashing MD5 and add AES decryption from another?


Messages In This Thread
RE: Any idea if this would be much faster on a GPU?(MD5 x3 + AES decrypt) - by polarathene - 05-28-2017, 06:46 PM