Re: Best practices for OpenPGP keys?
On Wed, Mar 10, 2010 at 09:44:03AM -0600, Drew Scott Daniels wrote:
> 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/
>
Sorry, can't help with specific documentation.
The main problem I see is the passphrase for your private key. Because
what does it help, if your key is ultra long, but then your passphrase
has an entropy of just 20 bits? And a passphrase with an entropy of
128 bits is impossible to remember.
I find the best trade-off between security and convenience is to store
the key on a smart card. The key would be locked/destroyed, if the
passphrase/PIN were to be entered wrongly 3 or 4 times. This solves a
lot of problems:
- the passphrase/PIN can be short and thus easy to remember
- your key can't be stolen without you noticing it, so no offline
cracking attempts are possible, and even if someone were to know your
passphrase, he still would have to get your card (though someone could
"borrow" it without you noticing).
Though of course other problems remain:
- someone could sniff your PIN between the keyboard and the
card. you'd need an EPP (encrypting PIN pad) that works together with
the card.
- if you sign a document, you can never be sure, if the document, that
you see on the screen is really the one that is actually signed.
So it still holds, that the machine on which you use your key should
be secure.
> 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.
I never thought, expiry dates were uncommon, on the contrary. Care to elaborate?
> * 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.
Revocation has a very serious problem: you can never be sure if
everybody else knows about it.
> * 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
Well, it doesn't have to be really long. Last time I checked the
consesus was that 1024 bits (for RSA) is now considered to short for
long-term security. 2048 are suggested. I use 4096, because I
can. Performance is no issue with current average computing power. You
might have to make trade-offs, if embedded systems or some such are involved.
> * 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...
Keeping the machines secure is always a good idea. But usually you
trade convinience for security. Only using a non-networked machine,
locked away in vault, is probably far too much trouble for the general use-case.
harry
PS: I think that this is really off-topic for debian-devel
Reply to: