Use a Pre-Calculated Hash for Signing a File with GnuPG

Question

When using GnuPG to sign a file, one usually uses something along the lines of:

gpg2 --detach-sign --armour <file-to-sign>

Now, let us assume that for some reasons in company X signing of releases is only possible on a remote machine. Signing involves the calculation of a cryptographic hash of the file to be signed and that hash is then encrypted with the private key. In the above company, one would have to transfer the release file to the remote machine, sign it there, delete the file again and publish the signature alongside the release file.

With large releases and slow connections, signature generation can take up hours and company X's boss does not like that, so the employees must find a faster solution.

The fast solution is to calculate the cryptographic hash of the file locally and pass the hash to the remote machine to make a signature using this hash. The idea would be to use something like:

gpg2 --detach-sign --armour --input-is-ALGO-hash <hash-for-signature>

But, how would you do that in a way that makes the resulting .sig file indistinguishable from one generated by GnuPG calculating the hash and signing it? Are there any disadvantages to this security-wise?

Answer 1

This is possible, though in a slightly different level than what you're asking. Instead of running the gpg command in the signing machine, you instead run gpg-agent, and forward the gpg-agent's socket to the machine that calculates the signature. This is effectively the same as what you're asking for, except that you'd be running gpg/gpg2 command on the machine that calculates the hash rather than the one that calculates signature.

Alternatively, you could put the private key on an OpenPGP smartcard, which can act as a key agent.

For best security though, you might want to wrap gpg agent in a service that creates audit logs of anything being signed/encrypted. Many OpenPGP smartcard does this, though the limited storage space in a card might limit a smartcard's log storage space.

Are there any disadvantages to this security-wise?

Yes, the signing machine will be blind signing everything that the hashing machine tells it to sign. It has no way to enforce a policy on what it is signing (e.g. frobnicate directory must be signed by another person, sekrit.c must contain the string "42", issue tracker must be set to "Spline Reticulated" status), you have to trust the hashing machine to check the signing policy.

Answer 2

I'm pretty sure there's no way to make it indistinguishable with standard GnuPG. GnuPG is open source so you could of course modify it, and it implements an open standard so you could use another implementation (that can get/use the signing key) which is probably easier to modify, such as BouncyCastle at least in the Java version (which I use; I'm not a dotnetter) (although whether you can install Java on a security-significant system may be an argument on its own).

An alternative which is fairly common and accepted IME is to use two stages:

• use sha1sum (no longer preferred) or sha256sum or similar to create a (small) file e.g. 'hash' containing the name and (hex) hash of the real file(s); if there are multiple component and/or variant and/or otherwise related files in one logical release, you can put multiple hashes and names into one 'hash' file

• PGP detached-sign or clear-sign the small 'hash' file

The recipient correspondingly

• PGP verifies the 'hash' file

• uses sha256sum -c hash or similar to verify the real file(s) match the hash(es) in the 'hash' file

This allows a recipient who doesn't have a PGP implementation (or can't get or doesn't trust the signing key, but that's less likely) but who can get the 'hash' file securely enough, e.g. from an HTTPS website, to verify the file(s), which would range from hard to impossible with only a PGP signature.

Obviously you need to make sure that the hash value(s) in method A, or the 'hash' file in method B, is transferred from the hashing maching to the signing machine by a channel that can't be blocked or tampered by any adversary, as well as each of them being secure on its own.

Answer 3

This is an interesting question. Unfortunately I don't have a good answer for you, only some more things to think about.

I'm thinking along the following lines:

The most obvious gain you get from moving the signing step to it's own host is that you can isolate the private key used for signatures on a machine that only does the signing, and therefore protect it better from being stolen or misused.

But then I start wondering: Is that really relevant?

If you keep the signing code and key on another host, you'll have to put in place some kind of service that sends the signing host the hashes (or files) to sign, and the signing host returns you a valid signature.

Now assume the host that has the release files is breached. The attacker will most likely be able to use the signing service to get any content he chooses signed (and if he doesn't, that means he doesn't get full root access, and wouldn't have gained access to a signing key sitting directly on the host, either). So even though he doesn't control the private key used for signing, he can still get what he wants - valid signatures on his chosen content.

Basically, look at it from this perspective: The security of the host that holds the release files is absolutely critical. If it is breached, and an attacker manages to change the release files, it won't really matter that he doesn't have access to the signing key.

Also, by separating out the signing step, you've created a new avenue of attack: If an attacker cannot get access to the server that keeps the release files, he might try to get access to the signing service. If he can successfully pose as the server that keeps the release files, or otherwise gain access to the service, you've also lost.

So what exactly have you gained in security by separating the file host and the signing host? If your main reason for not signing the release files where they are, but doing it on a different host, is in fact to protect the key, couldn't you use a master key to sign a signing key with it, protect the master key by keeping it offline, and using the signing key directly on the host that has the release files?

If the host was breached, you could revoke the signing key and create a new one, again signed by the master key.