Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Jun 2013 10:39:14 +1000
From: Michael Samuel <>
Subject: Re: Resume for KDEPaste external mode

If I generate an 8-char password, then put 0 into word[8], could I put the
seed into word[9] for the purposes of restore?

On 13 June 2013 09:42, Michael Samuel <> 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 <> wrote:
>> On Wed, Jun 12, 2013 at 11:57:41PM +0200, magnum wrote:
>> > On 12 Jun, 2013, at 23:45 , magnum <> 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.