operational pgp - draft

gistfile1.md

Operational PGP

This is a guide on how to email securely.

There are many guides on how to install and use PGP to encrypt email. This is not one of them. This is a guide on secure communication using email with PGP encryption. If you are not familiar with PGP, please read another guide first. If you are comfortable using PGP to encrypt and decrypt emails, this guide will raise your security to the next level.

PGP is used to protect email content, but there is so much more to secure email than simply encrypting content. This guide will attempt to lay out operational guidelines for secure email practices. Following these rules will enable you to use PGP to maximum effect.

Protecting the content of an email conversation is just the start of secure email. It is also critical to secure the operational procedures surrounding email use. This includes things like how you write your emails, how you store them, how you store your keys and use them, and so on. Everything related to the process of sending and receiving email must be secured.

Operationally secure email is not much more difficult than normal email, it just requires a little more attention to detail, some changes to default settings, and consistent discipline.

MetaData

Metadata provides the context to the content of the email. Protecting the email content (with PGP) will significantly enhance the security of the communication. Frequently, the context (the metadata) is sufficient to learn a great deal about the communication even without the content. Unfortunately, even PGP encrypted email leaves comms metadata exposed, this includes:

• Subject
• To
• From
• Dates and times
• IP addresses
• email application

Minimising the contextual information leakage from the comms starts with knowing what metadata will be exposed. Where possible, and relevant, take control over that infomation and unlink it from data linked to you. For example, you can control the From field by creating a new email account. The IP address of the sending email client can be changed by using a VPN, Tor, or a public Internet connection. One option to consider is the use of Torbirdy which integrates Tor directly into Thunderbird (as well as sanitizes emails slightly). The usual caveats about Tor apply: do not rely exclusively on Tor, if you need to protect your IP address then use an IP address that is not attributable to you.

the Subject must never be relevant

There is little else you can do about the To, From, and IP, as those are controlled by the infrastructure. However, you have complete control over the Subject. All acceptable subjects are listed below:

• ...
• xxx
• ;;;
• :::

The Subject must never ever refer to the content of the email, even obliquely. For example, "Subject: Your cocaine has shipped!" is a total email security failure.

• Subjects should be empty!
  • Disable the Warn about empty subject setting on your email client

Safer Keys

Key loss is catastrophic

The primary problem with PGP is that there is no Forward Secrecy. Losing a key means that all content encrypted with thatkey is compromised. There are two ways of dealing with this:

1. create a single master holy grail key and guard it with your life
2. create keys frequently and destroy them as soon as they are no longer needed

If you are going to go with option #1 then you should probably use an OpenGPG smart card. There are a number of vendors that sell them.

Mitigate by having more keys for shorter times

A more secure mitigation against key loss is to generate new keys frequently, use them for specific opertaions, andthen destroy them. For example, when traveling, create a new Travel PGP Key and use that until you are back home. That way if anyone compromises your travel laptop they only breach the compartment for the duration of your travel. The impact of the compromise is contained by the limitation on the utility of the PGP key.

So -- more keys, more often.

Publishing? Not a great idea

If you are serious about the anonymity of your PGP protected communications, you need to avoid publishing your key to the keyservers. Exchange your key only with the person(s) that you will communicate with. This will mitigate against future attribution attempts.

Deniable key exchange

You can deniably exchange keys by having an easily locatable and identifiable public key. Tell all correspondents to use your public key to contact you and include their public key in the encrypted body of the message. This mitigates against both Mallory and Eve attacking the key exchange step. Just ensure that your public is verifiable through multiple channels, for example: twitter, facebook, blog, public mailing lists, key servers, etc. The more channels that host your PGP key fingerprint, the harder it is for Eve to attack them all.

Compromised Key Alerts

• Have a public signal that will alert people that your key has been compromised.

For example if you post a specific message to twitter (e.g. "Someone has a case of the Mondays!") then your correspondants will be alerted that your key is no longer valid. They must rekey internally and disregard all future comms using the old key.

Writing

There are fundamentally two options when composing an email: you can either write the email in a text editor, or in an email client. For security, that is, control over the process, a text editor is safer. For convenience most people will use their email client.

• Safest
  • Write in a text editor
  • Encrypt on the command line
  • Only expose already-encrypted data to the email client
• Realistic
  • At least restrict the plaintext to the local system you control

Drafts

• Don't save Drafts in plaintext

Drafts can be a significant source of risk. The storage and handling of drafts must be approached with care. In particular, make sure that they are encrypted (never stored in plaintext), that they are stored locally (where you can be sure of deleting them) and that they are deleted after use. Make sure to configure your email client to store drafts locally and to encrypt them before writing them to disk.

• Don't store on server

• Ensure they are encrypted

• Ensure they are deleted after use

Composition

• Delete the content in a reply, only quote the relevant parts if necessary

Mitigate against the potential threat of any single email being compromised by limiting the information within any single email. The more information is stored in the mental context of the corresponents, the less useful the information in the email is to an adversary. Wherever possible minimise the amount of irrelevant contextual information within the email body. Keep it short, simple, and clean.

Attachments

• PGP has all the capability of tar or zip.

It is possible to include all the files you need to include as a pure PGP messages without having an attachment called secret-leaked-nsa-docs.tar.gz.gpg.asc. The program to use is gpg-zip and it takes both --tar= command line options and gpg command line options. Use this to bundle your files and send them as an opaque encrypted blob.

Encrypting

• use --throw-keys to prevent leaking more metadata

PGP encryption stores metadata about the decryption keys in the encrypted data. This is a simple optimisation to allow the recipient to rapidly determine whether the email can be decrypted by a private key they possess. This information also allows an attacker to determine who can read the email. If the email is intended to be truly anonymous, this metadata must be discarded. Fortunately, there is a gpg command line flag for this: --throw-keys.

Ensure that --throw-keys is added to the command line when encrypting data.

• PGP/MIME and inline PGP -ear aren't the same.

For more control and compatibility, use inline PGP.

Sending

Ensure you encrypt by default

Accidentally sending an unencrypted email is a potentially fatal error. Configure your email client to always encrypt by default. If you want to send a plaintext email, then deliberately set that option.

Think about signing

Signing an email provides guarantees that the content was written by someone that possess the private key. That it is, it positively identifies at least one person involved in the email exchange. Think carefully about whether you want to be positively identified as the author of the email. Set your email client to not sign messages by default.

Sign messages explicitly.

Store sent messages locally, then delete them

After the email has been sent and is no longer operationally useful, delete it. To make sure that you can do this, configure your email client to store your Sent messages locally. When in doubt, store locally. At least you will have some control over whether it is thoroughly deleted.

Receiving

• Delete emails after they are no longer necessary
• INBOX ZERO
• OUTBOX ZERO
• DRAFTS ZERO
• TRASH ZERO
• Regularly delete all emails. Easiest way is to set the Trash to erase everything after 30 days, and then delete every email after it has been processed.

Riseup.net PGP Configuration Guide

There is a PGP configuration guide from riseup.net. If you want to incorporate their best practice recommendations without any of their terrible advice about using key servers etc, then simply install this gpg.conf into your ~/.gnupg.

• gpg.conf

Outreach

• Remind your correspondents to practice the same PGP hygiene

First thoughts:

It's not clear who this article is for. It doesn't help people know it is for them. Why should I use PGP? When should I use it? For what use cases do these particular standards apply? It appears to be pitched at relatively sophisticated users (e.g. it doesn't walk you through installation or key concepts). It might be worth noting that.

It's not clear that we need more PGP guides as opposed to better PGP guides. There's a ton out there. This guide might reach more people as an adjunct to an existing guide.

You talk about key loss. But what you describe is more like private key discovery. I usually think of losing the key as when I accidentally format the usb stick that had my key on it, not as when I accidentally email the private key to all my coworkers.

You emphasize the need to keep keys secure but public keys are obviously not going to be kept secret. This could be confusing for novice users.

You talk editing workflow and not saving drafts in two places: Composition and Drafts. The recommendations there don't harmonize and could use some explanation to the effect that "If you can't follow the safest composition process, then these practices around drafts apply."

Yeah, this guide is meant to augment other PGP guides. I don't think anyone needs another "how to make a PGP key" copypasta, but very few people know how to actually use PGP in a secure manner. This is not for a novice user, this is for someone who knows what PGP is, why they need it, and wants to make sure that they don't make mistakes.

Also it is to get more people using PGP like me so I have more cover traffic! ;)

Your suggestions are helpful. I will reedit the Composition vs. Drafts thing. You got the right idea, "ideally you use vim + gpg on the command line... failing that, at least make sure you do the following: ". I think I need to adjust the structure to capture that dichotomy.

I think of key compromise as "lost key material", but that is probably confusing to anyone who doesnt speak fluent IC. Their mindset is all about control. As soon as something goes outside of your control, it is lost, and therefore you assume that it is compromised and a problem to be addressed. I guess the more native English meaning makes more sense for a guide.

thanks.

In the "Safer Keys" section, you should make reference to the excellent subkeys guide on the Debian Wiki. It provides a middle-ground between "use one key for everything that is known and trusted" and "use new keys for everything to improve security". The private master key is kept offline and separate, while any number of subkeys can be generated for different purposes (or different people). Emails encrypted with different subkeys have an element of forward secrecy (or at least compartmentalization), but can still be verified as being from the same person.

Maybe mention --cipher-algo and --compress-algo? Most people still have CAST as preferred algorithm or none (and GPG defaults to CAST). I feel better choosing other algorithms (both in my key preferences, so other sheep do it right and when encrypting to any sheep by enforcing on my command line). Also, in todays Intertubz, you can probably not compress at all?

A couple of things I'd suggest:

Keep your PGP key on a single device (and if you dual-boot, keep it in a single OS).

Use full disk encryption, and be aware of cold boot and evil maid attacks. And don't get hacked :).

If supported by your email service, use POP3 instead of IMAP. You can set your email client to delete messages off of the server immediately after downloading. Now the bulk of your email is only in one place, on your own computer. This also solves that accidentally-saving-plaintext-stuff-to-the-server problem. Also, if you're using POP3 I don't think there's any benefit to composing your email in a text editor.

You mention problems with attachment filenames. This may be controversial, but using PGP/MIME instead of Inline PGP completely solves this problem (and it also makes it so you can use HTML email if you want). When you use attachments in a PGP/MIME email, the files and metadata just become MIME parts in a larger multipart blob that all gets encrypted together, so all attachment-related data because part of the content. However, it makes it a pain in the ass for recipients who decrypt emails on the command line instead of in an email client.

I know you're not going into details of email clients, but one of your suggestions is "Configure your email client to always encrypt by default." Apple Mail has obnoxious problems with this -- you can't tell it to "encrypt" until you put people in the to box and it verifies that you have public keys for those email addresses.

Also, you can edit ~/.gnupg/gpg.conf to make it change default options getting passed in to gpg. For example, you might want to add these to that file to remove unnecessary metadata about your gpg client and key:

no-emit-version
no-comments

You might also want to put throw-keys in there too, to not include keyids in the PGP metadata. But in my experience this because a huge usability hassle to people on the receiving end if they're not too savvy.

check fingerprints of new keys without and before importing them

Before importing a new key or doing anything else with it you should always check the fingerprint of keys: use the not-well-known command

gpg --with-fingerprint keyfile.asc

which shows the fingerprint without the need to actually import the key. If the fingerprint is as expected (via second channel), you then can import it

gpg --import keyfile.asc

In section Publishing? Not a great idea I suggest to add:

(I regard the keyserver idea developed more than 20 years ago as a design failure in most cases.)

* Never upload your or foreign keys to keyservers without the expressed permission
  of the key owners (and permission of the key signers. if the keys are signed).
* Also teach your *recipients* never to upload their or foreign keys to keyservers
  without the expressed permission of the key owner
  (and permission of the key signers, if the keys are signed).

prevents:

• meta data mining
• contact and relation data mining

citation from https://twitter.com/micahflee/status/506950892994580480

Email opsec tip: Use POP3 instead of IMAP. If your email is already locked to a single device for PGP, why keep all your emails on a server?

I like the suggestion to compose all emails in a text editor. You might want to briefly address the issue of unintentionally leaking persistent plain text message data to the local file system depending on the which editor and operating system is in use. For example, would this issue compel a Windows or Mac user to choose something other than the default text editors for their respective operating systems? Does vi or vim create any temp files that could later be used to recover the plain text data?

The OpenPGP smart card suggestion is a fine idea, however I believe there is only a single vendor at present, Kernel Concepts in Germany. http://g10code.com/p-card.html

@sysfu - I believe Yubikey manufacture OpenPGP smart cards as well. https://www.yubico.com/2012/12/yubikey-neo-openpgp/

Instead of having new keys all the time, using subkeys is quite an acceptable compromise to have more security but without the catastrophic scenarios of a single key.

I especially like some of the hardening that is being suggested in the Riseup openpgp practices documen: https://help.riseup.net/en/security/message-security/openpgp/best-practices

ideally you use vim + gpg on the command line

Don't forget that vim stores swap and backup files.

set noswapfile
set nobackup
set nowritebackup

These are not "sane" guidelines to use PGP, these are uber-paranoiac and unpractical guidelines. If you really need to delete all of your emails and mask your IP and on and on then yes, but I doubt most person using PGP daily need that as well.

I don't like that you call it PGP, PGP is just a software, use OpenPGP :)

@n0way0ut I think it's ok to just reference to "PGP" instead of "OpenPGP". As I understand OpenPGP is the reference for the actual implementations.

Brainstorm for advanced cases not necessarily specific to the tool itself (if a person is directly targeted):

1. Deleting: prefer spinning disks to SSD for plaintext. Get a secure delete utility. Also presumably firmware can be modified to retain state that is not visible to operating system. Consider restoring the device from a backup after encrypting sensitive text in case device is leaking some form of the plaintext to another OS accessible location on the computer.
2. Attribution: as others have stated, use plain ASCII text (no Microsoft Word etc). Consider how the information might identify the source: does it contain any unique changes relevant to where it came from? If you wrote it, consider the style and vocabulary of your writing. Consider sharing the encrypted text broadly (Pastebin/Classifieds/etc) if trying to protect identification of the recipient. Consider the use of cut-outs
3. Encryption: Have a dedicated never-network-connected device for encryption. Consider storing private key encrypted further by Veracrypt. Transfer encrypted text to other devices via pluggable media (or better pic of encrypted->text OCR since pluggable media is often itself compromised) to other network connected devices and remember at that point it might be something that can be attributed to you if the device is compromised. Ensure your private key is under physical control at all times. Maybe use the pic of glitter finger nail polish trick on the edge of the encryption device to identify tampering. Do you trust the private key generation? If not, use another technique to generate it and then import into GNUPG
4. Side channel attacks: Don't forget risk of EMF transmissions when encrypting sensitive text, key loggers, compromised power supplies that communicate, ultrasonic leaks, cameras or personal location devices in the vicinity of encryption/delivery of message, other types of implants.
5. Traffic analysis: consider the length of the encrypted text, the timing of when it is shared and with whom it is shared.

This is just my top of head brainstorming of practical encryption issues from what I've read or thought about over the years (for discussion).

The option you are probably talking about is named --throw-keyids not --throw-keys ?

But the good news is, you can throw away pgp entirely and start having PFS aka --burn for your mail via https://github.com/stealth/opmsg

Also have a look at cross-domain ECDH if you dont trust some entities that publish EC curve params.

Thank you, @grugq.
The very article for any user who decided to give PGP a second chance.
Your confident narrative definitely inspires and resolves some previous doubts.

Why destroy operational keys when you have "holy grail" key? You can keep encrypted copy of all old keys encrypted with the holy grail key. Or the paranoia is so big that we cannot be sure how safe are they even in encrypted form? The encrypted content is safe, but encrypted key is dangerous.

@SY6502: The difference is what happens if the "holy grail" key is compromised. If you've destroyed the operational keys, then past communications remain secure; they are not decryptable without the operation key they were encrypted to. If you've instead stored the operational keys encrypted, then the operational keys can be decrypted, and thus so can all past communication.

Thus, with short-lived operational keys, the damage from the main/root key being compromised is greatly limited: the damage is limited to future communications (and any past communications from the current operational key, if that is also compromised), and only until the compromise is discovered & the main key replaced.