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. > 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. _______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
