A: By and large, all PGP 2.x, 5.x and GPGs kan interoperate if:
Only RSA keys are used, of at most 2048 bits length,
MD5 is used as hash algorithm
IDEA is used for the symmetrical algorithm.
A: GNU Privacy Guard and PGP 5.x and higher are by and large OpenPGP compliant and interoperable.
A: This problem can arise when you have placed the entire public key ring from one of the servers into your local pubring.pgp file. PGP may have to search through several thousand keys to find the one that it is after. If you need to have these large keyrings (e.g. because you cannot count on being able to contact the keyservers to look up new keys), the solution to this dilemma is to maintain 2 public key rings (See How do I create a secondary key file?). 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.
A: 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.
A: It is also possible, although fairly unprobable, that the random pool has run empty and PGP is waiting for enough randomness to amass. Remember that PGP needs randomness to create cryptographic keys, if these are not sufficiently random they could be guessed by an attacker. So to be sure, PGP (or the OS supplying it via /dev/random) waits until enough randomness is available. As this random pool is filled by events from among others keyboard and mouse, wriggling the mouse or tapping keys helps (use the control, alt and shift keys if you are worried that the keystrokes might trigger something). As usually enough randomness is gathered during normal operation and only a little is used each time, this is occurs mostly when large amounts of encryptions are done.
A: 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.
A: Plugins and configurations to use GNU Privacy Guard can be found on the GNU Privacy Guard Project website, under Frontends.
A: PGP 5.x and higher already includes a number of plugins for other programs. More are listed on at PGPi.org.
A: With conventional encryption, you can read the message by running PGP on the encrypted file and giving the pass phrase you used to encrypt.
A: With PGP's public key encryption, it's only possible if you encrypted to yourself as well.
With the PGP 5.x and higher versions, it is the default setting to also encrypt to the default key. You can change this under PGP options / General / Always encrypt to default key.
For PGP 2.x 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 secret key is compromised, this means that the attacker will be able to decode all the messages you sent as well as the ones you've received. Similarly if you are forced to reveal decrypt your data (see Can I be forced to reveal my pass phrase in any legal proceedings?), you can now also decrypt the messages you sent, instead of only those you received! On the other hand, it allows you to read back the messages you sent in the past.
A: 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 abort 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.
A: 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 change the body of the mail and thereby invalidate the signature.
If you use PGP/MIME type signatures, the signature is presented as an attachement to receivers that do not have PGP.
For signing files, the accepted method is to use a seperate signature file.
A: 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.
Storing your passphrase like this is very dangerous! Remember that your passphrase is all that protects your secret keys from an attacker snooping around in your system.
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 and UNIX, 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 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 as most allow other users to see the command options of programs run by another user.
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 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: 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.
A: The file randseed.bin is used by PGP to store and generate randomness, which is used to create new random session keys every time you encrypt something. Afterwards, it is filled with new random data. A virus or integrity checker will then of course detect that the file has changed. Since the file has a .bin extension, some 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 is to instruct PGP to use a file with another extension, e.g. random.rnd. For the 2.6 versions this is done by puttting Randseed=C:\PGP\RANDOM.RND in your config.txt file. The PGP 5.x and higher GUI has a similar setting for Random Seed File.
Deleting the random seed file will not do any harm; PGP will just ask you for some random keystrokes and generate the file again next time you encrypt something.
A: 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 non-zero 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 should return 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".
A: The random keystrokes were necessary to generate random events, but newer PGPs acquire these events automatically. PGP 5.x and up for the Microsoft Windowses and Mac OS uses (the timing of) system events that go on all the time to constantly update the random seed file 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.
Under UNIX-like systems, PGP 5.x and GNU Privacy Guard use the output of the random device /dev/random when available, which gathers randomness in a similar way.
A: 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 (see What's with the patent on RSA?).
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.
A: 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.