The comp.security.pgp FAQ

You are probably using MIT PGP, or possibly some other version of PGP with the "legal_kludge" option turned off.

As part of the agreement made to settle PGP's patent problems, MIT PGP changed its format slightly to prevent PGP 2.4 and older versions from decrypting its messages. This format change was written into MIT PGP to happen on September 1, 1994. Thus, all messages encrypted with MIT PGP after that date are unreadable by 2.4 (and earlier). The idea was that people using 2.4 and earlier would be forced to upgrade, and so the patent violating version would no longer be used.

The best route here is for your friend to upgrade to a newer version of PGP. Alternatively, if you are using a non-MIT version, look up the "legal_kludge" option in your documentation; you should be able to configure your copy of PGP to generate old-style messages. In 2.6.2i and 2.6.3i, this is done by putting Legal_Kludge=off in your config.txt file for PGP.

Note that the "old" output can be read perfectly well by newer versions, so if you are corresponding with MIT and 2.3 users, you will be best off with the Legal_Kludge=off statement in your config.txt.

Version 2.3a introduced the "pkcs_compat" option, allowing the format of signatures to change slightly to make them more compatible with industry standards. MIT PGP, because it uses the RSAREF library, is unable to understand the old signature format, so it therefore ignores the signature and warns you that it is doing so.

This problem comes up mostly with old key signatures. If your key contains such old signatures, try to get those people who signed your key to resign it with a newer version of PGP.

If an old signature is still vitally important to check, get a non-MIT version of PGP to check it with, such as ViaCrypt's.

This problem can arise when you have placed the entire public key ring from one of the servers into the pubring.pgp file. PGP may have to search through several thousand keys to find the one that it is after. The solution to this dilemma is to maintain 2 public key rings (See question 4.2). The first ring, the normal pubring.pgp file, should contain only those individuals that you send messages to quite often. The second key ring can contain ALL of the keys for those occasions when the key you need isn't in your short ring. You will, of course, need to specify the key file name whenever encrypting messages using keys in your secondary key ring. Now, when encrypting or decrypting messages to individuals in your short key ring, the process will be a LOT faster.

Encryption and decryption time also increases with the key size. A 2048 bits key will take much longer to work with than, for example, a 512 bits key.

First, let's assume that you have all of the mammoth public key ring in your default pubring.pgp file. First, you will need to extract all of your commonly used keys into separate key files using the -kx option. Next, rename pubring.pgp to some other name. For this example, I will use the name "pubring.big". Next, add each of the individual key files that you previously created to a new pubring.pgp using the -ka option. To encrypt a message to someone in the short default file, use the command pgp -e <file> <userid>. To encrypt a message to someone in the long ring, use the command pgp -e +pubring=c:\pgp\pubring.big <file> <userid>. Note that you need to specify the complete path and file name for the secondary key ring. It will not be found if you only specify the file name.

When encrypting a message to multiple addresses, you will notice that the length of the encrypted file only increases by a small amount for each additional address. The reason that the message only grows by a small amount for each additional key is that the body of the message is only encrypted once using a random session key and IDEA. It is only necessary then to encrypt this session key once for each address and place it in the header of the message. Therefore, the total length of a message only increases by the size of a header segment for each additional address. (To avoid a known weakness in RSA when encrypting the same message to multiple recipients, the IDEA session key is padded with different random data each time it is RSA-encrypted.)

There are many scripts and programs available for making PGP easier to use. There is an index to all of these at http://www.primenet.com/~shauert/.

If you know of a shell, script or front-end which is not mentioned at this site, submit the URL (or other useful information) to the owner of this site (Scott Hauert, <shauert@primenet.com>), not to me.

With conventional encryption, you can read the message by running PGP on the encrypted file and giving the pass phrase you used to encrypt.

With PGP's public key encryption, it's impossible unless you encrypted to yourself as well.

There is an undocumented setting, EncryptToSelf, which you can set in your CONFIG.TXT or on the command line to "on" if you want PGP to always encrypt your messages to yourself. Be warned, though; if your key is compromised, this means that the "cracker" will be able to read all the message you sent as well as the ones you've received.

Most likely this is caused because PGP can't create the public and private key ring files. If the environment variable PGPPATH isn't defined, PGP will try to put those files in the subdirectory ".pgp" off your home directory. It will not create the directory if needed, so if the directory's not there already, PGP will crash after generating the key. This also happens if PGPPATH points to a directory for which you don't have write permission.

There are two solutions: set the PGPPATH environment variable to point to the location of your key rings, or run mkdir $HOME/.pgp; chmod 700 $HOME/.pgp before generating your key.

PGP does this because of the "-----BEGIN PGP MESSAGE-----" (and related) headers it uses to mark the beginning of PGP messages. To keep it from getting confused, it tacks a "- " to the beginning of every line in the regular text which has a dash at the start. It strips the extra dash and space when you check the message's signature, and writes the original text to the output.

This also happens with several lines that start with "special" phrases, such as "From ", because those lines are otherwise "escaped" by mail programs, as required by the mail standard. This would invalidate the signature.

PGP will normally only accept one file to encrypt on the command line. Many platforms allow you to call a program in a "batch" sequence. You can use this to call PGP on multiple files automatically.

Under MS-DOS and OS/2, this works as follows:

for %a in (*.*) do pgp -ea %a userid

You can also do conventional encryption this way, using the undocumented "-z" option to specify the passphrase to encrypt all these files with:

for %a in (*.*) do pgp -c %a -z"the passphrase"

Under UNIX, this would be done like this:

for a in *
do
  pgp -ea $a userid
done

Several shells and front-ends will also let you encrypt multiple files at once, usually.

There are three ways to do this. The easiest way is probably to set the environment variable PGPPASS to contain your pass phrase. Under DOS, you can just type set PGPPASS=My secret pass phrase to do this.

This is very insecure, as anyone who has access to your environment can see what your passphrase is. This includes people who come along during your lunch break and type "set" at a DOS prompt on your computer. Under several variations of UNIX, it is possible to examine someone else's environment as well.

Another option, especially useful for shells, is to use the -z option. You just add the option -z"My secret passphrase" to the PGP command line. Include the passphrase in quotes if there are any spaces or "special" characters in it, such as a < or > character which may confuse the command shell.

This is even more insecure on a multi-user system. Everyone else can see what programs you are running, including all the options passed to it.

The best, but also the most complicated way is using the PGPPASSFD environment variable. This variable should contain a "file descriptor number" pointing to a file which contains the passphrase. This will protect the passphrase from anyone but the superuser, if you properly set the file's permissions.

Thanks to Jack Gostl <gostl@argos.argoscomp.com> for the following.

You can find something on this in the appnotes file in the pgp262 distribution. If you set PGPPASSFD to 0, pgp will read the passphrase from stdin as soon it starts.

PGPPASSFD=0; export PGPPASSFD
echo "PassPhraseHere" | pgp -east file recipient1 recipient2..

Patrick J. LoPresti <patl@lcs.mit.edu> added:

You could also use funky shell redirection to make PGP get the passphrase from an arbitrary file. The exact command to define a variable depends on the shell; ksh and the likes use export PGPPASSFD=3, and csh and derivates use setenv PGPPASSFD 3.

setenv PGPPASSFD 3; pgp -eat file recipient 3 < /my/passphrase/file

This last example has the added advantage that standard input is still available to the user, for example to answer Yes or No to certain questions.

The file 'randseed.bin' is used by PGP to generate a new random session key every time you encrypt something. Afterwards, it is filled with new random data. A virus checker will then of course detect that the file has changed. Since the file has a "bin" extension, most checkers think that it is an executable, and so will inform you they have detected a possible virus.

However, this file is only used by PGP to read some random data, and will never be executed. It is therefore safe to put it in the "exclusion" list of your virus scanner, so it will be skipped in future. An alternative for the 2.6 versions is to put Randseed=C:\PGP\RANDOM.SRC in your config.txt file. This will tell PGP to use that file, rather than the default 'randseed.bin', to store the random bits.

Deleting 'randseed.bin' will not do any harm; PGP will just ask you for some random keystrokes and generate the file again next time you encrypt something.

Zbigniew Fiedorowicz <fiedorow@math.ohio-state.edu> explains:

This is a genuine bug in MIT MacPGP 2.6.2 which is certainly a FAQ on the pgp newsgroups. MIT MacPGP 2.6.2 mysteriously claims it can't find your secret key, even though it can find your secret keyring. This may occur sporadically. The reason for this is an uninitialized pointer which is supposed to point to your userid if you have set one set, or to the empty string otherwise. Unfortunately in the latter case it is not initialized and points to some random area of RAM. If this area starts with a NULL byte, all will be well and MacPGP will use the first secret key in your secring.pgp. But otherwise MIT MacPGP will assume your userid is some random garbage and consequently won't be able to find your secret key. The workaround is to edit your config.txt and add the string MyName = "name as in secret key".

The TZ environment variable is used to indicate the timezone your computer is in. This allows PGP to generate timestamps for GMT time, so there won't be any conflicts when someone in another timezone verifies the signature and finds that it was signed in the future, or at another incorrect moment. It is specified in your AUTOEXEC.BAT file (in DOS) or your CONFIG.SYS file (in OS/2). For other operating systems, consult the manual.

In most cases, you can use the setting from the following list:

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 Auckland: SET TZ=NZT-12DST

For other countries, the full form of the TZ value has to be used. More formally, this is:
SET TZ=SSS[+|-]nDDD,sm,sw,sd,st,em,ew,ed,et,shift
Where 'SSS', 'n', and 'DDD' are the values as in the simple form. In the long form, all the other values must be specified, as follows:

'sm' is the starting month (1 to 12)

'sw' is the starting week (1 to 4 counting from the beginning, or - 1 to -4 counting from the end). 0 indicates that a particular day of the month is to be specified.

'sd' is the starting day (0 to 6 [where 0 is Sunday] if 'sw' is non-zero, or 1 to 31 if 'sw' is 0)

'st' is the starting time in seconds from midnight (e.g., 3600 for 01:00)

'em', 'ew', 'ed', and 'et' define the end time for daylight savings, and take the same values.

'shift' is the shift in daylight time change, in seconds (e.g., 3600 if one hour is to be added during daylight savings time).

For example, for the UK in 1995, the setting is expected to be:

SET TZ=GMT0BST,3,0,26,3600,10,0,22,3600,3600

Normally, PGP runs in "interactive" mode, and so you can always read on the screen what went wrong, where and hopefully why. But if you want to use PGP in a batch file, or in the background, you need to find out if the operation was successful in another way. The usual approach for this is to use the "exit code" returned by PGP.

To be able to detect if PGP could do what you asked, you need to add the +batchmode option to the command line. (To avoid getting "stuck" at prompts asking you to choose "yes" or "no", add the +force option). PGP will then return 0 if everything went ok, and 1 if something went wrong.

The PGP source contains a list of exit codes that are supposed to be returned when the associated events occur. It seems that this does not always work as expected. For example, PGP returns exit code 31 when no passphrase was specified to decrypt the file, but if you try to check a signature, exit code 1 is used to indicate any error, including "No key to check signature" and "Bad signature".

The random keystrokes were necessary to generate random events, but PGP 5.0 uses system events that go on all the time to constantly update the randseed.bin file. These events include disk access, keystrokes, mouse movements and other things that are reasonably random. If you check, you will see that the randseed.bin's last modified date often changes, even if you are not using PGP.

PGP 5.x is backward compatible to PGP 2.6.x. It implies, that PGP 5.x can work with everything generated by PGP 2.6.x. Only if RSA keys are used with MD5 hashes and IDEA encryption, PGP 2.6.x can work with a PGP 5.x output. There is a small problem with DSS or ElGamal certificates of RSA keys: The PGP 2.6.x check of keyring (-kc) reports some strange errors. PGP 2.6.3in fixes this (negligible) bug.

PGP 2.6.x and PGP 5.x are perfectly interoperable, if and only if the algorithms are restricted to MD5, RSA and IDEA only.