Changing default digest algo
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Nov 4 08:13:37 CET 2013
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.
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:
More information about the Gnupg-users