Best Practices

[David Tomaschik]

I'm currently in the process of changing my "primary" email address.  I have
hopes to make this a permanent transition, and have had some thoughts about
my existing GPG keypair.

For better or worse, I've been playing around with GPG since I was a
teenager, and (unfortunately) there are a number of keys on the keyservers
that bear my name.  The good news is that with the exception of one old
(2000) keypair, all the others that I no longer use have been revoked.  I
feel bad for the "litter" this introduces to the keyservers.

I currently have a 4096-bit RSA sign/encrypt keypair with no subkeys.  I
believe, but am not certain, that it was generated with SHA1 hashes.  (Is
there a way I can check?)  This keypair was generated in May of this year.

What is the best way to transition my email address?  Add a new UID and
revoke the old?  Should a new keypair be generated?  What is the
conventional wisdom on the strength of RSA-4096?

If a new keypair is generated, what length would be sufficient for a decent
(10+ year, preferrably 20+) margin of safety?  I know that there may be
unforeseen advances in computing that allow for keys to be broken rapidly
(Quantum computing, new sieve algorithms, etc.), but there's surely some
guidance based on the current generation of things.  keylength.com suggests
4096 bits should probably be fine.

In a new keypair, is it safe to use SHA512 for hashes?  I know SHA1 is
unlikely to hold up for 20+ years.  I can't say that SHA512 will, but it
will almost certainly outlast SHA1.

Is it considered best practice to use a "master key" only for key signing
and use separate subkeys for signing/encrypting data?

Most of the GPG best practices I can find online are quite dated, and since
the field of encryption is changing so rapidly, I thought the insights of
this group might be useful in my next steps.  Your help is appreciated.

-- 
David Tomaschik, RHCE, LPIC-1
GNU/Linux System Architect
david at systemoverlord.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20101209/791bcf0b/attachment.htm>