Average computer users would be forgiven for not having any idea what PGP is. There is so much going on below the surface of the modern computing experience that even critically important security tools like PGP are tucked away.
To be sure, there are specialized circles that make regular explicit use of PGP. Diligent Linux users would have at least a passing familiarity with PGP, since the fact that manufacturers didn't install our OS for us means we have to verify its integrity ourselves.
Otherwise, if your work doesn't touch on information security, PGP would understandably be a mystery to you. But like I said, it is no less important for this reality. In fact, PGP played a significant part in why we have secure communications on the Internet. This actually isn't because it's widely used, although it definitely is utilized in software installation utilities the world over. Rather, its significance stems from its defiant challenge to an overzealous government that sought to compromise encryption long before most Americans used the Internet regularly.
My aim in treating PGP here is twofold. The first is to shed some light on it for the uninitiated. The second, and more importantly, is to teach the daring among you how to wield this powerful tool. Hopefully, you found your way here after reading my security guide. If not, check out the last installment, and you will see that PGP can be useful in certain high-stakes threat scenarios.
Before we proceed, keep in mind that, as with any tool, the usefulness of PGP adheres to the network effect. Its practicability is extremely limited due to scant adoption software development circles. If you seek to apply PGP toward interpersonal communication, those you communicate with must do the same.
Every Hero Has an Origin Story
The Crypto Wars were a dark time...and still are, depending on your perspective. Like with most government attempts to fundamentally change technological implementations, the first crypto war came as moral panic swept over Washington. Elected officials were terrified that the Internet would be a lawless realm where fiends preyed on the innocent. To remedy this, they desperately sought a way to ensure that law enforcement could peer into the activity of abusive netizens. Encryption made this impossible.
This inclination is understandable, because the Internet was so new and foreboding to their constituents. Nor should it be forgotten that people were indeed getting hurt from interactions which wholly or partly took place online.
Their answer was to attempt to weaken encryption so that law enforcement could be assured of compliance when it served a warrant. Encryption, by definition, is only effective if the contents of a message are indecipherable to all but the intended sender and receiver. The proposal, well-meaning as it was, completely flouted this principle.
That's when Phil Zimmerman offered the world PGP. He wrote PGP, which stands for "Pretty Good Privacy," before the Crypto Wars, back in 1991. But when hostilities broke out, unbreakable encryption advocates rallied under its banner. In Zimmerman's eyes, if the government was bent on compromising all the ciphers it held sway over, he would make his own and refuse to play ball.
The government quickly fired back, opening a criminal investigation into him in 1993 for violating a regulation that helped advance their encryption-weakening campaign: export restrictions. Under these restrictions, the U.S. government made it illegal to export encryption software to other countries that was as strong as U.S. encryption software without an arms-dealing license. Phil Zimmerman did not have one of those.
That's when Zimmerman got creative: he published his program as a book, which anyone, anywhere in the world, was free to purchase. If these book buyers chose, they could transcribe its contents into a code editor and save it as a file. In fact, that is exactly what some people did. When the government told Zimmerman to cut the funny business, he pointed to his First Amendment rights, and court rulings establishing that computer code is speech.
Between PGP and other pressures, the government eventually left everyone's crypto alone. Fortunately, the government has mostly refrained attempting to legislate dilutions of encryption, at least until recently.
Far from an early-Internet relic, PGP (theoretically) remains viable today. Despite advances in supercomputing and cryptanalysis, the fundamental cipher that PGP uses by default remains sound. Whenever a supercomputer is built which can break a key, users need only make longer keys.
So How Does PGP Work?
As with most encryption, the technical details are tough to wrap your head around, but the basics are pretty straightforward. PGP is an encryption program which uses either the RSA or DSA ciphers. Either way, PGP generates what are called "asymmetric" keys -- that is, a pair of keys.
The "main" key is the private key. The private key (or, as some implementations call it, the "secret key"), as the name implies, stays private. After generating a keypair, a user should guard their private key like their deepest, darkest secret.
The other key in the pair is the public key. Unlike the private key, by design, this one gets around. The user hands this key to anyone who wants to send them things securely. There's no real security risk in letting others have it.
Each key in a keypair can reverse the cryptographic operation performed using the other key. When a key is applied to plaintext (the normal, readable file contents), it becomes ciphertext (effectively gibberish). Applying the complement of the key that created the ciphertext will restore the plaintext. So in practice, if a user communicates with PGP, they will have one private key and many public keys: their own private key, their own public key, and one public key each for every person they communicate with.
Because it isn't associated with any one messaging client, you can do a lot of cool things with PGP. To start with, you can encrypt any "raw" plaintext. Since your computer represents everything as bits, and all PGP does is scramble and unscramble them, PGP is capable of encrypting email or chat content, audio and video files, and even messages posted on the Web.
Normally, you encrypt plaintext with a public key so the private key-holder can decrypt it, but there's a trick you can do if you invert the process. If you "encrypt" using your private key so that people with its public key counterpart "decrypt" it, you can create what's known as a cryptographic signature. These signatures allow you to prove that whatever you signed was unequivocally authored by you.
This is actually how PGP is used to check software. The developers sign their software with their private key and then release their public key to anyone who wants to check the software's authenticity. If anyone tampers with the key or the signature (but not both), the subterfuge will be detected. The attack could work if the signature and public key were altered in just the right way, but this is logistically tricky enough that it's unlikely.
Donning the Mask for Yourself
At this point, you're probably ready to test drive this bad boy, so let's get to it.
For all the examples to follow, I will be using a tool called GPG (Gnu Privacy Guard), a free and open-source command line implementation of PGP. The rationale for this is that since security is the whole point of PGP, a simpler, open, and mature tool works best.
This guide also assumes you're using some kind of Unix-flavored computer, meaning, Linux, BSD, or macOS. GPG is supposed to work the same way on Windows, but having not tested it, I won't swear that that's true.
As a final caveat, all of these commands are based on my testing with GPG 2.2.19, as packaged Linux Mint 20. I will try to note where you may experience divergent behavior, but regardless, keep that in the back of your mind.
You will start by making a keypair, which involves a simple one-line command:
gpg --gen-key
In the GPG version I tested, this is the streamlined key generation option, as opposed to the customizable "--full-gen-key" option. Definitely explore the latter if you're the adventurous type, but I won't go into it here.
Before running the command, you will need to have a few details figured out for the screen prompts that arise when it executes.
First, ensure that you have an email address to associate with your key. Second, pick the name you want to enter. Only enter your real name if you're sure you want your public key to identify you. Third, choose a password for your key. The importance of this step is not lost on you, I'm sure.
The next thing we must do is generate a revocation certificate. This is done with the following command:
gpg --gen-revoke --armor key_name > privkey_rev.asc
The "--gen-revoke" is self-explanatory, but you might wonder what the "--armor" option does. This outputs the key with bits represented as ASCII characters instead of the raw format that looks like your terminal is chanting an elder being summoning incantation.
Revocation certificates let people know your private key has been compromised and not to trust it anymore. They only go into effect when you publish them, but it's a good idea to have them made up before you need them.
One this is done, immediately back up your keypair and revocation certificate to an encrypted external storage medium. There's nothing stopping you from having duplicate files of the same key or certificate for extra safety, but just make sure you can account for all copies of these files.
To perform this backup, you will have to export your keys as files. By default, they are just bytes in a key database parsable only by GPG.
Export your keys by running the following commands:
gpg --export --armor key_name > pubkey.asc
gpg --export-secret-keys --armor key_name > privkey.asc
Copy your private key, public key, and revocation certificate onto your encrypted storage.
Now all you need are public keys for the people you want to talk to and you're in business. There are essentially two ways of obtaining these
The first is to import public keys from a file transferred directly to your machine locally. In most cases, this means your friend handing you a flash drive so you can copy the public key right onto your computer. This approach has substantive benefits.
The biggest plus is the high level of security: because you aren't sending a key over the Internet, there's a considerably reduced chance that the key was sabotaged. Your friend is also on hand to confirm with you that the key is legit, since they can look at your screen and say "yup, that's the one."
The steps for doing so are fairly straightforward:
2. Get the file from the storage medium onto your computer. Your device, OS, and storage medium will dictate how this goes.
3. On your terminal, import the public key into your GPG keyring by running the following command.
gpg --import pub_key.asc
4. Then, run this command to display the key's fingerprint, a string of text uniquely identifying a key but which does not compromise its security.
gpg --fingerprint pub_key_name
5. Have the person you ID'd verify that their public key's fingerprint as shown on your system is the same as the one that their public key actually produces.
The other nice thing about the local key exchange method is that you don't have to mess with keyservers. Keyservers are not that hard to use, in the grand scheme of GPG, but interfacing with them is still a little clunky.
That is, however, the other major transfer method: downloading public keys from a keyserver on the Internet. Keyservers which, as the name suggests, maintain keys, have been around for computer eons. Maintained by organizations like MIT, these servers sync with one another to allow users to distribute their public keys widely.
Keyservers have the distinct benefit of enabling you to obtain public keys from people you can't meet in person. After all, the Internet is useful precisely because it allows instantaneous remote communication. However, because the public key owner can't assure you of the key's integrity in person, there's a chance the key was compromised in transit.
This is usually addressed by public key owners posting their key's fingerprint elsewhere on the public Web. Depending on your adversary's capabilities, though, you can't be certain the Web-posted fingerprint hasn't been altered to match the phony fingerprint you get from a compromised keyserver-based key. You probably shouldn't stay up at night worrying about this, but it is a risk.
You can import a key from the keyserver using the following steps:
gpg --search-keys keyword
2. You will now be presented with the search results in pages of 10. Page through the results and select the desired key the corresponding number and hitting Enter. Your device will now download the key.
3. Run the following command to output the key's fingerprint.
gpg --fingerprint pub_key_name
4. Finally, find a published fingerprint for the public key's owner and check it against the fingerprint the previous command outputted.
Next, run GPG's encrypt command, which looks like this:
gpg -e file
The operation will ask which public key to use when encrypting the file, which you specify using the number-and-letter sequence on the second line of the key's entry -- to see this entry you should run 'gpg --list-keys'. When the encrypt command completes, it creates an encrypted file with a filename identical to the input file plus ".gpg" appended. Send it to the public key's creator and they'll know what to do.
Decrypting files sent to you is just as easy. Find the file encrypted for you and run the following command: gpg -d file > outfile
Enter your private key's password, and you've got a decrypted file.
By default, the decryption flag just outputs the decrypted file contents to the console. Since you'll probably want the decrypted plaintext saved for later, the '> outfile' part of the command is included to output the operation to a file.
Two Private Keys Are Better Than One
What could be more secure than one private key? How about two?
Some clarification is needed. I don't mean creating two full-fledged private keys. Rather, this approach uses two parts of your private key: one can only decrypt messages encrypted with the public key, the other can sign files.
So what does this get you? Splitting your key allows you to keep your master key exclusively on encrypted external storage until you need it.
Because the subkey can decrypt messages sent to you, you can maintain your ordinary correspondence by keeping only the subkey on your device. If your computer ever gets infected (which you may never detect), your attackers won't be able to forge your signatures, making it easier for you to revoke the stolen key and start fresh.
Without a doubt, separate private keys with separate security controls induces a much bigger headache. To start with, you have to be able to tell them apart, because if you allow your master key to be on your computer while it is connected to the network, from an operational security standpoint, your master key will be poisoned, exposed to an unverifiable degree of danger which qualifies its integrity.
But even assuming you keep them in the right place, you have to have an operationally secure procedure for PGP signing--at a minimum, that disabling your networking on an OS level (preferably the hardware level), plugging in your encrypted storage, importing a copy of the master key, executing the signing operation, deleting the copy of the master key on your device and its data in your GPG keyring, ejecting your encrypted storage, and reenabling your networking.
My version of GPG actually splits the key into these two parts by default, but bundles them together, both in your keyring and in private key exports.
However, if you want to split the keys, perform these steps instead:
2. Perform the same private key export as before.
3. Export your private subkey to its own respective file using this command.
gpg --export-secret-subkeys --armor key_name > sub_key.asc
4. Move your private key and subkey files to secure external storage.
5. Run this command, following the prompts to delete the main secret key from your keyring, but not the subkey.
gpg --delete-secret-keys
6. Ensure that all file copies of your main private key are deleted from your device.
Here Comes the Kryptonite
There are some serious limitations to keep in mind with PGP. After all, if it were perfect, everyone would be using it.
One issue is that keyservers have a glaring flaw that seems beyond mitigation, in which attackers can render a certificate too massive to be functionally processed properly. Unless your public key becomes a hot ticket item, you probably won't get hit with this. However, it contributes to the general disdain for PGP.
However, that's actually another issue: a cumbersome user interface that places a considerable manual verification burden on the user is nigh unto a death sentence for security software. If a tool is only secure for those who painstakingly follow an easily botched procedure, chances are high that someone, you or your recipient, will slip up.
All of that is to say that I wouldn't rely on PGP unless you have had a lot of practice, and superior alternatives don't exist. I would say, though, that PGP is valuable enough for appreciating encryption and the key maintenance that undergirds it. So if you set your expectations realistically, you can get a worthwhile experience out of PGP. 
Jonathan Terrasi has been an ECT News Network columnist since 2017. His main interests are computer security (particularly with the Linux desktop), encryption, and analysis of politics and current affairs. He is a full-time freelance writer and musician. His background includes providing technical commentaries and analyses in articles published by the Chicago Committee to Defend the Bill of Rights.
August 18, 2020 at 02:38AM
https://www.technewsworld.com/story/Digital-Security-Is-as-Easy-as-PGP-86805.html
Digital Security Is as Easy as PGP - TechNewsWorld
https://news.google.com/search?q=easy&hl=en-US&gl=US&ceid=US:en
No comments:
Post a Comment