Best Practices

David Tomaschik david at
Sun Dec 12 08:10:04 CET 2010

My thoughts at this point are to generate a new RSA4k certify-only key,
generate subkeys (probably RSA2k) for each encrypt and sign, move the
primary key offline (stored in 2 secure places) and then use the subkeys for
daily operations.  This seems to be the method most people who are fairly
concerned with security are using.  I may place my keys on a smart card at
some point, but I haven't decided on that yet.  (I'm aware that there are
some attacks I'm vulnerable to by not using one, but the offline
certify/primary key should help mitigate some of that.)

In my gpg.conf, I have (other than keyserver/no-greeting/etc. settings):
personal-digest-preferences SHA512
cert-digest-algo SHA512

Are there any other settings (or changes to these) that would be considered
more "forward looking"?

I appreciate everyone's help on this -- trying to make sure I get it


On Sat, Dec 11, 2010 at 11:24 AM, Robert J. Hansen <rjh at>wrote:

> On 12/10/2010 9:16 PM, David Tomaschik wrote:
> > Are there any disadvantages to distinct signature & encryption keys?
> None that I've found.
> > Is the weakness in the hash used to sign the key internally, or just when
> > it is used to sign data?  I guess that's the part that eludes me.
> Err -- "yes."
> A certificate is just a block of key material plus some associated data.
>  SHA-1 is used internally by the certificate to sign some parts of the
> data, as well as for computing a key fingerprint.  You can to some
> extent mitigate how much SHA-1 gets used, but you can't remove it
> completely.
> You can also choose to use SHA-1 to sign messages and files.  Here, you
> can remove it completely in favor of some other hash algorithm.
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at

David Tomaschik, RHCE, LPIC-1
GNU/Linux System Architect
GPG: 0x
david at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101212/5ed7368a/attachment.htm>

More information about the Gnupg-users mailing list