First Time User - MD5 Help ("Updating" password w/ digits)
#1
As title says, I'm a first time user. I've read through the documentation and I understand how to run the program with its parameters and such. I can't seem to find in the documentation what I am trying to do and I was wondering if someone might be able to point me in the right direction.

I have a "password" of sorts with known length (145 combinations of 2 digit integers from -1 to 36 with spaces in between). Example:
Code:
17 -1 00 33 18 12 -1 20 12 -1 31 04 33 30 01 34 11 00 01 13 19 27 11 19 16 23 09 00 16 21 06 09 14 09 07 03 11 28 02 22 25 13 15 34 10 23 14 22 35 00 26 23 09 13 29 34 08 31 21 27 23 13 33 36 30 27 02 10 08 03 13 31 05 08 13 22 18 35 17 01 36 30 33 05 05 27 05 29 04 11 05 25 11 23 -1 34 08 16 04 24 14 10 34 03 10 15 33 20 25 04 12 18 13 00 34 30 26 33 36 24 22 20 29 28 13 18 01 35 00 30 21 32 06 28 08 35 04 16 21 33 24 08 25 22 12

The last 25 combinations are used as a form of "salt" in it's own sense. Crunching the numbers shows that there are (145 numbers)*(38 possibilities)*(2 digits per possibility) = 11,020 possibilities. I obviously know that this would be possible to solve using oclHashcat for MD5 (I forgot to mention it's MD5 encoded). I am wondering what I can do to indicate to oclHashcat that there are spaces after each combination of 2? Each one of the numbers also outputs after 30 seconds so if there might be a way to feed an "update" to oclHashcat indicating that the digits are known since this would exponentially decrease the amount of possibilities every 30 seconds.

I'm using oclHashcat for CUDA drivers on my GTX 970M. If someone could help me with known ways to do this, or point me in the right direction that'd be helpful! Big Grin

P.S. I think my graphics card is good enough for this, but could someone aid me in figuring out how long it might take to break this hash?
#2
You have two problems here.

First problem, the input data is way too long, oclHashcat does not support input of that length.

Second problem, you can't math. Your keyspace isn't 145*38, it's 145^38. That's 272.84 bits...
#3
(04-09-2016, 09:17 PM)epixoip Wrote: You have two problems here.

First problem, the input data is way too long, oclHashcat does not support input of that length.

Second problem, you can't math. Your keyspace isn't 145*38, it's 145^38. That's 272.84 bits...

Okay, I get the issue regarding the input length, but I feel like there might be a misunderstanding regarding the keyspace...

The resulting MD5 hash looks like this:
Code:
56d6c29e569e657fc0a1edea2c65a355
but the digits look like this:
Code:
36 15 18 26 01 13 12 22 19 27 07 02 33 17 34 20 03 13 35 03 09 08 -1 30 23 33 11 36 29 31 14 15 14 05 14 01 35 18 34 08 26 09 23 04 28 19 16 29 01 35 05 21 04 25 30 08 31 13 00 23 06 31 09 17 29 06 03 19 11 18 34 08 27 13 30 25 21 07 10 05 00 16 28 01 18 07 16 01 24 05 29 07 18 17 33 29 05 35 15 17 04 07 34 05 26 18 31 33 24 32 26 13 26 25 -1 21 19 24 03 36 14 03 16 09 15 21 -1 22 30 10 01 36 04 33 26 25 04 33 06 14 34 21 -1 26 21

I could also be completely confused. I'm fairly new to cryptography hashing as I just started learning about it and coding with it in Java. It's an interesting concept for me so I began to dig and here I am.

Is there not a way of a given "format" that it would be able to hash through? As mentioned previously, it's done in those 2 digit patterns with spaces in between. I feel like there has to be some way to brute-force that to get the resulting MD5. If oclHashcat can't do it, will regular Hashcat work? I just know that oclHashcat is faster because of GPU usage instead of CPU. Or should I be looking for some other program?

The reason I feel that it's possible is because there are only 38 possibilities for each "couple". Given the 145 "couples" that form, I would think that it might be possible although I see what you mean by 145^38 instead of 145*38. I think the solution to solving the problems you mentioned, and my possible confusion, would be the latter part of my original post. With given digits over time, would an input file containing those digits make it more practical? This being since it would narrow down the possibilities.
#4
hashcat and oclHashcat are optimized for short inputs, like passwords, and thus only implement a single MD5 block (55 bytes.) You are wanting to hash 434 bytes, so you need a generic multiblock implementation of MD5, as found in something like OpenSSL.

You are completely confused, yes. There are 145 positions each comprised of 38 possibilities. That means the keyspace is 145^38. That keyspace is well beyond the impossible. Knowing some of the digits over time will make it more practical -- but in order for you to crack it within one year with your GTX 970M, you would need to know 134 of the 145 numbers (meaning you'd only be searching for 10 of them) (and this is assuming of course that oclHashcat could even hash 434 bytes and it somehow magically ran at the same speed as the heavily optimized 55-byte implementation, which of course it would not, it would be much slower.) And since this is a GTX 970M, your laptop would surely die a painful death long before that year was up.

So yes, you are confused and your task is impossible.
#5
(04-09-2016, 10:31 PM)epixoip Wrote: hashcat and oclHashcat are optimized for short inputs, like passwords, and thus only implement a single MD5 block (55 bytes.) You are wanting to hash 434 bytes, so you need a generic multiblock implementation of MD5, as found in something like OpenSSL.

You are completely confused, yes. There are 145 positions each comprised of 38 possibilities. That means the keyspace is 145^38. That keyspace is well beyond the impossible. Knowing some of the digits over time will make it more practical --  but in order for you to crack it within one year with your GTX 970M, you would need to know 134 of the 145 numbers (meaning you'd only be searching for 10 of them) (and this is assuming of course that oclHashcat could even hash 434 bytes and it somehow magically ran at the same speed as the heavily optimized 55-byte implementation, which of course it would not, it would be much slower.) And since this is a GTX 970M, your laptop would surely die a painful death long before that year was up.

So yes, you are confused and your task is impossible.

Well that's fine then. At least I learned that it was impossible before even trying. :Smile Better that my laptop didn't die a painful death. Any recommendations as to how I might even consider trying something similar?
#6
(04-09-2016, 09:17 PM)epixoip Wrote: Your keyspace isn't 145*38, it's 145^38.

If you got a range of 38 possible characters and the number of positions is 145 would't the keyspace be 38^145?
I mean it doesn't matter since both is way too much to crack within reasonable time.

Edit: spelling
#7
No it would be... oh for fucks sake, how did I fuck that up? Yes you're correct, it would indeed be 38^145. Ugh that's like the second "correct but details are wrong" answer I've given in two weeks, I'm slipping lately!