PGP

Pretty Good Privacy (PGP) is a data encryption and decryption computer program that provides cryptographic privacy and authentication for data communication. PGP is often used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. It was created by Phil Zimmermann in 1991.

PGP, GPG, and similar software follow the OpenPGP standard (4880) for encrypting and decrypting data.

Operation

PGP relies on asymmetric encryption, and also can work with symmetric encryption. There are two main modes of operation: signing and encrypting. They may be (should be) combined. If used properly, PGP is one of the strongest and most versatile forms of encryption on the market, however it is extremely complex.

Signing

A user uses their private key to create a cryptographic signature, which can be verified by anyone who has their public key. This cryptographically proves that the message came from the holder of the key.

Encryption

A user can encrypt a file in one of two ways, either with another user's public key, or with a symmetric key. By signing with the public key of a user, it can only be decrypted by their private key, which only they should have. Signing with a symmetric key (a password) is stronger and less CPU-intensive, but has the issue of sending the password to another person.

Where do I get it?

Where do I get it?

GPG stands for Gnu Privacy Guard, an OpenPGP implementation from our favorite freetards at the FSF.

Macfags: http://gpgtools.org

Linuxfags: Install the package gpg from your favourite package manager or compile from their Git, http://git.gnupg.org/

Winfags http://gpg4win.org

Proper and safe usage

Use GPG.

Start by reading the documentation, there are many good tutorials out there. The man page is great for greping if you need more info on a specific option.

The following section will show you how to use GNUPG in the UNIX command line.

Getting started

Pre-usage hardening

When using on Linux, this is the recommended GNUPG configuration, in ~/.gnupg/gpg.conf

# Default Key (If you are using multiple keys, you might
# want to change this
#default-key 0ABC123

# Suppress the initial copyright message
no-greeting

# Disable inclusion of the version string in ASCII armored output
#no-emit-version

# Disable comment string in clear text signatures and ASCII armored messages
#no-comments

# Refuse to run if GnuPG cannot get secure memory
require-secmem

# Long keyids are more collision-resistant than short keyids
keyid-format 0xlong

# List all keys along with their fingerprints
with-fingerprint

# Do not merge primary user ID and primary key in --with-colon
# listing mode and print all timestamps as seconds since
# 1970-01-01
fixed-list-mode

# Show usage information for keys and subkeys in the standard key listing
list-options show-usage

# Show policy URLs in the --list-sigs or --check-sigs listings
list-options show-policy-urls

# Show all signature notations in the -list-sigs or --check-sigs listings
list-options show-notations

# Show any preferred keyserver URL in the --list-sigs or --check-sigs listings
list-options show-keyserver-urls

# Display the calculated validity of user IDs during key listings
list-options show-uid-validity

# Show revoked and expired user IDs in key listings
list-options show-unusable-uids

# Show revoked and expired subkeys in key listings
list-options show-unusable-subkeys

# Show signature expiration dates (if any) during --list-sigs or --check-sigs
# listings
list-options show-sig-expire

# Display any photo IDs present on the key that issued the signature
verify-options show-photos

# Show policy URLs in the signature being verified
verify-options show-policy-urls

# Show all signature notations in the signature being verified
verify-options show-notations

# Show any preferred keyserver URL in the signature being verified
verify-options show-keyserver-urls

# Display the calculated validity of the user IDs on the key that issued the
# signature
verify-options show-uid-validity

# Show revoked and expired user IDs during signature verification
verify-options show-unusable-uids

# Enable PKA lookups to verify sender addresses
verify-options pka-lookups

# Locate a key using DNS CERT, as specified in RFC4398
auto-key-locate cert

# Locate a key using DNS PKA
auto-key-locate pka

# Locate  a  key  using whatever keyserver is defined using the --keyserver
# option
auto-key-locate keyserver

# Use name as your keyserver
keyserver http://keys.gnupg.net
keyserver http://subset.pool.sks-keyservers.net

# Automatically fetch keys as needed from the keyserver when verifying
# signatures or when importing keys that have been revoked by a revocation
# key that is not present on the keyring
keyserver-options auto-key-retrieve

# When searching, include keys marked as "revoked" on the keyserver
keyserver-options include-revoked

# If the key in question has a preferred keyserver URL, then use that preferred
# keyserver to refresh the key from
keyserver-options honor-keyserver-url

# If auto-key-retrieve is set, and the signature being verified has a PKA
# record, then use the PKA information to fetch the key
keyserver-options honor-pka-record

# Tell the keyserver helper program how long (in seconds) to try and perform
# a keyserver action before giving up
keyserver-options timeout=10

# To make use of the agent, you have to run an agent as daemon and use the
# option
use-agent

# This allows the user to safely override the algorithm chosen by the recipient
# key preferences, as GPG will only select an algorithm that is usable by all
# recipients
personal-cipher-preferences   AES256 CAMELLIA256 AES192 CAMELLIA192
personal-digest-preferences   SHA512 SHA384 SHA256 SHA224
personal-compress-preferences ZLIB BZIP2 Uncompressed

# This preference list is used for new keys and becomes the default for
# "setpref" in the edit menu
default-preference-list AES256 CAMELLIA256 AES192 CAMELLIA192 SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 Uncompressed

# Message digest algorithm used when signing a key
cert-digest-algo SHA512

# Command line that should be run to view a photo ID
photo-viewer feh --quiet --borderless --title 'GnupG KeyID 0x%K' -

This will harden it and add some customization. After you do this, change the permissions by doing sudo chattr +i ~/.gnupg/gpg.conf. This is to make sure it is not easily edited without your knowledge.

Next, change your configuration in ~/.gnupg/gpg-agent.conf to this:

# Set the minimal length of a passphrase
min-passphrase-len 10

# Set the minimal number of digits or special characters required in a passphrase
min-passphrase-nonalpha 3

# Ask the user to change the passphrase since the last change
#max-passphrase-days 90

# Enable the OpenSSH Agent protocol
enable-ssh-support

Again, do sudo chattr +i ~/.gnupg/gpg-agent.conf. Your setup is now nice and hardened, as well as personalized to a better format than the default.

Making a key

You need to make a key first. This is simple as

gpg --gen-key

and answering some questions. You'll be asked for a name and email. You don't have to use real info here, but choose something you like because you can't change it later.

A note: If you will be sharing messages on image boards (a great place, mind you), decide how long you want your key to be. A 4096 bit key might be super secure, but it also means you'll run into post limits on most boards. Choose carefully. ElGamal also has shorter signatures, and should be chosen over RSA. However, RSA is much more secure over the other options.

Usually you'll see keys and messages as a bunch of noise - they're base64 encoded (or "ASCII armored").

Exchanging keys

Now, you need to post your public key. If you do a

gpg --export --armor (part of the name you chose earlier)

The --armor is necessary to encode as text rather than binary. If you will be sharing as a file, binary is fine, but to post messages in emails and on imageboards, it must be text

You'll get a blob of text back that starts with "BEGIN PGP PUBLIC KEY BLOCK". Copy that and paste it to its destination, including the begin and end bits.

You need a public key for the person you want to send a message to. Do

gpg --import

and pasting their key in, ending with Control + D.

Keyservers

Warning: Using a keyserver, while common practice, can be an OPSEC fail. Keyservers never delete information. Keyservers can be poisoned. It is a good tip to both self-host your key, and also publish a key to a keyserver

The alternative is to locate someone's key on a public key server instead of manually exchanging keys. pgp.mit.edu is a good one.

gpg --keyserver pgp.mit.edu --send-keys <keyID>

Find your key ID by running

gpg -k

or

gpg --list-keys

Then look for the string under "pub" that is xxxx/<KeyID>

To search on a keyserver for someones key:

gpg --keyserver pgp.mit.edu --search-keys {Name | KeyID | Email}

Then it will give you a few options, and it will allow you to type the number of the key you want from the results, and it will import it for you.

Regular Usage

Tip: There are many front-ends for this that make the whole process easier. Some are integrated into email programs, such as Evolution. More advance front-ends are better for a more active UNIX user, such as Emacs, which includes everything the PGP utility does.

Encrypting/Decrypting shit

Encrypt a message to somone:

gpg --encrypt --armor --recipient {name | KeyID | email}

To decrypt a message, use:

gpg --decrypt

To sign a message, use

gpg --sign

to make a signature, or

gpg --clearsign

for a ASCII signature.

To test a signed message to see if it is valid:

gpg --verify

You can use short flags or long flags, like -e or --encrypt, and you can combine them like such:

gpg -sear {Name | KeyID | Email}

-sear is a go to flag combo, as it means it will sign, encrypt, armor, and define recipient for the following message.

You can make groups. Go into gpg.conf, (~/.gnupg/gpg.conf on Linux) you can define groups anywhere with an uncommented line like such:

group 8ch = Alice Jones KeyIDHere [email protected]

Using this, you can now encrypt to multiple recipients WITHOUT doing -r X -r Y -r Z for persons X, Y, and Z, instead you can run gpg -sear 8ch, assuming you have the line group 8ch = X Y Z

Regarding concerns, -r and -R (or --recipient and --Recipient) do two different things, -R and --Recipient removes metadata from the recipients, and this is a personal choice you can make when encrypting things. If you want people to know who the message is encrypted to, use -r, if not, -R.

GPG and files

GPG normally works by taking STDIN (standard input, aka what you type/paste into the terminal), operating on it, then dumping the results to STDOUT (standard output, aka what comes spitting up on your teminal)

This can be changed to have GPG input from and/or output to files. One way is shell redirection ( < file, > file )

GPG looks for a filename at the end of the options, if it finds one, this is used for input.

The -o <filename> option will send output to the named file rather than STDOUT.

Example:

gpg -sear [email protected] -o output_file.gpg input_file

Safe Usage

Do not ever lose your private key. Safest practice is to use a master key and use it to sign sub keys, then use the sub keys. Keep the master key on an air-gapped computer, and mainly use the subkeys for proper Compartmentalization. Have revocation certificates handy in case your keys are lost.

Make sure you have a password on your keys. This is not enough to stop a determined attacker, so when you are transporting them in an easily seized form, like a flash drive, you should pack your keys into a tarball with some padding (the ~/.gnupg directory works nicely) and encrypt it with AES 256 and a strong password.

ElGammal keys should be used in preference to RSA due to security concerns around RSA. Due to backwards compatibility, many defaults are weak, and should be changed.

Metadata is not encrypted using PGP, so if you email someone you should use a client that sends the least amount of metadata possible. Things usually beyond your control in sending is the client, your IP and the subject. Client is usually a non-issue, you can change your IP using a VPN or Tor proxy, and you should use a subject that is as vague as possible (i.e. "That Thing you Wanted", or "Jamie: Email 1").

Tip: For additional security, you can make your subject simple dots, or commas. For example, one email thread could be "..." while another could be ",,,".

Issues

Web of Trust

PGP public keys work on a Web of Trust model which means that in order for you to trust that the key you have actually belongs to your contact, you must establish an unbroken chain of trust between them and yourself.

For example, if you want to talk to Bob but haven't exchanged keys with him in person, you need a chain of people between you and Bob who have all signed each others keys. Bob knows Jane, Jane knows Fred, Fred knows Arthur, Arthur knows Sally, Sally knows Claire, and you know Claire.

Without this chain of trust, you can't be sure that you have Bob's true key.

Metadata

Email encrypted with PGP does nothing to stop metadata being collected about who you contacted, when and how often. A journalist using PGP to talk to a source is not hiding their source. All emails encrypted with PGP have their headers unencrypted. This means that your IP is unencrypted, the sender address is unencrypted, the receiving address is unencrypted, and most importantly the subject is unencrypted. You should choose your subject well when sending PGP email; the vaguer the subject the better.

Interesting facts

In the 1990's, the US government had incredibly stupid regulations involving computer encryption. Anything above 40 bits was considered to be in the same boat as low-yeld nuclear devices or grenade launchers (under the laws of munitions). Due to this, the FBI continually threatened the creator, Phil Zimmerman, for criminal indictment.

Zimmermann challenged these regulations in an imaginative way. He published the entire source code of PGP in a hardback book, via MIT Press, which was distributed and sold widely. Anybody wishing to build their own copy of PGP could cut off the covers, separate the pages, and scan them using an OCR program (or conceivably enter it as a type-in program if OCR software was not available), creating a set of source code text files. One could then build the application using the freely available GCC. PGP would thus be available anywhere in the world. The claimed principle was simple: export of munitions—guns, bombs, planes, and software—was (and remains) restricted; but the export of books is protected by the First Amendment. The question was never tested in court with respect to PGP. In cases addressing other encryption software, however, two federal appeals courts have established the rule that cryptographic software source code is speech protected by the First Amendment (as decided by the Ninth Circuit Court of Appeals in the Bernstein v. United States case and the Sixth Circuit Court of Appeals in the Junger v. Daley case).

Zimmerman later abandoned PGP, feeling he won the war and its use was over. He now doesn't use any PGP implementation, and gets mad if people attempt to ask him for his own key.

External links

• Phil Zimmerman: Why I wrote PGP