home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-07-23 | 98.4 KB | 2,219 lines |
- 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 key, make certain it has
- not been tampered with. A new public key from someone else should be
- trusted only if you got it directly from its owner, or if it has been
- signed by someone you trust. Make sure no one else can tamper with
- your own public key ring. Maintain physical control of both your
- public key ring and your secret key ring, preferably on your own
- personal computer rather than on a remote timesharing system. Keep a
- backup copy of both key rings.
-
-
- "Not Quite Deleted" Files
- -------------------------
-
- Another potential security problem is caused by how most operating
- systems delete files. When you encrypt a file and then delete the
- original plaintext file, the operating system doesn't actually
- physically erase the data. It merely marks those disk blocks as
- deleted, allowing the space to be reused later. It's sort of like
- discarding sensitive paper documents in the paper recycling bin
- instead of the paper shredder. The disk blocks still contain the
- original sensitive data you wanted to erase, and will probably
- eventually be overwritten by new data at some point in the future.
- If an attacker reads these deleted disk blocks soon after they have
- been deallocated, he could recover your plaintext.
-
- In fact this could even happen accidentally, if for some reason
- something went wrong with the disk and some files were accidentally
- deleted or corrupted. A disk recovery program may be run to recover
- the damaged files, but this often means some previously deleted files
- are resurrected along with everything else. Your confidential files
- that you thought were gone forever could then reappear and be
- inspected by whomever is attempting to recover your damaged disk.
- Even while you are creating the original message with a word
- processor or text editor, the editor may be creating multiple
- temporary copies of your text on the disk, just because of its
- internal workings. These temporary copies of your text are deleted
- by the word processor when it's done, but these sensitive fragments
- are still on your disk somewhere.
-
- Let me tell you a true horror story. I had a friend, married with
- young children, who once had a brief and not very serious affair.
- She wrote a letter to her lover on her word processor, and deleted
- the letter after she sent it. Later, after the affair was over, the
- floppy disk got damaged somehow and she had to recover it because it
- contained other important documents. She asked her husband to
- salvage the disk, which seemed perfectly safe because she knew she
- had deleted the incriminating letter. Her husband ran a commercial
- disk recovery software package to salvage the files. It recovered
- the files alright, including the deleted letter. He read it, which
- set off a tragic chain of events.
-
- The only way to prevent the plaintext from reappearing is to somehow
- cause the deleted plaintext files to be overwritten. Unless you know
- for sure that all the deleted disk blocks will soon be reused, you
- must take positive steps to overwrite the plaintext file, and also
- any fragments of it on the disk left by your word processor. You can
- overwrite the original plaintext file after encryption by using the
- PGP -w (wipe) option. You can take care of any fragments of the
- plaintext left on the disk by using any of the disk utilities
- available that can overwrite all of the unused blocks on a disk. For
- example, the Norton Utilities for MSDOS can do this.
-
- Even if you overwrite the plaintext data on the disk, it may still be
- possible for a resourceful and determined attacker to recover the
- data. Faint magnetic traces of the original data remain on the disk
- after it has been overwritten. Special sophisticated disk recovery
- hardware can sometimes be used to recover the data.
-
-
- Viruses and Trojan Horses
- -------------------------
-
- Another attack could involve a specially-tailored hostile computer
- virus or worm that might infect PGP or your operating system. This
- hypothetical virus could be designed to capture your pass phrase or
- secret key or deciphered messages, and covertly write the captured
- information to a file or send it through a network to the virus's
- owner. Or it might alter PGP's behavior so that signatures are not
- properly checked. This attack is cheaper than cryptanalytic attacks.
-
- Defending against this falls under the category of defending against
- viral infection generally. There are some moderately capable
- anti-viral products commercially available, and there are hygienic
- procedures to follow that can greatly reduce the chances of viral
- infection. A complete treatment of anti-viral and anti-worm
- countermeasures is beyond the scope of this document. PGP has no
- defenses against viruses, and assumes your own personal computer is a
- trustworthy execution environment. If such a virus or worm actually
- appeared, hopefully word would soon get around warning everyone.
-
- Another similar attack involves someone creating a clever imitation
- of PGP that behaves like PGP in most respects, but doesn't work the
- way it's supposed to. For example, it might be deliberately crippled
- to not check signatures properly, allowing bogus key certificates to
- be accepted. This "Trojan horse" version of PGP is not hard for an
- attacker to create, because PGP source code is widely available, so
- anyone could modify the source code and produce a lobotomized zombie
- imitation PGP that looks real but does the bidding of its diabolical
- master. This Trojan horse version of PGP could then be widely
- circulated, claiming to be from me. How insidious.
-
- You should make an effort to get your copy of PGP from a reliable
- source, whatever that means. Or perhaps from more than one
- independent source, and compare them with a file comparison utility.
-
- There are other ways to check PGP for tampering, using digital
- signatures. If someone you trust signs the executable version of
- PGP, vouching for the fact that it has not been infected or tampered
- with, you can be reasonably sure that you have a good copy. You
- could use an earlier trusted version of PGP to check the signature on
- a later suspect version of PGP. But this will not help at all if
- your operating system is infected, nor will it detect if your
- original copy of PGP.EXE has been maliciously altered in such a way
- as to compromise its own ability to check signatures. This test also
- assumes that you have a good trusted copy of the public key that you
- use to check the signature on the PGP executable.
-
-
- Physical Security Breach
- ------------------------
-
- A physical security breach may allow someone to physically acquire
- your plaintext files or printed messages. A determined opponent
- might accomplish this through burglary, trash-picking, unreasonable
- search and seizure, or bribery, blackmail or infiltration of your
- staff. Some of these attacks may be especially feasible against
- grassroots political organizations that depend on a largely volunteer
- staff. It has been widely reported in the press that the FBI's
- COINTELPRO program used burglary, infiltration, and illegal bugging
- against antiwar and civil rights groups. And look what happened at
- the Watergate Hotel.
-
- Don't be lulled into a false sense of security just because you have
- a cryptographic tool. Cryptographic techniques protect data only
- while it's encrypted-- direct physical security violations can still
- compromise plaintext data or written or spoken information.
-
- This kind of attack is cheaper than cryptanalytic attacks on PGP.
-
-
- Tempest Attacks
- ---------------
-
- Another kind of attack that has been used by well-equipped opponents
- involves the remote detection of the electromagnetic signals from
- your computer. This expensive and somewhat labor-intensive attack is
- probably still cheaper than direct cryptanalytic attacks. An
- appropriately instrumented van can park near your office and remotely
- pick up all of your keystrokes and messages displayed on your
- computer video screen. This would compromise all of your passwords,
- messages, etc. This attack can be thwarted by properly shielding all
- of your computer equipment and network cabling so that it does not
- emit these signals. This shielding technology is known as "Tempest",
- and is used by some Government agencies and defense contractors.
- There are hardware vendors who supply Tempest shielding commercially,
- although it may be subject to some kind of Government licensing. Now
- why do you suppose the Government would restrict access to Tempest
- shielding?
-
-
- Exposure on Multi-user Systems
- ------------------------------
-
- PGP was originally designed for a single-user MSDOS machine under
- your direct physical control. I run PGP at home on my own PC, and
- unless someone breaks into my house or monitors my electromagnetic
- emissions, they probably can't see my plaintext files or secret keys.
-
- But now PGP also runs on multi-user systems such as Unix and VAX/VMS.
- On multi-user systems, there are much greater risks of your plaintext
- or keys or passwords being exposed. The Unix system administrator or
- a clever intruder can read your plaintext files, or perhaps even use
- special software to covertly monitor your keystrokes or read what's
- on your screen. On a Unix system, any other user can read your
- environment information remotely by simply using the Unix "ps"
- command. Similar problems exist for MSDOS machines connected on a
- local area network. The actual security risk is dependent on your
- particular situation. Some multi-user systems may be safe because
- all the users are trusted, or because they have system security
- measures that are safe enough to withstand the attacks available to
- the intruders, or because there just aren't any sufficiently
- interested intruders. Some Unix systems are safe because they are
- only used by one user-- there are even some notebook computers
- running Unix. It would be unreasonable to simply exclude PGP from
- running on all Unix systems.
-
- PGP is not designed to protect your data while it is in plaintext
- form on a compromised system. Nor can it prevent an intruder from
- using sophisticated measures to read your secret key while it is
- being used. You will just have to recognize these risks on
- multi-user systems, and adjust your expectations and behavior
- accordingly. Perhaps your situation is such that you should consider
- only running PGP on an isolated single-user system under your direct
- physical control. That's what I do, and that's what I recommend.
-
-
- Traffic Analysis
- ----------------
-
- Even if the attacker cannot read the contents of your encrypted
- messages, he may be able to infer at least some useful information by
- observing where the messages come from and where they are going, the
- size of the messages, and the time of day the messages are sent.
- This is analogous to the attacker looking at your long distance phone
- bill to see who you called and when and for how long, even though the
- actual content of your calls is unknown to the attacker. This is
- called traffic analysis. PGP alone does not protect against traffic
- analysis. Solving this problem would require specialized
- communication protocols designed to reduce exposure to traffic
- analysis in your communication environment, possibly with some
- cryptographic assistance.
-
-
- Cryptanalysis
- -------------
-
- An expensive and formidable cryptanalytic attack could possibly be
- mounted by someone with vast supercomputer resources, such as a
- Government intelligence agency. They might crack your RSA key by
- using some new secret factoring breakthrough. Perhaps so, but it is
- noteworthy that the US Government trusts the RSA algorithm enough in
- some cases to use it to protect its own nuclear weapons, according to
- Ron Rivest. And civilian academia has been intensively attacking it
- without success since 1978.
-
- Perhaps the Government has some classified methods of cracking the
- IDEA(tm) conventional encryption algorithm used in PGP. This is
- every cryptographer's worst nightmare. There can be no absolute
- security guarantees in practical cryptographic implementations.
-
- Still, some optimism seems justified. The IDEA algorithm's designers
- are among the best cryptographers in Europe. It has had extensive
- security analysis and peer review from some of the best cryptanalysts
- in the unclassified world. It appears to have some design advantages
- over the DES in withstanding differential cryptanalysis, which has
- been used to crack the DES.
-
- Besides, even if this algorithm has some subtle unknown weaknesses,
- PGP compresses the plaintext before encryption, which should greatly
- reduce those weaknesses. The computational workload to crack it is
- likely to be much more expensive than the value of the message.
-
- If your situation justifies worrying about very formidable attacks of
- this caliber, then perhaps you should contact a data security
- consultant for some customized data security approaches tailored to
- your special needs. Boulder Software Engineering, whose address and
- phone are given at the end of this document, can provide such
- services.
-
-
- In summary, without good cryptographic protection of your data
- communications, it may have been practically effortless and perhaps
- even routine for an opponent to intercept your messages, especially
- those sent through a modem or E-mail system. If you use PGP and
- follow reasonable precautions, the attacker will have to expend far
- more effort and expense to violate your privacy.
-
- If you protect yourself against the simplest attacks, and you feel
- confident that your privacy is not going to be violated by a
- determined and highly resourceful attacker, then you'll probably be
- safe using PGP. PGP gives you Pretty Good Privacy.
-
-
- Legal Issues
- ============
-
-
- Trademarks, Copyrights, and Warranties
- --------------------------------------
-
- "Pretty Good Privacy", "Phil's Pretty Good Software", and the "Pretty
- Good" label for computer software and hardware products are all
- trademarks of Philip Zimmermann and Phil's Pretty Good Software. PGP
- is (c) Copyright Philip R. Zimmermann, 1990-1993. Philip Zimmermann
- also holds the copyright for the PGP User's Manual, as well as any
- foreign language translations of the manual or the software.
-
- The author assumes no liability for damages resulting from the use of
- this software, even if the damage results from defects in this
- software, and makes no representations concerning the merchantability
- of this software or its suitability for any specific purpose. It is
- provided "as is" without express or implied warranty of any kind.
-
-
- Patent Rights on the Algorithms
- -------------------------------
-
- The RSA public key cryptosystem was developed at MIT, which holds a
- patent on it (U.S. patent #4,405,829, issued 20 Sep 1983). A company
- in California called Public Key Partners (PKP) holds the exclusive
- commercial license to sell and sub-license the RSA public key
- cryptosystem.
-
- PKP has not granted a patent license for anyone to use their RSA
- algorithm in PGP. The author of this software implementation of the
- RSA algorithm is providing this implementation for educational use
- only. Licensing this algorithm from PKP is the responsibility of
- you, the user, not the author. The author assumes no liability for
- any patent infringement that may result from executing the RSA
- algorithm on the user's computer without a license from the RSA
- patent holder.
-
- Non-US users should note that the RSA patent does not apply outside
- the US, and there is no RSA patent in any other country. Federal
- agencies may use it because the Government paid for the development
- of RSA with grants from the National Science Foundation and the
- Navy. And companies that have already licensed the patent from PKP
- may be able to use PGP, depending on the terms of their license.
-
- I wrote my PGP software from scratch, with my own independently
- developed implementation of the RSA algorithm. Before publishing
- PGP, I got a formal written legal opinion from a patent attorney with
- extensive experience in software patents. I'm convinced that
- publishing PGP the way I did does not violate patent law.
-
- Not only did PKP acquire the exclusive patent rights for the RSA
- cryptosystem, but they also acquired the exclusive rights to three
- other patents covering other public key schemes invented by others at
- Stanford University, also developed with Federal funding. This
- essentially gives one company a legal lock in the USA on nearly all
- practical public key cryptosystems. They even appear to be claiming
- patent rights on the very concept of public key cryptography,
- regardless of what clever new original algorithms are independently
- invented by others. I find such a comprehensive monopoly troubling,
- because I think public key cryptography is destined to become a
- crucial technology in the protection of our civil liberties and
- privacy in our increasingly connected society. At the very least,
- it places these vital tools at risk by affording to the Government
- a single pressure point of influence.
-
- There are negotiations under way with RSA Data Security Inc (RSADSI),
- a sister company to PKP, to legalize PGP in the US. This would be
- accomplished by integrating RSAREF into PGP. RSAREF is a subroutine
- package from RSADSI that implements the RSA algorithm. The RSAREF
- subroutines would have to be used instead of PGP's original
- subroutines to implement the RSA functions in PGP. There are some
- technical obstacles to getting this done, but a solution may be found
- if the negotiations with RSADSI proceed favorably. If RSAREF is
- integrated into PGP, it will be licensed by RSADSI for noncommercial
- usage in the US. Foreign versions of PGP will not use RSAREF, but
- will continue to use PGP's original faster subroutine library to do
- the RSA calculations. RSADSI may require PGP's name to change in
- order to make all this possible. Stay tuned.
-
- It appears certain that there will be future releases of PGP,
- regardless of the outcome of licensing problems with Public Key
- Partners. If PKP does not license PGP, then future releases of PGP
- will likely not come from me. There are countless fans of PGP outside
- the US, and many of them are software engineers who want to improve
- PGP and promote it, regardless of what I do. The second release of
- PGP was a joint effort of an international team of software
- engineers, implementing enhancements to the original PGP with design
- guidance from me. It was released by Branko Lankester in The
- Netherlands and Peter Gutmann in New Zealand, out of reach of US
- patent law. Although released only in Europe and New Zealand, it
- spontaneously spread to the USA without help from me or the PGP
- development team.
-
- The IDEA(tm) conventional block cipher used by PGP is covered by a
- patent in Europe, held by ETH and a Swiss company called Ascom-Tech
- AG. The patent number is PCT/CH91/00117. International patents are
- pending. IDEA(tm) is a trademark of Ascom-Tech AG. There is no
- license fee required for noncommercial use of IDEA. Ascom Tech AG
- has granted permission for PGP to use the IDEA cipher, and places no
- restrictions on using PGP for any purpose, including commercial use.
- You may not extract the IDEA cipher from PGP and put it in another
- commercial product without a license. Commercial users of IDEA may
- obtain licensing details from Dieter Profos, Ascom Tech AG, Solothurn
- Lab, Postfach 151, 4502 Solothurn, Switzerland, Tel +41 65 242885,
- Fax +41 65 235761.
-
- The ZIP compression routines in PGP come from freeware source code,
- with the author's permission. I'm not aware of any patents on the
- compression algorithms used in the ZIP routines, but you're welcome to
- check into that question yourself.
-
-
- Licensing and Distribution
- --------------------------
-
- In the USA PKP controls, through US patent law, the licensing of the
- RSA algorithm. But I have no objection to anyone freely using or
- distributing my PGP software, without payment of fees to me. You must
- keep the copyright notices on PGP and keep this documentation with
- it. However, if you live in the USA, this may not satisfy any legal
- obligations you may have to PKP for using the RSA algorithm as
- mentioned above.
-
- PGP is not shareware, it's freeware. Forbidden freeware. Published
- as a community service. Giving PGP away for free will encourage far
- more people to use it, which hopefully will have a greater social
- impact. This could lead to widespread awareness and use of the RSA
- public key cryptosystem.
-
- All the source code for PGP is available for free under the "Copyleft"
- General Public License from the Free Software Foundation (FSF). A
- copy of the FSF General Public License is included in the source
- release package of PGP.
-
- Regardless of and perhaps contrary to some provisions of the FSF
- General Public License, the following terms apply:
-
- 1) Written discussions of PGP in magazines or books may include
- fragments of PGP source code and documentation, without
- restrictions.
-
- 2) Although the FSF General Public License allows non-proprietary
- derivative products, it prohibits proprietary derivative products.
- Despite this, I may grant you a special license if you want to derive
- a proprietary commercial product from some of PGP's parts. There may
- or may not be a fee, depending on the circumstances. Retaining my
- copyright notice and attribution might suffice in some cases. Give
- me a call and we'll discuss it. I'm real easy to please. Any such
- license would not free you of any patent licensing requirements.
-
- Feel free to disseminate the complete PGP release package as widely
- as possible. Give it to all your friends. If you have access to any
- electronic Bulletin Boards Systems, please upload the complete PGP
- executable object release package to as many BBS's as possible. You
- may disseminate the PGP source release package too, if you've got
- it. The PGP version 2.3 executable object release package for MSDOS
- contains the PGP executable software, documentation, sample key rings
- including my own public key, and signatures for the software and this
- manual, all in one PKZIP compressed file called pgp22.zip. The PGP
- source release package for MSDOS contains all the C source files in
- one PKZIP compressed file called pgp22src.zip. The filename for the
- release package is derived from the version number of the release.
-
- You may obtain free copies or updates to PGP from thousands of BBS's
- worldwide or from other public sources such as Internet FTP sites.
- Don't ask me for a copy directly from me, since I'd rather avoid
- further legal problems with PKP at this time. I might be able to
- tell you where you can get it, however.
-
- After all this work I have to admit I wouldn't mind getting some fan
- mail for PGP, to gauge its popularity. Let me know what you think
- about it and how many of your friends use it. Bug reports and
- suggestions for enhancing PGP are welcome, too. Perhaps a future PGP
- release will reflect your suggestions.
-
- This project has not been funded and the project has nearly eaten me
- alive. This means you can't count on a reply to your mail, unless
- you only need a short written reply and you include a stamped
- self-addressed envelope. But I do reply to E-mail. Please keep it in
- English, as my foreign language skills are weak. If you call and I'm
- not in, it's best to just try again later. I usually don't return
- long distance phone calls, unless you leave a message that I can call
- you collect. If you need any significant amount of my time, I am
- available on a paid consulting basis, and I do return those calls.
-
- The most inconvenient mail I get is for some well-intentioned person
- to send me a few dollars asking me for a copy of PGP. I don't send
- it to them because I'd rather avoid any legal problems with PKP. Or
- worse, sometimes these requests are from foreign countries, and I
- would be risking a violation of US cryptographic export control
- laws. Even if there were no legal hassles involved in sending PGP to
- them, they usually don't send enough money to make it worth my time.
- I'm just not set up as a low cost low volume mail order business. I
- can't just ignore the request and keep the money, because they
- probably regard the money as a fee for me to fulfill their request.
- If I return the money, I might have to get in my car and drive down
- to the post office and buy some postage stamps, because these
- requests rarely include a stamped self-addressed envelope. And I
- have to take the time to write a polite reply that I can't do it. If
- I postpone the reply and set the letter down on my desk, it might be
- buried within minutes and won't see the light of day again for
- months. Multiply these minor inconveniences by the number of
- requests I get, and you can see the problem. Isn't it enough that
- the software is free? It would be nicer if people could try to get
- PGP from any of the myriad other sources. If you don't have a modem,
- ask a friend to get it for you. If you can't find it yourself, I
- don't mind answering a quick phone call.
-
- If anyone wants to volunteer to improve PGP, please let me know. It
- could certainly use some more work. Some features were deferred to
- get it out the door. A number of PGP users have since donated their
- time to port PGP to Unix on Sun SPARCstations, to Ultrix, to VAX/VMS,
- to OS/2, to the Amiga, and to the Atari ST. Perhaps you can help
- port it to some new environments. But please let me know if you plan
- to port or add enhancements to PGP, to avoid duplication of effort,
- and to avoid starting with an obsolete version of the source code.
-
- Because so many foreign language translations of PGP have been
- produced, most of them are not distributed with the regular PGP
- release package because it would require too much disk space.
- Separate language translation "kits" are available from a number of
- independent sources, and are sometimes available separately from the
- same distribution centers that carry the regular PGP release
- software. These kits include translated versions of the file
- LANGUAGE.TXT, PGP.HLP, and the PGP User's Guide. If you want to
- produce a translation for your own native language, contact me first
- to get the latest information and standard guidelines, and to find
- out if it's been translated to your language already. Colin Plumb
- (colin@nyx.cs.du.edu) maintains a comprehensive collection of foreign
- language kits from other translators.
-
- Future versions of PGP may have to change the data formats for
- messages, signatures, keys and key rings, in order to provide
- important new features. This may cause backward compatibility
- problems with this version of PGP. Future releases may provide
- conversion utilities to convert old keys, but you may have to dispose
- of old messages created with the old PGP.
-
- If you have access to the Internet, watch for announcements of new
- releases of PGP on the Internet newsgroups "sci.crypt" and PGP's own
- newsgroup, "alt.security.pgp". There is also an interest group
- mailing list called info-pgp, which is intended for users without
- access to the "alt.security.pgp" newsgroup. Info-pgp is moderated by
- Hugh Miller, and you may subscribe to it by writing him a letter at
- info-pgp-request@lucpul.it.luc.edu. Include your name and Internet
- address. If you want to know where to get PGP, Hugh can send you a
- list of Internet FTP sites and BBS phone numbers. Hugh may also be
- reached at hmiller@lucpul.it.luc.edu.
-
-
-
- Export Controls
- ---------------
-
- The Government has made it illegal in many cases to export good
- cryptographic technology, and that may include PGP. They regard this
- kind of software as munitions. This is determined by volatile State
- Department policies, not fixed laws. I will not export this software
- out of the US or Canada in cases when it is illegal to do so under US
- State Department policies, and I assume no responsibility for other
- people exporting it on their own.
-
- If you live outside the US or Canada, I advise you not to violate US
- State Department policies by getting PGP from a US source. Since
- thousands of domestic users got it after its initial publication, it
- somehow leaked out of the US and spread itself widely abroad, like
- dandelion seeds blowing in the wind. If PGP has already found its
- way into your country, then I don't think you're violating US export
- law if you pick it up from a source outside of the US.
-
- It seems to some legal observers I've talked with, that the framers of
- the US export controls never envisioned that they would ever apply to
- cryptographic freeware that has been published and scattered to the
- winds. It's hard to imagine a US attorney trying to build a real
- case against someone for the "export" of software published freely in
- the US. As far as anyone I've talked to knows, it's never been done,
- despite numerous examples of export violations. I'm not a lawyer and
- I'm not giving you legal advice-- I'm just trying to point out what
- seems like common sense.
-
- Starting with PGP version 2.0, the release point of the software has
- been outside the US, on publicly-accessible computers in Europe.
- Each release is electronically sent back into the US and posted on
- publicly-accessible computers in the US by PGP privacy activists in
- foreign countries. There are some restrictions in the US regarding
- the import of munitions, but I'm not aware of any cases where this
- was ever enforced for importing cryptographic software into the US.
- I imagine that a legal action of that type would be quite a spectacle
- of controversy.
-
- Some foreign governments impose serious penalties on anyone inside
- their country for merely using encrypted communications. In some
- countries they might even shoot you for that. But if you live in
- that kind of country, perhaps you need PGP even more.
-
-
-
- Computer-Related Political Groups
- =================================
-
- PGP is a very political piece of software. It seems appropriate to
- mention here some computer-related activist groups. Full details on
- these groups, and how to join them, is provided in a separate
- document file in the PGP release package.
-
- The Electronic Frontier Foundation (EFF) was founded in July, 1990,
- to assure freedom of expression in digital media, with a particular
- emphasis on applying the principles embodied in the US Constitution
- and the Bill of Rights to computer-based communication. They can be
- reached in Washington DC, at (202) 347-5400. Internet E-mail address:
- eff@eff.org.
-
- Computer Professionals For Social Responsibility (CPSR) empowers
- computer professionals and computer users to advocate for the
- responsible use of information technology and empowers all who use
- computer technology to participate in public policy debates on the
- impacts of computers on society. They can be reached at:
- 415-322-3778 in Palo Alto, E-mail address cpsr@csli.stanford.edu.
-
- The League for Programming Freedom (LPF) is a grass-roots organization
- of professors, students, businessmen, programmers and users dedicated
- to bringing back the freedom to write programs. They regard patents
- on computer algorithms as harmful to the US software industry. They
- can be reached at (617) 433-7071. E-mail address: lpf@uunet.uu.net.
-
- For more details on these groups, see the accompanying document in
- the PGP release package.
-
-
- Recommended Introductory Readings
- =================================
-
- 1) Dorothy Denning, "Cryptography and Data Security", Addison-Wesley,
- Reading, MA 1982
- 2) Dorothy Denning, "Protecting Public Keys and Signature Keys",
- IEEE Computer, Feb 1983
- 3) Martin E. Hellman, "The Mathematics of Public-Key Cryptography,"
- Scientific American, Aug 1979
- 4) Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54.
- (This is a "must-read" article on PGP and other related topics.)
-
- Other Readings
- ==============
-
- 5) Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory
- for Computer Science, 1991
- 6) Xuejia Lai, "On the Design and Security of Block Ciphers",
- Institute for Signal and Information Processing, ETH-Zentrum,
- Zurich, Switzerland, 1992
- 7) Xuejia Lai, James L. Massey, Sean Murphy, "Markov Ciphers and
- Differential Cryptanalysis", Advances in Cryptology- EUROCRYPT'91
- 8) Philip Zimmermann, "A Proposed Standard Format for RSA
- Cryptosystems", Advances in Computer Security, Vol III, edited by
- Rein Turn, Artech House, 1988
- 9) Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and
- Source Code in C", John Wiley & Sons, 1993 (coming in November)
- 10) Paul Wallich, "Electronic Envelopes", Scientific American, Feb
- 1993, page 30. (This is an article on PGP)
-
-
- To Contact the Author
- =====================
-
- Philip Zimmermann may be reached at:
-
- Boulder Software Engineering
- 3021 Eleventh Street
- Boulder, Colorado 80304 USA
- Phone 303-541-0140 (voice or FAX) (10:00am - 7:00pm Mountain Time)
- Internet: prz@acm.org
-
-
-
- Appendix A: Where to Get PGP
- =============================
-
- The following describes how to get the freeware public key
- cryptographic software PGP (Pretty Good Privacy) from an anonymous
- FTP site on Internet, or from other sources.
-
- PGP has sophisticated key management, an RSA/conventional hybrid
- encryption scheme, message digests for digital signatures, data
- compression before encryption, and good ergonomic design. PGP is
- well featured and fast, and has excellent user documentation. Source
- code is free.
-
- PGP uses the RSA cryptosystem which is claimed by a US patent held by
- a company called Public Key Partners. PGP users outside the US take
- note that there is no RSA patent outside the US. Also, bear in mind
- that there are US and Canadian export laws prohibiting anyone inside
- the US and Canada from exporting cryptographic software like this.
- If you live outside the US, you're probably not violating US export
- law if you pick it up from a source outside of the US. Note that due
- to negotiations with the RSA patent holders, the name of PGP may
- change in a future release.
-
- What follows is a small sample of places that allegedly have PGP, as
- of June 1993. This information is not guaranteed to be correct.
- Some US sites have occasionally withdrawn PGP because of fear of
- legal intimidation from the RSA patent holders.
-
- There are two compressed archive files in the standard release, with
- the file name derived from the release version number. For PGP
- version 2.3, you must get pgp23.zip which contains the MSDOS binary
- executable and the PGP User's Guide, and you can optionally get
- pgp23src.zip which contains all the source code. These files can be
- decompressed with the MSDOS shareware archive decompression utility
- PKUNZIP.EXE, version 1.10 or later. For Unix users who lack an
- implementation of UNZIP, the source code can also be found in the
- compressed tar file pgp23src.tar.Z.
-
- A reminder: Set mode to binary or image when doing an FTP transfer.
- And when doing a kermit download to your PC, specify 8-bit binary
- mode at both ends. Here are some Internet sites that have PGP via
- anonymous FTP:
-
- Finland: nic.funet.fi (128.214.6.100)
- Directory: /pub/unix/security/crypt/
-
- Italy: ghost.dsi.unimi.it (149.132.2.1)
- Directory: /pub/security/
-
- UK: src.doc.ic.ac.uk
- Directory: /computing/security/software/PGP
-
- For those lacking FTP connectivity to the net, nic.funet.fi also
- offers the files via email. To get version 2.3, send the following
- mail message to mailserv@nic.funet.fi:
-
- ENCODER uuencode
- SEND pub/unix/security/crypt/pgp23src.zip
- SEND pub/unix/security/crypt/pgp23.zip
-
- This will deposit the two zipfiles, as (about) 15 batched messages in
- your mailbox within about 24 hours. Save and uudecode.
-
- In the US, PGP may be found on God knows how many BBS systems, far
- too many to list here. Still, if you don't have any local BBS phone
- numbers handy, here are some BBS's you might try.
-
- The GRAPEVINE BBS in Little Rock Arkansas has set up a special
- account for people to download PGP for free. The SYSOP is Jim Wenzel,
- at jim.wenzel@grapevine.lrk.ar.us. The following phone numbers are
- applicable and should be dialed in the order presented (i.e., the
- first one is the highest speed line): (501) 753-6859, (501)
- 753-8121, (501) 791-0124. When asked to login use the following
- information:
-
- name: PGP USER ('PGP' is 1st name, 'USER' is 2nd name)
- password: PGP
-
- PGP is also widely available on Fidonet, a large informal network of
- PC-based bulletin board systems interconnected via modems. Check
- your local bulletin board systems. It is available on many foreign
- and domestic Fidonet BBS sites.
-
- In New Zealand, try this (supposedly free) dial-up BBS system:
- Kappa Crucis: +64 9 817-3714, -3725, -3324, -8424, -3094, -3393
-
- Source and binary distributions of PGP are available from the Canadian
- Broadcasting Corporation library, which is open to the public. It has
- branches in Toronto, Montreal, and Vancouver. Contact Max Allen, at
- +1 416 205-6017 if you have questions.
-
- For information on PGP implementations on the Apple Macintosh,
- Commodore Amiga, or Atari ST, or any other questions about where to
- get PGP for any other platform, contact Hugh Miller at
- hmiller@lucpul.it.luc.edu.
-
- Here are a few people and their email addresses or phone numbers you
- can contact in some countries to get information on local PGP
- availability:
-
- Peter Gutmann Hugh Kennedy
- pgut1@cs.aukuni.ac.nz 70042.710@compuserve.com
- New Zealand Germany
-
- Branko Lankester Miguel Angel Gallardo
- lankeste@fwi.uva.nl gallardo@batman.fi.upm.es
- +31 2159 42242 (341) 474 38 09
- The Netherlands Spain
-
- Hugh Miller Colin Plumb
- hmiller@lucpul.it.luc.edu colin@nyx.cs.du.edu
- (312) 508-2727 Toronto, Ontario, Canada
- USA
-
- Jean-loup Gailly
- jloup@chorus.fr
- France
-
-