[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <55D257F4.5090001@web.de>
Date: Mon, 17 Aug 2015 22:53:56 +0100
From: Demian Smith <demian.smith@....de>
To: john-users@...ts.openwall.com
Subject: Re: Merging rec sessions for --restore
Hi Alexander.
thanks for the feedback - I don't let them run together, I just keep one
session of john running, for one hash (i.e. either ripemd or sha). I
thought if there are multiple hashes, it could be done in such a way
that candidates are tested for both together, which then would have
saved time. As I don't know which hash I did use, I was wondering could
this be accomplished, but was afraid to "lose" the candidates already
tested (maybe "merge" was not the best way to express it, pretty much I
want to tell john which candidate has been tested on ripemd and which on
sha, do the missing ones on sha and then take it from there :s slightly
utopist thinking here)
As I don't know the hash, I am just looking for the method to get the
most out of my john on this old laptop (w/o a GPU, unfortunately).
Would it be recommended to fork it into two instances (a pointer shall
be sufficient, I can read the doc, if I know which one ^^)?
I've tested 402396136 candidates on sha (which is about seven times
faster the ripemd ...) and 1072044168 for ripemd, but am not prepared to
give up either (which results in my laptop running 24/7).
Thanks,
Demian
★ On 15/08/17 12:02 p.m. Solar Designer wrote ★
> On Sun, Aug 16, 2015 at 10:22:37PM +0100, Demian Smith wrote:
>> I have a hash (truecrypt) that is, per default, saved as three possible
>> hashtype (ripe, sha and whirlpool).
>>
>> I ran john (1.8.0.6-jumbo-1-639-gd647405) on it for some time (46 days,
>> to be precise), specifying ripe to try. I have now, just to see would it
>> be more successful, started another session for sha.
>
> I hope you're not trying to run both at the same time on the same
> machine and with OpenMP enabled in each. That would result in poor
> performance, with much processing time lost in OpenMP implementation's
> thread synchronization. (OpenMP only works well on an otherwise idle
> system.) You may, however, halve the OpenMP thread count in each, with
> the OMP_NUM_THREADS env var, in which case it'd be OK. (Still slightly
> slower than --fork, though. And a lot slower than what you can achieve
> with a GPU.)
>
>> Of course this is anything but optimal, so I was wondering could the two
>> sessions be merged= I'd remove the whirlpool hash from the hashfile and
>> just restore the "merges" session, so that both hashes are tried
>> simultaneous - or is that (both) not possible at all?
>
> I doubt there's much to merge here. I am not familiar with TrueCrypt,
> nor with the corresponding JtR format, but I think most processing time
> is in fact spent on those different hashes. So even if some steps could
> be merged (candidate password generation, decryption attempts with the
> derived keys), the speedup from that would likely be negligible. Also,
> you would have skipped all the most likely candidate passwords that you
> already tested in those 46 days from being tested against the SHA hashes.
>
> Alexander
>
--
-`ღ´-
What happens in the heart
populates the universe.
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.
