Interesting...
I cheated a little in cracking "biscotte". I gave the following info:
Min length = 8
Max length = 8
Characters = biscote
Not only that but I tweaked the code so that it started counting at "bisibbbb", so it did it in 54 seconds.
On my Intel Core Duo 1.83 GHz laptop running Backtrack3 (with a browser open in the background), it peaked at about 121 keys per second. Might be able to get it faster though as I tweak the code.
Interesting...
Is 121 k/s good or bad for a 1.83 GHz Intel Core Duo laptop? (I really haven't got anything to compare it to).Originally Posted by theberries
And of course it goes without saying that you have to take into consideration how much time (and hard disk space) you saved by not creating a dictionary file beforehand.
Honestly, I have no idea. I know there are some smart people 'round here with more experience in this dept. that should be able to chime in.
i've tried to use the code but after compiled it to a .c file after i press the maximum lenght of the password i got this error
What is the minimum length of the password? 1
What is the maximum length of the password? 8
Use all (A)SCII characters or (S)pecify your own (A/S)? FATAL ERROR: Bad Input. Exiting...
that's just after i type 8 , i get quickly that error messages withuot have the time to press A or S , is that happened to u also ?
The best way to determine this would be to simply compare it against the same process using a precompiled dictionary instead. This will show you how much speed you have to give up in order to save disc space.
-Monkeys are like nature's humans.
You still think reading from a dictionary file would be faster?
Wups sorry, I had that same problem at first as well.
For some reason the "standard input stream" behaves differently on Linux. When I try to use "fgets" on the standard input stream, it won't allow the user to supply a string, it just instantly returns without taking input from the user.
I know some people who spend their day working with I/O streams in C so I'll ask them and get back to you.
Yes I do. Since your CPU would not have to generate the words during the process but could passively read them from a pre-existing file.
If you on the other hand take the complete procedure starting from generating the dictionary from scratch and then running it against the handshake afterwards into account, I do not know which way it would swing. However, this comparison would seem a bit unfair to me as it completely misses the point of the time-memory trade-off, i.e. that the wordlist once generated can be used countless times
-Monkeys are like nature's humans.
The word generator is extremely simple, it takes less than ten CPU instructions to increment "aaaa" to "aaab".
Reading a word from a file would take hundreds, if not thousands, of CPU cycles. Add to that the actual physical speed of your hard disk.
I would expect an on-the-fly version to run several times faster.
Perhaps if the dictionary file were stored in RAM, it might run a tiny bit faster than the generator version, or then again maybe the generator might even be a tiny bit faster than jumping through RAM. I'd expect the difference to be less than 5%. But... then you'd have to consider the time spent filling RAM with the combinations, and so the on-the-fly version would win out again.
Anyway enough talk out of me, I'll make a dictionary file, compare the two methods, and produce my findings.
Posting Permissions