[PATCH] Allow signing of files which are not present on the system

Jerome Baum jerome at jeromebaum.com
Wed Jul 27 18:48:55 CEST 2011

Why modify print-md to no longer print the "normal" hash?


Am 27.07.2011 18:20 schrieb "Steven J. Murdoch" <
gnupg+Steven.Murdoch at cl.cam.ac.uk>:

For a particular use case of GnuPG, I needed to sign a number of files which
were not on the same machine as the private key. It would be insecure to
the private key to the machine with the files, and it would take a very long
time to download all the files to the machine with the private key.

I've written a patch which does this (attached), but I'd like to find out
whether this (after some cleaning up), would be considered for acceptance?

Options I looked at included forwarding gpg-agent over SSH, but gpg-agent
still requires having the private key on the machine doing the signing.

I therefore looked into signing a hash of the file, as suggested here:

It turned out to be a bit more complicated than that mail suggested, because
GnuPG appends a footer to the file to be signed, before calculating the hash
which is actually signed. This footer includes a timestamp, so is different
time. Therefore, I don't think it is possible to sign a file, given only the
hash of that file.

My solution was to modify --print-md to output the intermediate state of the
hash calculation, after hashing the file but before finalizing the hash.
Then I
modified --sign so that it will accept this intermediate state as input.

To use it, on the system with the files you want to sign, run:
$ gpg --with-colons --print-md sha256 FILENAME | cut -f 4 -d ':'
where FILENAME is the name of the file you want to sign.
This will output the intermediate state of the message digest needed to
calculate a SHA256 signature.

On the system with your private key run:
$ gpg --use-agent --load-md-state STATE --personal-digest-preferences sha256
--detach-sign --output OUTPUT < /dev/null
where STATE is the intermediate state output by the command above, and
where you want to save the signature.

The attached patch (on GnuPG 1.4.11) works, but needs some cleaning up
before it
could be merged. My question is whether this feature would be considered for
acceptance by the GnuPG team?

I would also like feedback on both the feature design and patch code.



Gnupg-devel mailing list
Gnupg-devel at gnupg.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110727/9b656a15/attachment.htm>

More information about the Gnupg-devel mailing list