We are still actively working on the spam issue.
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.
Contents
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
Linuxfags: Install the package gpg from your favourite package manager or compile from their Git, http://git.gnupg.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
Next, change your configuration in ~/.gnupg/gpg-agent-info[YOUR PC NAME HERE] 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-info[YOUR PC NAME HERE]. Your setup is now nice and hardened.
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
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
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").
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).
