En
1991...
Manuel
original de PGP 1.0 (5 juin 1991)
Il y a 7 ans, le 5 juin 1991,
Philip Zimmermann publiait Pretty Good Privacy. C'était un coup
de tonnerre dans le domaine de la vie privée : pour la première
fois, la cryptographie à clef publique, inventée en 1976
au "Massachusetts Institute of Technology", était mise à
la portée de tous avec un logiciel gratuit et grand public.
Le texte qui suit est le
manuel original de PGP 1.0
A sa lecture, on peut voir
que dès cet instant Phil savait ce qui était en jeu. On peut
aussi remarquer qu'aujourd'hui encore de larges parties du passage "Why
I wrote PGP" figurent texto dans le manuel de la version freeware 5.0.
A l'heure où Network
Associates Inc. n'a toujours pas gagné la confiance des utilisateurs,
un retour aux sources de 1991 était nécessaire...
L'épopée de
PGP est due à deux facteurs, semble-t-il :
1. La nature visionnaire
de Phil, sa compétence technique et son courage personnel
2. Comme l'a raconté
Adam Back : l'erreur de la NSA et du FBI, qui en 1991 pensèrent
que ce logiciel pour MS-DOS avait été écrit par quelqu'un
de chez PKP Inc. (devenu RSA Inc.) sans finalité opérationnelle,
juste à titre d'amusement, abusés qu'ils furent par ce passage
du manuel d'utilisation : "The author of this software implementation of
the RSA algorithm is providing this implementation for educational use
only."
On sait ce qu'il en est advenu
depuis, tant des relations entre le FBI et Phil, que de celles entre RSA
Inc. et PGP Inc.
On sait surtout que plus
rien ne sera jamais comme avant car, comme l'a écrit le New York
Times, avec PGP "le génie est sorti de la bouteille et il n'y
rentrera plus"...
ATTENTION : les
informations techniques sur l'utilisation de PGP développées
dans ce manuel sont périmées ! L'intérêt de
ce texte est uniquement HISTORIQUE.
Le dernier manuel pour la
version DOS est celui de PGP 2.62 / 2.63i.
Pretty Good Privacy est
aujourd'hui rendu à la version 2.63i pour DOS PC compatibles, 5.0i
pour DOS PC 386, et 5.5i pour Windows 95 et Mac.
Toutes les versions à
jour sont disponibles ici : 
WARNING : this
manual is completly out-of-date ! For the actual version go to :
PGPI
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 1
Phil's Pretty Good Software
presents
===
PGP
===
Pretty Good Privacy
RSA Public Key Cryptography
for the Masses
Version 1.0 - 5 Jun 91
PGP User's Guide
(c) Copyright 1990 Philip
Zimmermann
Software and Documentation
Written by Philip Zimmermann
For information on PGP licensing, distribution, copyrights, patents,
trademarks, liability limitations, and export controls, see the "Legal
Issues" section later in this document.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 2
Contents
========
Quick Overview
How it Works
Installing PGP
How to Use PGP
To See a Usage Summary
Encrypting a Message
Signing a Message
Signing and then Encrypting
Using Just Conventional Encryption
Decrypting and Checking Signatures
Managing Keys
RSA Key Generation
Adding a Key to Your Key Ring
Removing a Key from Your Key Ring
Viewing the Contents of Your Key Ring
Signed Public Key Certificates
Advanced Topics
Separating Signatures from Messages
Sending Ciphertext Through E-mail Channels: Uuencode Format
Leaving No Traces of Plaintext on the Disk
Environmental Variable for Path Name
A Peek Under the Hood
Random Numbers
PGP's Conventional Encryption Algorithm
Data Compression
Vulnerabilities
Compromised Pass Phrase and Secret Key
Public Key Tampering
"Not Quite Deleted" Files
Viruses and Trojan Horses
Physical Security Breach
Tempest Attacks
Traffic Analysis
Cryptanalysis
Trusting Snake Oil
Why Do You Need PGP?
PGP Quick Reference
Legal Issues
Trademarks, Copyrights, and Warranties
Patent Rights on the Algorithms
Licensing and Distribution
Export Controls
Acknowledgements
Recommended Readings
About the Author
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 3
Quick Overview
==============
Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a
high security cryptographic software application for MSDOS. PGP
allows people to exchange files or messages with privacy,
authentication, and convenience. Privacy means only those intended
to receive a message can read it. Authentication means messages that
appear to be from a particular person can only have originated from
that person. Convenience means that privacy and authentication are
provided without the hassles of managing keys associated with
conventional cryptographic software. No secure channels are needed
to exchange keys between users, which makes PGP much easier to use.
This is because PGP is based on an powerful new technology called
"public key" cryptography.
PGP combines the convenience of the Rivest-Shamir-Adleman (RSA)
public key cryptosystem with the speed of fast conventional
cryptographic algorithms, fast message digest algorithms, data
compression, and sophisticated key management. And PGP performs the
RSA functions faster than most other software implementations. PGP
is
RSA public key cryptography for the masses.
PGP does not provide any built-in modem communications capability.
You must use a separate product such as TELIX or PROCOMM for that.
This document only explains how to use PGP without explaining the
underlying technology details and data structures and cryptographic
algorithms. It would help if you were already familiar with the
concept of cryptography in general and RSA public key cryptography in
particular. Nonetheless, here are a few introductory remarks about
public key cryptography.
How it Works
------------
In conventional cryptosystems, such as the Federal Data Encryption
Standard (DES), a single key is used for both encryption and
decryption. This means that keys must be initially transmitted
via secure channels so that both parties can know them before
encrypted messages can be sent over insecure channels. This may be
inconvenient. If you have a secure channel for exchanging keys, then
why do you need cryptography in the first place?
In public key cryptosystems, everyone has two related complimentary
keys, a publicly revealed key and a secret key. Each key unlocks
the
code that the other key makes. Knowing the public key does not help
you deduce the corresponding secret key. The public key can be
published and widely disseminated across a communications network.
This protocol provides privacy without the need for the same kind of
secure channels that a conventional cryptosystem requires.
Anyone can use a recipient's public key to encrypt a message to that
person, and that recipient uses her own corresponding secret key to
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 4
decrypt that message. No one but the recipient can decrypt it,
because no one else has access to that secret key. Not even the
person who encrypted the message can decrypt it.
Message authentication is also provided. The sender's own secret
key
can be used to encrypt a message, thereby "signing" it. This creates
a digital signature of a message, which the recipient (or anyone
else) can check by using the sender's public key to decrypt it. This
proves that the sender was the true origin of the message, and that
the message has not been subsequently altered by anyone else, because
the sender alone possesses the secret key that made that signature.
Forgery of a signed message is infeasible, and the sender cannot
later disavow his signature.
These two processes can be combined to provide both privacy and
authentication by first signing a message with your own secret key,
then encrypting the signed message with the recipient's public key.
The recipient reverses these steps by first decrypting the message
with her own secret key, then checking the enclosed signature with
your public key. These steps are done automatically by the
recipient's software.
Because the RSA public key encryption algorithm is so slow,
encryption is better accomplished by using a high-quality fast
conventional encryption algorithm to encipher the message. This
original unenciphered message is called "plaintext". In a process
invisible to the user, a temporary random key, created just for this
one "session", is used to conventionally encipher the plaintext
file. Then the recipient's RSA public key is used to encipher this
temporary random conventional key. This RSA-enciphered conventional
"session" key is sent along with the enciphered text (called
"ciphertext") to the recipient. The recipient uses her own RSA
secret key to recover this temporary session key, and then uses that
key to run the fast conventional algorithm to decipher the large
ciphertext message.
RSA keys are kept in "key certificates" that include the key owner's
user ID (which is that person's name), a timestamp of when the key
pair was generated, and the actual key material. A key file, or "key
ring" contains one or more of these key certificates. Public key
certificates contain the public key material, while secret key
certificates contain the secret key material. Public key rings
contain only public keys, and secret key rings contain just secret
keys. Secret keys are cryptographically protected by their own
password.
The keys are also internally referenced by a "key ID", which is an
"abbreviation" of the public key (the least significant 64 bits of
the large public RSA key). When this key ID is displayed, only the
lower 24 bits are shown for further brevity. While many keys may
share the same user ID, for all practical purposes no two keys share
the same key ID.
PGP uses message digests to form signatures. A message digest is
a
128-bit cryptographically strong one-way hash function of the
message. It is somewhat analogous to a "checksum" or CRC error
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 5
checking code, in that it compactly "represents" the message and is
used to detect changes in the message. Unlike a CRC, however, it
is
computationally infeasible for an attacker to devise a substitute
message that would produce an identical message digest. The message
digest gets encrypted by the RSA secret key to form a signature.
The
message digest algorithm used here is the MD4 Message Digest
Algorithm, placed in the public domain by RSA Data Security, Inc.
Documents are signed by prefixing them with signature certificates,
which contain the key ID of the key that was used to sign it, an
RSA-signed message digest of the document, and a timestamp of when the
signature was made. The key ID is used by the receiver to look up
the sender's public key to check the signature. The receiver's
software automatically looks up the sender's public key and user ID in
the receiver's public key ring.
Encrypted files are prefixed by the key ID of the public key used to
encrypt them. The receiver uses this key ID message prefix to look
up the secret key needed to decrypt the message. The receiver's
software automatically looks up the necessary secret decryption key
in the receiver's secret key ring.
These two types of key rings are the principal method of storing and
managing public and secret keys. Rather than keep individual keys
in
separate key files, they are collected in key rings to facilitate the
automatic lookup of keys either by key ID or by user ID. Each user
keeps his own pair of key rings. An individual public key is
temporarily kept in a separate file long enough to send to your
friend who will then add it to her key ring. An individual key file
is no different from a key ring that contains only one key.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 6
Installing PGP
==============
To install PGP on your MSDOS system, you just have to copy it into a
suitable directory on your hard disk (like C:\PGP), and use the
shareware PKUNZIP utility to decompress it from the compressed
archive release file. For best results, you will also modify your
AUTOEXEC.BAT file, as described elsewhere in this manual, but you can
do that later, after you've played with PGP a bit and read more of
this manual.
For further details on installation, see the separate PGP
Installation Guide, in the MSDOS file SETUP.DOC included with this
release. It fully describes how to set up the PGP directory and how
to use PKUNZIP to install it, and also describes how to detect virus
infections of PGP releases.
How to Use PGP
==============
To See a Usage Summary
----------------------
To see a quick command usage summary for PGP, just type:
pgp
This will display a usage summary for the most essential commands
only. The commands described in the Advanced Topics section are not
displayed.
Encrypting a Message
--------------------
To encrypt a plaintext file with the recipent's public key, type:
pgp -e textfile her_userid
This command produces a ciphertext file called textfile.ctx. A
specific example is:
pgp -e letter.txt Alice_S
This will search your public key ring file "keyring.pub" for any
public key certificates that contain the string "Alice S" anywhere in
the user ID field. The search is not case-sensitive. Note that
underlines get changed to spaces. That's because you can't use real
spaces in the user ID on the command line. If it finds a matching
public key, it uses it to encrypt the plaintext file "letter.txt",
producing a ciphertext file called "letter.ctx".
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 7
PGP will attempt to compress the plaintext before encrypting it,
thereby greatly enhancing resistance to cryptanalysis. Thus the
ciphertext file will likely be smaller than the plaintext file.
Signing a Message
-----------------
To sign a plaintext file with your secret key, type:
pgp -s textfile your_userid
This command produces a signed file called textfile.ctx. A specific
example is:
pgp -s letter.txt Bob
This will search your secret key ring file "keyring.sec" for any
secret key certificates that contain the string "Bob" anywhere in the
user ID field. The search is not case-sensitive. Note that
underlines get changed to spaces. If it finds a matching secret key,
it uses it to sign the plaintext file "letter.txt", producing a
signature file called "letter.ctx".
Signing and then Encrypting
---------------------------
To sign a plaintext file with your secret key, and then encrypt it
with the recipent's public key:
pgp -es textfile her_userid your_userid
This example produces a nested ciphertext file called textfile.ctx.
Your secret key to create the signature is automatically looked up in
your secret key ring via your_userid. Her public encryption key is
automatically looked up in your public keyring via her_userid. If
you leave these user ID fields off the command line, you will be
prompted for them.
Note that PGP will attempt to compress the plaintext before
encrypting it.
Using Just Conventional Encryption
----------------------------------
Sometimes you just need to encrypt a file the old-fashioned way, with
conventional single-key cryptography. This approach is useful for
protecting archive files that will be stored but will not be sent to
anyone else. Since the same person that encrypted the file will also
decrypt the file, public key cryptography is not really necessary.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 8
To encrypt a plaintext file with just conventional cryptography,
type:
pgp -c textfile
This example encrypts the plaintext file called textfile, producing a
ciphertext file called textfile.ctx, without using public key
cryptography, key rings, user IDs, or any of that stuff. It prompts
you for a pass phrase to use as a conventional key to encipher the
file. Note that PGP will attempt to compress the plaintext before
encrypting it.
Decrypting and Checking Signatures
----------------------------------
To decrypt an encrypted file, or to check the signature integrity of a
signed file:
pgp ciphertextfile [plaintextfile]
Note that [brackets] denote an optional field, so don't actually type
real brackets.
The ciphertext file name is assumed to have a default extension of
".ctx". The optional plaintext file name specifies where to put
processed plaintext output. If no name is specified, the ciphertext
filename is used, with no extension. If a signature is nested inside
of an encrypted file, it is automatically decrypted and the signature
integrity is checked. The full user ID of the signer is displayed.
Note that the "unwrapping" of the ciphertext file is completely
automatic, regardless of whether the ciphertext file is just signed,
just encrypted, or both. PGP uses the key ID prefix in the
ciphertext file to automatically find the appropriate secret
decryption key on your secret key ring. If there is a nested
signature, PGP will then use the key ID prefix in the nested
signature to automatically find the appropriate public key on your
public key ring to check the signature. If all the right keys are
already present on your key rings, no user intervention is required,
except that you will be prompted for your password for your secret
key if necessary. If the ciphertext file was conventionally
encrypted without public key cryptography, PGP will recognize this
and will prompt you for the pass phrase to decrypt it.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 9
Managing Keys
=============
RSA Key Generation
------------------
To generate your own unique public/secret key pair of a specified
size, type:
pgp -k
The software will prompt you for a filename for the pair of keys,
which will be written to filename.pub and filename.sec. It will also
give you a menu of recommended key sizes (casual grade, commercial
grade, or military grade) and prompt you for what size key you want,
up to around a thousand bits.
It also asks for a user ID, which means your name. It's a good idea
to use your full name as your user ID, because then there is less
risk of other people using the wrong public key to encrypt messages
to you. Spaces and punctuation are allowed in the user ID.
Also, if
you put your last name first it would facilitate producing lists of
public keys sorted by user ID. e.g.: "Smith, Robert M."
It will also ask for a "pass phrase" to protect your RSA secret key
in case it falls into the wrong hands. Nobody can use your secret
key
file without this pass phrase. The pass phrase is like a password,
except that it can be a whole phrase or sentence with many words,
spaces, punctuation, or anything else you want in it. Don't lose
this pass phrase, there's no way to recover it if you do lose it.
This pass phrase will be needed later every time you use your RSA
secret key. The pass phrase is case-sensitive, and should not be
too
short or easy to guess. It is never displayed on the screen.
Don't
leave it written down anywhere where someone else can see it. If
you
don't want a pass phrase (ill-advised), just press return (or enter)
at the pass phrase prompt.
The RSA key pair is derived from large truly random numbers derived
from measuring the intervals between your keystrokes with a fast
timer.
Note that RSA key generation is a VERY lengthy process. It may take
a few seconds for a small key on a fast processor, or many minutes
for a large key, or even hours for a large key on an old IBM PC/XT.
The public keyfile can be sent to your friends for inclusion in their
public key rings. Naturally, you keep your secret key file to
yourself, and you should include it on your secret key ring. Each
secret key on a key ring is individually protected with its own pass
phrase.
Never give you secret key to anyone else. For the same reason, don't
make keys for your friends. Everyone should make their own key pair.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 10
Adding a Key to Your Key Ring
-----------------------------
To add a public or secret key file's contents to your public or
secret key ring (note that [brackets] denote an optional field):
pgp -a keyfile [keyring]
The keyfile extension defaults to ".pub", implying a public key.
The
optional keyring file name is assumed to be literally "keyring.pub"
or "keyring.sec", depending on whether the keyfile name had a ".pub"
or ".sec" extension. You may specify a different key ring file
name. The default key ring extension is ".pub".
If the key is already on your keyring, PGP will not add it again.
All of the keys in the keyfile will be added to the keyring. Note
that the keyfile should only contain one key, because PGP only checks
the first key in the keyfile for duplicates on the keyring.
Removing a Key from Your Key Ring
---------------------------------
To remove a key from your public key ring:
pgp -r userid [keyring]
This will search for the specified user ID in your keyring, and will
remove it if it finds a match. Remember that any fragment of the
user ID will suffice for a match. The optional keyring file name
is
assumed to be literally "keyring.pub". It can be omitted, or you
can
specify "keyring.sec" if you want to remove a secret key. You may
specify a different key ring file name. The default key ring
extension is ".pub".
Viewing the Contents of Your Key Ring
-------------------------------------
To view the contents of your public key ring:
pgp -v [userid] [keyring]
This will list any keys in the key ring that match the specified user
ID substring. If you omit the user ID, all of the keys in the key
ring will be listed. The optional keyring file name is assumed to
be
literally "keyring.pub". It can be omitted, or you can specify
"keyring.sec" if you want to list secret keys. If you want to
specify a different key ring file name, you can. The default key
ring extension is ".pub".
If you want to specify a particular key ring file name, but want to
see all the keys in it, try this alternative approach:
pgp keyfile.sec
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 11
Using this approach requires that the key ring name be fully
qualified with the extension of ".pub" or ".sec", because if you
don't specify a file extension, ".ctx" is assumed.
Signed Public Key Certificates
------------------------------
In a public key cryptosystem, you don't have to protect public keys
from exposure. In fact, it's better if they are widely disseminated.
But it is important to protect public keys from tampering, to make
sure that a public key really belongs to whom it appears to belong.
Let's first look at a potential disaster, then at how to safely avoid
it with PGP.
Suppose you wanted to send a private message to Alice. You download
Alice's public key certificate from an electronic bulletin board
system (BBS). You encrypt your letter to Alice with this public key
and send it to her through the BBS's E-mail facility.
Unfortunately, unbeknownst to you or Alice, another user named
Charles has infiltrated the BBS and generated a public key of his own
with Alice's user ID attached to it. He covertly substitutes his
bogus key in place of Alice's real public key. You unwittingly use
this bogus key belonging to Charles instead of Alice's public key.
All looks normal because this bogus key has Alice's user ID. Now
Charles can decipher the message intended for Alice because he has
the matching secret key. He may even re-encrypt the deciphered
message with Alice's real public key and send it on to her so that no
one suspects any wrongdoing. Furthermore, he can even make
apparantly good signatures from Alice with this secret key because
everyone will use the bogus public key to check Alice's signatures.
The only way to prevent this disaster is to prevent anyone from
tampering with public keys. If you got Alice's public key directly
from Alice, this is no problem. But that may be difficult if Alice
is a thousand miles away, or is currently unreachable. Perhaps you
could get Alice's public key from a mutual trusted friend David who
knows he has a good copy of Alice's public key. David could sign
Alice's public key, vouching for the integrity of Alice's public
key. David would create this signature in the usual way, with
his own secret key.
This would create a signed public key certificate, and would show
that Alice's key had not been tampered with. This requires you have
a
known good copy of David's public key to check his signature. Perhaps
David could provide Alice with a signed copy of your public key also.
David is thus serving as an "introducer" between you and Alice.
This signed public key certificate for Alice could be uploaded by
David or Alice to the BBS, and you could download it later. You
could then check the signature via David's public key and thus be
assured that this is really Alice's public key. No imposter can fool
you into accepting his own bogus key as Alice's because no one else
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 12
can forge signatures made by David.
A widely trusted person could even specialize in providing this
service of "introducing" users to each other by providing signatures
for their public key certificates. This trusted person could be
regarded as a "key server", or as a "Certifying Authority". Any
public key certificates bearing the key server's signature could be
trusted as truly belonging to whom they appear to belong to. All
users who wanted to participate would need a known good copy of just
the key server's public key, so that the key server's signatures
could be verified.
A trusted centralized key server or Certifying Authority is
especially appropriate for large impersonal centrally-controlled
corporate or government institutions. Some institutional
environments use hierarchies of Certifying Authorities. For more
decentralized grassroots "guerilla style" environments, allowing all
users to act as a trusted introducers for their friends would probably
work better than a centralized key server. PGP tends to emphasize
this decentralized non-institutional approach. It better reflects
the natural way humans interact on a personal social level, and
allows people to better choose who they can trust for key management.
You should add a new public key to your key ring only after you are
sure that it is a good public key that has not been tampered with and
actually belongs to the person it claims to. You can be sure of this
if you got this public key certificate directly from its owner, or if
it bears the signature of someone else that you trust, from whom you
already have a good public key. The user ID should have the full
name of the key's owner, not just her first name.
If you are asked to sign someone else's public key certificate, make
certain that it really belongs to that person named in the user ID of
that public key certificate. This is because your signature on her
public key certificate is a promise by you that this public key
really belongs to her. Other people who trust you will accept her
public key because it bears your signature. Bear in mind that your
signature on a public key certificate does not vouch for the
integrity of that person, but only vouches for the integrity (the
ownership) of that person's public key.
You may want to keep your own public key around with signatures from
a variety of "introducers" in the hopes that most people will trust
at least one of the introducers to vouch for your own public key's
integrity.
Make sure no one else can tamper with your own public key ring.
Checking a new signed public key certificate must ultimately depend
on the integrity of the public keys that are already on your own
public key ring. Keep a trusted backup copy of your public key ring
on write-protected media, and check it once in a while against the
working copy. Back up your secret key ring, too.
Protect your own secret key and your pass phrase carefully. Really,
really carefully. If your secret key is ever compromised, you'd
better get the word out quickly to all interested parties (good luck)
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 13
before someone else uses it to make signatures in your name. For
example, they could use it to sign bogus public key certificates,
which could create problems for many people, especially if your
signature is widely trusted.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 14
Advanced Topics
===============
Separating Signatures from Messages
-----------------------------------
Normally, signature certificates are prepended (attached) to the text
they sign. This makes it convenient in simple cases to check
signatures. It is desirable in some circumstances to have signature
certificates stored separately from the messages they sign. It is
possible to generate signature certificates that are detached from
the text they sign. To do this, combine the 'b' (break) option with
the 's' (sign) option. For example:
pgp -sb letter.txt your_userid
This example produces an isolated signature certificate in a file
called "letter.ctx". The contents of letter.txt are not appended
to
the signature certificate.
After creating the signature certificate file (letter.ctx in the
above example), send it along with the original text file to the
recipient. The recipient must have both files to check the signature
integrity. When the recipient attempts to process the signature
file, PGP will notice that there is no text in the same file with the
signature and will prompt the user for the filename of the text.
Only then will PGP be able to properly check the signature
integrity. If the recipient knows in advance that the signature is
detached from the text file, she can specify both filenames on the
command line:
pgp letter.ctx letter.txt
or: pgp letter letter.txt
PGP will not have to prompt for the text file name in this case.
A detached signature certificate is useful if you want to keep the
signature certificate in a separate certificate log. A detached
signature of an executable program is also useful for detecting a
subsequent virus infection. It is also useful if more than one party
must sign a document such as a legal contract, without nesting
signatures. Each person's signature is independent.
Sending Ciphertext Through E-mail Channels: Uuencode Format
-----------------------------------------------------------
For all you Unix fans out there: PGP supports uuencode format for
ciphertext messages. This special format represents binary data by
using only printable ASCII characters, so it is useful for
transmitting binary encrypted data through 7-bit channels or for
sending binary encrypted data as normal E-mail text.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 15
Uuencode format converts the plaintext by expanding groups of 3
binary 8-bit bytes into 4 printable ASCII characters, so the file
will grow by about 35%. But this expansion isn't so bad when you
consider that the file probably was compressed more than that by PGP
before it was encrypted.
To produce a ciphertext file in uuencode format, just add the "u"
option when encrypting or signing a message, like so:
pgp -esu message.txt her_userid your_userid
This example produces a ciphertext file called "message.ctx" that
contains data in Unix uuencode format. This file can be easily
uploaded into a text editor through 7-bit channels for transmission
as normal E-mail on Internet or any other E-mail network.
Decrypting the uuencode-formatted message is no different than a
normal decrypt. For example:
pgp message
PGP will automatically recognize that the file "message.ctx" is in
uuencode format and will uudecode it before processing as it normally
does. The output file will be in normal plaintext form, just as it
was in the original file "message.txt".
During decryption, after PGP uudecodes the ".ctx" file, it leaves it
in binary ciphertext form. In other words, the ".ctx" file is no
longer in uuencode format when PGP is done processing it. PGP
produces a decrypted plaintext file, and also produces as a by-product
a uudecoded ciphertext file in binary form.
If you want to send a public key or key ring to someone else in
uuencode format, sign it with the "-su" options to create a ".ctx"
file with the signed key in uuencode format.
Leaving No Traces of Plaintext on the Disk
------------------------------------------
After PGP makes a ciphertext file for you, you can have PGP
automatically overwrite the plaintext file and delete it, leaving no
trace of plaintext on the disk so that no one can recover it later
using a disk block scanning utility. This is useful if the plaintext
file contains sensitive information that you don't want to keep
around.
To wipe out the plaintext file after producing the ciphertext file,
just add the "w" (wipe) option when encrypting or signing a message,
like so:
pgp -esw message.txt her_userid your_userid
This example will create the ciphertext file "message.ctx", and the
plaintext file "message.txt" will be destroyed beyond recovery.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 16
Obviously, you should be careful with this option. Also note that
this will not wipe out any fragments of plaintext that your word
processor might have created on the disk while you were editing the
message before running PGP. Most word processors create backup
files, scratch files, or both.
Environmental Variable for Path Name
------------------------------------
The standard key ring files "keyring.pub" and "keyring.sec" can be kept
in any directory, by setting the environmental variable "PGPPATH" to
the desired pathname. For example, the MSDOS shell command:
SET PGPPATH=C:\PGP
will make PGP assume the key ring filenames "C:\PGP\keyring.pub" and
"C:\PGP\keyring.sec". Assuming, of course, this directory exists.
Use your favorite text editor to modify your MSDOS AUTOEXEC.BAT file
to automatically set up this variable whenever you start up your
system. If PGPPATH remains undefined, these special files are
assumed to be in the current directory.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 17
A Peek Under the Hood
=====================
Let's take a look at a few internal features of PGP.
Random Numbers
--------------
PGP uses a cryptographically strong pseudorandom number generator for
creating temporary conventional session keys. The seed file for this
is called "randseed.pgp". It too can be kept in whatever directory
is indicated by the PGPPATH environmental variable. If this random
seed file does not exist, it will be automatically created and seeded
with truly random numbers derived from timing your keystroke
latencies.
This generator reseeds the disk file each time it is used with new
key material partially derived with the time of day and other truly
random sources. It uses the conventional encryption algorithm as
an
engine for the random number generator. The seed file contains both
random seed material and random key material to key the conventional
encryption engine for the random generator.
If you are a security fanatic and distrust any algorithmically
derived random number source however strong, you can defeat this
feature by creating an empty file named "randseed.pgp". This file
must be empty or nearly empty to turn off this pseudorandom
generator. In that case, every encryption session key will require
a
bothersome request to the user to type some text in at the keyboard
to measure the keystroke intervals with a high speed timer. It would
be more convenient and not that unsafe to use the strong pseudorandom
generator.
PGP's Conventional Encryption Algorithm
---------------------------------------
PGP does not use the DES as its conventional single-key algorithm to
encrypt messages. Instead it uses a custom conventional single-key
block encryption algorithm. It "bootstraps" into this faster
algorithm by using RSA to encipher the conventional session key.
For the cryptographically curious, PGP's conventional block cipher
has a 256-byte block size for the plaintext and the ciphertext. It
also uses a key size of up to 256 bytes. Permutation and substitution
are used on all the bits throughout the block in each round, rapidly
building intersymbol dependance between the ciphertext and both the
plaintext and the key. It can be configured to run from 1 to 8
rounds. It compares well with software implementations of the DES
in
speed. Like the DES, it can be used in cipher feedback (CFB) and
cipher block chaining (CBC) modes. PGP uses it in CFB mode.
PGP's conventional encryption algorithm is based in large part on
cryptographer Charles Merritt's algorithms. Merritt's algorithm does
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 18
have something of a track record; derivatives of it have been used
for secure U.S. military communications. Merritt's original designs
were refined by Zhahai Stewart and myself to improve security and to
improve performance in a portable C implementation. The algorithm
has not yet (in 1991) been through a formal security review and has
had only limited peer review. It has been carefully scrutinized for
weaknesses. A full discussion of the architecture is beyond the
scope of this preliminary draft of this document. Interested parties
can get design details from me or from the published source code.
Data Compression
----------------
PGP normally compresses the plaintext before encrypting it. It's
too
late to compress it after it has been encrypted; encrypted data is
incompressible. Data compression saves modem transmission time and
disk space and more importantly strengthens cryptographic security.
Most cryptanalysis techniques exploit redundancies found in the
plaintext to crack the cipher. Data compression reduces this
redundancy in the plaintext, thereby greatly enhancing resistance to
cryptanalysis. It seems to take longer to compress the plaintext
than to encrypt it, but from a security point of view it seems worth
the extra time, at least in my cautious opinion.
Files that are too short to compress or just don't compress well are
not compressed by PGP.
If you prefer, you can use PKZIP to compress the plaintext before
encrypting it. PKZIP is a widely-available and effective MSDOS
shareware compression utility from PKWare, Inc (9025 N Deerwood Dr,
Brown Deer, WI 53223). Unlike PGP's built-in compression algorithm,
PKZIP has the nice feature of compressing multiple files into a
single compressed file, which is reconstituted again into separate
files when decompressed. PKZIP also compresses faster than the
internal compression algorithm used in PGP. PGP will not try to
compress a plaintext file that has already been compressed by PKZIP.
After decrypting, the recipient can decompress the plaintext with
PKUNZIP. If the decrypted plaintext is a PKZIP compressed file, PGP
will automatically recognize this and will advise the recipient that
the decrypted plaintext appears to be a PKZIP file.
For the technically curious readers, PGP uses the public domain LZHuf
compression routines written in Japan by Haruyasu Yoshizaki, based on
the original LZSS compression routines by Haruhiko Okumura. The
adaptive Huffman algorithm was added by Yoshizaki to increase speed
and compression, and he used the LZHuf routines to develop the LHarc
archiver. Allan Hoeltje added a run-length encoding layer for better
speed. This compression software was selected for PGP because of
its
public domain portable C source code availability, and because it has
a good compression ratio.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 19
Vulnerabilities
===============
No data security system is inpenetrable. PGP can be circumvented
in
a variety of ways. In any data security system, you have to ask
yourself if the information you are trying to protect is valuable
enough to your attacker that the cost of the attack is less than the
value of the information. This should lead you to protecting
yourself from the cheapest attacks, while not worrying about the more
expensive attacks. Some of the discussion that follows may seem
unduly paranoid, but such an attitude is appropriate for a reasonable
discussion of vulnerability issues.
Compromised Pass Phrase and Secret Key
--------------------------------------
Probably the simplest attack is if you leave your pass phrase
for your secret key written down somewhere. If someone gets it and
gets your secret key file, they can read your messages and make
signatures in your name. Also, don't use obvious passwords that can
be easily guessed, such as the names of your kids or spouse.
Public Key Tampering
--------------------
Another vulnerability exists if public keys are tampered with. This
attack and appropriate hygienic countermeasures are detailed in this
document in the section "Signed Public Key Certificates". When you
use someone's public key, make certain it has not been tampered with.
Also make sure no one else can tamper with your own public key ring.
"Not Quite Deleted" Files
-------------------------
Another potential security problem is caused by how most operating
systems delete files. When you encrypt a file and then delete the
original plaintext file, the operating system doesn't actually
physically erase the data. It merely marks those disk blocks as
deleted, allowing the space to be reused later. It's sort of like
discarding sensitive paper documents in the paper recycling bin
instead of the paper shredder. The disk blocks still contain the
original sensitive data you wanted to erase, and will probably
eventually be overwritten by new data at some point in the future.
If an attacker reads these deleted disk blocks soon after they have
been deallocated, he could recover your plaintext.
In fact this could even happen accidentally, if for some reason
something went wrong with the disk and some files were accidentally
deleted or corrupted. A disk recovery program may be run to recover
the damaged files, but this often means some previously deleted files
are resurrected along with everything else. Your confidential files
that you thought were gone forever could then reappear and be
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 20
inspected by whomever is attempting to recover your damaged disk.
Even while you are creating the original message with a word
processor or text editor, the editor may be creating multiple
temporary copies of your text on the disk, just because of its
internal workings. These temporary copies of your text are deleted
by the word processor when it's done, but these sensitive fragments
are still on your disk somewhere. The only way to prevent all this
from happening is to somehow cause the sensitive deleted plaintext
files to be overwritten. There are disk utilities available that
can
overwrite all of the unused blocks on a disk. For example, I think
the Norton Utilities for MSDOS can do this.
Viruses and Trojan Horses
-------------------------
Another attack could involve a specially-tailored hostile computer
virus or worm that might infect PGP or your operating system. This
hypothetical virus could be designed to capture your pass phrase or
secret key or deciphered messages, and covertly write the captured
information to a file or send it through a network to the virus's
owner. Or it might alter PGP's behavior so that signatures are not
properly checked. This attack is cheaper than cryptanalytic attacks.
Defending against this falls under the catagory of defending against
viral infection generally. There are some moderately capable
anti-viral products commercially available, and there are hygienic
procedures to follow that can greatly reduce the chances of viral
infection. A complete treatment of anti-viral and anti-worm
countermeasures is beyond the scope of this document. PGP has no
defenses against viruses, and assumes your own personal computer is a
trustworthy execution environment. If such a virus or worm actually
appeared, hopefully word would soon get around warning everyone.
Another similar attack involves someone creating a clever imitation
of PGP that behaves like PGP in most respects, but doesn't work the
way it's supposed to. For example, it might be deliberately crippled
to not check signatures properly, allowing bogus key certificates to
be accepted. This "Trojan horse" version of PGP is not hard for an
attacker to create, because PGP source code is widely available, so
anyone could modify the source code and produce a lobotomized zombie
imitation PGP that looks real but does the bidding of its diabolical
master. This Trojan horse version of PGP could then be widely
circulated, claiming to be from me. How insidious.
To help protect against viral infection of PGP or later Trojan horse
copies of PGP, I included a signature certificate file called PGP.CTX
in the MSDOS release of PGP. It bears my signature for the MSDOS
executable file PGP.EXE, to assure that PGP.EXE has not been
subsequently infected with a virus. To run this self-test of PGP
to check its own integrity with my signature certificate, type:
pgp pgp.ctx pgp.exe
PGP should report a good signature from Philip R. Zimmermann on the
PGP.EXE executable program file, which, in theory, indicates your copy
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 21
of PGP software has no virus infection and has not been tampered
with. This will not help at all if your operating system is infected,
nor will it detect if your original copy of PGP.EXE has been
maliciously altered in such a way as to compromise its own ability to
check signatures.
You should try to get at least your first copy of PGP from a trusted
reliable source, so that you can use it to check my signature on
subsequent releases of PGP. You can keep the older trusted version
of PGP around on a write-protected backup floppy, along with a
trusted copy of my public key to check signatures on future PGP
releases. You'd also have to somehow make sure that my public key
(also included in the PGP release) actually belongs to me, so it can
be trusted to verify my signature. Make sure that you use this
trusted copy of my public key, and not rely on a public key included
with a newer release of PGP that may be suspect.
Just for good measure, I also included a signature certificate for
this document, called PGPGUIDE.CTX. I also included a signature
certificate for the all PGP source files in the source release.
Physical Security Breach
------------------------
A physical security breach may allow someone to physically acquire
your plaintext files or printed messages. A determined opponent
might accomplish this through burglery, trash-picking, unreasonable
search and seizure, or coercion or infiltration of your staff. Some
of these attacks may be especially feasible against grassroots
political organizations that depend on a largely volunteer staff.
It
has been widely reported in the press that the FBI's COINTELPRO
program used burglery, infiltration, and illegal bugging against
antiwar and civil rights groups. And look what happened at the
Watergate Hotel. Don't be lulled into a false sense of security just
because you have a cryptographic tool. Cryptographic techniques
protect data only while it's encrypted-- direct physical security
violations can still compromise plaintext data or written or spoken
information. This kind of attack is cheaper than cryptanalytic
attacks.
Tempest Attacks
---------------
Another kind of attack that has been used by well-equipped opponents
involves the remote detection of the electromagnetic signals from
your computer. This expensive and somewhat labor-intensive attack
is
probably still cheaper than direct cryptanalytic attacks. An
appropriately instrumented van can park near your office and remotely
pick up all of your keystrokes and messages displayed on your
computer video screen. This would compromise all of your passwords,
messages, etc. This attack can be thwarted by properly shielding
all
of your computer equipment and network cabling so that it does not
emit these signals. This shielding technology is known as "Tempest",
and is used by some Government agencies and defense contractors.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 22
There are hardware vendors who supply Tempest shielding commercially,
although it may be subject to some kind of Government licensing.
Traffic Analysis
----------------
Even if the attacker cannot read the contents of your encrypted
messages, he may be able to infer at least some useful information by
observing where the messages come from and where they are going, the
size of the messages, and the time of day the messages are sent.
This is analogous to the attacker looking at your long distance phone
bill to see who you called and when and for how long, even though the
actual content of your calls is unknown to the attacker. This is
called traffic analysis. PGP alone does not protect against traffic
analysis. Solving this problem would require specialized
communication protocols designed to reduce exposure to traffic
analysis in your communication environment, possibly with some
cryptographic assistance.
Cryptanalysis
-------------
An expensive and formidible cryptanalytic attack could possibly be
mounted by someone with vast supercomputer resources, such as a
Government intelligence agency. They might crack your RSA key by
using some new secret factoring breakthrough. Perhaps so, but it
is
noteworthy that the US Government trusts the RSA algorithm enough in
some cases to use it to protect its own nuclear weapons, according to
Ron Rivest.
Perhaps the Government has some classified methods of cracking the
conventional encryption algorithm used in PGP. This is every
cryptographer's worst nightmare. There can be no absolute security
guarantees in practical cryptographic implementations. Still, some
optimism seems justified. Widely accepted cryptographic design
principles were followed in the design of this algorithm. Since the
source code and design are publicly available, other cryptographers
will have a chance to review it. Even if this algorithm has some
subtle unknown weaknesses, the data compression of the plaintext
before encryption should greatly reduce those weaknesses.
If your situation justifies worrying about very formidible attacks of
this caliber, then perhaps you should contact a data security
consultant for some customized data security approaches tailored to
your special needs. Boulder Software Engineering, whose address and
phone are given at the end of this document, can provide such
services.
Without good cryptographic protection of your data communications, it
may have been practically effortless and perhaps even routine for an
opponent to intercept your messages, especially those sent through a
modem or E-mail system. If you use PGP and follow reasonable
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 23
precautions, the attacker will have to expend far more effort and
expense to violate your privacy.
If you protect yourself against the simplest attacks, and you feel
confident that your privacy is not going to be violated by a
determined and highly resourceful attacker, then you'll probably be
safe using PGP. PGP gives you Pretty Good Privacy.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 24
Trusting Snake Oil
==================
When examining a cryptographic software package, the question always
remains, why should you trust this product? Even if you examined
the
source code yourself, not everyone has the cryptographic experience
to judge the security. Even if you are an experienced cryptographer,
subtle weaknesses in the algorithms could still elude you.
When I was in college in the early seventies, I devised what I
believed was a brilliant encryption scheme. A simple pseudorandom
number stream was added to the plaintext stream to create
ciphertext. This would seemingly thwart any frequency analysis of
the ciphertext, and would be uncrackable even to the most resourceful
Government intelligence agencies. I felt so smug about my
achievement. So cock-sure.
Years later, I discovered this same scheme in several introductory
cryptography texts and tutorial papers. How nice. Other
cryptographers had thought of the same scheme. Unfortunately, the
scheme was presented as a simple homework assignment on how to use
elementary cryptanalytic techniques to trivially crack it. So much
for my brilliant scheme.
From this humbling experience I learned how easy it is to fall into a
false sense of security when devising an encryption algorithm. Many
mainstream software engineers have developed equally naive encryption
schemes (often even the very same encryption scheme), and some of
them have been incorporated into commercial encryption software
packages and sold for good money to thousands of unsuspecting users.
This is like selling automotive seat belts that look good and feel
good, but snap open in even the slowest crash test. Depending on
them may be worse than not wearing seat belts at all. No one
suspects they are bad until a real crash. Depending on weak
cryptographic software may cause you to unknowingly place sensitive
information at risk. You might not otherwise have done so if you
had
no cryptographic software at all. Perhaps you may never even
discover your data has been compromised.
Sometimes commercial packages use the Federal Data Encryption
Standard (DES), a good conventional algorithm recommended by the
Government for commercial use (but not for classified information,
oddly enough-- Hmmm). There are several "modes of operation" the
DES can use, some of them better than others. The Government
specifically recommends not using the weakest simplest mode for
messages, the Electronic Codebook (ECB) mode. But they do recommend
the stronger and more complex Cipher Feedback (CFB) or Cipher Block
Chaining (CBC) modes.
Unfortunately, most of the commercial encryption packages I've looked
at use ECB mode. When I've talked to the authors of a number of
these implementations, they say they've never heard of CBC or CFB
modes, and didn't know anything about the weaknesses of ECB mode.
The very fact that they haven't even learned enough cryptography to
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 25
know these elementary concepts is not reassuring. These same
software packages often include a second faster encryption algorithm
that can be used instead of the slower DES. The author of the
package often thinks his proprietary faster algorithm is as secure as
the DES, but after questioning him I usually discover that it's just
a variation of my own brilliant scheme from college days. Or maybe
he won't even reveal how his proprietary encryption scheme works, but
assures me it's a brilliant scheme and I should trust it. I'm sure
he believes that his algorithm is brilliant, but how can I know that
without seeing it?
In all fairness I must point out that these products do not come from
companies that specialize in cryptographic technology.
In some ways, cryptography is like pharmaceuticals. Its integrity
may be absolutely crucial. Bad penicillin looks the same as good
penicillin. You can tell if your spreadsheet software is wrong, but
how do you tell if your cryptography package is weak? The ciphertext
produced by a weak encryption algorithm looks as good as ciphertext
produced by a strong encryption algorithm. There's a lot of snake
oil out there. A lot of quack cures. Unlike the patent medicine
hucksters of old, these software implementors usually don't even know
their stuff is snake oil. They usually haven't even read any of the
academic literature in cryptography. But they think they can write
good cryptographic software. And why not? After all, it seems
intuitively easy to do so. And their software seems to work okay.
The Government has peddled snake oil too. After World War II, the
US
sold German Enigma ciphering machines to third world governments.
But they didn't tell them that the Allies cracked the Enigma code
during the war, a fact that remained classified for many years. Even
today many Unix systems worldwide use the Enigma cipher for file
encryption, in part because the Government has created legal
obstacles against using better algorithms. They even tried to
prevent the initial publication of the RSA algorithm in 1977. And
they have squashed essentially all commercial efforts to develop
effective secure telephones for the general public.
The principle job of the US Government's National Security Agency
(NSA) is to gather intelligence, principally by covertly tapping into
people's private communications (see James Bamford's book, "The
Puzzle Palace"). They have amassed considerable skill and resources
for cracking codes. When people can't get good cryptography to
protect themselves, it makes NSA's job much easier. NSA also has
the
responsibility of approving and recommending encryption algorithms.
Some critics charge that this is a conflict of interest, like putting
the fox in charge of guarding the henhouse. NSA has been pushing
a
new encryption algorithm that they designed, and they won't tell
anybody how it works because that's classified. They want others
to
trust it and use it. But any cryptographer can tell you that a
well-designed encryption algorithm does not have to be classified to
remain secure. Only the keys should need protection. How does
anyone else really know if NSA's classified algorithm is secure?
It's not that hard for NSA to design an encryption algorithm that
only they can crack, if no one else can review the algorithm. Are
they deliberately selling snake oil?
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 26
I'm not as cock-sure about the security of PGP as I once was about my
brilliant encryption software from college. If I were, that would
be
a bad sign. But I'm pretty sure that PGP does not contain any snake
oil. Source code is available, so other cryptographers are welcome
to review its design. It's reasonably well researched. It's
based
on the work of a number of reputable cryptographers. It's been years
in the making. And I don't work for the NSA. I hope it doesn't
require a large "leap of faith" to trust the security of PGP.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 27
Why Do You Need PGP?
====================
It's personal. It's private. And it's no one's business but
yours.
You may be planning a political campaign, discussing your taxes, or
having an illicit affair. Or you may be doing something that you
feel shouldn't be illegal, but is. Whatever it is, you don't want
your private electronic mail (E-mail) or confidential documents read
by anyone else. There's nothing wrong with asserting your privacy.
Privacy is as apple-pie as the Constitution.
Perhaps you think your E-mail is legitimate enough that encryption is
unwarranted. If you really are a law-abiding citizen with nothing
to
hide, then why don't you always send your paper mail on postcards?
Why not submit to drug testing on demand? Why require a warrant for
police searches of your house? Are you trying to hide something?
You must be a subversive or a drug dealer if you hide your mail
inside envelopes. Or maybe a paranoid nut. Do law-abiding citizens
have any need to encrypt their E-mail?
What if everyone believed that law-abiding citizens should use
postcards for their mail? If some brave soul tried to assert his
privacy by using an envelope for his mail, it would draw suspicion.
Perhaps the authorities would open his mail to see what he's hiding.
Fortunately, we don't live in that kind of world. Because everyone
protects most of their mail with envelopes, no one draws suspicion by
asserting their privacy with an envelope. There's safety in numbers.
Analogously, it would be nice if everyone routinely used encryption
for all their E-mail, innocent or not, so that no one drew suspicion
by asserting their E-mail privacy with encryption. Think of it as
a
form of solidarity.
If the Government wants to violate the privacy of ordinary citizens,
it has to expend a certain amount of expense and labor to intercept
and steam open and read paper mail, and listen to and possibly
transcribe spoken telephone conversation. This kind of labor-
intensive monitoring is not practical on a large scale. This is only
done in important cases when it seems worthwhile.
More and more of our private communications are going to be routed
through electronic channels. Electronic mail will gradually replace
conventional paper mail. E-mail messages are just too easy to
intercept and scan for interesting keywords. This can be done easily,
routinely, automatically, and undetectably on a grand scale.
International cablegrams are already scanned this way on a large
scale by the NSA.
We are moving toward a future when the nation will be crisscrossed
with high capacity fiber optic data networks linking together all our
increasingly ubiquitous personal computers. E-mail will be the norm
for everyone, not the novelty it is today. Perhaps the Government
will protect our E-mail with Government-designed encryption
algorithms. Probably most people will trust that. But perhaps
some
people will prefer their own protective measures.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 28
The 17 Apr 1991 New York Times reports on an unsettling US Senate
proposal that is part of a counterterrorism bill. If this nonbinding
resolution became real law, it would force manufacturers of secure
communications equipment to insert special "trap doors" in their
products, so that the Government can read anyone's encrypted messages.
It reads: "It is the sense of Congress that providers of electronic
communications services and manufacturers of electronic communications
service equipment shall insure that communications systems permit the
Government to obtain the plain text contents of voice, data, and
other communications when appropriately authorized by law."
If privacy is outlawed, only outlaws will have privacy. Intelligence
agencies have access to good cryptographic technology. So do the
big
arms and drug traffickers. So do defense contractors, oil companies,
and other corporate giants. But ordinary people and grassroots
political organizations mostly do not have access to affordable
"military grade" public-key cryptographic technology.
PGP enables people to take their privacy into their own hands.
There's a growing social need for it. That's why I wrote it.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 29
PGP Quick Reference
===================
Here's a quick summary of PGP commands.
To encrypt a plaintext file with the recipent's public key:
pgp -e textfile her_userid
To sign a plaintext file with your secret key:
pgp -s textfile your_userid
To sign a plaintext file with your secret key, and then encrypt it
with the recipent's public key:
pgp -es textfile her_userid your_userid
To encrypt a plaintext file with just conventional cryptography, type:
pgp -c textfile
To decrypt an encrypted file, or to check the signature integrity of a
signed file:
pgp ciphertextfile [plaintextfile]
To generate your own unique public/secret key pair:
pgp -k
To add a public or secret key file's contents to your public or
secret key ring:
pgp -a keyfile [keyring]
To remove a key from your public key ring:
pgp -r userid [keyring]
To view the contents of your public key ring:
pgp -v [userid] [keyring]
To create a signature certificate that is detached from the document:
pgp -sb textfile your_userid
To produce a ciphertext file in Unix uuencode format, just add the
"u" option when encrypting or signing a message:
pgp -esu textfile her_userid your_userid
To wipe out the plaintext file after producing the ciphertext file,
just add the "w" (wipe) option when encrypting or signing a message:
pgp -esw message.txt her_userid your_userid
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 30
Legal Issues
============
Trademarks, Copyrights, and Warranties
--------------------------------------
"Pretty Good Privacy", "Phil's Pretty Good Software", and the "Pretty
Good" label for computer software and hardware products are all
trademarks of Philip Zimmermann and Phil's Pretty Good Software.
PGP
is (c) Copyright Philip R. Zimmermann, 1990.
The author assumes no liability for damages resulting from the use of
this software, even if the damage results from defects in this
software, and makes no representations concerning the merchantability
of this software or its suitability for any specific purpose. It
is
provided "as is" without express or implied warranty of any kind.
Patent Rights on the Algorithms
-------------------------------
The RSA public key cryptosystem was developed at MIT with Federal
funding from grants from the National Science Foundation and the
Navy. It is patented by MIT (U.S. patent #4,405,829, issued 20 Sep
1983). A company called Public Key Partners (PKP) holds the exclusive
commercial license to sell and sub-license the RSA public key
cryptosystem. For licensing details on the RSA algorithm, you can
contact Robert Fougner at PKP, at 408/735-6779. The author of this
software implementation of the RSA algorithm is providing this
implementation for educational use only. Licensing this algorithm
from PKP is the responsibility of you, the user, not Philip
Zimmermann, the author of this software implementation. The author
assumes no liability for any breach of patent law resulting from the
unlicensed use by the user of the underlying RSA algorithm used in
this software.
The LZHuf compression routines in PGP come from public domain source
code. I'm not aware of any patents on the LZHuf algorithm, but I've
heard that a related compression algorithm, LZW, has some patent
claims from Unisys Corporation. LZHuf is different from LZW, and
might not be affected by this patent. If you're interested, you're
welcome to look into this murky issue yourself. If there are any
patent claims that apply to LZHuf, then well, sorry, you'll have to
take care of the patent licensing, not me.
It seems like the patent office has been issuing patents on ideas to
anyone who applies for one. A software engineer may create a
software package and unknowingly infringe on any number of patents.
Perhaps there is a patent somewhere on using a computer to do any
kind of cryptography at all. I once saw a Peanuts cartoon in the
newspaper where Lucy showed Charlie Brown a fallen autumn leaf and
said "This is the first leaf to fall this year." Charlie Brown said,
"How do you know that? Leaves have been falling for weeks."
Lucy
replied, "I had this one notarized."
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 31
Licensing and Distribution
--------------------------
PKP controls licensing of the underlying RSA algorithm, but not on
the PGP software that uses their RSA algorithm. As far as I'm
concerned, anyone may freely use or distribute PGP, without payment
of fees to me (except as provided below). You must keep the
copyright notices on PGP and keep this documentation with it.
However, this may not satisfy any legal obligations you may have to
PKP for using the RSA algorithm as mentioned above. You may choose
to pay PKP a licensing fee on the RSA algorithm.
PGP is not shareware, it's freeware. Published as a community
service. If I sold PGP for money, then I would have to pay a license
fee to PKP for using their RSA algorithm. More importantly, giving
PGP away for free will encourage far more people to use it, which
hopefully will have a greater social impact. This could lead to
widespread awareness and use of the RSA public key cryptosystem,
which will probably make more money for PKP in the long run.
All the source code for PGP is available for free under the "Copyleft"
General Public License from the Free Software Foundation (FSF). A
copy of the FSF General Public License is included in the source
release package of PGP.
Regardless of and perhaps contrary to some provisions of the FSF
General Public License, the following terms apply:
1) Written discussions of PGP in magazines or books may include
fragments of PGP source code and documentation, without
restrictions.
2) If you are able and willing to pay PKP a license fee for the RSA
algorithm, then I guess that sort of makes PGP not exactly free,
doesn't it? If you decide to do that, then I'm asking for a $50
donation from each user that pays PKP a license fee.
3) Although the FSF General Public License allows non-proprietary
derivative products, it prohibits proprietary derivative products.
Despite this, I may grant you a special license if you want to
derive a proprietary commercial product from some of PGP's parts.
There may or may not be a fee depending on what kind of a deal you
plan to pursue with PKP. Retaining my copyright notice and
attribution might suffice in some cases. Give me a call and we'll
discuss it. I'm real easy to please.
Please disseminate the complete PGP release package as widely as
possible. Give it to all your friends. If you have access to
any
electronic Bulletin Boards Systems, please upload the complete PGP
executable object release package to as many BBS's as possible. You
may disseminate the PGP source release package too, if you've got
it. The PGP version 1.0 executable object release package for MSDOS
contains the PGP executable software, documentation, sample keyrings
including my own public key, and signatures for the software and this
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 32
manual, all in one PKZIP compressed file called PGP10.ZIP. The PGP
source release package for MSDOS contains all the C source files in
one PKZIP compressed file called PGP10SRC.ZIP.
You may obtain free updates to PGP from BBS's or other public
sources. If you must have an update directly from me, send me a $50
handling charge (made out to Philip Zimmermann). This fee is NOT
a
charge for PGP, which you can get for free anywhere else. This
outrageous fee is just to get me to overcome my procrastination and
interrupt my bread-and-butter work and prepare a release disk for you
and maybe drive down to the post office to buy some stamps, since I
don't have a secretary to handle these matters. If you want much
faster service, include a stamped self-addressed floppy disk mailer
and a blank floppy disk. If you want even faster service, include
your Federal Express account number (or better yet, one of your own
Fedex airbill forms already filled out addressed to you) and I will
Fedex it to you overnight at your expense. I will send you a disk
with my latest and greatest source and executable object release
packages of PGP. Assuming that no one tampers with the disk before
it reaches you, you can trust that my public key is good and that the
software is free of viruses. There's no guarantee that my version
of
PGP is more up-to-date than the one you have already.
After all this work I have to admit I wouldn't mind getting some fan
mail for PGP, to gauge its popularity. Let me know where you heard
about it and what you think and how many of your friends use it.
Bug
reports and suggestions for enhancing PGP are welcome, too. Perhaps
a future PGP release will reflect your suggestions. But please don't
count on a reply, because this project has not been funded. Technical
support is cheerfully provided for an hourly fee.
If anyone wants to volunteer to improve PGP, please let me know.
It
could certainly use some more work. Some features were deferred to
get it out the door. Perhaps you can help port it to some new
machine environments, such as the Apple Macintosh or MS Windows or X
Windows or XVT.
This is the first release of PGP. Future versions of PGP may have
to
change the data formats for messages, signatures, keys and key rings,
in order to provide important new features. This may cause backward
compatibility problems with this version of PGP. Future releases
may
provide conversion utilities to convert old keys if this is practical,
but you may have to generate new keys and dispose of old messages
created with the old PGP. Such a conversion effort will probably
only have to be done once, if at all.
Export Controls
---------------
The Government has made it illegal in many cases to export good
cryptographic technology, and that may include PGP. This is
determined by volatile State Department policies, not fixed laws.
Many foreign governments impose serious penalties on anyone inside
their country using encrypted communications. In some countries they
might even shoot you for that. I will not export this software in
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 33
cases when it is illegal to do so under US State Department policies,
and I assume no responsibility for other people exporting it without
my permission.
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 34
Acknowledgements
================
I'd like to thank the following people for their contributions to the
creation of PGP. Charlie Merritt designed the prototypic
conventional encryption algorithm and taught me how to do decent
multiprecision arithmetic. Zhahai Stewart wrote some 8086 assembly
primitives and gave many helpful suggestions on PGP file formats and
on the conventional encryption algorithm improvements. Allan Hoeltje
integrated the LZHuf compression routines into PGP. These were
developed and placed in the public domain by Haruyasu Yoshizaki and
Haruhiko Okumura. The MD4 routines were developed and placed in the
public domain by Ron Rivest.
Charlie Merritt can be reached at PO Box 317, West Fork, AR 72774.
Zhahai Stewart can be reached at 6521 Old Stage Rd, Boulder, CO 80302.
Allan Hoeltje can be reached at PO Box 18045, Boulder, CO 80308.
Recommended Readings
====================
1) Dorothy Denning, "Cryptography and Data Security", Addison-Wesley,
Reading, MA 1982
2) Dorothy Denning, "Protecting Public Keys and Signature Keys",
IEEE Computer, Feb 1983
3) Philip Zimmermann, "A Proposed Standard Format for RSA
Cryptosystems", IEEE Computer, Sep 1986
4) Ronald Rivest, "The MD4 Message Digest Algorithm", MIT Laboratory
for Computer Science, 1990
About the Author
================
Philip Zimmermann is a software engineer consultant with 17 years
experience, specializing in embedded real-time systems, cryptography,
authentication, and data communications. Experience includes design
and implementation of authentication systems for financial
information networks, network data security, key management
protocols, embedded real-time multitasking executives, operating
systems, and local area networks.
Faster versions of RSA implementations are available from Zimmermann,
as well as other cryptography and authentication products and custom
product development services.
His consulting firm's address is:
Boulder Software Engineering
3021 Eleventh Street
Boulder, Colorado 80304 USA
Phone 303-444-4541 (10:00am - 7:00pm Mountain Time)
FAX 303-444-4541 ext 10
Internet: prz@sage.cgd.ucar.edu
PGPGUIDE.DOC
Wednesday, June 5, 1991 2:28 pm
Page 35
© Copyright 1990
Philip Zimmermann
(Mis en ligne avec l'autorisation
de l'auteur)
Mise à
jour : juin 1998
© 1997, 1998, 1999, 2000,
pplf 14A0 4A67 0431 2402 684D 6EBA 537F 664D 3F80 0D58
pgpenfrancais@bigfoot.com |