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
Legal_Kludge=off statement in your config.txt.
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.
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.
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.
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, <firstname.lastname@example.org>), not to me.
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.
There are two solutions: set the PGPPATH environment variable to point
to the location of your key rings, or run
chmod 700 $HOME/.pgp before
generating your key.
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.
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.
set PGPPASS=My secret pass phraseto 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
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 <email@example.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.Patrick J. LoPresti <firstname.lastname@example.org> added:PGPPASSFD=0; export PGPPASSFD echo "PassPhraseHere" | pgp -east file recipient1 recipient2..
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 useThis 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.
export PGPPASSFD=3, and csh and derivates use
setenv PGPPASSFD 3.setenv PGPPASSFD 3; pgp -eat file recipient 3 < /my/passphrase/file
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
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.
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".
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:
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:
To be able to detect if PGP could do what you asked, you need to add
+batchmode option to the command line. (To avoid
getting "stuck" at prompts asking you to choose "yes" or "no", add
+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".
randseed.binfile. 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.
-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.
[ Previous | Next | Table of Contents | About this FAQ | Glossary ]