<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 6/1/2025 16:54:19, Richard Stoughton
via Gnupg-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADmVL_7eZ6RQhnpdc+5kv0C7=LrRfCqNx9X_N2sV7j=8BedtZA@mail.gmail.com">
<pre wrap="" class="moz-quote-pre">On Tue, May 20, 2025 at 10:09 AM Werner Koch <a class="moz-txt-link-rfc2396E" href="mailto:wk@gnupg.org"><wk@gnupg.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
On Mon, 19 May 2025 15:40, Richard Stoughton said:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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.
</pre>
</blockquote>
<font face="monospace">The closest to the OP described approach
would be to generalize the code<br>
referenced in yesterday's post from Wiktor Kwapisiewicz .<br>
<br>
Otherwise, here's a simple traditional approach not needing to<br>
manage a custom MAC key (This is based on an earlier suggestion<br>
in this thread):<br>
<br>
1. M computes a traditional file of hashes in the same format as<br>
output by the GNU CoreUtils command:<br>
shaXXXsum -b filename.ext filetwo2.ex2 filetre3.ex3<br>
<br>
2. Someone trusted picks up the file of hashes while looking for<br>
signs of compromise of M, then submits the file of hashes to H <br>
with appropriate user authentication (like being someone with <br>
login access to H and checking the hash file on H is the same<br>
one just checked ) .<br>
<br>
Note: "Signs of compromise" is the same well known security <br>
concept applied by security guards to notice if a door has <br>
been forced open since the last round. It is imperfect but <br>
good enough .<br>
<br>
3. H runs a trusted minimalist (less trusted code!) script that <br>
checks that the hash file has the right number of lines, right<br>
filenames, and right line format (a specific number of <br>
lowercase hex digits, a space, a star, the expected filename,<br>
end-of line), then invokes gpg to sign the file of hashes .<br>
Note that this does not require H to have the storage space<br>
for the full artifacts.<br>
<br>
4. L checks the signature on the signed file of hashes using gpgv,<br>
then rechecks the hash file content format (like on H), then<br>
checks the file hashes like running the GNU CoreUtils command<br>
shaXXXsum -c hashfileWithoutTheSignture.shaXXXsums<br>
</font><br>
<br>
<blockquote type="cite"
cite="mid:CADmVL_7eZ6RQhnpdc+5kv0C7=LrRfCqNx9X_N2sV7j=8BedtZA@mail.gmail.com">
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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.
</pre>
</blockquote>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
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 </pre>
</body>
</html>