+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: How to generate/try random keys for 3des? (/thread-6782.html)
How to generate/try random keys for 3des? - alex1984 - 08-14-2017
Hi, I just want to know how to generate random hex keys to bruteforce 3des.
What is the best way to go about this?
Do I use the stats-processor to generate the random key candidates, and then feed them into hashcat as an input?
Or do I have to patch the 3des kernel or the sources, to allow the rand() function to be used?
Thanks.
RE: How to generate/try random keys for 3des? - philsmd - 08-14-2017
You should be more specific about what you know about the keys/passwords.
If the keys are completely random and k1, k2 and k3 could all be different, then the keyspace is very large (way too large to bruteforce).
On the other hand, if you know that the key was generated like this: srand (time ()); k1= rand (); k2 = rand (); k3 = rand () where the seed to the RNG was just the time since the epoche, then there could be a chance to recover the key if you know the estimated time when the key was generated.
So the short answer is, if it is completely random and k1/k2/k3 could be all different, then a bruteforce is unfeasible. implementing rand () doesn't help, nor does the use of statsprocessor (why do you even think this helps here?).
Normally, when new hashcat users think about rand (), they actually mean a mask attack (bruteforce). This is accomplished by using the attack mode -a 3 = mask attack.
But as said, in this specific case it doesn't make sense to use bruteforce/mask attack if you do not have a reduce keyspace (or know that a weak algorithm generated the key ... or a known seed to the random number generator etc).
RE: How to generate/try random keys for 3des? - alex1984 - 08-14-2017
Hi Philsmd, thanks for the reply, but I think that I have to be more specific.
I have the cipher text, and plaintext pair, I don't know much about the keys, all I believe is that there is not more than 2 adjacent bytes the same (and I think that it only happens once).
I have made the 3des kernel to be k1,k2,k1, and it works properly. That makes it a 16 byte keyspace now.
The default mask attack I believe is sequential (correct me if I'm wrong), which is not what I want, because it would take a long time to build up to try a real key (in my instance).
What I am looking for is just to generate random 16 hex bytes, and to try them.
What I don't want to try is keys like this: 0101010101010101FAFAFAFAFAFAFAFA
or 1290B2D4AA9802DCFAFAFAFAFAFAFAFA.
What I want it just randomly made, such as 1290B2D4AA9802DC5D76BEC5601A3E34, etc.
I just want to use the rand() function to generate k1,k2, with a seed of the time (only at start-up), and to keep on trying random keys until my patched 3des kernel gives me the found plaintext.
Thanks.
RE: How to generate/try random keys for 3des? - philsmd - 08-14-2017
I see no reason to use rand () here. That would only make sense if you know the seed (as explained in my previous post). Otherwise it would just slow everything down by a lot.
Furthermore, there is no GPU implementation for hashcat for rand ().
No, mask attack is not sequential by default. It uses markov, use --markov-disable to disable it.
I also do not see why you think that a random number generator could not generate a key with 2 or more identical bytes one after the other. If it is really random, the sequence of 2+ identical bytes is perfectly reasonable (even though the amount of keys with a sequence of 2 identical bytes one after the other isn't that high compared to the overall number of keys, the keys that have 2+ identical bytes can't be ignored).
You can only use a filter like this if you know that the key with which the ciphertext was encrypted really had that limitation/filter i.e. that no more than 2+ bytes are the same.
BTW, maskprocessor has an option to limit the number of same bytes next to each other:
Code:
-q, --seq-max=NUM Maximum number of multiple sequential charactersBut you can see that whenever you use a filter like this e.g.:
Code:
mp64 -q 2 [mask] | hashcat -w 4 -m 14100 -a 0 hash.txtTherefore my question is: do you know that the key was generated with a filter/limitation like "no key can contain 2 identical bytes next to each other". If not, it doesn't make sense to limit it like this.
Anyway, bruteforcing a *random* 16 byte key is infeasible anyway, no matter if you add a filter or not (and as we can see, the filter could reduce speed and rand () will decrease the speed even more).
I think the problem is your understanding of "random"... a random key does not necessarily mean that it used the ANSI C rand () function (but maybe you have more details about this and know that the key was generated by using rand (time()) ) ...
rand () is slow and there is no GPU-friendly implementation for hashcat of this.
"random" does not mean that a key with 2+ bytes that are equal, or even all bytes that are equal, could not exist... instead, if the key was generated randomly (cryptographically, truly random) there is no such limitation/filter.
RE: How to generate/try random keys for 3des? - alex1984 - 08-14-2017
Yes I know that 2+ identical bytes can happen easily in a random number generator, but the chances of getting like 8 identical bytes next to each other are very low in a random number generator, (or even 8 bytes, and then another 8 bytes, just like in my example before). Even if that happens it can be ignored compared to the overall keys generated.
And I know that the keys are not all identical, not even 8 identical + another 8 different identical. The max adjacent identical are about 2 to 3.
And you are correct, I tried the mask processor approach and the speed dropped by a lot, from roughly 400 MH/s down to 15 MH/s (not enough work for the gpu when adding -q 2 limitation). I am using an AMD r9-290 gpu by the way.
RE: How to generate/try random keys for 3des? - alex1984 - 08-15-2017
Thanks for your help Philsmd, I understand your explanation of the rand() function seeded with the time(), and with a lack of knowledge of an estimate of the time seeded it would be difficult to find the correct keys.