On 6/1/2025 16:54:19, Richard Stoughton via Gnupg-users wrote:
On Tue, May 20, 2025 at 10:09 AM Werner Koch<[email protected]> 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
_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users
