![\"\"](\"https:\/\/www.practicallynetworked.com\/wp-content\/uploads\/2021\/09\/hall_100.jpg\")
<\/p>\nLearn how to protect your e-mail and files you want to keep private using Pretty Good Privacy (PGP) encryption.<\/b><\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Early last month I promised to get back to the topic of enhancing your digital security and privacy with\u00a0PGP<\/a>\u00a0or its Free Software derivative,\u00a0GnuPG<\/a>. Both use a kind of cryptography referred to as “public-key” or “asymmetric.” With PGP or GnuPG, you gain the capability to encrypt or sign data in such a way that decrypting it is impractically difficult for any eavesdroppers, and altering data you’ve cryptographically signed without being detected is virtually impossible.<\/p>\n We’re all used to dealing with some sort of encryption in our everyday net dealings.\u00a0SSL<\/a>, for instance, is used to secure Internet traffic between your computer’s e-mail or Web client and a remote server. From our perspective as end users, this kind of encryption is a very passive process. We make sure to stick an “s” at the end of “http” when we type in a URL, or we point our e-mail client at port 993 or 995 of an\u00a0IMAP<\/a>\u00a0or\u00a0POP<\/a>\u00a0server when we’re setting it up, and then we forget all about it. If the browser shows a little padlock icon somewhere, we decide our information is safe from eavesdroppers on the network.<\/p>\n Though it also uses public-key cryptography, SSL as we experience it in a Web browser is based on a model of authentication that relies heavily on third-parties, referred to as “certification authorities<\/a>\u00a0(CAs),” that effectively vouch for the authenticity of a Web site’s cryptographic credentials. SSL browsing is transparent to us largely because browser programmers make a few assumptions on our behalf, including how much trust we should place in the CA that signed a Web site’s certificate.<\/p>\n PGP and GnuPG provide a much less passive experience, and it requires a little explanation and some setup before we can get into using it. We’re going to use the Mac OS X implementation of GnuPG to help with our explanation, and we’re going to do this in two parts. In this installment, we’ll cover the basics of setting up the cryptographic keys we’ll use to secure our data, and later we’ll deal with using GnuPG to encrypt and sign e-mail.<\/p>\n Before we jump into making keys and using them, it will help to offer a broad outline of how all the pieces relate to each other in GnuPG’s public-key scheme. GnuPG and PGP both use the OpenPGP protocol, so if you become familiar with the GnuPG and later decide you need some of the more advanced features provided by a commercial PGP offering, the concepts you pick up here will still apply.<\/p>\n The math involved in OpenPGP is more than we want to deal with, but the mechanics of daily use are easy to understand, if a little more involved than most of us are used to. In short, here are the basics:<\/p>\n These two keys are called a “keypair.” The keypair is used to perform three basic operations:<\/p>\n MacGPG<\/a>, which provides a GUI for GnuPG, is available as a no-cost download. Its and its underlying software, GNU Privacy Guard, are Free Software provided under the\u00a0GNU General Public License<\/a>\u00a0(GPL), just like Linux and Samba.<\/p>\n We’ll save an in-depth tutorial on using Mac GPG for e-mail for later, because covering both how GnuPG works and setting it up for mail would slow us down quite a bit, but you will need MacGPG to get through this week’s column.<\/p>\n At the\u00a0MacGPG site<\/a>, you’ll see a list of files. You should download the following:<\/p>\n You can optionally download these packages, but we won’t be doing anything with them this week:<\/p>\n If you want to use GPG to secure e-mail you send using Apple’s Mail.app, you’ll also want to download\u00a0GPGMail<\/a>, but we won’t use it until next time, and installing it now will just cause Mail.app to complain that GPG isn’t set up yet, so save installation for later.<\/p>\n You can install MacGPG by running the installer found in the “GnuPG Mac OS X” disk image you downloaded. MacGPG itself provides program files that run from the terminal.<\/p>\n You can install the GPG Keychain Access program, which is what you’ll be using to generate and manage cryptographic keys, by opening the “GPG Keychain Access” zip archive you downloaded and dragging the app file of the same name into your Applications folder.<\/p>\n As I mentioned earlier, the root of GPG is the notion of a “key pair.” To encrypt or sign data with GPG, you have to have a public key you share with others and a private key, which has a password only you know. If you want to ensure maximum security and privacy, you should choose that password with the same seriousness you’d choose a password for the administrative or root account on a production server: Avoid words you could find in the dictionary, avoid clever misspellings (like “m1ke” instead of “mike,”) and use a mix of letters, numbers and symbols.<\/p>\n Before we can do anything with GPG, we have to have a key pair, and that’s where GPG Keychain Access fits in.<\/p>\n Go ahead and launch GPG Keychain Access by doubleclicking on its icon once you have it moved into your Applications folder. It will immediately present a warning that you don’t have “a private or secret key.” It will offer the option to either “Import<\/b>,” “Quit<\/b>,” or “Generate<\/b>.” Click “Generate<\/b>.”<\/p>\n Unless you set it to do otherwise, GPG Keychain Access provides an assistant to generate your keys. When you click “Generate<\/b>,” that assistant will launch. Click “Continue<\/b>.”<\/p>\n Next, it will ask what kind of key you want to generate. The default is “DSA and ElGamal,” which allows you to use your key to both encrypt and sign your data. Keep it set to the default and click “Continue<\/b>.”<\/p>\n Next, it asks how large the key should be (in bytes). The default is 1024, which is fine. Click “Continue.”<\/p>\n Next, you’ll be asked for an Expiration Date. This setting is optional … though the key won’t stop working for purposes of decrypting or verifying data, you won’t be able to encrypt or sign with it once it has expired. In sensitive security settings, it’s not uncommon for there to be short lifespans for assorted keys and passcodes. In some military units, for instance, radio network signs and countersigns are retired in a matter of days. In less sensitive applications, it may not be as much of an issue.\u00a0The GNU Privacy Handbook says this<\/a>:<\/p>\n “There are two reasons why you may choose an expiration date. First, you may intend for the key to have a limited lifetime. For example, it is being used for an event such as a political campaign and will no longer be useful after the campaign is over. Another reason is that if you lose control of the key and do not have a revocation certificate with which to revoke the key, having an expiration date on the master key ensures that the key will eventually fall into disuse.”<\/p><\/blockquote>\n Once you’ve decided on an expiration date (or decided to assign none at all,) click “Continue<\/b>.”<\/p>\n Next, you’ll be presented with the personally identifying information to be embedded in your key. GPG Keychain Access pre-populates this form with information from your Mac address book:<\/p>\n The comment can be used in a number of ways. Some people include a URL where more contact information may be found, or the username or i.d. they wish to associate with their key.<\/p>\nGnuPG Cryptography in a Nutshell<\/h3>\n
\n
\n
Installing MacGPG<\/h3>\n
\n
\n
Generating a Key with GPG Keychain Access<\/h3>\n
![\"\"](\"https:\/\/www.practicallynetworked.com\/wp-content\/uploads\/2021\/09\/gpg_keychain_access.jpg\")
<\/p>\n\n