[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 May 2015 00:33:21 -0400
From: Yulong <yyl.dev@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Question on showing number of guesses tried
Hi,
thanks for the detailed explanation! I was able to obtain the batch info
and also the logs you mentioned in later email. I used still the 1.8.0
jumbo1, not build from bleed.
0:00:00:09 + Cracked ? as candidate #45219840
0:00:00:23 + Cracked ? as candidate #96829440
0:00:00:24 + Cracked ? as candidate #103858176
Mine is very close to yours, although it didn't print out the actual
cracked password. One thing I am still not clear is, so now the number is #
of candidates tried, is it equivalent to # of guesses, or # of word from
the wordlist? The two things might be different because one word from
wordlist could produce many guesses based on different rules.
For my research, exact figure would be desirable, but a number within a
tight range (like in a batch of 64) is acceptable. I am trying to compare
say two different sets of passwords in terms of resistance towards to
cracking.
On Tue, May 5, 2015 at 6:45 PM, magnum <john.magnum@...hmail.com> wrote:
> On 2015-05-06 00:01, magnum wrote:
>
>> On 2015-05-05 23:14, Yulong wrote:
>>
>>> Regarding to the inaccuracy, is it totally off? I mean, if we know how
>>> many
>>> passwords per "batch" we try, then the actual number of guesses would be
>>> just "displayed result"/"# per batch"? Thought the question now
>>> becomes how
>>> to know # of passwords per batch.
>>>
>>
>> Well you can query it like this:
>>
>> $ ../run/john --list=format-all-details --format=wpapsk
>> Format label wpapsk
>> Disabled in configuration file no
>> Min. password length in bytes 8
>> Max. password length in bytes 63
>> Min. keys per crypt 8
>> Max. keys per crypt 64 <-- this figure
>> (...)
>>
>> So for WPAPSK format, it's 64 on my system (you may get a different
>> figure - it depends on build options, number of cores, AVX/AVX2 and
>> other things).
>>
>> In that case, if a password is found among candidate 1-64, it will be
>> shown as 64. If it's found among 65-128, it will be shown as 128 and so
>> on. There is obviously no way to divide that number to get a more exact
>> figure.
>>
>
> I found a trivial way to get an exact figure in the log file without
> affecting performance. Screen output will still be rounded up to batch size
> but log file will show the exact numbers, as in:
>
> $ ../run/john ../test/rawmd5_tst.in -form:raw-md5 -inc
> Loaded 1500 password hashes with no different salts (Raw-MD5 [MD5 128/128
> AVX 4x3])
> Warning: poor OpenMP scalability for this hash type, consider --fork=8
> Will run 8 OpenMP threads
> Press 'q' or Ctrl-C to abort, almost any other key for status
> 12345 (u28-RawMD5)
> start1 (u54-RawMD5)
> 2g 24576p 0:00:00:01 1.086g/s 13356p/s 13356c/s 20034KC/s 013356..breash
> (u6-RawMD5)
> 1 (u8-RawMD5)
> 4g 49152p 0:00:00:02 1.941g/s 23860p/s 23860c/s 35766KC/s breasd..153928
> (...)
>
> $ grep Cracked ../run/john.log
> 0:00:00:01 + Cracked u28-RawMD5 as candidate #2
> 0:00:00:01 + Cracked u54-RawMD5 as candidate #1834
> 0:00:00:01 + Cracked u6-RawMD5 as candidate #25740
> 0:00:00:01 + Cracked u8-RawMD5 as candidate #25741
>
>
> If you need this, build from a snapshot of bleeding-jumbo:
> https://github.com/magnumripper/JohnTheRipper
>
> magnum
>
>
--
Best,
Yulong
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
