Secret key storage question

[Robert J. Hansen]

> Mac GPG applications.  Before I looked at implementing this, though, I 
> wanted to know if there would be some benefit (i.e. there's some real 
> improved difficulty in hacking the key if someone got hold of your 
> secret keyring and the passphrase is long and random enough that the 
> user couldn't remember it without a program like Keychain).

Once the private key is acquired, the strength of the
passphrase--defined by how much entropy the passphrase possesses--is the
only thing that stands between the user and a catastrophic key
compromise.  So yes, there is a benefit to having strong passphrases,
but only in the event your private key is acquired--otherwise it's a
case of "they serve as well who merely stand and wait".

> A follow up question:  what would be the longest reasonable length for a 
> passphrase (keeping in mind the other three factors David Shaw mentioned 
> that are involved in protecting a secret key)?

About 100 English letters.  At that point you've got 130 bits of
entropy, which is more than the 128-bit cipher used to protect the
passphrase.

> Also, can the passphrase be any string of bits (lumped into bytes before 
> giving it to GnuPG), or are there some limitations?

GnuPG is written in C, and C's string-handling routines are quite
fragile.  Even if GnuPG handles arbitrary binary input, there's no
guarantee that the standard C library on whatever system it's running on
will be as well-behaved.

As an obvious example, consider throwing in a zero-byte.  Zero-byte has
two meanings: one is ASCII 0 (NULL), and the other is C "end of
string".  So if your passphrase were to be 128 bits, but in bits 8-15
you had eight binary 0s, GnuPG would stop reading the input and truncate
your passphrase at bit 8--leaving you with only eight bits of entropy in
your passphrase.

That's an obvious example; there may well be more subtle ones, depending
on your platform and how fragile your C library's string calls are. 
Stick to ASCII 32-127.