Date: Wed, 26 Aug 2015 06:43:56 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: The ETA for -single is somewhat useless On Tue, Aug 25, 2015 at 11:16:58PM -0400, jfoug@....net wrote: > ---- Solar Designer <solar@...nwall.com> wrote: > > Also, it's not just a reporting issue: this granularity coincides with > > how much work will be redone if you interrupt and restore. > > If this is a buffered granularity issue (which became VERY apparent with the number of > candidates in formats like sha512crypt in recent CMIYC). and we pre-build this buffer, > and track it while running, then we could write code to store off this list, and upon resume > reload it. For cracking modes other than single, we don't even need to store and reload this buffer. Those same candidate passwords are already quickly regenerated when you restore. What you'd want to save and restore, which isn't being done now, is the current salt being tested. Yes, this sounds like an enhancement we can actually make, along with keeping track of salt progress for the percentage and ETA reporting. For single crack mode, this is slightly trickier. We may be at different rule numbers for different salts. Right now, only the oldest still in use rule number is saved and restored. Ideally, we'd need to save and restore those per-salt rule numbers, but this means a larger .rec file (or a separate file), and this in turn reduces reliability over system crashes. Another issue is that, although the per-salt candidate passwords are already regenerated on restore, some planned work is getting lost and not re-introduced (not now, and not with the changes discussed above): specifically, successful per-salt guesses only from the current run are being retested against all other salts. (A feature which you've made optional with a recent commit to jumbo. When it's disabled, this issue obviously disappears along with the feature.) > In the same manner, ETA could be deal with at time of actual work being done, > vs jumping to 50%, and sitting there for a day, then jumping to DONE and sitting there > for a day. Like I mentioned in the github issue posted about this issue, there is almost > no usefulness for ETA for this situation. Yes, it does give you a bit of insite to the amount > of queue'd work, but any form of ETA is pretty laughable. I am told the run will be over in > a couple minutes (when it starts out), and then 20 hours later it is over. I agree the ETA is broken. But it's a jumbo specific thing, so I am not responsible for it and it's yours to fix. ;-) > I did not say it was an easy problem, just that if it 'can' be improved upon, then possibly > we should look into it. Agreed. I think it's preferable to approach the instances of the problems affecting all modes other than single first. It's simpler and it will be of greater help. Hopefully, most of this can be done in a generic manner, in cracker.c rather than in each cracking mode individually. 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.