		     Phil's Pretty Good Software

			       Presents



				 ===

				 PGP

				 ===



			 Pretty Good Privacy

		 Public Key Encryption for the Masses





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

			   PGP User's Guide

		      Volume II: Special 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-1993 Philip Zimmermann. 

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

trademarks, liability limitations, and export controls, see the

"Legal Issues" section.





Contents

========



Quick Overview

Special Topics

  Selecting Keys via Key ID

  Separating Signatures from Messages

  Decrypting the Message and Leaving the Signature on it

  Sending ASCII Text Files Across Different Machine Environments

  Leaving No Traces of Plaintext on the Disk

  Displaying Decrypted Plaintext on Your Screen

  Making a Message For Her Eyes Only

  Preserving the Original Plaintext Filename

  Editing Your User ID or Pass Phrase

  Editing the Trust Parameters for a Public Key

  Checking If Everything is OK on Your Public Key Ring

  Verifying a Public Key Over the Phone

  Using PGP as a Unix-style Filter

  Suppressing Unneccessary Questions:  BATCHMODE

  Force "Yes" Answer to Confirmation Questions:  FORCE

  PGP Returns Exit Status to the Shell

  Environmental Variable for Pass Phrase

  Setting Configuration Parameters: CONFIG.TXT

    TMP - Directory Pathname for Temporary Files

    LANGUAGE - Foreign Language Selector

    MYNAME - Default User ID for Making Signatures

    TEXTMODE - Assuming Plaintext is a Text File

    CHARSET - Specifies Local Character Set for Text Files

    ARMOR - Enable ASCII Armor Output

    ARMORLINES - Size of ASCII Armor Multipart Files

    KEEPBINARY - Keep Binary Ciphertext Files After Decrypting

    COMPRESS - Enable Compression

    COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed

    MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed

    CERT_DEPTH - How Deep May Introducers Be Nested

    BAKRING - Filename for Backup Secret Keyring

    PAGER - Selects Shell Command to Display Plaintext Output

    SHOWPASS - Echo Pass Phrase to User

    TZFIX - Timezone Adjustment

    CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text

    VERBOSE - Quiet, Normal, or Verbose Messages

    INTERACTIVE - Ask for Confirmation for Key Adds

  Protecting Against Bogus Timestamps

  A Peek Under the Hood

    Random Numbers

    PGP's Conventional Encryption Algorithm

    Data Compression

    Message Digests and Digital Signatures

  Compatibility with Previous Versions of PGP

Vulnerabilities

  Compromised Pass Phrase and Secret Key

  Public Key Tampering

  "Not Quite Deleted" Files

  Viruses and Trojan Horses

  Physical Security Breach

  Tempest Attacks

  Exposure on Multi-user Systems

  Traffic Analysis

  Cryptanalysis

Legal Issues

  Trademarks, Copyrights, and Warranties

  Patent Rights on the Algorithms

  Licensing and Distribution

  Export Controls

Computer-Related Political Groups

Recommended Readings

To Contact the Author

Appendix A:  Where to Get PGP





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



This volume II of the PGP User's Guide covers advanced topics about

PGP that were not covered in the "PGP User's Guide, Volume I:

Essential Topics".  You should first read the Essential Topics

volume, or this manual won't make much sense to you.  Reading this

Special Topics volume is optional.







Special Topics

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





Selecting Keys via Key ID

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



In all commands that let the user type a user ID or fragment of a

user ID to select a key, the hexadecimal key ID may be used instead. 

Just use the key ID, with a prefix of "0x", in place of the user ID. 

For example:



    pgp -kv 0x67F7



This would display all keys that had 67F7 as part of their key IDs.



This feature is particularly useful if you have two different keys

from the same person, with the same user ID.  You can unambiguously

pick which key you want by specifying the key ID.





Separating Signatures from Messages

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



Normally, signature certificates are physically 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



This example produces an isolated signature certificate in a file

called "letter.sig".  The contents of letter.txt are not appended to

the signature certificate.



After creating the signature certificate file (letter.sig 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 notices that there is no text in the same file with the

signature and prompts the user for the filename of the text. Only

then can PGP 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.sig 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.



If you receive a ciphertext file that has the signature certificate

glued to the message, you can still pry the signature certificate

away from the message during the decryption.  You can do this with

the -b option during decrypt, like so:



    pgp -b letter



This decrypts the letter.pgp file and if there is a signature in it,

PGP checks the signature and detaches it from the rest of the

message, storing it in the file letter.sig.





Decrypting the Message and Leaving the Signature on it

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



Usually, you want PGP to completely unravel a ciphertext file,

decrypting it and checking the nested signature if there is one,

peeling away the layers until you are left with only the original

plaintext file.



But sometimes you want to decrypt an encrypted file, and leave the

inner signature still attached, so that you are left with a decrypted

signed message.  This may be useful if you want to send a copy of a

signed document to a third party, perhaps re-enciphering it.  For

example, suppose you get a message signed by Charlie, encrypted to

you.  You want to decrypt it, and, leaving Charlie's signature on it,

you want to send it to Alice, perhaps re-enciphering it with Alice's

public key.  No problem.  PGP can handle that.



To simply decrypt a message and leave the signature on it intact,

type:



    pgp -d letter



This decrypts letter.pgp, and if there is an inner signature, it is

left intact with the decrypted plaintext in the output file.



Now you can archive it, or maybe re-encrypt it and send it to someone

else.







Sending ASCII Text Files Across Different Machine Environments

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



You may use PGP to encrypt any kind of plaintext file, binary 8-bit

data or ASCII text.  Probably the most common usage of PGP will be for

E-mail, when the plaintext is ASCII text.  



ASCII text is sometimes represented differently on different

machines.  For example, on an MSDOS system, all lines of ASCII text

are terminated with a carriage return followed by a linefeed.  On a

Unix system, all lines end with just a linefeed.  On a Macintosh, all

lines end with just a carriage return.  This is a sad fact of life.



Normal unencrypted ASCII text messages are often automatically

translated to some common "canonical" form when they are transmitted

from one machine to another.  Canonical text has a carriage return

and a linefeed at the end of each line of text.  For example, the

popular KERMIT communication protocol can convert text to canonical

form when transmitting it to another system.  This gets converted

back to local text line terminators by the receiving KERMIT.  This

makes it easy to share text files across different systems.



But encrypted text cannot be automatically converted by a

communication protocol, because the plaintext is hidden by

encipherment.  To remedy this inconvenience, PGP lets you specify

that the plaintext should be treated as ASCII text (not binary data)

and should be converted to canonical text form before it gets

encrypted.  At the receiving end, the decrypted plaintext is

automatically converted back to whatever text form is appropriate for

the local environment.



To make PGP assume the plaintext is text that should be converted to

canonical text before encryption, just add the "t" option when

encrypting or signing a message, like so:



   pgp -et message.txt her_userid



This mode is automatically turned off if PGP detects that the

plaintext file contains what it thinks is non-text binary data.



For PGP users that use non-English 8-bit character sets, when PGP 

converts text to canonical form, it may convert data from the local

character set into the LATIN1 (ISO 8859-1 Latin Alphabet 1) character

set, depending on the setting of the CHARSET parameter in the PGP

configuration file.  LATIN1 is a superset of ASCII, with extra

characters added for many European languages.







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



This example creates the ciphertext file "message.pgp", and the 

plaintext file "message.txt" is destroyed beyond recovery.



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.  Also, it overwrites the file only

once, which is enough to thwart conventional disk recovery efforts,

but not enough to withstand a determined and sophisticated effort to

recover the faint magnetic traces of the data using special disk

recovery hardware.







Displaying Decrypted Plaintext on Your Screen

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



To view the decrypted plaintext output on your screen (like the

Unix-style "more" command), without writing it to a file, use the -m

(more) option while decrypting:



     pgp -m ciphertextfile



This displays the decrypted plaintext display on your screen one

screenful at a time.







Making a Message For Her Eyes Only

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



To specify that the recipient's decrypted plaintext will be shown

ONLY on her screen and cannot be saved to disk, add the -m option:



     pgp -sem message.txt her_userid



Later, when the recipient decrypts the ciphertext with her secret key

and pass phrase, the plaintext will be displayed on her screen but

will not be saved to disk.  The text will be displayed as it would if

she used the Unix "more" command, one screenful at a time.  If she

wants to read the message again, she will have to decrypt the

ciphertext again.



This feature is the safest way for you to prevent your sensitive

message from being inadvertently left on the recipient's disk.  This

feature was added at the request of a user who wanted to send

intimate messages to his lover, but was afraid she might accidentally

leave the decrypted messages on her husband's computer.







Preserving the Original Plaintext Filename

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



Normally, PGP names the decrypted plaintext output file with a name

similar to the input ciphertext filename, but dropping the 

extension.  Or, you can override that convention by specifying an

output plaintext filename on the command line with the -o option.

For most E-mail, this is a reasonable way to name the plaintext file,

because you get to decide its name when you decipher it, and your

typical E-mail messages often come from useless original plaintext

filenames like "to_phil.txt".  



But when PGP encrypts a plaintext file, it always saves the original

filename and attaches it to the plaintext before it compresses and

encrypts the plaintext.  Normally, this hidden original filename is

discarded by PGP when it decrypts, but you can tell PGP you want to

preserve the original plaintext filename and use it as the name of

the decrypted plaintext output file.  This is useful if PGP is used

on files whose names are important to preserve.



To recover the original plaintext filename while decrypting, add 

the -p option, like so:



     pgp -p ciphertextfile



I usually don't use this option, because if I did, about half of my

incoming E-mail would decrypt to the same plaintext filenames of

"to_phil.txt" or "prz.txt".







Editing Your User ID or Pass Phrase

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



Sometimes you may need to change your pass phrase, perhaps because

someone looked over your shoulder while you typed it in.  



Or you may need to change your user ID, because you got married and

changed your name, or maybe you changed your E-mail address.  Or

maybe you want to add a second or third user ID to your key, because

you may be known by more than one name or E-mail address or job

title.  PGP lets you attach more than one user ID to your key, any

one of which may be used to look up your key on the key ring.



To edit your own userid or pass phrase for your secret key:



     pgp -ke userid [keyring]



PGP prompts you for a new user ID or a new pass phrase.



The optional [keyring] parameter, if specified, must be a public

keyring, not a secret keyring.  The userid field must be your own

userid, which PGP knows is yours because it appears on both your

public keyring and your secret keyring.  Both keyrings will be

updated, even though you only specified the public keyring.







Editing the Trust Parameters for a Public Key

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



Sometimes you need to alter the trust parameters for a public key on

your public key ring.  For a discussion on what these trust

parameters mean, see the section "How Does PGP Keep Track of Which

Keys are Valid?" in the Essential Topics volume of the PGP User's

Guide.



To edit the trust parameters for a public key:



     pgp -ke userid [keyring]



The optional [keyring] parameter, if specified, must be a public

keyring, not a secret keyring.







Checking If Everything is OK on Your Public Key Ring

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



Normally, PGP automatically checks any new keys or signatures on your

public key ring and updates all the trust parameters and validity

scores.  In theory, it keeps all the key validity status information

up to date as material is added to or deleted from your public key

ring.  But perhaps you may want to explicitly force PGP to perform a

comprehensive analysis of your public key ring, checking all the

certifying signatures, checking the trust parameters, updating all

the validity scores, and checking your own ultimately-trusted key

against a backup copy on a write-protected floppy disk.  It may be a

good idea to do this hygienic maintenance periodically to make sure

nothing is wrong with your public key ring.  To force PGP to perform

a full analysis of your public key ring, use the -kc (key ring check)

command:



     pgp -kc



You can also make PGP check all the signatures for just a single

selected public key by:



     pgp -kc userid [keyring]



For further information on how the backup copy of your own key is

checked, see the description of the BAKRING parameter in the

configuration file section of this manual.







Verifying a Public Key Over the Phone

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



If you get a public key from someone that is not certified by anyone

you trust, how can you tell if it's really their key?  The best way

to verify an uncertified key is to verify it over some independent

channel other than the one you received the key through.  One

convenient way to tell, if you know this person and would recognize

them on the phone, is to call them and verify their key over the

telephone.  Rather than reading their whole tiresome (ASCII-armored)

key to them over the phone, you can just read their key's

"fingerprint" to them.  To see this fingerprint, use the -kvc

command:



     pgp -kvc userid [keyring]



This will display the key with the 16-byte digest of the public key

components.  Read this 16-byte fingerprint to the key's owner on the

phone, while she checks it against her own, using the same -kvc

command at her end.  



You can both verify each other's keys this way, and then you can sign

each other's keys with confidence.  This is a safe and convenient way

to get the key trust network started for your circle of friends.







Using PGP as a Unix-style Filter

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



Unix fans are accustomed to using Unix "pipes" to make two

applications work together.  The output of one application can be

directly fed through a pipe to be read as input to another

application.  For this to work, the applications must be capable of

reading the raw material from "standard input" and writing the

finished output to "standard output".  PGP can operate in this mode.

If you don't understand what this means, then you probably don't need

this feature.



To use a Unix-style filter mode, reading from standard input and

writing to standard output, add the -f option, like so:



     pgp -feast her_userid <inputfile >outputfile



This feature makes it easier to make PGP work with electronic mail

applications.



When using PGP in filter mode to decrypt a ciphertext file, you may

find it useful to use the PGPPASS environmental variable to hold the

pass phrase, so that you won't be prompted for it.  The PGPPASS

feature is explained below.







Suppressing Unneccessary Questions:  BATCHMODE

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



With the BATCHMODE flag enabled on the command line, PGP will not ask

any unneccessary questions or prompt for alternate filenames.  Here

is an example of how to set this flag:



    pgp +batchmode cipherfile 



This is useful for running PGP non-interactively from Unix shell

scripts or MSDOS batch files.  Some key management commands still

need user interaction even when BATCHMODE is on, so shell scripts may

need to avoid them.  



BATCHMODE may also be enabled to check the validity of a signature on

a file.  If there was no signature on the file, the exit code is 1. 

If it had a signature that was good, the exit code is 0.





Force "Yes" Answer to Confirmation Questions:  FORCE

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



This command-line flag makes PGP assume "yes" for the user response

to the confirmation request to overwrite an existing file, or when

removing a key from the keyring via the -kr command.  Here is an

example of how to set this flag:



    pgp +force cipherfile 

or:

    pgp -kr +force Smith



This feature is useful for running PGP non-interactively from a Unix

shell script or MSDOS batch file.







PGP Returns Exit Status to the Shell

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



To facilitate running PGP in "batch" mode, such as from an MSDOS

".bat" file or from a Unix shell script, PGP returns an error exit

status to the shell.  An exit status code of zero means normal exit,

while a nonzero exit status indicates some kind of error occurred.

Different error exit conditions return different exit status codes to

the shell.







Environmental Variable for Pass Phrase

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



Normally, PGP prompts the user to type a pass phrase whenever PGP 

needs a pass phrase to unlock a secret key.  But it is possible to

store the pass phrase in an environmental variable from your

operating system's command shell.  The environmental variable PGPPASS

can be used to hold the pass phrase that PGP will attempt to use

first.  If the pass phrase stored in PGPPASS is incorrect, PGP 

recovers by prompting the user for the correct pass phrase.



For example, on MSDOS, the shell command:



    SET PGPPASS=zaphod beeblebrox for president



would eliminate the prompt for the pass phrase if the pass phrase

were indeed "zaphod beeblebrox for president". 



This dangerous feature makes your life more convenient if you have to

regularly deal with a large number of incoming messages addressed to

your secret key, by eliminating the need for you to repeatedly type

in your pass phrase every time you run PGP.



I added this feature because of popular demand.  However, this is a

somewhat dangerous feature, because it keeps your precious pass

phrase stored somewhere other than just in your brain.  Even worse,

if you are particularly reckless, it may even be stored on a disk on

the same computer as your secret key.  It would be particularly

dangerous and stupid if you were to install this command in a batch

or script file, such as the MSDOS AUTOEXEC.BAT file.  Someone could

come along on your lunch hour and steal both your secret key ring and

the file containing your pass phrase.  



I can't emphasize the importance of this risk enough.  If you are

contemplating using this feature, be sure to read the sections

"Exposure on Multi-user Systems" and "How to Protect Secret Keys from

Disclosure" in this volume and in the Essential Topics volume of the 

PGP User's Guide.



If you must use this feature, the safest way to do it would be to

just manually type in the shell command to set PGPPASS every time you

boot your machine to start using PGP, and then erase it or turn off

your machine when you are done.  And you should definitely never do

it in an environment where someone else may have access to your

machine.  Someone could come along and simply ask your computer to

display the contents of PGPPASS.







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.



Configuration parameters may be assigned integer values, character

string values, or on/off values, depending on what kind of

configuration parameter it is.  A sample configuration file is

provided with PGP, so you can see some examples.



In the configuration file, blank lines are ignored, as is anything

following the '#' comment character.  Keywords are not

case-sensitive.  



Here is a short sample fragment of a typical configuration file:



   # TMP is the directory for PGP scratch files, such as a RAM disk.

   TMP = "e:\"    # Can be overridden by environment variable TMP.

   Armor = on     # Use -a flag for ASCII armor whenever applicable.

   # CERT_DEPTH is how deeply introducers may introduce introducers.

   cert_depth = 3



If some configuration parameters are not defined in the configuration

file, or if there is no configuration file, or if PGP can't find the

configuration file, the values for the configuration parameters

default to some reasonable value.



Note that it is also possible to set these same configuration

parameters directly from the PGP command line, by preceding the

parameter setting with a "+" character.  For example, the following

two PGP commands produce the same effect:



     pgp -e +armor=on message.txt smith

or:  pgp -ea message.txt smith





The following is a summary of the various parameters than may be

defined in the configuration file.





TMP - Directory Pathname for Temporary Files

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



Default setting:  TMP = ""



The configuration parameter TMP specifies what directory to use for

PGP's temporary scratch files.  The best place to put them is on a

RAM disk, if you have one.  That speeds things up quite a bit, and

increases security somewhat.  If TMP is undefined, the temporary

files go in the current directory.  If the shell environmental

variable TMP is defined, PGP instead uses that to specify where the

temporary files should go.





LANGUAGE - Foreign Language Selector

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



Default setting:  LANGUAGE = "en"



PGP displays various prompts, warning messages, and advisories to the

user on the screen.  For example, messages such as "File not found.",

or "Please enter your pass phrase:".  These messages are normally in

English.  But it is possible to get PGP to display its messages to

the user in other languages, without having to modify the PGP

executable program.



A number of people in various countries have translated all of PGP's

display messages, warnings, and prompts into their native languages. 

These hundreds of translated message strings have been placed in a

special text file called "language.txt", distributed with the PGP

release.  The messages are stored in this file in English, Spanish,

Dutch, German, French, Italian, Russian, Latvian, and Lithuanian. 

Other languages may be added later.  



The configuration parameter LANGUAGE specifies what language to

display these messages in.  LANGUAGE may be set to "en" for English,

"es" for Spanish, "de" for German, "nl" for Dutch, "fr" for French,

"it" for Italian, "ru" for Russian, "lt3" for Lithuanian, "lv" for

Latvian, "esp" for Esperanto.  For example, if this line appeared in

the configuration file:



   LANGUAGE = "fr"



PGP would select French as the language for its display messages.

The default setting is English.



When PGP needs to display a message to the user, it looks in the

"language.txt" file for the equivalent message string in the selected

foreign language and displays that translated message to the user.

If PGP can't find the language string file, or if the selected

language is not in the file, or if that one phrase is not translated

into the selected language in the file, or if that phrase is missing

entirely from the file, PGP displays the message in English.



To conserve disk space, most foreign translations are not included 

in the standard PGP release package, but are available separately.





MYNAME - Default User ID for Making Signatures

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



Default setting:  MYNAME = ""



The configuration parameter MYNAME specifies the default user ID to

use to select the secret key for making signatures.  If MYNAME is not

defined, the most recent secret key you installed on your secret key

ring will be used.  The user may also override this setting by

specifying a user ID on the PGP command line with the -u option.





TEXTMODE - Assuming Plaintext is a Text File

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



Default setting:  TEXTMODE = off



The configuration parameter TEXTMODE is equivalent to the -t command

line option.  If enabled, it causes PGP to assume the plaintext is a

text file, not a binary file, and converts it to "canonical text"

before encrypting it.  Canonical text has a carriage return and a

linefeed at the end of each line of text.



This mode will be automatically turned off if PGP detects that the

plaintext file contains what it thinks is non-text binary data.



For VAX/VMS systems, the current version of PGP defaults TEXTMODE=ON.



For further details, see the section "Sending ASCII Text Files Across

Different Machine Environments".





CHARSET - Specifies Local Character Set for Text Files

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



Default setting:  CHARSET = NOCONV



Because PGP must process messages in many non-English languages with

non-ASCII character sets, you may have a need to tell PGP what local

character set your machine uses.  This determines what character

conversions are performed when converting plaintext files to and from

canonical text format.  This is only a concern if you are in a

non-English non-ASCII environment.



The configuration parameter CHARSET selects the local character set. 

The choices are NOCONV (no conversion), LATIN1 (ISO 8859-1 Latin

Alphabet 1), KOI8 (used by most Russian Unix systems), ALT_CODES

(used by Russian MSDOS systems), ASCII, and CP850 (used by most

western European languages on standard MSDOS PCs).



LATIN1 is the internal representation used by PGP for canonical text,

so if you select LATIN1, no conversion is done.  Note also that PGP

treats KOI8 as LATIN1, even though it is a completely different

character set (Russian), because trying to convert KOI8 to either

LATIN1 or CP850 would be futile anyway.  This means that setting

CHARSET to NOCONV, LATIN1, or KOI8 are all equivalent to PGP.



If you use MSDOS and expect to send or receive traffic in western

European languages, set CHARSET = "CP850".  This will make PGP

convert incoming canonical text messages from LATIN1 to CP850 after

decryption.  If you use the -t (textmode) option to convert to

canonical text, PGP will convert your CP850 text to LATIN1 before

encrypting it.



For further details, see the section "Sending ASCII Text Files Across

Different Machine Environments".





ARMOR - Enable ASCII Armor Output

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



Default setting:  ARMOR = off



The configuration parameter ARMOR is equivalent to the -a command

line option.  If enabled, it causes PGP to emit ciphertext or keys in

ASCII Radix-64 format suitable for transporting through E-mail

channels.  Output files are named with the ".asc" extension.



If you tend to use PGP mostly for E-mail, it may be a good idea to

enable this parameter.



For further details, see the section "Sending Ciphertext Through

E-mail Channels: Radix-64 Format" in the Essential Topics volume. 





ARMORLINES - Size of ASCII Armor Multipart Files

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



Default setting:  ARMORLINES = 720



When PGP creates a very large ".asc" radix-64 file for sending

ciphertext or keys through the E-mail, it breaks the file up into

separate chunks small enough to send through Internet mail

utilities.  Normally, Internet mailers prohibit files larger than

about 50000 bytes, which means that if we restrict the number of

lines to about 720, we'll be well within the limit.  The file chunks

are named with suffixes ".as1", ".as2", ".as3", ... 



The configuration parameter ARMORLINES specifies the maximum number

of lines to make each chunk in a multipart ".asc" file sequence.  If

you set it to zero, PGP will not break up the file into chunks.



Fidonet email files usually have an upper limit of about 32K bytes,

so 450 lines would be appropriate for Fidonet environments.



For further details, see the section "Sending Ciphertext Through

E-mail Channels: Radix-64 Format" in the Essential Topics volume.





KEEPBINARY - Keep Binary Ciphertext Files After Decrypting

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



Default setting:  KEEPBINARY = off



When PGP reads a ".asc" file, it recognizes that the file is in

radix-64 format and will convert it back to binary before processing

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

file in binary form.  After further processing to decrypt the ".pgp"

file, the final output file will be in normal plaintext form.



You may want to delete the binary ".pgp" intermediate file, or you

may want PGP to delete it for you automatically.  You can still rerun

PGP on the original ".asc" file.



The configuration parameter KEEPBINARY enables or disables keeping

the intermediate ".pgp" file during decryption.



For further details, see the section "Sending Ciphertext Through

E-mail Channels: Radix-64 Format" in the Essential Topics volume.





COMPRESS - Enable Compression

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



Default setting:  COMPRESS = on



The configuration parameter COMPRESS enables or disables data

compression before encryption.  It is used mainly for debugging PGP. 

Normally, PGP attempts to compress the plaintext before it encrypts

it.  Generally, you should leave this alone and let PGP attempt to

compress the plaintext.





COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed

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



Default setting:  COMPLETES_NEEDED = 1



The configuration parameter COMPLETES_NEEDED specifies the minimum

number of completely trusted introducers required to fully certify a

public key on your public key ring.  This gives you a way of tuning

PGP's skepticism.



For further details, see the section "How Does PGP Keep Track of 

Which Keys are Valid?" in the Essential Topics volume.





MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed

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



Default setting:  MARGINALS_NEEDED = 2



The configuration parameter MARGINALS_NEEDED specifies the minimum

number of marginally trusted introducers required to fully certify a

public key on your public key ring.  This gives you a way of tuning

PGP's skepticism.



For further details, see the section "How Does PGP Keep Track of 

Which Keys are Valid?" in the Essential Topics volume.





CERT_DEPTH - How Deep May Introducers Be Nested

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



Default setting:  CERT_DEPTH = 4



The configuration parameter CERT_DEPTH specifies how many levels deep

you may nest introducers to certify other introducers to certify

public keys on your public key ring.  For example, If CERT_DEPTH is

set to 1, there may only be one layer of introducers below your own

ultimately-trusted key.  If that were the case, you would be required

to directly certify the public keys of all trusted introducers on

your key ring.  If you set CERT_DEPTH to 0, you could have no

introducers at all, and you would have to directly certify each and

every key on your public key ring in order to use it.  The minimum

CERT_DEPTH is 0, the maximum is 8.



For further details, see the section "How Does PGP Keep Track of 

Which Keys are Valid?" in the Essential Topics volume.





BAKRING - Filename for Backup Secret Keyring

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



Default setting:  BAKRING = ""



All of the key certification that PGP does on your public key ring

ultimately depends on your own ultimately-trusted public key (or

keys).  To detect any tampering of your public key ring, PGP must

check that your own key has not been tampered with.  To do this, PGP

must compare your public key against a backup copy of your secret key

on some tamper-resistant media, such as a write-protected floppy

disk.  A secret key contains all the information that your public key

has, plus some secret components.  This means PGP can check your

public key against a backup copy of your secret key.



The configuration parameter BAKRING specifies what pathname to use

for PGP's trusted backup copy of your secret key ring.  On MSDOS, you

could set it to "a:\secring.pgp" to point it at a write-protected

backup copy of your secret key ring on your floppy drive.  This check

is performed only when you execute the PGP -kc option to check your

whole public key ring.



If BAKRING is not defined, PGP will not check your own key against

any backup copy.



For further details, see the sections "How to Protect Public Keys

from Tampering" and "How Does PGP Keep Track of Which Keys are

Valid?" in the Essential Topics volume.





PAGER - Selects Shell Command to Display Plaintext Output

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



Default setting:  PAGER = ""



PGP lets you view the decrypted plaintext output on your screen (like

the Unix-style "more" command), without writing it to a file, if you

use the -m (more) option while decrypting.  This displays the

decrypted plaintext display on your screen one screenful at a time.



If you prefer to use a fancier page display utility, rather than

PGP's built-in one, you can specify the name of a shell command that

PGP will invoke to display your plaintext output file.  The

configuration parameter PAGER specifies the shell command to invoke

to display the file.  For example, on MSDOS systems, you might want

to use the popular shareware program "list.com" to display your

plaintext message.  Assuming you have a copy of "list.com", you may 

set PAGER accordingly:



   PAGER = "list"



However, if the sender specified that this file is for your eyes

only, and may not be written to disk, PGP always uses its own

built-in display function.



For further details, see the section "Displaying Decrypted Plaintext 

on Your Screen".





SHOWPASS - Echo Pass Phrase to User

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



Default setting:  SHOWPASS = off



Normally, PGP does not let you see your pass phrase as you type it

in.  This makes it harder for someone to look over your shoulder

while you type and learn your pass phrase.  But some typing-impaired

people have problems typing their pass phrase without seeing what

they are typing, and they may be typing in the privacy of their own

homes.  So they asked if PGP can be configured to let them see what

they type when they type in their pass phrase.



The configuration parameter SHOWPASS enables PGP to echo your typing 

during pass phrase entry.





TZFIX - Timezone Adjustment

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



Default setting:  TZFIX = 0



PGP provides timestamps for keys and signature certificates in

Greenwich Mean Time (GMT), or Coordinated Universal Time (UTC), which

means the same thing for our purposes.  When PGP asks the system for

the time of day, the system is supposed to provide it in GMT.  



But sometimes, because of improperly configured MSDOS systems, the

system time is returned in US Pacific Standard Time time plus 8

hours.  Sounds weird, doesn't it?  Perhaps because of some sort of US

west-coast jingoism, MSDOS presumes local time is US Pacific time,

and pre-corrects Pacific time to GMT.  This adversely affects the

behavior of the internal MSDOS GMT time function that PGP calls. 

However, if your MSDOS environmental variable TZ is already properly

defined for your timezone, this corrects the misconception MSDOS has

that the whole world lives on the US west coast.  



The configuration parameter TZFIX specifies the number of hours to

add to the system time function to get GMT, for GMT timestamps on

keys and signatures.  If the MSDOS environmental variable TZ is

defined properly, you can leave TZFIX=0.  Unix systems usually

shouldn't need to worry about setting TZFIX at all.  But if you are

using some other obscure operating system that doesn't know about

GMT, you may have to use TZFIX to adjust the system time to GMT. 



On MSDOS systems that do not have TZ defined in the environment, you

should make TZFIX=0 for California, -1 for Colorado, -2 for Chicago,

-3 for New York, -8 for London, -9 for Amsterdam.  In the summer,

TZFIX should be manually decremented from these values.  What a mess.



It would be much cleaner to set your MSDOS environmental variable TZ

in your AUTOEXEC.BAT file, and not use the TZFIX correction.  Then

MSDOS gives you good GMT timestamps, and will handle daylight savings

time adjustments for you.  Here are some sample lines to insert into

AUTOEXEC.BAT, depending on your time zone:



For Los Angeles:  SET TZ=PST8PDT

For Denver:       SET TZ=MST7MDT

For Arizona:      SET TZ=MST7

   (Arizona never uses daylight savings time)

For Chicago:      SET TZ=CST6CDT

For New York:     SET TZ=EST5EDT

For London:       SET TZ=GMT0BST

For Amsterdam:    SET TZ=MET-1DST

For Moscow:       SET TZ=MSK-3MSD

For Aukland:      SET TZ=NZT-13





CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text

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



Default setting:  CLEARSIG = off



Normally, unencrypted PGP signed messages have a signature

certificate prepended in binary form.  To send this through a 7-bit

E-mail channel, radix-64 ASCII armor is applied (see the ARMOR

parameter), rendering the message unreadable to casual human eyes,

even though the message is not actually encrypted.  The recipient

must use PGP to strip the armor off before reading the message.



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 to read the

signed message with human eyes, without the aid of PGP.  Of course,

you still need PGP to actually check the signature.



To enable this feature, set CLEARSIG=ON, and set ARMOR=ON (or use

the -a option), and set TEXTMODE=ON (or use the -t option).  For

example, you can set CLEARSIG directly from the command line:



     pgp -sta +clearsig=on message.txt



This message representation is analogous to the MIC-CLEAR message type

used in Internet Privacy Enhanced Mail (PEM).  It is important to

note that since this method only applies ASCII armor to the binary

signature certificate, and not to the message text itself, there is

some risk that the unarmored message may suffer some accidental

molestation while en route.  This can happen if it passes through

some E-mail gateway that performs character set conversions, or in

some cases extra spaces may be added to or stripped from the ends of

lines.  If this occurs, the signature will fail to verify, which may

give a false indication of intentional tampering.  But since PEM

lives under a similar vulnerability, it seems worth having this

feature despite the risks.



Beginning with PGP version 2.2, trailing blanks are ignored on each

line in calculating the signature for text in CLEARSIG mode.





VERBOSE - Quiet, Normal, or Verbose Messages

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



Default setting:  VERBOSE = 1



VERBOSE may be set to 0, 1, or 2, depending on how much detail you

want to see from PGP diagnostic messages.  The settings are:



0 - Display messages only if there is a problem.  Unix fans wanted

this "quiet mode" setting.



1 - Normal default setting.  Displays a reasonable amount of detail

in diagnostic or advisory messages.



2 - Displays maximum information, usually to help diagnose problems

in PGP.  Not recommended for normal use.  Besides, PGP doesn't have

any problems, right?

 



INTERACTIVE - Ask for Confirmation for Key Adds

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



Default Setting:  INTERACTIVE = off



Enabling this mode will mean that if you add a key file containing

multiple keys to your key ring, PGP will ask for confirmation for

each key before adding it to your key ring.







Protecting Against Bogus Timestamps

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



A somewhat obscure vulnerability of PGP involves dishonest users

creating bogus timestamps on their own public key certificates and

signatures.  You can skip over this section if you are a casual user

and aren't deeply into obscure public key protocols.



There's nothing to stop a dishonest user from altering the date and

time setting of his own system's clock, and generating his own public

key certificates and signatures that appear to have been created at a

different time.  He can make it appear that he signed something

earlier or later than he actually did, or that his public/secret key

pair was created earlier or later.  This may have some legal or

financial benefit to him, for example by creating some kind of 

loophole that might allow him to repudiate a signature.



A remedy for this could involve some trustworthy Certifying Authority

or notary that would create notarized signatures with a trustworthy

timestamp.  This might not necessarily require a centralized

authority.  Perhaps any trusted introducer or disinterested party

could serve this function, the same way real notary publics do now. 

A public key certificate could be signed by the notary, and the

trusted timestamp in the notary's signature would have some legal

significance.  The notary could enter the signed certificate into a

special certificate log controlled by the notary.  Anyone can read

this log. 



The notary could also sign other people's signatures, creating a

signature certificate of a signature certificate.  This would serve

as a witness to the signature the same way real notaries do now with

paper.  Again, the notary could enter the detached signature

certificate (without the actual whole document that was signed) into

a log controlled by the notary.  The notary's signature would have a

trusted timestamp, which might have greater credibility than the

timestamp in the original signature.  A signature becomes "legal" if

it is signed and logged by the notary.



This problem of certifying signatures with notaries and trusted

timestamps warrants further discussion.  This can of worms will not

be fully covered here now.  There is a good treatment of this topic

in Denning's 1983 article in IEEE Computer (see references).  There

is much more detail to be worked out in these various certifying

schemes.  This will develop further as PGP usage increases and other

public key products develop their own certifying schemes.





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.bin".  It too can be kept in whatever directory

is indicated by the PGPPATH environmental variable.  If this random

seed file does not exist, it is 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 by mixing

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



This random seed file should be at least slightly protected from

disclosure, to reduce the risk of an attacker deriving your next or

previous session keys.  The attacker would have a very hard time

getting anything useful from capturing this random seed file, because

the file is cryptographically laundered before and after each use. 

Nonetheless, it seems prudent to at least try to keep it from falling

into the wrong hands.



If you feel uneasy about trusting any algorithmically derived random

number source however strong, keep in mind that you already trust the

strength of the same conventional cipher to protect your messages. 

If it's strong enough for that, then it should be strong enough to

use as a source of random numbers for temporary session keys.  Note

that PGP still uses truly random numbers from physical sources

(mainly keyboard timings) to generate long-term public/secret key

pairs.







PGP's Conventional Encryption Algorithm

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



As described earlier, PGP "bootstraps" into a conventional single-key

encryption algorithm by using a public key algorithm to encipher the

conventional session key and then switching to fast conventional

cryptography.  So let's talk about this conventional encryption

algorithm.  It isn't the DES.



The Federal Data Encryption Standard (DES) is a good algorithm for

most commercial applications.  However, the Government does not trust

the DES to protect its own classified data.  Perhaps this is because

the DES key length is 56 bits, short enough for a brute force attack

with a special purpose machine built from massive numbers of DES

chips.  Also, Biham and Shamir have had some success recently on

attacking the full 16-round DES.



PGP does not use the DES as its conventional single-key algorithm to

encrypt messages.  Instead, PGP uses a different conventional

single-key block encryption algorithm, called IDEA(tm).  A future

version of PGP may support the DES as an option, if enough users

ask for it.  But I suspect IDEA is better than DES.



For the cryptographically curious, the IDEA cipher has a 64-bit block

size for the plaintext and the ciphertext.  It uses a key size of 128

bits.  It is based on the design concept of "mixing operations from

different algebraic groups".  It runs much faster in software than

the DES.  Like the DES, it can be used in cipher feedback (CFB) and

cipher block chaining (CBC) modes.  PGP uses it in 64-bit CFB mode.



The IPES/IDEA block cipher was developed at ETH in Zurich by James L.

Massey and Xuejia Lai, and published in 1990.  This is not a 

"home-grown" algorithm.  Its designers have a distinguished

reputation in the cryptologic community.  Early published papers on

the algorithm called it IPES (Improved Proposed Encryption Standard),

but they later changed the name to IDEA (International Data

Encryption Algorithm).  So far, IDEA has resisted attack much better

than other ciphers such as FEAL, REDOC-II, LOKI, Snefru and Khafre. 

And preliminary evidence suggests that IDEA may be more resistant

than the DES to Biham & Shamir's highly successful differential

cryptanalysis attack.  Biham and Shamir have been examining the IDEA

cipher for weaknesses, without success.  Academic cryptanalyst groups

in Belgium, England, and Germany are also attempting to attack it, as

well as the military services from several European countries.  As

this new cipher continues to attract attack efforts from the most

formidable quarters of the cryptanalytic world, confidence in IDEA is

growing with the passage of time.



A famous hockey player once said, "I try to skate to where I think

the puck will be."  A lot of people are starting to feel that the

days are numbered for the DES.  I'm skating toward IDEA.



It is not ergonomically practical to use pure RSA with large keys to

encrypt and decrypt long messages.  Absolutely no one does it that way

in the real world.  But perhaps you are concerned that the whole

package is weakened if we use a hybrid public-key and conventional

scheme just to speed things up.  After all, a chain is only as strong

as its weakest link.  Many people less experienced in cryptography

mistakenly believe that RSA is intrinsically stronger than any

conventional cipher.  It's not.  RSA can be made weak by using weak

keys, and conventional ciphers can be made strong by choosing good

algorithms.  It's usually difficult to tell exactly how strong a good

conventional cipher is, without actually cracking it.  A really good

conventional cipher might possibly be harder to crack than even a

"military grade" RSA key.  The attraction of public key cryptography

is not because it is intrinsically stronger than a conventional

cipher-- its appeal is because it helps you manage keys more

conveniently.







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 takes extra time to compress the plaintext, but 

from a security point of view it seems worth it, 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.  Or you can use ZIP,

a PKZIP-compatible freeware compression utility on Unix and other

systems, available from Jean-Loup Gailly.  There is some advantage in

using PKZIP or ZIP in certain cases, because unlike PGP's built-in

compression algorithm, PKZIP and ZIP have the nice feature of

compressing multiple files into a single compressed file, which is

reconstituted again into separate files when decompressed.  PGP will

not try to compress a plaintext file that has already been

compressed.  After decrypting, the recipient can decompress the

plaintext with PKUNZIP.  If the decrypted plaintext is a PKZIP

compressed file, PGP automatically recognizes this and advises the 

recipient that the decrypted plaintext appears to be a PKZIP file.



For the technically curious readers, the current version of PGP uses

the freeware ZIP compression routines written by Jean-loup Gailly,

Mark Adler, and Richard B. Wales.  This ZIP software uses

functionally-equivalent compression algorithms as those used by

PKWare's new PKZIP 2.0.  This ZIP compression software was selected

for PGP mainly because of its free portable C source code

availability, and because it has a really good compression ratio, and

because it's fast.  



Peter Gutmann has also written a nice compression utility called

HPACK, available for free from many Internet FTP sites.  It encrypts

the compressed archives, using PGP data formats and key rings.  He

wanted me to mention that here.







Message Digests and Digital Signatures

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



To create a digital signature, PGP encrypts with your secret key. 

But PGP doesn't actually encrypt your entire message with your secret

key-- that would take too long.  Instead, PGP encrypts a "message

digest".  



The message digest is a compact (128 bit) "distillate" of your

message, similar in concept to a checksum.  You can also think of it

as a "fingerprint" of the message.  The message digest "represents"

your message, such that if the message were altered in any way, a

different message digest would be computed from it.  This makes it

possible to detect any changes made to the message by a forger.  A

message digest is computed using a cryptographically strong one-way

hash function of the message.  It would be computationally infeasible

for an attacker to devise a substitute message that would produce an

identical message digest.  In that respect, a message digest is much

better than a checksum, because it is easy to devise a different

message that would produce the same checksum.  But like a checksum,

you can't derive the original message from its message digest.  



A message digest alone is not enough to authenticate a message.  The

message digest algorithm is publicly known, and does not require

knowledge of any secret keys to calculate.  If all we did was attach

a message digest to a message, then a forger could alter a message

and simply attach a new message digest calculated from the new

altered message.  To provide real authentication, the sender has to

encrypt (sign) the message digest with his secret key.  



A message digest is calculated from the message by the sender.  The

sender's secret key is used to encrypt the message digest and an

electronic timestamp, forming a digital signature, or signature

certificate.  The sender sends the digital signature along with the

message.  The receiver receives the message and the digital

signature, and recovers the original message digest from the digital

signature by decrypting it with the sender's public key.  The

receiver computes a new message digest from the message, and checks

to see if it matches the one recovered from the digital signature.  If

it matches, then that proves the message was not altered, and it came

from the sender who owns the public key used to check the signature.



A potential forger would have to either produce an altered message

that produces an identical message digest (which is infeasible), or

he would have to create a new digital signature from a different

message digest (also infeasible, without knowing the true sender's

secret key).



Digital signatures prove who sent the message, and that the message

was not altered either by error or design.  It also provides

non-repudiation, which means the sender cannot easily disavow his

signature on the message.



Using message digests to form digital signatures has other advantages

besides being faster than directly signing the entire actual message

with the secret key.  Using message digests allows signatures to be

of a standard small fixed size, regardless of the size of the actual

message.  It also allows the software to check the message integrity

automatically, in a manner similar to using checksums.  And it allows

signatures to be stored separately from messages, perhaps even in a

public archive, without revealing sensitive information about the

actual messages, because no one can derive any message content from a

message digest.



The message digest algorithm used here is the MD5 Message Digest

Algorithm, placed in the public domain by RSA Data Security, Inc.

MD5's designer, Ronald Rivest, writes this about MD5:



"It is conjectured that the difficulty of coming up with two messages

having the same message digest is on the order of 2^64 operations,

and that the difficulty of coming up with any message having a given

message digest is on the order of 2^128 operations.  The MD5

algorithm has been carefully scrutinized for weaknesses.  It is,

however, a relatively new algorithm and further security analysis is

of course justified, as is the case with any new proposal of this

sort.  The level of security provided by MD5 should be sufficient for

implementing very high security hybrid digital signature schemes

based on MD5 and the RSA public-key cryptosystem."







Compatibility with Previous Versions of PGP

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



I'm sorry, PGP version 2.0 is not compatible with PGP version 1.0.  

If you have keys generated with version 1.0, you will have to

generate new keys to use with this version.  This version of PGP uses

all new algorithms for conventional cryptography, compression, and

message digests, as well as using a much better approach to key

management.  There were just too many changes to make it compatible

with the old format messages, signatures, and keys.  Perhaps we could

have provided a special conversion utility to convert old keys into

new keys, but we were all tired and wanted to get the new release out

the door.  Besides, converting the old keys into new keys would

probably create more problems than it would solve, because we have

changed to a new recommended uniform style for the user ID that

includes the full name and E-mail address in a particular syntax.



There is compatibility from version 2.0 to higher versions.  Because

new features are added, older versions may not always be able to

handle some files created with newer versions. 



We made some effort to design the internal data structures of this

version of PGP to be adaptable to future changes, so that hopefully

you will not be required to discard and regenerate your keys in future

versions.





Vulnerabilities

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



No data security system is impenetrable.  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 more

valuable to your attacker than the cost of the attack.  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 also

gets your secret key file, they can read your messages and make

signatures in your name.  



Don't use obvious passwords that can be easily guessed, such as the

names of your kids or spouse.  If you make your pass phrase a single

word, it can be easily guessed by having a computer try all the words

in the dictionary until it finds your password.  That's why a pass

phrase is so much better than a password.  A more sophisticated

attacker may have his computer scan a book of famous quotations to

find your pass phrase.  An easy to remember but hard to guess pass

phrase can be easily constructed by some creatively nonsensical

sayings or very obscure literary quotes.  



For further details, see the section "How to Protect Secret Keys from

Disclosure" in the Essential Topics volume of the PGP User's Guide.





Public Key Tampering

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



A major vulnerability exists if public keys are tampered with.  This

may be the most crucially important vulnerability of a public key

cryptosystem, in part because most novices don't immediately

recognize it.  The importance of this vulnerability, and appropriate

hygienic countermeasures, are detailed in the section "How to Protect

Public Keys from Tampering" in the Essential Topics volume.    



To summarize:  When you use someone's public ke