Signing a file given its hash only

[Jakob Bohm]

On 6/1/2025 16:54:19, Richard Stoughton via Gnupg-users wrote:
> On Tue, May 20, 2025 at 10:09 AM Werner Koch<wk at gnupg.org> wrote:
>> On Mon, 19 May 2025 15:40, Richard Stoughton said:
>>
>>> creates the final signatures. This could be done in a much more
>>> efficient way if GnuPG would be able to create signatures with hashes
>>> instead of  the complete file content as input.
>> Many years ago we pondered wit this idea.  However it is complicated
>> because *PGP does not simpluy sign a hash but has a prefix and a suffix
>> to append.  Thus for signing we would need to provide a tool which takes
>> some internal hash context, continue to has the file, and let gpg
>> finalize the hashing.  This is a bit ugly and would raise problems with
>> certifications etc.
> OK, I see that by signing a hash it is not feasible to obtain the
> signature for the file hashed.
>
> So we'll try another approach to preserve the security level of M on L:
>
> H injects a secret nonce into a build run on M. M uses the nonce to
> create a MAC for each artifact it creates. M pushes the MACs along
> with the artifacts to L.
>
> To sign an artifact H fetches the artifact and the corresponding MAC
> to its local file system. Then H verifies the MAC using the secret
> nonce it has previously injected into the build on M. If the MAC is
> valid then H signs the artifact using gpg. Then H pushes the signature
> to L.
The closest to the OP described approach would be to generalize the code
referenced in yesterday's post from Wiktor Kwapisiewicz .

Otherwise, here's a simple traditional approach not needing to
manage a custom MAC key  (This is based on an earlier suggestion
in this thread):

1. M computes a traditional file of hashes in the same format as
   output by the GNU CoreUtils command:
    shaXXXsum -b filename.ext filetwo2.ex2 filetre3.ex3

2. Someone trusted picks up the file of hashes while looking for
   signs of compromise of M, then submits the file of hashes to H
   with appropriate user authentication (like being someone with
   login access to H and checking the hash file on H is the same
   one just checked ) .

   Note: "Signs of compromise" is the same well known security
   concept applied by security guards to notice if a door has
   been forced open since the last round.  It is imperfect but
   good enough .

3. H runs a trusted minimalist (less trusted code!) script that
   checks that the hash file has the right number of lines, right
   filenames, and right line format (a specific number of
   lowercase hex digits, a space, a star, the expected filename,
   end-of line), then invokes gpg to sign the file of hashes .
    Note that this does not require H to have the storage space
   for the full artifacts.

4. L checks the signature on the signed file of hashes using gpgv,
   then rechecks the hash file content format (like on H), then
   checks the file hashes like running the GNU CoreUtils command
     shaXXXsum -c hashfileWithoutTheSignture.shaXXXsums


>> Our solution was to to implement remote signing.  This allows to do the
>> private key operations on your machines while the actual hashing and
>> signing is done on the server.  From a security POV this is the same as
>> running only the bulk hashing on the server.
> I don't think that I can use remote signing in our use case.
>
> If L is compromized, an attacker could possibly spoof the artifact
> presented to the MAC validation while letting gpg sign a compromized
> artifact.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250603/f1ec1470/attachment-0001.html>