Date: Thu, 13 Jun 2013 10:39:14 +1000 From: Michael Samuel <mik@...net.net> To: john-users@...ts.openwall.com Subject: Re: Resume for KDEPaste external mode If I generate an 8-char password, then put 0 into word, could I put the seed into word for the purposes of restore? On 13 June 2013 09:42, Michael Samuel <mik@...net.net> wrote: > Hi, > > Sorry about that - to restore you need to keep track of the seed. You > shouldn't need restore for this if you narrow down the time range (eg. > using a password expiry field) - it's almost instant. > > Regards, > Michael > > > On 13 June 2013 08:41, Solar Designer <solar@...nwall.com> wrote: > >> On Wed, Jun 12, 2013 at 11:57:41PM +0200, magnum wrote: >> > On 12 Jun, 2013, at 23:45 , magnum <john.magnum@...hmail.com> wrote: >> > > KDEPaste lacks a restore() function. If you resume it, it will just >> restart from scratch. My first question is: Should this not be detected and >> resulting in refusal to resume? Or could some modes work fine without a >> resume() function? I guess some could... but at least we should warn or >> something? >> > >> > On second thought I really think it should bail out with error. Modes >> that don't really need any special code should implement a dummy restore(). >> I will try implementing this in Jumbo and see where it goes but it should >> be in core too IMHO. >> >> There are definitely external modes that are --restore'able even though >> they lack a restore(). Warning when there's no restore() and adding a >> dummy restore() to those formats to suppress the new warnings is an >> interesting idea. >> >> I was also thinking of some way to make interrupt/restore of external >> modes easier - such as by introducing a way to declare external mode >> variables that would be automatically saved and restored (maybe have >> "static" mean this, or introduce a keyword of our own - e.g., "restore"). >> In terms of implementation, we could either traverse the variables list >> and save/restore the needed ones - or we could have these placed in a >> separate memory region, which would be saved/restored in its entirety. >> >> In fact, we could easily be saving/restoring all of the variables, but >> this would make the .rec files for some external modes much larger than >> necessary, which with the current in-place rewrites could reduce >> reliability over system crashes, and it'd have some performance impact. >> >> 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.