Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm new to using GnuPG and trying to understand how best to use it. I've reviewed Short, easy to understand explanation of GPG/PGP for nontechnical people?, but most guides explain PGP with a single-machine perspective.

I want to use GnuPG on three computing devices: a Linux PC, a Linux laptop, and an Android phone.

The fundamental use case is encrypting/decrypting email managed by an IMAP service, so all devices need the same private key for decryption.

I figure my choices are:

  1. Just copy all my keys to the keyring on each device and rely mainly on the private key password for protection.

  2. Create a master key (with --gen-key) to represent my identity, then create a separate disposable key (again with --gen-key) for encrypting/decrypting emails and signed with the master key. The former resides only on my PC, the latter is distributed to each device. As long as my mobile devices are not compromised, then the disposable key remains valid.

I may be overly paranoid and making this more complicated than it has to be, but humor me, please. I believe in not putting all your eggs in one basket.

The master key is supposed to be my digital identity. A lot of effort will be spent building trust around that identity, and I'd rather suffer the inconvenience of my paranoia than lose my key from carelessness and have to build trust around a new master key (maybe this isn't as bad as I think, but I am new to this).

I'm more likely to lose my laptop or my phone than my PC. If loss == compromise, then I'd rather lose an disposable key-pair (which I can revoke) than my master key-pair. I can always bestow the trust of my master key upon a new disposable key.

Sorry for the really long question. :-)


Is a password sufficient protection for storing my master private key across multiple devices?

Is my plan for option #2 feasible? Did I get something wrong or can it be improved?

If option #2 is a bad idea, then what are the best practices when using GnuPG for a single user across multiple devices?

share|improve this question

2 Answers 2

up vote 10 down vote accepted

Well, this is a bit embarrassing. I've spent hours over the course of a week trying to figure this problem out, and the answer appears to lie with subkeys--a topic the GnuPG manual and FAQ glosses over.

While researching what subkeys are and why they might be used instead of --gen-key, I stumbled across this gem: http://wiki.debian.org/subkeys.

Debian's wiki explains how to implement option #2 (see OP) using a master key with subkeys, and further explains how to remove the master key from any system after storing it on a backup medium (e.g. a flash drive). The subkeys can then be distributed among my keyrings on each device.


  1. Does not rely mainly on password to protect master key,

  2. If any system is compromised, the master key is not immediately available (unless I foolishly leave my flash drive plugged in, or attach said drive to a compromised system),

  3. This is a practice implemented by the Debian development team.

  4. Uses the subkey feature of GnuPG. Which seems a bit more organized than having a bunch of loose keys on your keyring, yes?

share|improve this answer
Good Q&A, but AFAIK there's still one problem with this setup... It's great for signing, but not for encryption if you don't want to share the same enc key between your different devices, because when someone makes you recipient of an encrypted message, gpg use by default the latest not revoked enc key generated. It's not possible to force the senders to use an specific enc subkey depending on UID (home or work, etc). –  KurzedMetal Oct 17 '12 at 2:12
Perhaps this is a problem. My greatest concern is losing the web of trust that I build around my master key (which only signs). Of course the encryption subkey must exist on all devices I use to read encrypted messages. If my encryption key is ever compromised, then the recovery process involves only myself; as opposed to losing my master signing key and having to ask/convince my web of trust to sign the new key. I did not intend to relocate the encryption subkey in my vault. –  Justin C Jul 16 '13 at 20:06

As somebody who also doesn't like single points of failure (including master keys and especially passwords), this is the way I would do it. It allows for devices to operate via a web of trust, while still allowing decentralized identity.

I don't know if there's already an existing system for this, but I think it could probably be scrobbled together with a cron job and a few lines of Bash.

In this system, you have two classes of keypair: device keypairs and timeframe keypairs. One device keypair is generated for the user on each device, and stays on that device for its lifetime. A timeframe keypair is generated by a central server at routine intervals (monthly, daily, hourly - depends on how paranoid you want to be). The public key is announced publicly (the server itself having its own device keypair to sign with), and the private key is distributed encrypted with the public key of each device that is meant to have access to this key. (This distribution should be as private as possible, eg. having devices connect to the server directly.)

For signing messages, you would use the device key of whatever device you're sending the message from. If someone wants to send you a message, they can sign it with your current public timeframe key. (They should have an automated system to keep up with announcements.) You can then read their message from any device.

For reading older encrypted messages, older timeframe keypairs are backed up on each device according to an appropriate strategy (including the timeframe-keypair-generating server, if you so wish - again, depending on your level of paranoia), where you have another set of password-protected keypairs protecting the older keys (with however many passwords over time as you feel comfortable remembering).

If a device is stolen or otherwise compromised, you can use another one of your publically-trusted devices to create a publicly-signed message verifying your identity (by whatever means, eg. noting that you will be at a public meetup and/or or having a trusted friend verify you in person) and revoking the compromised device key and any timeframe keys it had access to. When revoking the key, you also remove the stolen device from the server's list of trusted devices (with a password and your trusted device key).

The policy for trusting newly-announced device keys should follow something like current trust policies- I believe an appropriate policy is to trust the generating server, a mobile device, and a big-and-heavy device, as it is hard to steal/infiltrate a user's phone, a desktop PC, and VPS in a concerted heist before the user notices.

If your server is compromised, you just revoke it by the same procedure described for any other compromised device (possibly with a stronger policy akin to the one for adding a new device), and use a re-secured or altogether new server (with a new device keypair) going forward.

share|improve this answer
The revoking section is a little cloudy as written - revoking a device should be possible with an announcement from any other device (so as to not fail if someone steals your laptop and your phone can't contact the server directly), but not possible to be done by a thief (so devices should have a password-protected key for revocation). In the event of conflicting reports, all keys should be temporarily mistrusted until manual verification by a third party can be performed. –  Stuart P. Bentley Aug 2 '14 at 1:11
In fact, it may be advisable to have another mechanism for revoking keys, using a strong public password that is manually updated (replaced) on a regular basis- this way, you can revoke the key without depending on any device (say you're out with only your phone and somebody steals it), so long as you keep the password a secret. –  Stuart P. Bentley Aug 2 '14 at 1:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.