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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e81248fe0396a754c3fc202791ccdfb6.squir...@webmail.dreamhost.com