[PATCH] Add ability to save/load an md5 checkpoint file

Ben Guthro ben.guthro at virtualcomputer.com
Thu Dec 1 13:49:31 CET 2011


I figured it was a bit of a long shot that you'd take the patch as-is...but thought it was 
useful functionality that might, at least spark a discussion as to the proper way to
implement such a feature that would be acceptable upstream.

As for copyright assignments...doesn't the code fall under the existing copyright in
the file?

On Dec 1, 2011, at 7:28 AM, Werner Koch wrote:

> On Wed, 30 Nov 2011 22:59, ben.guthro at virtualcomputer.com said:
>> For large encryption streams - it can be convenient to write a checkpoint file, 
>> to be able to be able to resume later.
> 
> I can image that is is usable.  However, your code does not fit into the
> Libgcrypt architecture: It is only for an old and for most purposes
> broken algorithm, it uses direct write to a file and it is not
> architecture neutral.  Further we would need copyright assignments to
> the FSF.
> 
> A better way of doing this is to have a general way of serializing and
> exporting/importing the state of a hash algorithm.  Given that the state
> is an internal property of Libgcrypt, we can't export it because that
> would mean to keep that serialized state compatible to all future
> versions; this is a too high burden for maintenance.  What we can do is
> to return the state a long with a version number and allow restoring it
> only if the version number matches - that should be okay for this
> purpose.
> 
> It is a bit of work, though.
> 
> 
> Salam-Shalom,
> 
>   Werner
> 
> 
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
> 




More information about the Gcrypt-devel mailing list