Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Apr 2006 00:16:18 +0400
From: Solar Designer <>
Subject: Re: JTR and Speed

On Tue, Apr 04, 2006 at 07:08:47PM +0200, 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>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - bringing security into open computing environments

Was I helpful?  Please give your feedback here:

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ