Best practices for securely creating master RSA key

[Daniel Kahn Gillmor]

Hi Tomer--

On 05/10/2014 05:23 AM, Tomer Altman wrote:
> 1. Find a computer that you think is relatively free of malware
> 2. Download a Live Linux distro CD/DVD/USB, and verify its signatures to make sure you are not installing a tainted version
> 3. Launch the verified Linux distro. 
> 4. Use GnuPG to create private RSA key, and two subkeys (signing & encrypting)
> 5. Strip the master private key from the keychain, saving on an encrypted medium (e.g., encrypted USB stick)
> 6. Create necessary revocation certificates, also save on encrypted USB stick
> 7. Copy over GnuPG keychain without master private key to work computer, personal laptop, etc.
> 8. Store encrypted USB stick somewhere safe
> 
> Can people comment on what I recalled correctly, and what needs to be added/modified?

Your steps above seem pretty sensible to me, especially if you don't
already have a trust-worthy, trusted machine that runs gpg.  I would
only adjust the creation and storage of the revocation certificate(s).

first: i think you only need one revocation certificate, not several; in
particular, you should make a generic "this key has been compromised"
certificate for your primary key.  This certificate is capable of
invalidating all your user IDs and subkeys.

second: I don't think it makes sense to store the revocation certificate
on the same medium (the encrypted USB stick) as the primary secret key.

If you need to revoke, and the encrypted USB stick is still available to
you, then you can just use the primary secret key to generate a new
revocation certificate (which can even be clearer about the specific
reason for revocation, if you want it to be.

If you need to revoke, and the encrypted USB stick is not available
(e.g. it is physically lost, destroyed, or you no longer have access to
the passphrase), then you won't be able to get to the revocation
certificate.

So that suggests that you probably want to store the revocation
certificate someplace else.  I'd argue that you probably want it to be
*more* available than your master secret key.  If your revocation
certificate is compromised, the worst that an attacker can do is
invalidate your key.  This is a bad thing, but not nearly as bad as what
a compromise of the master secret key could do.

You could print out the revocation certificate and store it in a safe
place, or entrust it to a technically-proficient and responsible friend.
 Or do both :)

When printing, you could use plain ascii text (the armored certificate)
or you could pass it through a tool like optar (or other
machine-readable encoding mechanisms) to make it more easily recoverable
from paper.  I'm not sure that the machine-readability is particularly
useful.   It's a lot of work to type in an ascii revocation certificate
by hand (esp. with large RSA keys), but if you ever have good cause to
use your revocation certificate, you will probably have much more work
to do (repairing your digital identity) and typing in a dozen lines of
base64 will seem simple by comparison :P

All the best,

	--dkg



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140510/fa000e8e/attachment.sig>