Best practices for securely creating master RSA key
taltman1 at stanford.edu
Mon May 12 09:35:16 CEST 2014
Hi dkg & Josef,
Thank you very much for your replies. I appreciate it.
Below please find my revised steps to follow, as per your advice.
dkg, I had a few questions:
You recommend creating a revocation certificate against the private key, but the GPG documentation seems to recommend creating the revocation certificate against the public (sub-)key:
What are the pluses and minuses of the two approaches?
Also, do you know if such a set of recommended steps is documented somewhere. I *swear* that I saw it somewhere on the myriad GPG webpages, but now I can't seem to find it. If it does not exist, do you think it would be worthwhile to add it somewhere, perhaps as a FAQ entry?
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
3.1 Make sure the distro is completely disconnected from any network connection before proceeding
4. Use GnuPG to create private RSA key, and two subkeys (signing &
4.1 Set expiration date on (public) sub-key
4.2 Create both a paper and digital backup of master private key
Store the backups in two different physical locations, so no single point
4.3 Create a revocation certificate for the public encrypting sub-key
4.4 Create both a paper and digital backup of the revocation certificate
Store the backups in two different physical locations, so no
single point of failure
5. Strip the master private key from the keychain.
6. Copy over GnuPG keychain without master private key to work computer, personal laptop, etc.
----- Original Message -----
From: "Daniel Kahn Gillmor" <dkg at fifthhorseman.net>
To: "Tomer Altman" <taltman1 at stanford.edu>, gnupg-users at gnupg.org
Sent: Saturday, May 10, 2014 9:06:38 AM
Subject: Re: Best practices for securely creating master RSA key
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
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,
More information about the Gnupg-users