[PATCH] Add ability to save/load an md5 checkpoint file
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
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
> It is a bit of work, though.
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gcrypt-devel