GPG: the Best Free Crypto You Aren't Using, Part II of II
And now, at long last, JoJo's ready to start encrypting everything in sight. Suppose JoJo wants to send an encrypted e-mail to Dan. The most common way for him to do this is to compose his message with the text editor or word processor of his choice and save it to disk. JoJo writes a letter with vi and saves it as dan0729.txt. Then he encrypts it with the command:
gpg --output dan0729.txt.asc --encrypt --recipient firstname.lastname@example.org dan0729.txt
Finally, he sends the file dan0729.txt.asc as an e-mail attachment or even listed in the body of an e-mail message (JoJo's got an “armor” line in his options file).
Note that if JoJo encrypts without passing gpg the --armor flag and he doesn't have an armor line in his options file, he should call the encrypted file dan0729.txt.gpg instead since it will be saved in the gpg binary format. Also, it will only be transmittable as an attachment. Remember, Armored ASCII is much more versatile. The gpg binary format may be preferable if file size matters because it tends to produce less output than Armored ASCII.
When Dan receives this file, he should save it to disk and decrypt it with the command:
gpg --output dan0729.txt --decrypt dan0729.txt.asc
Unlike encrypting, you don't need to specify a key when decrypting. gpg automatically determines which key to try to decrypt it with. Similarly, it doesn't matter whether the file Dan tries to decrypt is in gpg binary or Armored ASCII format; gpg will determine which format the file is in automatically, after prompting Dan for a passphrase. If Dan doesn't type his passhprase correctly, gpg won't decrypt the file.
Signing and verifying is very similar to decrypting and encrypting things. Suppose JoJo writes a nonconfidential but important letter to Dan that he wants Dan to be able to verify the validity of but doesn't need to actually encrypt. To sign his file beercontract.txt, JoJo would enter the command:
gpg --output beercontract_signed.txt --clearsign beercontract.txt
This will add a signature header and footer to the file and save it as beercontract_signed.txt. It's important that the output file be named differently than the input file, or the original file will be replaced with a signature for an empty file. You should use the clear-text method of signing when you want to be able to copy-and-paste your signed message into or out of e-mail, or otherwise treat it as plaintext.
The alternative is, you guessed it, to create a binary signature. There are two types of these. To create a binary signature that contains the original document and the signature in one compressed binary file, use the --sign command instead of --clearsign. To create a much smaller binary file containing a signature but not the file it references, use the --detach-sig command. Both --sign and --detach-sig should be preceded by an --output directive.
When Dan receives JoJo's beer contract, he can verify the signature appended to it by saving the file to disk, say as bcs.asc, and entering the command:
gpg --verify bcs.asc
Remember, if Dan doesn't have JoJo's public key in his keyring, gpg will return an error. If Dan does have JoJo's public key and the signature checks out, gpg will return something like the following:
gpg: Signature made Fri 27 Jul 2001 04:46:46 PM CDT using DSA key ID C1C34866 gpg: Good signature from "John J. Figplucker (Smooth JoJo) <email@example.com>"Then and only then will Dan know for sure that the contract he just received was signed by the bearer of JoJo's private key. Could JoJo have had a spear pointed at his tuckis? We don't know. Could JoJo have left his passphrase scrawled on the bottom of his keyboard, to be used by his office mates for impersonation pranks? Again, we really don't know. But if we trust JoJo to use and protect his key properly, we can be fairly sure that he did indeed create this valid signature.
I hope you're not too overwhelmed by all these options, flags and commands (Welcome to UNIX!). This has really been more of a survey than anything else; there's much I haven't covered. But I do believe that gpg is an important and useful tool. So much so that a number of people are working on more user-friendly front ends for it. The official GnuPG GUI is called the GNU Privacy Assistant (GPA), and while it's still a work-in-progress, it looks very promising indeed. It uses the GIMP toolkit, and is, unsurprisingly, nice to look at indeed.
Other GUIs under various stages of development include Seahorse and GnomePGP for the GNOME desktop; Geheimnis for KDE; TkPGP (written in Tk and therefore relatively windowmanager-agnostic); and a variety of wrappers, plugins and enhancements to popular mail user agents (or MUAs, aka e-mail clients). See the “Frontends” section of the GnuPG home page for links to these and other tools.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Favorite (and easily brute-forced) pw's
1 hour 32 min ago
- Have you tried Boxen? It's a
7 hours 24 min ago
- seo services in india
11 hours 55 min ago
- For KDE install kio-mtp
11 hours 56 min ago
- Evernote is much more...
13 hours 56 min ago
- Reply to comment | Linux Journal
22 hours 42 min ago
- Dynamic DNS
23 hours 16 min ago
- Reply to comment | Linux Journal
1 day 14 min ago
- Reply to comment | Linux Journal
1 day 1 hour ago
- Not free anymore
1 day 5 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?