<emphasis>Peter van der Linden's Guide to Linux</emphasis>: A Lesson in Encryption, Part 1
Editor's Note: The following is an excerpt from
chapter 11, "Keeping Your Data Private", of
Peter van der Linden's Guide to Linux,
published August 2005 by Prentice Hall, ISBN 0-13-187284-2.
One of the qualities that distinguishes Linux from lesser operating
systems is its superior support for your privacy and security. That
means more than avoiding buggy virus-propagating applications, such
as Microsoft's Outlook and Internet Explorer. Savvy people and
organizations quite rightly want to protect their data files and
e-mail from snooping eyes. One way to do so is by keeping important
files in coded form, a practice known as encryption.
Don't think encryption is only for secret agents or computer gurus
with ponytails down to the waist and witty t-shirts from thinkgeek.com.
Putting an ordinary file on a PC is like leaving a letter face up
on a desk. It's in plain view for anyone who passes by. Encryption
is practical for ordinary people who want to keep their data private
when they put it on a PC. It effectively puts that letter into a
strong sealed envelope. You can do it, and it's an important ability
Keeping your data and email truly private is an increasingly significant
skill in these times. Privacy through encryption apparently is
important enough that governments as diverse as those of France,
Britain and Iran want to deny it to their citizens. In the US,
the First Amendment to the Constitution prohibits the government
from denying freedom of speech to its citizens. Or at least, the
Constitution makes it more probable that such denial eventually will
be overturned in the courts. Freedom of speech has been interpreted
by the courts to include freedom of dance, of song, of cinema, and it includes
the freedom to write down whatever random numbers you like.
This tutorial on Linux encryption is offered in three parts. Part 1,
here, describes how public key encryption works and where to get the
GnuPG encryption software. Part 2 walks through some examples
of file encryption/decryption, and Part 3 explains how to send and read
Introducing GNU Privacy Guard
The terms GnuPG and GPG refer to the same thing, the GNU Privacy
Guard program. The executable file name is gpg, and the name GnuPG
is used in some of the documentation. The name is a spoof on a
similar program called Pretty Good Privacy or PGP. PGP used to be
an open-source program but later versions went commercial, so the
GNU community reimplemented a free version and named it accordingly.
What the Software Does
GNU Privacy Guard is software that scrambles and unscrambles
files or e-mail on command. The purpose of scrambling (encrypting)
a file is to keep its contents private from those who do not have the
key to unencrypt it.
If unauthorized persons somehow get hold of an encrypted file,
they will not be able to make sense of the contents. The content
of an encrypted file is changed fundamentally, not merely mixed
up. It is extremely difficult to retrieve the original contents
from the scrambled version unless you have the secret key. If the
information is important enough, governments or rich organizations
may be able to do it by exhaustive searching, using many powerful
computers. The average consumer or company does not have the resources
to break GnuPG encryption.
For reasons relating to mathematical definitions, we refer to encryption
algorithms, encrypting and decrypting, whereas non-mathematicians would
say codes, encoding, and decoding. To the ordinary user, these three
pairs of terms correspond to each other. The meanings of "code" in
source code and the code used to encrypt a file were originally
similar in philosophy, but there's no useful overlap, so separate them in
Basics of Public Key Encryption
For hundreds of years, conventional codes have relied on using a single
key. The key is a secret number or phrase that is used in the
transformation of plain text into the coded message. The recipient of the
message uses the same key to reverse the procedure and recover the
plain text. Figure 1 depicts the classic approach to cryptography:
a single key that is used for both coding and decoding.
Figure 1. Traditional Cryptography: One Key Both Encrypts
People have added very clever refinements, such as changing the letter
substitution with every letter in the message; the German Enigma code
machine did this. But the basic approach has a single secret key used
by both coder and decoder. Managing shared secret keys is very expensive
and a source of considerable insecurity. It requires you to send a
secret message (the key) before you can send a secret message.
GNU Privacy Guard uses a different encryption technique called
public key encryption (PKE), invented comparatively recently. Each
user of Public Key Encryption has two keys. The two keys are
long numbers--thousands of digits long--that are related mathematically
and form a pair that work together. No two people ever should have
the same numbers. Your two numbers have a mathematical relationship
between them, but knowing one number doesn't provide any practical
way to learn the second number.
One key is used to encrypt messages for a specific user, and
(amazingly) this key is published to the world. Hence it is called
a public key. When anyone wants to send Biff a secret message, say, he
or she uses Biff's public key to encrypt it, and no one else can make
sense of that encrypted message.
The other key of the matched pair is employed by the user to decrypt the
messages that were encrypted by someone using his public key. This
decrypting key has to be kept secret. Hence, it is called a private key.
Anyone who wants to send you an encrypted message looks up your public
key on your Web page, or from a floppy disk you sent them or from a
PKE server. The encryption program crunches the secret message with
your public key to produce an encrypted message. This encrypted message
is a string of random-looking text. It is not possible for just
anyone to decrypt it, even when they know your public key.
The only practical way to decrypt a message encrypted with your public
key is with your private key. The two numbers were generated as a
matched pair to ensure that they would have this "one encodes, the other
decodes" quality. The GnuPG program does some intensive processing to
convert the encrypted message plus your private key back into the
original text. You must keep your private key well guarded, as anyone
who has your private key is able to decrypt any secret files
intended only for you.
You might think it would be clearer if your public and private key
were called a locking key and an unlocking key, respectively. If
it helps, by all means think about them that way. There's a
reason why those terms aren't used, which I'll explain in the last
article in this series.
To summarize, a public key converts plain text into random-looking
encoded text. The public key doesn't have to be kept secret, and
usually isn't. Only the corresponding private key can unlock the
meaning--neither your public key nor anybody else's public or private
key can recover the original text. Your private key has to be
kept secret. Figure 2 portrays public key cryptography.
Figure 2. A public key is used to encrypt a file.
The corresponding private key is used to decrypt the
You use public key encryption whenever you send your
credit card details to an on-line store in a browser. The browser
encrypts your details using the server's public key before sending them
across the Internet. This is part of the secure HTTP protocol,
known as HTTPS. The corresponding private key never leaves the
server, so no eavesdroppers can decrypt your credit card data.
The mathematical qualities that PKE relies on have a beautiful
symmetry to them, and PKE rocked the worlds of computer science and
encryption when it appeared in the 1970s. Government scientists in
Britain's GCHQ eavesdropping and phone-tapping center later claimed
that they had invented the technique some years earlier, but kept
it secret! Indeed, they did uncover some of the theory, but it was
clear that the spies of GCHQ had not grasped its practical
Before PKE, secret communications relied on the sender and receiver
having the same key and keeping it secret. This was a real weakness. The
big advance of PKE is that you no longer have to send someone a secret
message (key) before you can send them a secret message. With PKE, the
recipient openly publishes something that allows anyone to send him a
On a Debian-based release, this command installs GnuPG:
apt-get install gnupg
Check that you have installed GnuPG correctly by running the program with
the --help option. In a shell, type this command:
You should see about 120 lines of not terrifically helpful help
information flash by, ending in a line that reads:
Please report bugs to <email@example.com>.
If the program doesn't start or doesn't produce that help information,
there is a problem with your GnuPG installation that needs to be fixed
before you can move forward.
Creating Your Own GPG Key
You need a key pair of your own to be able to encrypt and decrypt. There
are a number of commercial organizations that will sell you a key pair
and provide varying assurances that your key really belongs to you and
not to some imposter. They call the key pair plus the assurance a
certificate, and it exists in the form of a computer file.
Most people encoding and decoding for personal use don't need that level
of trustability by the outside world. They create their own key using
the GnuPG utility. There is a way to boost confidence in personally
created keys by getting your friends to vouch for them electronically.
GnuPG Still Is Evolving
The GnuPG program is in active development, and the team makes
several new releases a year. This article was developed with GnuPG version
1.4.1. You might find that you are working with a later version of GnuPG,
and that the output does not precisely match the prompts or output shown
here. That's fine. Make the small adjustments to map between the text
and the GnuPG program. The fundamentals don't change.
Linux encryption software is not as polished as it should be. That's
a common limitation of software produced by volunteers. However,
most of the hurdles lie in the one-time setup part, not in daily use.
We'll walk through the one-time setup here.
Use GnuPG to Generate Your Pair of Keys
In this section, you'll create a pair of keys, one to publish and
one to keep highly secret. Here is the one-time setup to get your
pair of keys for use with GnuPG.
Create the pair by running the GnuPG program, with the command line
option to generate keys:
GnuPG runs interactively and asks a few questions. It's fine to accept
the default suggestions made by GnuPG. Notice that part of the output,
"We need to generate a lot of random bytes", appears twice. This is
because that portion of the code is executed twice, once for each key.
The entire sequence looks like this:
$ gpg --gen-key gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (5) RSA (sign only) Your selection? 1 DSA keypair will have 1024 bits. ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Requested keysize is 2048 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 0 Key expires at Thu 07 Apr 2005 05:11:17 PM PDT Is this correct? (y/N) Y You need a user ID to identify your key; the software constructs the user ID from the Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) " Real name: Peter van der Linden (working on Linux) Email address: firstname.lastname@example.org Comment: working on Linux You selected this USER-ID: "Peter van der Linden (working on Linux) " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. Enter passphrase: My secret phrase entered here Repeat passphrase: My secret phrase entered here We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. .++++++++++..+++++++++++++++++++++++++++++++++++++++++++++++++++++++..+++++.+++ ++++++++++++.+++++++++++++++..+++++..++++++++++.+++++++++++++++>.+++++.+++++>++ +++..............<+++++>.+++++...<+++++...................>+++++..<.+++++>+++++ ....................................................................+++++ We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. +++++++++++++++...+++++.+++++.+++++..+++++.++++++++++++++++++++++++++++++.+++++ ..+++++.++++++++++..+++++.+++++.++++++++++.+++++.++++++++++++++++++++++++++++++ +++++>.++++++++++>.+++++>+++++.................<.+++++>...+++++.<+++++......... ..>.+++++...............................................................<+++++. ...........................>.+++++......................................+++++^^^ gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 6C7C81B2 marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 1024D/6C7C81B2 2005-04-03 [expires: never] Key fingerprint = C2A9 6818 3158 C13B 457A 1409 11ED 2943 6C7C 81B2 uid Peter van der Linden (working on Linux) / sub 2048g/68F3472B 2005-04-03 [expires: never]/
As you might surmise, GnuPG was created by programmers who are
more skilled at cryptography than at human interface design. The program
takes only a few seconds to run, and you get three things back from it.
The first two things are a pair of large numbers, the public and private
keys. They are created for you and stored in binary form in files in the
directory ~/.gnupg . These files are given permissions that prevent other
users from reading or writing them. Burn a copy of that directory to CD
now, and lock the CD safely away. This allows you to restore your key
regardless of future disk or system failures. The third thing you get is
a "fingerprint", also called a key ID, which is a 40-byte-long checksum
of your newly created public key. You can use the fingerprint or even the
last eight digits of it--6C7C 81B2 here--when talking to GnuPG as a
shortcut for your public key, and it will retrieve and use the associated
key for you.
The e-mail address and the passphrase you gave are associated with the
keys and the fingerprint, and these also are used to identify and
authenticate you. They call it a passphrase rather than a password to emphasize that it
needs to be lengthy and secure. It's pointless to use GnuPG with a weak
passphrase, something like "dog". If you can't remember a passphrase, pick any
short sentence from any book and outline it with yellow highlighter so
you always can find it again.
You must give the passphrase when you need to access the secret key to
decrypt something. If you forget your passphrase, practically speaking,
the files you encrypted never can be decrypted.
That completes the one-time setup. In Part 2, I describe how to use the
GnuPG program to encrypt and decrypt files.
Peter van der Linden currently works in Silicon Valley as a software
consultant who specializes in Linux and open-source software. A graduate
of Yale, van der Linden also is author of The Official Handbook of
Practical Jokes, Expert C Programming
and Just Java.
|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|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Build a Skype Server for Your Home Phone System
- Validate an E-Mail Address with PHP, the Right Way
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
- Tech Tip: Really Simple HTTP Server with Python
3 hours 34 min ago
- Reply to comment | Linux Journal
3 hours 42 min ago
- Understanding the Linux Kernel
5 hours 56 min ago
8 hours 26 min ago
- Kernel Problem
18 hours 29 min ago
- BASH script to log IPs on public web server
22 hours 56 min ago
1 day 2 hours ago
- Reply to comment | Linux Journal
1 day 3 hours ago
- All the articles you talked
1 day 5 hours ago
- All the articles you talked
1 day 5 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
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?