Date: Sun, 8 Jul 2012 13:36:05 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: optimized mscash2-opencl On Sat, Jul 07, 2012 at 08:37:39PM +0200, Frank Dittrich wrote: > On 07/07/2012 11:48 AM, Solar Designer wrote: > > On Sat, Jul 07, 2012 at 01:31:06PM +0400, Solar Designer wrote: > >> Actual run: > >> > >> $ ./john -i=alpha ~/john/contest-2011/hashes-all.txt-1.mscash2 -fo=mscash2-opencl -pla=1 > > [...] > > > > I let this run until: > > > > guesses: 67 time: 0:00:28:24 0.00% c/s: 102413 trying: bara - choedia > > Use the "--show" option to display all of the cracked passwords reliably > > Session aborted > > > > Somehow john.pot and john.log were not being updated during the run, > > even though they should have been updated every 10 minutes. > > I didn't check the code. Could this be related to the fact that john was > working in the same bara - choedia MAX_KEYS_PER_CRYPT block of passwords? It could, but I think that would be a bug. With the current design, this should in fact prevent john.rec from being updated "for real" (with more than just the new running time and guess count), but it shouldn't prevent proper updates to john.pot and john.log. > Will john restart processing the bara - choedia block for all hashes, or > does the john.rec file really store information about how many > salts/hashes have already been processed for this particular block? The former. > I always thought this kind of information is not stored in a .rec file. > In that case, john would have to do almost all the work already done so > far again if you interrupt the session while it didn't finish the first > MAX_KEYS_PER_CRYPT block. (The only speedup would be due to the reduced > number of different salts) Exactly. This was not designed for large KPCs with slow hashes. We may need to solve this in some way. Here are some ideas: 1. Do record info on salts tried / not yet tried for the current keys block. This is tricky to implement. 2. Have the KPC depend on salt count - that is, reduce it when the hash is slow and we have a lot of salts loaded, so that we keep one block's duration sane (e.g., no worse than the "Save" interval, which is 10 minutes by default). Issue: with truly a lot of salts, KPC may become so low that the speed we're getting on GPU is worse than CPU's. So we'll need to impose a lowest allowed KPC as well, and disregard the original issue (of not advancing to a next block soon enough) in those cases. 3. Invoke GPU kernels on multiple salts at once, thereby letting them process fewer keys for the same amount of parallelism per invocation. This is tricky to implement and it complicates program structure. 4. Similar to the above, but rather than have John explicitly make such calls into a revised formats interface, have some formats within the existing interface use some hacks. A format implementation could cache salts on GPU side (like what myrice is implementing for another reason) and then process the keys (fewer of them) not only with the current salt, but also with previously cached salts. Further calls, for those other salts, would then return/use already-computed results. This is also tricky to implement, and it is hackish. I don't particularly like any of these options. :-( That said, we do need formats to support a variety of KPC settings (not a compile-time constant only) for other reasons as well - such as because of the single crack mode memory consumption issue, and for running with small wordlists (may have fewer entries than e.g. MSCash2's 256k KPC). 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.