Best practices for OpenPGP keys?
Hi,
Is there any good documentation about best practices for OpenPGP key
management? I plan to use gnupg (gpg), as it's conventional and seems like
the "best of breed" these days.
Most documentation I've found seems significantly out of date (including
long discussions of incompatibilities with versions from 2001...). I did
find it interesting that the IDEA patents are expiring in May this year
for the EU and US if I remember
The best documentation I have found includes:
http://arfore.com/2007/07/29/gpg-best-practices/
http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/
Over the years I've heard some ideas like:
* Only store your key on less common architecture to make break-ins
involve more esoteric techniques (e.g. common rootkits/scripts fail). A
variant of this would be adding a level of virtual abstraction by using
a virtual machine (though it's just a level of obfuscation).
* Set an expiry date on your primary key and/or sub-key and sign a new
key before the old key expires. I think this is problematic for some
key reading programs though I can't remember any instances. Expiry
dates aren't default and seemed to be uncommon last time I checked.
* Revoke primary and/or sub-keys after expiration, or instead of
expiration. While revoking keys can keep people from using the old key
even if they cracked it, many programs might expect that revoked keys
aren't trustworthy at all.
* Use a really long keylength for your sub-key. The trade off seems to
be that signing and encrypting things takes a lot longer.
* Use a really long keylength for your primary key and
* Don't store your key on machines that connect to any networks.
Transferring signed data is time consuming, inconvenient... I'm not
sure if it's fair to say it's vulnerable to social engineering attacks.
* Use a random string for your passphrase. I was "bit" by this on my
first attempt to use a keypair years ago (around 2003). I forgot the
passphrase.
* "Harden" machines that contain your private key. While it's usually a
good idea to do this for all machines, I would hope that most things
would be secure without having to spend the extra time doing
configurations...
>From the breakins over the years, and from the difficulties with "extra
secure" choices from some people, I really wonder whether best practices
aren't for a more secure key, but simply for good management of the
location of the key, the passphrase, the revocation data, and patients for
slow signing.
I think key-pair usage could use:
* Default expiry times. This would make expiry more common.
* Implied expiry for old keys (though "old" isn't reliable).
* Use of the existing levels of security, or new levels as it seems the
highest level of trust is all too often required.
* Spliting trust of identity from trust of actions. SSL management has
personal, server, and program sections. Imagine signing someone's key
because you know who they are, then wanting to not trust code that they
write, or not trust that their signing of other peoples keys.
* SELinux policy to only allow certain programs access to private keys
made default. E.g. It would be nice if I could prevent scp from
accessing my private key without my explicit authorization by changing
the security context, or via a proxy program's authorization (the proxy
could log the event etc.). AppArmor to exclude access to the private
key is something I think that already happens. A nice guide to
implement the appropriate SELinux security context for a private key
would be nice, maybe I'm missing something from gnupg, fedora and/or
elsewhere.
Please CC me on replies.
Thanks,
Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html
Reply to: