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

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.