Changing default digest algo

[Daniel Kahn Gillmor]

On 11/04/2013 12:45 AM, Chuck Peters wrote:
> I added the following to gpg.conf:
> personal-digest-preferences SHA512
> cert-digest-algo SHA512
> default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
> CAST5 ZLIB BZIP2 ZIP Uncompressed
>
> I changed the preferences:
> gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB
> BZIP2 ZIP Uncompressed
>
> And verified:
> gpg> showpref
> [ultimate] (1). Charles F. Peters II (Chuck) <cp at axs.org>
>       Cipher: AES256, AES192, AES, CAST5, 3DES
>       Digest: SHA512, SHA384, SHA256, SHA224, SHA1
>       Compression: ZLIB, BZIP2, ZIP, Uncompressed
>       Features: MDC, Keyserver no-modify

these steps look right to me, though i don't see the updated preferences 
on the public keyserver network yet.

> When I check the keys, it still shows SHA1:
> $ gpg --export-options export-minimal --export 23E9EB24 | gpg
> --list-packets |grep -A 2 signature|grep 'digest algo 2,'
>          digest algo 2, begin of digest a3 6e
>          digest algo 2, begin of digest 3b 34
>          digest algo 2, begin of digest f2 3e
>          digest algo 2, begin of digest ae 58
>          digest algo 2, begin of digest 67 fa
>          digest algo 2, begin of digest e6 39


your key has four signing-capable subkeys and two encryption-capable 
subkeys.  It also has two user IDs.  This means that there should be 
eight self-signatures (4 + 2 + 2 = 8).  Above, you're only showing 6 
self-sigs with SHA-1.  I suspect that your User IDs (where the 
preference subpackets are stored) are actually being certified with a 
stronger digest, but your subkey binding signatures have not been adjusted.

I just tested with an example profile using configuration options 
similar to the ones you've described above, and found that newly-created 
subkeys (after the config change) are bound with a subkey binding 
signature over the preferred cert-digest-algo.  so one approach (if 
there are no other suggestions for re-creating new subkey binding 
signatures on the existing subkeys) is that you could generate new 
subkeys and revoke the old ones.

hth,

	--dkg

PS as an aside, having two 4096-bit encryption-capable subkeys is 
probably not useful.  Your peers who encrypt traffic to you will need to 
choose one to encrypt to, and they will just choose the most recent one. 
  I recommend revoking all but the most recent.  If you have a good 
reason for keeping all 4 signing-capable subkeys (e.g. you are 
distributing signing-capable subkeys to separate devices which you want 
to be able to revoke if those devices become compromised), that's fine. 
  If that's not the case, you probably want to revoke most of those 
signing-capable subkeys too.

PPS you may be interested in:

  http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024986.html