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) <c...@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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
