What determines the clearsign hash algorithm used by GnuPG

digital-signaturegnupgopenpgp

When using GnuPG to clear sign a text, there is a hash part in signed message. Take the example:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

abc
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEZZvqE5j3koIxs9Xim0+E4a5Vo2cFAlkRdvQACgkQm0+E4a5V
o2ew2QgAzHuvZ7Hlb6+3qRLjc9Yhdi+6tBmNWXbWpKoAQxpzx6jKQp/FSpQeGWuj
RxcYnqU3pk4ycMLtaCFcfnHEW5N0B95eXGcurgMGz7A6xhy0hy25x8WBdeKVAQ+2
PLA2ytJLUn2L1S3ueqJWcdVUBRaiczOOsYvvO
...
...

-----END PGP SIGNATURE-----

But the hash algorithm is different for different keys (or servers), sometimes SHA1, sometimes SHA256, SHA512.

What determines this, the key or GnuPG client? I can't find info on this, when you use gpg create new keys , there is no option to specify the hash algorithm.

update: to clearify my question, I added more info below.
the command used to generate the example output above, is :

gpg --clearsign

( The gpg version is gpg2 on my system. )

then , I typed some random text and there comes the result above.
I wish to know, how to generate output with specific "Hash:" values ? say, SHA1 ?

Best Answer

The hashing algorithm is chosen by the implementation of OpenPGP, in your case GnuPG. Which one gets selected

is obviously restricted to algorithms support by GnuPG (gpg --version prints a list),
depends on compliance options used and finally
depends on your personal preferences.

For encrypting messages, additionally the recipient's preferences stored in the public key are considered.

Related Solutions

GnuPG Command Line – Verifying KeePass Signature

On the first command you provided you should be referencing the .asc signature file - not the .exe file. The .exe file should also be residing in the same directory as the .asc file.

From the gpg man page:

--verify
      Assume that the first argument is a signed file or a detached signature and verify it without generat-
      ing any output. With no arguments, the signature packet is read from STDIN. If only a sigfile is given,
      it may be a complete signature or a detached signature, in which case the signed stuff is expected in a
      file without the ".sig" or ".asc" extension.  With more than 1 argument, the first should be a detached
      signature and the remaining files are the signed stuff. To read the signed stuff from STDIN,  use  '-''
      as the second filename.  For security reasons a detached signature cannot read the signed material from
      STDIN without denoting it in the above way.

Verifying files with GPG, without a .sig or .asc file

Received an explanation from the GNU/GCC team about this, and the .sig files were missing due to an error with file replication to their mirror servers. From the team:

Interestingly, the .sig files are only on the GNU server (e.g., http://ftp.gnu.org/gnu/gcc/gcc-4.8.0/) but not on the GCC server (e.g., ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.8.0/). As the latter is used by the mirrors, it is also not available on the mirrors.

I found the .sig files on the GNU server like they suggested, but then had to dig some more to find the "GNU keyring file" required to actually verify the signature. All in all, the verification process was:

$ wget http://www.netgull.com/gcc/releases/gcc-4.8.0/gcc-4.8.0.tar.gz
$ wget http://ftp.gnu.org/gnu/gcc/gcc-4.8.0/gcc-4.8.0.tar.gz.sig
$ wget ftp://ftp.gnu.org/gnu/gnu-keyring.gpg
$ gpg --verify --keyring ./gnu-keyring.gpg ./gcc-4.8.0.tar.gz.sig

gpg: Signature made Fri 22 Mar 2013 08:32:29 AM CDT using DSA key ID C3C45C06
gpg: Good signature from "Jakub Jelinek <jakub@redhat.com>"
gpg: Note: This key has expired!
Primary key fingerprint: 33C2 35A3 4C46 AA3F FB29  3709 A328 C3A2 C3C4 5C06

Hopefully this helps anyone else trying to verify a tarball downloaded from one of GCC's mirror sites.

Related Question