Open tilsammans opened 6 years ago
GPG Sync encrypts the information that it communicates between computers. To configure the app for the first time, generate what we call an Authority Key. You can go naieve but simple, or do it properly, which is more work.
Generate a new keypair:
$ gpg2 --full-generate-key
The result:
pub rsa4096 2018-08-25 [SC]
7E964EB8685149584756E968A5DEA5900CC36E50
uid GPG Sync Example Authority <info@example.com>
sub rsa4096 2018-08-25 [E]
Generating a totally new keypair for each purpose is fine, but they have no strong relation to each other, where in fact they were all generated by a single person; you. And since each keypair has full capabilities, you need to use the nuclear option when you lose any single one.
It would be better to have one key—let's call it Master—that we'll use to generate many subkeys, which are our worker keys that can be used for a single thing, and when they get lost you don't have to press the panic button right away.
The ultimate end game here is moving your Master Key to a secure hardware device like a yubikey, which means it will be gone from the relative hostile environment that bred it. This will not be discussed here, as there are plenty of good documents online that describe exactly how that works.
$ gpg2 --full-generate-key
Make a note of the fingerprint and the key ID.
Follow this procedure to generate as many keys as you need. One key typically has a single use: being an Authority Key, one for GitHub, one for BitBucket, and you can even use one to open SSH connections.
$ gpg2 --edit-key KEYID
gpg> addkey
gpg> save
Make a note of the fingerprint and the key ID.
You should add all other identities (email most importantly) directly under your
control to your Master Key. Use adduid
to make it happen. Also, consider
setting your profile photo using addphoto
. It will get distributed along
with the public key details, making your key easier to spot.
This will become your nuclear option in case Master Key is compromised.
$ gpg2 --gen-revoke NAME
You don't use this when one of your subkeys needs to be decommissioned. Edit
your key instead and use revkey
.
Time to copy everything we created so far and move it to a secure location. Don't keep these backups on your computer and don't upload them to S3 either! Make sure access to it is as restricted as possible.
Using --armor
is optional; it creates rugged ASCII output that handles
transmission throughh various mediums better than the default, binary, output.
$ gpg2 --armor --export --export-options backup
$ gpg2 --armor --export-secret-keys --export-options backup
My clone of your Wiki is here: https://github.com/tilsammans/gpgsync-wiki
Thanks for working on this. I'm hesitant to include such specific instructions though without thinking them through thoroughly first. There are so many different permutations for managing a PGP key, and like threat modeling, I think the right choice really depends on the organization.
Some might choose to include the authority key on a Yubikey, and even only ever using it on an airgapped computer. But for other organizations, it might be fine (and definitely more usable) to store it in the techie's GPG keyring with a passphrase. All of these choices have security and usability trade-offs.
I think a more useful document would list what the options are for generating the authority key and what the trade-offs are, so people can make an educated choice on how they want to protect their authority key. One way of doing this, maybe, would be to offer 3 different options, each with a list of pros and cons, and step-by-step instructions for generating key in those ways.
I think things to consider would include:
Hey gang
I tried setting up GPG Sync but noticed I needed a little more hand-holding with the Authority Key generation. I decided to add a page to the Wiki but I cannot add id. I will post the entire Markdown text in the next comment. I have cloned your Wiki as well.
I hope you'll be able to use my contribution. If something needs changed, I'm your man.