[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140427230608.GA6155@openwall.com>
Date: Mon, 28 Apr 2014 03:06:08 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Many Problem's + Many Try's and no Soultion
On Sun, Apr 27, 2014 at 08:26:42PM +0000, wyss-adrian@...onet.ch wrote:
> the password is ?????"m\ZB:nG?4#53V8 .
> the ? are symbols i forget
> i do not use any thing twice, there will be no second Z or #
Here's an incremental and external mode combination implementing this:
[Incremental:Adrian]
File = $JOHN/ascii.chr
MinLen = 6
MaxLen = 6
CharCount = 95
[List.External:Adrian]
void filter()
{
word[13] = word[5];
word[5] = '"';
word[6] = 'm';
word[7] = '\\';
word[8] = 'Z';
word[9] = 'B';
word[10] = ':';
word[11] = 'n';
word[12] = 'G';
word[14] = '4';
word[15] = '#';
word[16] = '5';
word[17] = '3';
word[18] = 'V';
word[19] = '8';
word[20] = 0;
int i, c, mask[8];
i = 0;
while (i < 8)
mask[i++] = 0;
i = 0;
while (c = word[i++] & 0xff) {
int j, k;
j = c >> 5;
k = 1 << (c & 0x1f);
if (mask[j] & k) {
word = 0;
return;
}
mask[j] |= k;
}
}
The keyspace is 234 billion candidate passwords:
95-14 = 81
81*80*79*78*77*76 = 233668955520
At 1000 c/s, it'd take over 7 years to search this keyspace exhaustively:
81*80*79*78*77*76 / 86400 / 365 / 1000 = 7.41 years
Assuming that the order in which candidate passwords are tested is not
correlated with their probabilities, it'd take almost 4 years to reach a
50% chance of success. Luckily, incremental mode tries (normally) more
likely character combinations first. However, your specific password,
given what we know about it, might not be sufficiently similar to
typical passwords to achieve much of a reduction from these 4 years.
What may help is:
1. More info on possible/impossible characters for the 6 positions where
you don't recall the exact characters. Maybe it's fewer than 81
possibilities for some? For example, did you use the space character
anywhere in the password? If not, that's already one character less to
try, reducing the keyspace to:
80*79*78*77*76*75 = 216360144000
or by more than 7%. As you can see, by eliminating just a handful of
possible characters, you can speed this up greatly.
2. Higher c/s rate. 1000 c/s is pretty low, even for this slow hash
type. For example, bleeding-jumbo with --fork=32 gives me 121 c/s per
process, 32 processes - so about 3900 c/s total - on a 2xE5-2670 machine
(using CPUs only), running the above combination of incremental and
external modes (BTW, the c/s rate would be higher for shorter passwords).
Your machine is maybe twice slower, but it shouldn't be as slow as
1000 c/s at this kind of passwords. So you might be able to achieve
about 2000 c/s (cumulative, with --fork) on your CPUs. With a few GPUs,
you'd bring this to tens of thousands of c/s.
> in john 1.7.9 jumbo
> Warning: detected hash type "sha512crypt", but the string is also recognized as "crypt"
> Use the "--format=crypt" option to force loading these as that type instead
> Loaded 1 password hash (sha512crypt [64/64])
This is fine. Note that with this version of JtR, you should enable
OpenMP (at compile time) and you need to ensure you're not overbooking
the machine (if it has significant other load on it, reduce
OMP_NUM_THREADS to be a little bit lower than the number of logical CPUs
that the system sees - e.g., 15 if there are 16 logical CPUs in
/proc/cpuinfo on Linux).
> in john 1.8.0
> Loaded 1 password hash (crypt, generic crypt(3) [?/64])
For sha512crypt, you should preferably be using bleeding-jumbo, not the
1.8.0 release. You need to find out how many logical CPUs your system
has, e.g. with:
grep -c ^processor /proc/cpuinfo
(on Linux). Then pass this number to the --fork option. Do not worry
about possible overbooking (it's only important with OpenMP) if you use
this approach.
> the test runs for 5 days @ 1120 c/s with no result
Of course. 5 days is not 4 years.
> and the password should be inside this file because of all possibilities
>
> the file is 190GB big!
There's something wrong about this file's size. It should be much
bigger than 190 GB:
81*80*79*78*77*76 * 21 / 10^12 = 4.91 TB
That's with Unix linefeeds. Perhaps you actually do have more info on
what the password can and cannot be, and you included that when
generating the file? Or maybe something went wrong and the file
contains fewer possibilities than you think it does.
Please don't be lazy to do some basic math like above.
Alexander
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.
