		     Phil's Pretty Good Software

			       Presents



				 ===

				 PGP

				 ===



			 Pretty Good Privacy

		 Public Key Encryption for the Masses





		      --------------------------

			   PGP User's Guide

		      Volume I: Essential Topics

		      --------------------------

			 by Philip Zimmermann

			  Revised 14 Jun 93





		     PGP Version 2.3a - 1 Jul 93

			     Software by

			  Philip Zimmermann

				 with

	   Branko Lankester, Hal Finney, and Peter Gutmann









Synopsis:  PGP uses public-key encryption to protect E-mail and data

files.  Communicate securely with people you've never met, with no

secure channels needed for prior exchange of keys.  PGP is well

featured and fast, with sophisticated key management, digital

signatures, data compression, and good ergonomic design.





Software and documentation (c) Copyright 1990-1992 Philip Zimmermann. 

For information on PGP licensing, distribution, copyrights, patents,

trademarks, liability limitations, and export controls, see the

"Legal Issues" section in the "PGP User's Guide, Volume II: Special

Topics".





Contents

========



Quick Overview

Why Do You Need PGP?

How it Works

Installing PGP

How to Use PGP

  To See a Usage Summary

  Encrypting a Message

  Encrypting a Message to Multiple Recipients

  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 or User ID from Your Key Ring

    Extracting (copying) a Key from Your Key Ring

    Viewing the Contents of Your Key Ring

    How to Protect Public Keys from Tampering

    How Does PGP Keep Track of Which Keys are Valid?

    How to Protect Secret Keys from Disclosure

    Revoking a Public Key

    What If You Lose Your Secret Key?

Advanced Topics

  Sending Ciphertext Through E-mail Channels: Radix-64 Format

  Environmental Variable for Path Name

  Setting Configuration Parameters: CONFIG.TXT

Vulnerabilities

Beware of Snake Oil

PGP Quick Reference

Legal Issues

Acknowledgments

About the Author





Quick Overview

=============



Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a

high security cryptographic software application for MSDOS, Unix,

VAX/VMS, and other computers.  PGP allows people to exchange files or

messages with privacy, authentication, and convenience.  Privacy

means that only those intended to receive a message can read it. 

Authentication means that 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 a powerful new technology called "public key"

cryptography.  



PGP combines the convenience of the Rivest-Shamir-Adleman (RSA)

public key cryptosystem with the speed of conventional cryptography,

message digests for digital signatures, data compression before

encryption, good ergonomic design, and sophisticated key management. 

And PGP performs the public-key functions faster than most other

software implementations.  PGP is public key cryptography for the

masses.



PGP does not provide any built-in modem communications capability. 

You must use a separate software product for that.



This document, "Volume I: Essential Topics", only explains the

essential concepts for using PGP, and should be read by all PGP

users.  "Volume II: Special Topics" covers the advanced features of

PGP and other special topics, and may be read by more serious PGP

users.  Neither volume explains the underlying technology details of

cryptographic algorithms and data structures.  





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.  So 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.



Today, 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 being routed through

electronic channels.  Electronic mail is gradually replacing

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.  The Government will

protect our E-mail with Government-designed encryption protocols. 

Probably most people will trust that.  But perhaps some people will

prefer their own protective measures.



Senate Bill 266, a 1991 omnibus anti-crime bill, had an unsettling

measure buried in it.  If this non-binding resolution had become real

law, it would have forced 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."  This

measure was defeated after rigorous protest from civil libertarians

and industry groups.  



In 1992, the FBI Digital Telephony wiretap proposal was introduced to

Congress.  It would require all manufacturers of communications

equipment to build in special remote wiretap ports that would enable

the FBI to remotely wiretap all forms of electronic communication

from FBI offices.  Although it never attracted any sponsors in

Congress because of citizen opposition, it will be reintroduced in

1993.  



Most alarming of all is the White House's bold new encryption policy

initiative, under development at NSA for four years, and unveiled

April 16th, 1993.  The centerpiece of this initiative is a

Government-built encryption device, called the "Clipper" chip,

containing a new classified NSA encryption algorithm.  The Government

is encouraging private industry to design it into all their secure

communication products, like secure phones, secure FAX, etc.  AT&T is

now putting the Clipper into all their secure voice products.  The

catch:  At the time of manufacture, each Clipper chip will be loaded

with its own unique key, and the Government gets to keep a copy,

placed in escrow.  Not to worry, though-- the Government promises

that they will use these keys to read your traffic only when duly

authorized by law.  Of course, to make Clipper completely effective,

the next logical step would be to outlaw other forms of cryptography.



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 have not had access to affordable

"military grade" public-key cryptographic technology.  Until now.



PGP empowers people to take their privacy into their own hands.  

There's a growing social need for it.  That's why I wrote it.





How it Works

============



It would help if you were already familiar with the concept of

cryptography in general and public key cryptography in particular. 

Nonetheless, here are a few introductory remarks about public key

cryptography.



First, some elementary terminology.  Suppose I want to send you a

message, but I don't want anyone but you to be able to read it.  I

can "encrypt", or "encipher" the message, which means I scramble it

up in a hopelessly complicated way, rendering it unreadable to anyone

except you, the intended recipient of the message.  I supply a

cryptographic "key" to encrypt the message, and you have to use the

same key to decipher or "decrypt" it.  At least that's how it works

in conventional "single-key" cryptosystems.



In conventional cryptosystems, such as the US Federal Data Encryption

Standard (DES), a single key is used for both encryption and

decryption.  This means that a key must be initially transmitted via

secure channels so that both parties can know it 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 complementary

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

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 originator 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 public key encryption algorithm is much slower than

conventional single-key encryption, encryption is better accomplished

by using a high-quality fast conventional single-key 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

public key is used to encipher this temporary random conventional

key.  This public-key-enciphered conventional "session" key is sent

along with the enciphered text (called "ciphertext") to the

recipient.  The recipient uses her own secret key to recover this

temporary session key, and then uses that key to run the fast

conventional single-key algorithm to decipher the large ciphertext 

message.



Public keys are kept in individual "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.  Public

key certificates contain the public key material, while secret key

certificates contain the secret key material.  Each secret key is

also encrypted with its own password, in case it gets stolen.  A key

file, or "key ring" contains one or more of these key certificates. 

Public key rings contain public key certificates, and secret key

rings contain secret key certificates.  



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 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

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 secret key to form a signature.  



Documents are signed by prefixing them with signature certificates,

which contain the key ID of the key that was used to sign it, a

secret-key-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.







Installing PGP

==============



The MSDOS PGP 2.3 release comes in a compressed archive file called

PGP23.ZIP (each new release will have a name in the form "PGPxy.ZIP"

for PGP version number x.y).  The archive can be decompressed with

the MSDOS shareware decompression utility PKUNZIP, or the Unix

utility "unzip".  The PGP release package contains a README.DOC file

that you should always read before installing PGP.  This README.DOC

file contains late-breaking news on what's new in this release of

PGP, as well as information on what's in all the other files included

in the release.



If you already have PGP version 1.0 for MSDOS, you should probably

delete it, because no one else uses it anymore.  If you don't want to

delete it, rename the old executable file to pgp1.exe, to avoid name

conflicts with the new PGP.



To install PGP on your MSDOS system, you just have to copy the

compressed archive PGPxx.ZIP file into a suitable directory on your

hard disk (like C:\PGP), and decompress it with PKUNZIP.  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.  If you haven't

run PGP before, the first step after installation (and reading this

manual) is to run the PGP key generation command "pgp -kg".



Installing on Unix and VAX/VMS is generally similar to installing on

MSDOS, but you may have to compile the source code first.  A Unix

makefile is provided with the source release for this purpose.  



For further details on installation, see the separate PGP

Installation Guide, in the file SETUP.DOC included with this

release.  It fully describes how to set up the PGP directory and your

AUTOEXEC.BAT file and how to use PKUNZIP to install it.







How to Use PGP

==============





To See a Usage Summary

----------------------



To see a quick command usage summary for PGP, just type:



    pgp -h







Encrypting a Message

--------------------



To encrypt a plaintext file with the recipient's public key, type:



    pgp -e textfile her_userid



This command produces a ciphertext file called textfile.pgp.  A

specific example is:



    pgp -e letter.txt Alice

or:

    pgp -e letter.txt "Alice S"



The first example searches your public key ring file "pubring.pgp"

for any public key certificates that contain the string "Alice"

anywhere in the user ID field.  The second example would find any

user IDs that contain "Alice S".  You can't use spaces in the string

on the command line unless you enclose the whole string in quotes. 

The search is not case-sensitive.  If it finds a matching public key,

it uses it to encrypt the plaintext file "letter.txt", producing a

ciphertext file called "letter.pgp". 



PGP attempts 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.



If you want to send this encrypted message through E-mail channels,

convert it into printable ASCII "radix-64" format by adding the -a

option, as described later.







Encrypting a Message to Multiple Recipients

-------------------------------------------



If you want to send the same message to more than one person, you may

specify encryption for several recipients, any of whom may decrypt the

same ciphertext file.  To specify multiple recipients, just add more

user IDs to the command line, like so:



    pgp -e letter.txt Alice Bob Carol



This would create a ciphertext file called letter.pgp that could be

decrypted by Alice or Bob or Carol.  Any number of recipients may be

specified.







Signing a Message

-----------------



To sign a plaintext file with your secret key, type:



    pgp -s textfile [-u your_userid]



Note that [brackets] denote an optional field, so don't actually type

real brackets.  



This command produces a signed file called textfile.pgp.  A specific 

example is:



    pgp -s letter.txt -u Bob



This searches your secret key ring file "secring.pgp" for any secret

key certificates that contain the string "Bob" anywhere in the user

ID field.  The search is not case-sensitive.  If it finds a matching

secret key, it uses it to sign the plaintext file "letter.txt",

producing a signature file called "letter.pgp". 



If you leave off the user ID field, the first key on your secret

key ring is used as the default secret key for your signature.







Signing and then Encrypting

---------------------------



To sign a plaintext file with your secret key, and then encrypt it 

with the recipient's public key:



    pgp -es textfile her_userid [-u your_userid]



Note that [brackets] denote an optional field, so don't actually type

real brackets.  



This example produces a nested ciphertext file called textfile.pgp.

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 key ring via her_userid.  If

you leave off her user ID field from the command line, you will be 

prompted for it.



If you leave off your own user ID field, the first key on your secret

key ring is be used as the default secret key for your signature.



Note that PGP attempts to compress the plaintext before encrypting

it.



If you want to send this encrypted message through E-mail channels,

convert it into printable ASCII "radix-64" format by adding the -a

option, as described later.



Multiple recipients may be specified by adding more user IDs to the

command line.







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. 



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.pgp, 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.  This pass phrase need not be (and, indeed, SHOULD not be) the

same pass phrase that you use to protect your own secret key.  Note

that PGP attempts to compress the plaintext before encrypting it.  



PGP will not encrypt the same plaintext the same way twice, even if

you used the same pass phrase every time.







Decrypting and Checking Signatures

----------------------------------



To decrypt an encrypted file, or to check the signature integrity of a

signed file:



    pgp ciphertextfile [-o 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

".pgp".  The optional plaintext output 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 then uses 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 recognizes this and prompts you for the pass

phrase to conventionally decrypt it.





Managing Keys

=============



Since the time of Julius Caesar, key management has always been the

hardest part of cryptography.  One of the principal distinguishing

features of PGP is its sophisticated key management.  







RSA Key Generation

------------------



To generate your own unique public/secret key pair of a specified

size, type:  



    pgp -kg



PGP shows you a menu of recommended key sizes (casual grade,

commercial grade, or military grade) and prompts you for what size

key you want, up to around a thousand bits.  The bigger the key, the

more security you get, but you pay a price in speed.  



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.  It would

help if you put your E-mail address in <angle brackets> after your

name, like so:

  

    Robert M. Smith <rms@xyzcorp.com>



If you don't have an E-mail address, use your phone number or some

other unique information that would help ensure that your user ID is

unique.



PGP also asks for a "pass phrase" to protect your 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 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, and don't store it on

your computer.  If you don't want a pass phrase (You fool!), just

press return (or enter) at the pass phrase prompt.



The public/secret key pair is derived from large truly random numbers

derived mainly from measuring the intervals between your keystrokes

with a fast timer.  The software will ask you to enter some random

text to help it accumulate some random bits for the keys.  When

asked, you should provide some keystrokes that are reasonably random

in their timing, and it wouldn't hurt to make the actual characters

that you type irregular in content as well.  Some of the randomness

is derived from the unpredictability of the content of what you

type.  So don't just type repeated sequences of characters.



Note that RSA key generation is a lengthy process.  It may take a few

seconds for a small key on a fast processor, or quite a few minutes

for a large key on an old IBM PC/XT.



The generated key pair will be placed on your public and secret key

rings.  You can later use the -kx command option to extract (copy)

your new public key from your public key ring and place it in a

separate public key file suitable for distribution to your friends. 

The public key file 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 your secret key to anyone else.  For the same reason, don't

make key pairs for your friends.  Everyone should make their own key

pair.  Always keep physical control of your secret key, and don't risk

exposing it by storing it on a remote timesharing computer.  Keep it

on your own personal computer.







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 -ka keyfile [keyring]



The keyfile extension defaults to ".pgp".  The optional keyring file

name defaults to "pubring.pgp" or "secring.pgp", depending on whether

the keyfile contains a public or a secret key.  You may specify a

different key ring file name, with the extension defaulting to

".pgp".



If the key is already on your key ring, PGP will not add it again. 

All of the keys in the keyfile are added to the keyring, except for

duplicates.  If the key being added has attached signatures

certifying it, the signatures are added with the key.  If the key is

already on your key ring, PGP just merges in any new certifying

signatures for that key that you don't already have on your key ring.







Removing a Key or User ID from Your Key Ring

--------------------------------------------



To remove a key or a user ID from your public key ring:



    pgp -kr userid [keyring]



This searches for the specified user ID in your key ring, and removes

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 "pubring.pgp".  It can be omitted, or you can specify

"secring.pgp" if you want to remove a secret key.  You may specify a

different key ring file name.  The default key ring extension is

".pgp".



If more than one user ID exists for this key, you will be asked if

you want to remove only the user ID you specified, while leaving the

key and its other user IDs intact.  







Extracting (copying) a Key from Your Key Ring

---------------------------------------------



To extract (copy) a key from your public or secret key ring:



    pgp -kx userid keyfile [keyring]



This non-destructively copies the key specified by the user ID from

your public or secret key ring to the specified key file.  This is

particularly useful if you want to give a copy of your public key to

someone else.



If the key has any certifying signatures attached to it on your key

ring, they are copied off along with the key.



If you want the extracted key represented in printable ASCII

characters suitable for email purposes, use the -kxa options.







Viewing the Contents of Your Key Ring

-------------------------------------



To view the contents of your public key ring:



    pgp -kv[v] [userid] [keyring] 



This lists 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

are listed.  The optional keyring file name is assumed to be

"pubring.pgp".  It can be omitted, or you can specify "secring.pgp"

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

".pgp".  



To see all the certifying signatures attached to each key, use the

-kvv option:



    pgp -kvv [userid] [keyring] 



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



With no command options specified, PGP lists all the keys in

keyfile.pgp, and also attempts to add them to your key ring if they

are not already on your key ring.







How to Protect Public Keys from Tampering

-----------------------------------------



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 to.

This may be the most important vulnerability of a public-key

cryptosystem.  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

Charlie 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 Charlie instead of Alice's public key. 

All looks normal because this bogus key has Alice's user ID.  Now

Charlie 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

apparently 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 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 impostor can fool

you into accepting his own bogus key as Alice's because no one else

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 "guerrilla 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 organic 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.



This whole business of protecting public keys from tampering is the

single most difficult problem in practical public key applications. 

It is the "Achilles heel" of public key cryptography, and a lot of

software complexity is tied up in solving this one problem.  



You should use a public key 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.  Also, the user ID should have the full name of

the key's owner, not just her first name.



No matter how tempted you are-- and you will be tempted-- never,

NEVER give in to expediency and trust a public key you downloaded

from a bulletin board, unless it is signed by someone you trust. 

That uncertified public key could have been tampered with by anyone,

maybe even by the system administrator of the bulletin board.



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.  It may be ill-advised to

rely on hearsay-- don't sign her public key unless you have

independent firsthand knowledge that it really belongs to her. 

Preferably, you should sign it only if you got it directly from her. 



In order to sign a public key, you must be far more certain of that

key's ownership than if you merely want to use that key to encrypt a

message.  To be convinced of a key's validity enough to use it,

certifying signatures from trusted introducers should suffice.  But

to sign a key yourself, you should require your own independent

firsthand knowledge of who owns that key.  Perhaps you could call the

key's owner on the phone and read the key file to her to get her to

confirm that the key you have really is her key-- and make sure you

really are talking to the right person.  See the section called

"Verifying a Public Key Over the Phone" in the Special Topics volume

for further details.



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 aren't

risking your credibility by signing the public key of a sociopath, if

you were completely confident that the key really belonged to him. 

Other people would accept that key as belonging to him because you

signed it (assuming they trust you), but they wouldn't trust that

key's owner.  Trusting a key is not the same as trusting the key's

owner.



Trust is not necessarily transferable; I have a friend who I trust

not to lie.  He's a gullible person who trusts the President not to

lie.  That doesn't mean I trust the President not to lie.  This is

just common sense.  If I trust Alice's signature on a key, and Alice

trusts Charlie's signature on a key, that does not imply that I have

to trust Charlie's signature on a key.  



It would be a good idea to keep your own public key on hand with a

collection of certifying signatures attached from a variety of

"introducers", in the hopes that most people will trust at least one

of the introducers who vouch for your own public key's validity. 

You could post your key with its attached collection of certifying

signatures on various electronic bulletin boards.  If you sign

someone else's public key, return it to them with your signature so

that they can add it to their own collection of credentials for their

own public key.



PGP keeps track of which keys on your public key ring are properly

certified with signatures from introducers that you trust.  All you

have to do is tell PGP which people you trust as introducers, and

certify their keys yourself with your own ultimately trusted key.

PGP can take it from there, automatically validating any other keys

that have been signed by your designated introducers.  And of course

you may directly sign more keys yourself.  More on this later.



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 trusted public keys that are already on your

own public key ring.  Maintain physical control of your public key

ring, preferably on your own personal computer rather than on a

remote timesharing system, just as you would do for your secret key. 

This is to protect it from tampering, not from disclosure.  Keep a

trusted backup copy of your public key ring and your secret key ring

on write-protected media.



Since your own trusted public key is used as a final authority to

directly or indirectly certify all the other keys on your key ring,

it is the most important key to protect from tampering.  To detect

any tampering of your own ultimately-trusted public key, PGP can be

set up to automatically compare your public key against a backup copy

on write-protected media.  For details, see the description of the

"-kc" key ring check command in the Special Topics volume.



PGP generally assumes you will maintain physical security over your

system and your key rings, as well as your copy of PGP itself.  If an

intruder can tamper with your disk, then in theory he can tamper with

PGP itself, rendering moot the safeguards PGP may have to detect

tampering with keys.



One somewhat complicated way to protect your own whole public key ring

from tampering is to sign the whole ring with your own secret key. 

You could do this by making a detached signature certificate of the

public key ring, by signing the ring with the "-sb" options (see the

section called "Separating Signatures from Messages" in the PGP

User's Guide, Special Topics volume).  Unfortunately, you would still

have to keep a separate trusted copy of your own public key around to

check the signature you made.  You couldn't rely on your own public

key stored on your public key ring to check the signature you made

for the whole ring, because that is part of what you're trying to

check.  







How Does PGP Keep Track of Which Keys are Valid?

------------------------------------------------



Before you read this section, be sure to read the above section on 

"How to Protect Public Keys from Tampering".



PGP keeps track of which keys on your public key ring are properly

certified with signatures from introducers that you trust.  All you

have to do is tell PGP which people you trust as introducers, and

certify their keys yourself with your own ultimately trusted key.

PGP can take it from there, automatically validating any other keys

that have been signed by your designated introducers.  And of course

you may directly sign more keys yourself.



There are two entirely separate criteria PGP uses to judge a public

key's usefulness-- don't get them confused: 



  1)  Does the key actually belong to whom it appears to belong?  

      In other words, has it been certified with a trusted signature?

  2)  Does it belong to someone you can trust to certify other keys?



PGP can calculate the answer to the first question.  To answer the

second question, PGP must be explicitly told by you, the user.  When

you supply the answer to question 2, PGP can then calculate the

answer to question 1 for other keys signed by the introducer you

designated as trusted.



Keys that have been certified by a trusted introducer are deemed

valid by PGP.  The keys belonging to trusted introducers must

themselves be certified either by you or by other trusted

introducers.



PGP also allows for the possibility of you having several shades of

trust for people to act as introducers.  Your trust for a key's owner

to act as an introducer does not just reflect your estimation of

their personal integrity-- it should also reflect how competent you

think they are at understanding key management and using good

judgment in signing keys.  You can designate a person to PGP as

unknown, untrusted, marginally trusted, or completely trusted to

certify other public keys.  This trust information is stored on your

key ring with their key, but when you tell PGP to copy a key off your

key ring, PGP will not copy the trust information along with the key,

because your private opinions on trust are regarded as confidential. 



When PGP is calculating the validity of a public key, it examines the

trust level of all the attached certifying signatures.  It computes a

weighted score of validity-- two marginally trusted signatures are

deemed as credible as one fully trusted signature.  PGP's skepticism

is adjustable-- for example, you may tune PGP to require two fully

trusted signatures or three marginally trusted signatures to judge a

key as valid.



Your own key is "axiomatically" valid to PGP, needing no introducer's

signature to prove its validity.  PGP knows which public keys are

yours, by looking for the corresponding secret keys on the secret

key ring.  PGP also assumes you ultimately trust yourself to certify

other keys.



As time goes on, you will accumulate keys from other people that you

may want to designate as trusted introducers.  Everyone else will

each choose their own trusted introducers.  And everyone will

gradually accumulate and distribute with their key a collection of

certifying signatures from other people, with the expectation that

anyone receiving it will trust at least one or two of the signatures. 

This will cause the emergence of a decentralized fault-tolerant web

of confidence for all public keys.



This unique grass-roots approach contrasts sharply with Government

standard public key management schemes, such as Internet Privacy

Enhanced Mail (PEM), which are based on centralized control and

mandatory centralized trust.  The standard schemes rely on a

hierarchy of Certifying Authorities who dictate who you must trust. 

PGP's decentralized probabilistic method for determining public key

legitimacy is the centerpiece of its key management architecture. 

PGP lets you alone choose who you trust, putting you at the top of

your own private certification pyramid.  PGP is for people who prefer

to pack their own parachutes.







How to Protect Secret Keys from Disclosure

------------------------------------------



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)

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.  And of course, a compromise of your own

secret key could expose all messages sent to you.



To protect your secret key, you can start by always keeping physical

control of your secret key.  Keeping it on your personal computer at

home is OK, or keep it in your notebook computer that you can carry

with you.  If you must use an office computer that you don't always

have physical control of, then keep your public and secret key rings

on a write-protected removable floppy disk, and don't leave it behind

when you leave the office.  It wouldn't be a good idea to allow your

secret key to reside on a remote timesharing computer, such as a

remote dial-in Unix system.  Someone could eavesdrop on your modem

line and capture your pass phrase, and then obtain your actual secret

key from the remote system.  You should only use your secret key on a

machine that you have physical control over.  



Don't store your pass phrase anywhere on the computer that has your

secret key file.  Storing both the secret key and the pass phrase on

the same computer is as dangerous as keeping your PIN in the same

wallet as your Automatic Teller Machine bank card.  You don't want

somebody to get their hands on your disk containing both the pass

phrase and the secret key file.  It would be most secure if you just

memorize your pass phrase and don't store it anywhere but your brain.  

If you feel you must write down your pass phrase, keep it well

protected, perhaps even more well protected than the secret key file.



And keep backup copies of your secret key ring-- remember, you have

the only copy of your secret key, and losing it will render useless

all the copies of your public key that you have spread throughout the

world.  



The decentralized non-institutional approach PGP uses to manage

public keys has its benefits, but unfortunately this also means we

can't rely on a single centralized list of which keys have been

compromised.  This makes it a bit harder to contain the damage of a

secret key compromise.  You just have to spread the word and hope

everyone hears about it.



If the worst case happens-- your secret key and pass phrase are both

compromised (hopefully you will find this out somehow)-- you will

have to issue a "key compromise" certificate.  This kind of

certificate is used to warn other people to stop using your public

key.  You can use PGP to create such a certificate by using the "-kd"

command.  Then you must somehow send this compromise certificate to

everyone else on the planet, or at least to all your friends and

their friends, et cetera.  Their own PGP software will install this

key compromise certificate on their public key rings and will

automatically prevent them from accidentally using your public key

ever again.  You can then generate a new secret/public key pair and

publish the new public key.  You could send out one package containing

both your new public key and the key compromise certificate for your 

old key.







Revoking a Public Key

---------------------



Suppose your secret key and your pass phrase are somehow both

compromised.  You have to get the word out to the rest of the world,

so that they will all stop using your public key.  To do this, you 

will have to issue a "key compromise", or "key revocation" certificate

to revoke your public key.



To generate a certificate to revoke your own key, use the -kd

command:



     pgp -kd your_userid



This certificate bears your signature, made with the same key you are

revoking.  You should widely disseminate this key revocation

certificate as soon as possible.  Other people who receive it can add

it to their public key rings, and their PGP software then

automatically prevents them from accidentally using your old public

key ever again.  You can then generate a new secret/public key pair

and publish the new public key.



You may choose to revoke your key for some other reason than the

compromise of a secret key.  If so, you may still use the same

mechanism to revoke it.







What If You Lose Your Secret Key?

---------------------------------



Normally, if you want to revoke your own secret key, you can use the

"-kd" command to issue a revocation certificate, signed with your own

secret key (see "Revoking a Public Key").  



But what can you do if you lose your secret key, or if your secret

key is destroyed?  You can't revoke it yourself, because you must use

your own secret key to revoke it, and you don't have it anymore.  A

future version of PGP will offer a more secure means of revoking keys

in these circumstances, allowing trusted introducers to certify that

a public key has been revoked.  But for now, you will have to get the

word out through whatever informal means you can, asking users to

"disable" your public key on their own individual public key rings.



Other users may disable your public key on their own public key rings

by using the "-kd" command.  If a user ID is specified that does not

correspond to a secret key on the secret key ring, the -kd command

will look for that user ID on the public key ring, and mark that

public key as disabled.  A disabled key may not be used to encrypt

any messages, and may not be extracted from the key ring with the -kx

command.  It can still be used to check signatures, but a warning is

displayed.  And if the user tries to add the same key again to his

key ring, it will not work because the disabled key is already on the

key ring.  These combined features will help curtail the further

spread of a disabled key.



If the specified public key is already disabled, the -kd command will

ask if you want the key reenabled.





Advanced Topics

===============



Most of the "Advanced Topics" are covered in the "PGP User's Guide,

Volume II:  Special Topics".  But here are a few topics that bear

mentioning here.





Sending Ciphertext Through E-mail Channels: Radix-64 Format

-----------------------------------------------------------



Many electronic mail systems only allow messages made of ASCII text,

not the 8-bit raw binary data that ciphertext is made of.  To get

around this problem, PGP supports ASCII radix-64 format for

ciphertext messages, similar to the Internet Privacy-Enhanced Mail

(PEM) format.  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.  This format acts as a form of

"transport armor", protecting it against corruption as it travels

through intersystem gateways on Internet.  It also appends a CRC to 

detect transmission errors.



Radix-64 format converts the plaintext by expanding groups of 3

binary 8-bit bytes into 4 printable ASCII characters, so the file

grows by about 33%.  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 ASCII radix-64 format, just add the

"a" option when encrypting or signing a message, like so:



    pgp -esa message.txt her_userid



This example produces a ciphertext file called "message.asc" that

contains data in a PEM-like ASCII radix-64 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 radix-64 transport-armored message is no different than

a normal decrypt.  For example:



    pgp message



PGP automatically looks for the ASCII file "message.asc" before it

looks for the binary file "message.pgp".  It recognizes that the file

is in radix-64 format and converts it back to binary before

processing as it normally does, producing as a by-product a ".pgp"

ciphertext file in binary form.  The final output file is in normal

plaintext form, just as it was in the original file "message.txt".



Most Internet E-mail facilities prohibit sending messages that are

more than 50000 bytes long.  Longer messages must be broken into

smaller chunks that can be mailed separately.  If your encrypted

message is very large, and you requested radix-64 format, PGP 

automatically breaks it up into chunks that are each small enough to

send via E-mail.  The chunks are put into files named with extensions

".as1", ".as2", ".as3", etc.  The recipient must concatenate these

separate files back together in their proper order into one big file

before decrypting it.  While decrypting, PGP ignores any extraneous

text in mail headers that are not enclosed in the radix-64 message

blocks.



If you want to send a public key to someone else in radix-64 format,

just add the -a option while extracting the key from your keyring.



If you forgot to use the -a option when you made a ciphertext file or

extracted a key, you may still directly convert the binary file into

radix-64 format by simply using the -a option alone, without any

encryption specified.  PGP converts it to a ".asc" file.



If you want to send through an E-mail channel a plaintext file that

is signed but not encrypted, PGP will normally convert it all into

radix-64 armor, rendering it unreadable to the casual human observer. 

If the original plaintext message is in text (not binary) form, there

is a way to send it through an E-mail channel in such a way that the

ASCII armor is applied only to the binary signature certificate, but

not to the plaintext message.  This makes it possible for the

recipient to read the signed message with human eyes, without the aid

of PGP.  Of course, PGP is still needed to actually check the

signature.  For further information on this feature, see the

explanation of the CLEARSIG parameter in the section "Setting

Configuration Parameters: CONFIG.TXT" in the Special Topics volume.





Environmental Variable for Path Name

------------------------------------



PGP uses several special files for its purposes, such as your

standard key ring files "pubring.pgp" and "secring.pgp", the random

number seed file "randseed.bin", the PGP configuration file

"config.txt", and the foreign language string translation file

"language.txt".  These special files can be kept in any directory, by

setting the environmental variable "PGPPATH" to the desired pathname. 

For example, on MSDOS, the shell command:



    SET PGPPATH=C:\PGP



makes PGP assume that your public key ring filename is 

"C:\PGP\pubring.pgp".  Assuming, of course, that 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.







Setting Configuration Parameters: CONFIG.TXT

--------------------------------------------



PGP has a number of user-settable parameters that can be defined in a

special configuration text file called "config.txt", in the directory

pointed to by the shell environmental variable PGPPATH.  Having a

configuration file enables the user to define various flags and

parameters for PGP without the burden of having to always define

these parameters in the PGP command line.  



With these configuration parameters, for example, you can control

where PGP stores its temporary scratch files, or you can select what

foreign language PGP will use to display its diagnostics messages and

user prompts, or you can adjust PGP's level of skepticism in

determining a key's validity based on the number of certifying

signatures it has.



For more details on setting these configuration parameters, see the

appropriate section of the PGP User's Guide, Special Topics volume.







Vulnerabilities

---------------



No data security system is impenetrable.  PGP can be circumvented in

a variety of ways.  Potential vulnerabilities you should be aware of

include compromising your pass phrase or secret key, public key

tampering, files that you deleted but are still somewhere on the

disk, viruses and Trojan horses, breaches in your physical security,

electromagnetic emissions, exposure on multi-user systems, traffic

analysis, and perhaps even direct cryptanalysis.



For a detailed discussion of these issues, see the "Vulnerabilities"

section in the PGP User's Guide, Special Topics volume.





Beware of 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.  Most

people don't realize how fiendishly difficult it is to devise an

encryption algorithm that can withstand a prolonged and determined

attack by a resourceful opponent.  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

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 in most cases these products do

not come from companies that specialize in cryptographic technology.



There is a company called AccessData (87 East 600 South, Orem, Utah

84058, phone 1-800-658-5199) that sells a package for $185 that

cracks the built-in encryption schemes used by WordPerfect, Lotus

1-2-3, MS Excel, Symphony, Quattro Pro, Paradox, and MS Word 2.0.  It

doesn't simply guess passwords-- it does real cryptanalysis.  Some

people buy it when they forget their password for their own files. 

Law enforcement agencies buy it too, so they can read files they

seize.  I talked to Eric Thompson, the author, and he said his

program only takes a split second to crack them, but he put in some

delay loops to slow it down so it doesn't look so easy to the

customer.  He also told me that the password encryption feature of

PKZIP files can often be eas