[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Apr 2006 00:16:18 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: JTR and Speed
On Tue, Apr 04, 2006 at 07:08:47PM +0200, websiteaccess@...il.com wrote:
> Loaded 1 password hash (Traditional DES [128/128 BS AltiVec])
> guesses: 0 time: 0:00:00:10 5% c/s: 507827 trying: wi46 - wins46
> John25 (test)
> guesses: 1 time: 0:00:00:16 100% c/s: 503350 trying: Jklmno25 - Joonas25
>
>
> When I try to crack 527 encrpyted (same wordlist used), I use my own
> wordlist, I have 5350K (5,350,000) c/s ! (see below)
> -------------------------------------------------
> Loaded 527 password hashes with 90 different salts (Traditional DES
> [128/128 BS AltiVec])
> guesses: 0 time: 0:00:00:02 0% c/s: 5350K trying: jetski - jism
>
> Could you tell why that difference between 507827 and 5,350,000 c/s ?
There are two reasons:
1. Matching salts. In your second example, you have 527 password hashes
with only 90 different salts - meaning that you have around 6 password
hashes per salt on average. For each candidate password (from your
wordlist), John only needs to calculate 90 different hashes, not 527 -
yet that is sufficient for checking the candidates against all of the
loaded 527 password hashes.
2. Per-candidate "overhead". John has to read each candidate password
from your wordlist file and to set it up as a cryptographic key to be
tried. If you're using word mangling rules, the processing cost of that
is added, too. With only one password hash loaded, these operations are
performed for each password hash calculated and checked. With multiple
hashes loaded, these per-candidate operations are only performed once
for all password hash calculations and checks based on this candidate -
for all salts.
Both of these contribute to a higher effective combinations per second
rate with more password hashes loaded for cracking simultaneously.
BTW, it is uncommon to have only 90 different salts with 527 hashes.
This indicates a problem with the way salts were being generated on the
target system.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.
