Archive-name: pgp-faq/index Version: 1.5
See "About this document" for more information. The What's new section tells you what has been added, modified or removed in this version of the FAQ.
PGP can also be used to apply a digital signature to a message without encrypting it. This is normally used in public postings where you don't want to hide what you are saying, but rather want to allow others to confirm that the message actually came from you. Once a digital signature is created, it is impossible for anyone to modify either the message or the signature without the modification being detected by PGP.
While PGP is easy to use, it does give you enough rope so that you can
hang yourself. You should become thoroughly familiar with the various
options in PGP before using it to send serious messages. For example,
giving the command pgp -sat <filename> will only sign a message, it
will not encrypt it. Even though the output looks like it is
encrypted, it really isn't. Anybody in the world would be able to
recover the original text.
Xenon <[email protected]> puts it like this:
Crime? If you are not a politician, research scientist, investor, CEO, lawyer, celebrity, libertarian in a repressive society, investor, or person having too much fun, and you do not send e-mail about your private sex life, financial/political/legal/scientific plans, or gossip then maybe you don't need PGP, but at least realize that privacy has nothing to do with crime and is in fact what keeps the world from falling apart. Besides, PGP is FUN. You never had a secret decoder ring? Boo!-Xenon (Copyright 1993, Xenon)
It should be noted, however, that in the United States, some freeware versions of PGP *may* be a violation of a patent held by Public Key Partners (PKP). The MIT and PGP, Inc. versions specifically are not in violation; if you use anything else, it's your risk. See below (question 1.6) for more information on the patent situation.
Also, the free versions of PGP are free only for noncommercial use. If you need to use PGP in a commercial setting (and you live in the United States or Canada), you should buy a copy of PGP from PGP, Inc. This version of PGP has other advantages as well, most notably a limited license to export it to foreign branch offices. See below, under question 1.9, for information on how to contact them.
If you need to use PGP for commercial use outside the United States or Canada, you should contact Ascom Systec AG, the patent holders for IDEA. They have sold individual licenses for using the IDEA encryption in PGP. Contact:
Erhard Widmer
Tel ++41 64 56 59 83
Fax ++41 64 56 59 90
The legal status of encryption in many countries has been placed on the World Wide Web. See http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm for a complete overview.
First, there is a question as to whether or not PGP falls under ITAR regulations which govern the exporting of cryptographic technology from the United States. This despite the fact that technical articles on the subject of public key encryption have been available legally worldwide for a number of years. Any competent programmer would have been able to translate those articles into a workable encryption program. A lawsuit has been filed by the EFF challenging the ITAR regulations; thus, they may be relaxed to allow encryption technology to be exported.
The situation in Canada is somewhat special; although ITAR does not apply here, Canada honors the US export restrictions, which makes it illegal to export PGP from Canada if it were imported there from the USA.
Second, older versions of PGP (up to 2.3a) were thought to be violating the patent on the RSA encryption algorithm held by Public Key Partners (PKP), a patent that is only valid in the United States. This was never tested in court, however, and recent versions of PGP have been made with various agreements and licenses in force which effectively settle the patent issue. So-called "international" versions and older versions (previous to ViaCrypt PGP 2.4), however, are still considered in violation by PKP; if you're in the USA, use them at your own risk!
All versions of PGP after 2.3 produce messages that cannot be read
by 2.3 or earlier, although the "international" versions have a switch
to enable the creation of messages in a compatible format. This is
the legal_kludge=on option in the configuration file.
MIT has released the freeware version of PGP 5.0 for Windows '95 and the Macintosh. This version has some limitations over the previous "official" freeware version 2.6.2 (for example, no conventional encryption and no wiping option). The source for PGP 5.0 is only available in book form. An international effort is underway to scan in this source to produce the electronic form. US export regulations forbid the export of PGP source in electronic form, but not of export in book form.
Note: there now is a beta version of PGP 5.0 for Linux available at http://www.pgp.com/products/50-linux-beta.cgi. Thanks to Lou Rinaldi for pointing this out.
PGP, Inc sells two versions of PGP: PGPmail 4.5 for business use (formerly Viacrypt PGP Business Edition) and PGP 5.0 for personal use. See question 1.9 for more details on these versions.
PGP 2.6.3i ("international") is a version of PGP developed from the source code of MIT PGP, which was exported illegally from the United States at some point. Basically, it is MIT PGP 2.6.2, but it uses the old encryption routines from PGP 2.3a; these routines perform better than RSAREF and in addition do not have the usage restrictions in the RSAREF copyright license. It also contains some fixes for bugs discovered since the release of MIT PGP 2.6.2, as well as several small enhancements. For more information, see the International PGP homepage at http://www.ifi.uio.no/pgp/.
PGP 2.6ui ("unofficial international") is PGP 2.3a with minor modifications made so it can decrypt files encrypted with MIT PGP. It does not contain any of the MIT fixes and improvements; it does, however, have other improvements, most notably in the Macintosh version.
The 2.6.3(i)n version was developed to fullfill the policy of the Individual Network e.V. Certification Hierarchy. It supports the features described in the pgformat.doc:
It fixed announing bugs of PGP:
Furthermore it adds:
Of course, you can try using Dejanews (http://www.dejanews.com/) or Alta Vista (http://altavista.digital.com/) if you are looking for articles about specific topics.
The PGP 5.0 FAQ (http://www.pgp.com/products/PGP50-faq.cgi) discusses this version in more detail.
PGPmail 4.5 is the successor of Viacrypt PGP Business Edition. In addition to the features found in normal versions of PGP, it also has a "Corporate Message Recovery" feature, which enables a site admin to recover messages encrypted by employees using PGPmail 4.5 in case their secret key is lost. It also has the Enclyptor, which adds a toolbar for email programs and word processors. For more information, see http://www.pgp.com/products/PGPmail-faq.cgi.
(Note: the Corporate Message Recovery feature is not a backdoor in PGP in the traditional sense. The freeware versions of PGP do not have this feature, and PGPmail 4.5's encryption has not been weakened in any way. Its only function is a backup so that the company can recover company data if the employee who encrypted it has left or has lost his secret key.)
There is a PGP library that can be used in programs:
ftp://dslab1.cs.uit.no/pub/PGPlib.tar.gz.
NAI has a software developer's kit for PGP available at:
http://www.pgp.com/sdk/.
Alternatively, you can write your programs to call the PGP program
when necessary. In C, for example, you would use the system()
or spawn...() functions to do this.
There are several people working on DLL versions (most often for Windows 3.1 or NT) of PGP, but I have no information on the status of these versions. PGP Inc. (formerly Viacrypt, see question 1.9) sells an MS Windows DLL which can be used for this purpose.
If you don't see your favorite platform above, don't despair! It's likely that porting PGP to your platform won't be too terribly difficult, considering all the platforms it has been ported to. Just ask around to see if there might in fact be a port to your system, and if not, try it!
PGP's VMS port, by the way, has its own Web page (http://www.tditx.com/~d_north/pgp.html).
However, I will describe below the ways to get the differing versions of PGP from their source sites. Please refer to the above document for more information.
Telnet to net-dist.mit.edu and log in as "getpgp". You will then be given a short statement about the regulations concerning the export of cryptographic software, and be given a series of yes/no questions to answer. If you answer correctly to the questions (they consist mostly of agreements to the RSADSI and MIT licenses and questions about whether you intend to export PGP), you will be given a special directory name in which to find the PGP code. At that point, you can FTP to net-dist.mit.edu, change to that directory, and access the software. You may be denied access to the directories even if you answer the questions correctly if the MIT site cannot verify that your site does in fact reside in the USA.
Further directions, copies of the MIT and RSAREF licenses, notes, and the full documentation are freely available from:
ftp://net-dist.mit.edu/pub/PGP/
An easier method of getting to the PGP software is now available on the World Wide Web at the following location:
http://bs.mit.edu:8001/pgp-form.html
You may also get it via mail by sending a message to
[email protected] with your request in the subject:
GET pgp262i[s].[zip | tar.gz]
Specify the "s" if you want the source code. Putting ".zip" at the end gets you the files in the PKZIP/Info-ZIP archive format, while putting "tar.gz" at the end gets the files in a gzipped tar file.
A US-compiled version of 2.6.3i (which means it does not use the MPILIB RSA library that violates a patent in the USA) can be downloaded from http://www.isc.rit.edu/~pdw5973/crypto/pgpdown.html.
A note on ftpmail:
For those individuals who do not have access to FTP, but do have access to e-mail, you can get FTP files mailed to you. For information on this service, send a message saying "Help" to [email protected]. You will be sent an instruction sheet on how to use the ftpmail service.
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.
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, <[email protected]>), 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 mkdir $HOME/.pgp;
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 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 <[email protected]> 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 <[email protected]> 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 usesetenv 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 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.
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:
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
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".
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.
-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.
It would be beyond the goal of this FAQ to discuss all possible attacks against or possible flaws in PGP. If you want to know more than what is available in here, see infiNity's PGP Attack FAQ at http://www.stack.nl/~galactus/remailers/attack-faq.html.
The only type of attack that might succeed is one that tries to solve the problem from a mathematical standpoint by analyzing the transformations that take place between plain text blocks, and their cipher text equivalents. IDEA is still a fairly new algorithm, and work still needs to be done on it as it relates to complexity theory, but so far, it appears that there is no algorithm much better suited to solving an IDEA cipher than the brute force attack, which we have already shown is unworkable. The nonlinear transformation that takes place in IDEA puts it in a class of extremely difficult to solve mathmatical problems.
This option is especially useful if you want to back up sensitive files, or want to take an encrypted file to another system where you will decrypt it. Now you don't have to take your secret key with you. It will also be useful when you lose your secret key. And you can even pick a different passphrase for each file you encrypt, so that an attacker who manages to get one file decrypted can't decrypt all the other files as well now.
For this reason, when you read messages on USENET saying that "someone told them" that the NSA is able to break pgp, take it with a grain of salt and ask for some documentation on exactly where the information is coming from. In particular, the message at http://www.quadralay.com/www/Crypt/NSA/break-pgp.html is a joke.
First, there is the RSA-129 key. The inventors of RSA published a message encrypted with a 129-digits (430 bits) RSA public key, and offered $100 to the first person who could decrypt the message. In 1994, an international team coordinated by Paul Leyland, Derek Atkins, Arjen Lenstra, and Michael Graff successfully factored this public key and recovered the plaintext. The message read:
THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE
They headed a huge volunteer effort in which work was distributed via E-mail, fax, and regular mail to workers on the Internet, who processed their portion and sent the results back. About 1600 machines took part, with computing power ranging from a fax machine to Cray supercomputers. They used the best known factoring algorithm of the time; better methods have been discovered since then, but the results are still instructive in the amount of work required to crack a RSA-encrypted message.
The coordinators have estimated that the project took about eight months of real time and used approximately 5000 MIPS-years of computing time.
What does all this have to do with PGP? The RSA-129 key is approximately equal in security to a 426-bit PGP key. This has been shown to be easily crackable by this project. PGP used to recommend 384-bit keys as "casual grade" security; recent versions offer 512 bits as a recommended minimum security level.
Note that this effort cracked only a single RSA key. Nothing was discovered during the course of the experiment to cause any other keys to become less secure than they had been.
For more information on the RSA-129 project, see: ftp://ftp.ox.ac.uk/pub/math/rsa129/rsa129.ps.gz
A year later, the first real PGP key was cracked. It was the infamous Blacknet key, a 384-bits key for the anonymous entity known as "Blacknet". A team consisting of Alec Muffett, Paul Leyland, Arjen Lenstra and Jim Gillogly managed to use enough computation power (approximately 1300 MIPS) to factor the key in three months. It was then used to decrypt a publicly-available message encrypted with that key.
The most important thing in this attack is that it was done in almost complete secrecy. Unlike with the RSA-129 attack, there was no publicity on the crack until it was complete. Most of the computers only worked on it in spare time, and the total power is well within reach of a large, perhaps even a medium sized organization.
pgp [filename] > [diskfile]
The -m option was not intended as a fail-safe option to prevent plain text files from being generated, but to serve simply as a warning to the person decrypting the file that he probably shouldn't keep a copy of the plain text on his system.
This is why picking a strong pass phrase is so important. Many of these cracker programs are very sophisticated and can take advantage of language idioms, popular phrases, and rules of grammar in building their guesses. Single-word "phrases", proper names (especially famous ones), or famous quotes are almost always crackable by a program with any "smarts" in it at all.
There is a program available which can "crack" conventionally encrypted files by guessing the passphrase. It does not do any cryptanalysis, so if you pick a strong passphrase your files will still be safe. See http://www.voicenet.com/~markm/pgpcrack.html for more information and the program itself.
There are also other methods to get at the contents of an encrypted message, such as bribery, snooping of electronic emanation from the computers processing the message (often called a TEMPEST attack), blackmail, or "rubber-hose cryptography" - beating you on the head with a rubber hose until you give the passphrase.
A pass phrase which is composed of ordinary words without punctuation or special characters is susceptible to a dictionary attack. Transposing characters or mis-spelling words makes your pass phrase less vulnerable, but a professional dictionary attack will cater for this sort of thing.
See Randall T. Williams' Passphrase FAQ at http://www.stack.nl/~galactus/remailers/passphrase-faq.html for a more detailed analysis.
It may be a good idea to periodically try out all the passphrases, or to iterate them in your mind. Repeating them often enough will help keep them from being completely blanked out when the time comes that you need them.
If you use long passphrases, it may be possible to write down the initial portion without risking compromising it, so that you can read the "hint" and remember the rest of the passphrase. For a simple way to pick provably strong passphrases that are easy to remember, please see Arnold Reinhold's "Diceware" website at http://world.std.com/~reinhold/diceware.html.
If you already own a trusted version of PGP, it is easy to check the validity of any future version. Newer binary versions of MIT PGP are distributed in popular archive formats; the archive file you receive will contain only another archive file, a file with the same name as the archive file with the extension .ASC, and a "setup.doc" file. The .ASC file is a stand-alone signature file for the inner archive file that was created by the developer in charge of that particular PGP distribution. Since nobody except the developer has access to his/her secret key, nobody can tamper with the archive file without it being detected. Of course, the inner archive file contains the newer PGP distribution.
A quick note: If you upgrade to MIT PGP from an older copy (2.3a or before), you may have problems verifying the signature. See question 3.14 for a more detailed treatment of this problem.
To check the signature, you must use your old version of PGP to check
the archive file containing the new version. If your old version of
PGP is in a directory called C:\PGP and your new archive file and
signature is in C:\NEW (and you have retrieved MIT PGP 2.6.2), you may
execute the following command:
c:\pgp\pgp c:\new\pgp262i.asc c:\new\pgp262i.zip
If you retrieve the source distribution of MIT PGP, you will find two more files in your distribution: an archive file for the RSAREF library and a signature file for RSAREF. You can verify the RSAREF library in the same way as you verify the main PGP source archive.
Non-MIT versions typically include a signature file for the PGP.EXE program file only. This file will usually be called PGPSIG.ASC. You can check the integrity of the program itself this way by running your older version of PGP on the new version's signature file and program file.
Phil Zimmermann himself signed all versions of PGP up to 2.3a. Since then, the primary developers for each of the different versions of PGP have signed their distributions. As of this writing, the developers whose signatures appear on the distributions are:
MIT PGP 2.6.2 Jeff Schiller <[email protected]> ViaCrypt PGP 2.7.1 ViaCrypt PGP 2.6.2i Stale Schumacher <[email protected]> PGP 2.6ui mathew <[email protected]>
You may, first of all, not verify the signature and follow other methods for making sure you aren't getting a bad copy. This isn't as secure, though; if you're not careful, you could get passed a bad copy of PGP.
If you're intent on checking the signature, you may do an intermediate upgrade to MIT PGP 2.6. This older version was signed before the "time bomb" took effect, so its signature is readable by the older versions of PGP. Once you have validated the signature on the intermediate version, you can then use that version to check the current version.
As another alternative, you may upgrade to PGP 2.6.2i or 2.6ui, checking their signatures with 2.3a, and use them to check the signature on the newer version. People living in the USA who do this may be violating the RSA patent in doing so; then again, you may have been violating it anyway by using 2.3a, so you're not in much worse shape.
Second, all the freeware versions of PGP are released with full source code to both PGP and to the RSAREF library they use (just as every other freeware version before them were). Thus, it is subject to the same peer review mentioned in the question above. If there were an intentional hole, it would probably be spotted. If you're really paranoid, you can read the code yourself and look for holes!
There are no intentional backdoors of any kind in the international version, nor is the encryption strength reduced in any way.
You should be very careful, however. Your pass phrase may be passed over the network in the clear where it could be intercepted by network monitoring equipment, or the operator on a multi-user machine may install "keyboard sniffers" to record your pass phrase as you type it in. Also, while it is being used by PGP on the host system, it could be caught by some Trojan Horse program. Also, even though your secret key ring is encrypted, it would not be good practice to leave it lying around for anyone else to look at.
So why distribute PGP with directions for making it on Unix and VMS machines at all? The simple answer is that not all Unix and VMS machines are network servers or "mainframes." If you use your machine only from the console (or if you use some network encryption package such as Kerberos), you are the only user, you take reasonable system security measures to prevent unauthorized access, and you are aware of the risks above, you can securely use PGP on one of these systems.
You can still use PGP on multi-user systems or networks without a secret key for checking signatures and encrypting. As long as you don't process a private key or type a pass phrase on the multiuser system, you can use PGP securely there.
Of course, it all comes down to how important you consider your secret key. If it's only used to sign posts to Usenet, and not for important private correspondence, you don't have to be as paranoid about guarding it. If you trust your system administrators, then you can protect yourself against malicious users by making the directory in which the keyrings are only accessible by you.
The problem with using PGP on a system that swaps is that the system will often swap PGP out to disk while it is processing your pass phrase. If this happens at the right time, your pass phrase could end up in cleartext in your swap file. How easy it is to swap "at the right time" depends on the operating system; Windows reportedly swaps the pass phrase to disk quite regularly, though it is also one of the most inefficient systems. PGP does make every attempt to not keep the pass phrase in memory by "wiping" memory used to hold the pass phrase before freeing it, but this solution isn't perfect.
Because swapfiles shrink, and many applications (eg: MsWord) grab disk space (and unused memory) and don't always fill it all out, you will regularly get fragments of other work embedded in files unrelated to it.
Disabling swapping (after getting more memory) will help, but you should also be cautious about sending binary attachments (like Word DOCs). If you wish to keep your hard-drive more secure, you should consider a sector-level encryptor (such as SFS or SecureDisk or CryptDisk)
If you have reason to be concerned about this, you might consider getting a swapfile wiping utility to securely erase any trace of the pass phrase once you are done with the system. Several such utilities exist for Windows and Linux at least. Not all of them perform as well as claimed in the documentation, especially when it comes to erasing leftover bits in the last sector and removing traces from the file allocation table.
In addition, don't forget that private keys are useful for more than decrypting. Someone with your private key can also sign items that could later prove to be difficult to deny. Keeping your private key secure can prevent, at the least, a bit of embarassment, and at most could prevent charges of fraud or breach of contract.
Besides, many of the above procedures are also effective against some common indirect attacks. As an example, the digital signature also serves as an effective integrity check of the file signed; thus, checking the signature on new copies of PGP ensures that your computer will not get a virus through PGP (unless, of course, the PGP version developer contracts a virus and infects PGP before signing).
The following information applies only to citizens of the United States in U.S. Courts. The laws in other countries may vary.There have been several threads on Internet concerning the question of whether or not the fifth amendment right about not being forced to give testimony against yourself can be applied to the subject of being forced to reveal your pass phrase. Not wanting to settle for the many conflicting opinions of armchair lawyers on usenet, I asked for input from individuals who were more qualified in the area. The results were somewhat mixed. There apparently has NOT been much case history to set precedents in this area. So if you find yourself in this situation, you should be prepared for a long and costly legal fight on the matter. Do you have the time and money for such a fight? Also remember that judges have great freedom in the use of "Contempt of Court". They might choose to lock you up until you decide to reveal the pass phrase and it could take your lawyer some time to get you out. (If only you just had a poor memory!)
During encryption, only the RSA portion of the encryption process is affected by key size. The RSA portion is only used for encrypting the session key used by the IDEA. The main body of the message is totally unaffected by the choice of RSA key size. So unless you have a very good reason for doing otherwise, select the 1024 bit key size. Using currently available algorithms for factoring, the 384 and 512 bit keys are just not far enough out of reach to be good choices.
If you are using MIT PGP 2.6.2, ViaCrypt PGP 2.7.1, or PGP 2.6.3i, you can specify key sizes greater than 1024 bits; the upper limit for these programs is 2048 bits. Remember that you have to tell PGP how big you want your key if you want it to be bigger than 1024 bits. Generating a key this long will take you quite a while; however, this is, as noted above, a one-time process. Remember that other people running other versions of PGP may not be able to handle your large key.
There is a small bug in some versions of MIT PGP 2.6.2, which will actually create a 2047 bits key when you ask for a 2048 bits one.
In this case, it might be faster to rename your public keyring to something else, then name the keyserver's keyring "pubring.pgp" and add your own keyring to the big one. There is a danger to this, though; the trust parameters to your old keys will be lost, and you will be using the trust parameters from this big keyring.
Unfortunately, the present version of PGP does not allow you to do this directly. Fortunately, there is an indirect way to do it.
pgp -kx uid1 extract pgp -kx uid2 extract pgp -kx uid3 extract
This puts all three keys into extract.pgp. To get an ascii amored
file, call: pgp -a extract.pgp
You get an extract.asc. Someone who does a pgp extract and has
either file processes all three keys simultaneously.
A Unix script to perform the extraction with a single command would be as follows:
#!/bin/sh for name in name1 name2 name3 ... ; do pgp -kx $name /tmp/keys.pgp <keyring> endAn equivalent DOS command would be:
for %a in (name1 name2 name3 ...) do pgp -kx %a keys.pgp <keyring>
To generate this random session key, PGP will try to use information from a file called 'randseed.bin'. If this file does not exist, or for some reason isn't random enough, you are asked to type in some random keystrokes which will then be used as a "seed" for the random number generator.
pgp -kv userid.
Be careful: If you enter "0x123", you will be matching key IDs 0x12393764, 0x64931237, or 0x96412373. Any key ID that contains "123" anywhere in it will produce a match. They don't need to be the starting characters of the key ID. You will recognize that this is the format for entering hex numbers in the C programming language. For example, any of the following commands could be used to encrypt a file to my public key:
pgp -e <filename> "Arnoud Engelfriet"
pgp -e <filename> [email protected]
pgp -e <filename> 0x416A1A35
This same method of key identification can be used in the config.txt
file in the "MyName" variable to specify exactly which of the keys in
the secret key ring should be used for encrypting a message.
pgp -kc.
The command pgp -kc smith will not show the trust parameters for
smith.
pgp -kxa. After that, it depends on what type of computer
you want your key to be available on. Check the documentation for
that computer and/or its networking software.
Many computers running a Unix flavor will read information to be
displayed via finger from a file in each user's home directory called
".plan". If your computer supports this, you can put your public key
in this file. Make sure the file is world-readable, use chmod
644 .plan if other people can't get at your plan. The home
directory also has to be accessible. Use chmod +x . in
your home directory to do this.
Contact your system administrator if you have further problems with
this.
Additionally, keep in mind a snooper reading your outgoing mail can easily change the public key in there with his own fake key. Then he can still read the messages sent to you. If the other party gets your key from a different location with a different method, it is a lot harder for that snooper to change the keys. (Note that signing the message containing the key will not help; the snooper can easily re-sign the message with his key).
A PGP key ID is just the bottom 64 bits of the public modulus (but
only the bottom 32 bits are displayed with pgp -kv). It
is easy to select two primes which when multiplied together have a
specific set of low-order bits.
This makes it possible to create a fake key with the same key ID as
an existing one. The fingerprint will still be different, though.
By the way, this attack is sometimes referred to as a DEADBEEF attack. This term originates from an example key with key ID 0xDEADBEEF which was created to demonstrate that this was possible.
Paul Leyland provided the following technical explanation:
Inside a PGP key, the public modulus and encryption exponent are
each represented as the size of the quantity in bits, followed by
the bits of the quantity itself. The key fingerprint, displayed by
pgp -kvc, is the MD5 hash of the bits, but NOT of the lengths.
By transferring low-order bits from the modulus to the high-order
portion of the exponent and altering the two lengths accordingly, it
is possible to create a new key with exactly the same fingerprint.
For this reason, you should always verify that key ID, fingerprint, and key size correspond when you are about to use someone's key. And when you sign a user ID, make sure it is signed by the key's owner!
Similarly, if you want to provide information about your key, include key ID, fingerprint and key size.
pgp -sat +clearsig=on <filename>
The output file will contain your original unmodified text, along with section headers and an armored PGP signature. In this case, PGP is not required to read the file, only to verify the signature.
You should be careful when you "clearsign" a text file like this. Some mail programs might alter your message when it is being sent, for example because there are very long lines in the message. This will invalidate the signature on the message. Also, using 8-bit characters in your message can cause problems; some versions of PGP will think the file is actually a binary file, and refuse to clearsign it.
For this reason, PGP 2.6.3i will automatically ASCII armor messages with very long lines in it.
In the USA, the state of Utah adopted its Digital Signature Act (the "1995 Utah Act") on February 27, 1995. It was signed by Michael Leavitt, Governor of Utah, on March 9, 1995, and took effect on May 1,1995. Utah was the first legal system in the world to adopt a comprehensive statute enabling electronic commerce through digital signatures. Thereafter, the 1996 amendment became effective on April 29, 1996.
The Utah law is available from <URL:http://www.commerce.state.ut.us/web/commerce/digsig/dsmain.htm>.
Other USA states are also working on implementing this technology for commerce, like Georgia, Washington and Illinois, ect. Apart from Utah, currently California and Virgina have bills or laws enabling this technology.
The Georgia law is available from: http://www.cc.emory.edu/BUSINESS/gds.html
The Washington law is available from: http://access.wa.net/sb6423_info/index.html
The California law is available from: http://www.ss.ca.gov/digsig/digsig.htm.
In many jurisdictions, a prior agreement in writing to accept valid digital signatures as binding is itself binding. If you are going to be swapping many digitally-signed agreements with another party, this approach may be useful. You might want to check with a lawyer in your country if the digital signatures will be used for important or valuable contracts.
For this reason, you can use a so-called digital notary or time-stamping service. This is a system that does nothing but sign documents you send to it, after inserting a date and time somewhere in the text. The service uses a numbering scheme which makes it impossible to insert timestamps at a later time. One such service is run by Matthew Richardson. For more information about it, please see http://www.itconsult.co.uk/stamper.htm.
The options (which can be set in PGP's configuration file, CONFIG.TXT) to control this are
Cert_Dept = n
Completes_Needed = n
Marginals_Needed = n
You can display the trust parameters for a key with pgp -kc.
See also question 4.7.
Be careful about keys that are several levels removed from your immediate trust.
The PGP trust model is discussed in more detail by Alfarez Abdul-Rahman at http://www.cs.ucl.ac.uk/staff/F.AbdulRahman/docs/.
PGP -ks [-u yourid] <keyid>
This adds your signature (signed with the private key for yourid, if
you specify it) to the key identified with keyid. If keyid is a user
ID, you will sign that particular user ID; otherwise, you will sign
the default user ID on that key (the first one you see when you list
the key with pgp -kv <keyid>).
Next, you should extract a copy of this updated key along with its signatures using the "-kxa" option. An armored text file will be created. Give this file to the owner of the key so that he may propagate the new signature to whomever he chooses.
Be very careful with your secret keyring. Never be tempted to put a copy in somebody else's machine so you can sign their public key - they could have modified PGP to copy your secret key and grab your pass phrase.
It is very easy to add user IDs to someone else's key. All it takes is a binary editor or some knowledge of the PGP public key format. But since you are the only person who can sign your own user IDs, the fake ones will not be signed, and so anyone who gets the key can immediately spot the fake ones. For example, my entry in the public key ring now appears as follows if you use the "-kvv" command:
Type Bits/KeyID Date User ID pub 1024/416A1A35 1994/10/01 Arnoud Engelfriet <[email protected]> sig 416A1A35 Arnoud Engelfriet <[email protected]> *** <[email protected]> now INVALID! sig 416A1A35 Arnoud Engelfriet <[email protected]> Galactus <[email protected]> sig 3602A619 Stephen Hopkins <[email protected]> sig DD63EF3D Frank Castle <[email protected]> sig 416A1A35 Arnoud Engelfriet <[email protected]> Arnoud Engelfriet <[email protected]> sig 390E3FB1 Martijn Heemels <[email protected]> sig DA87C0C7 Edgar W. Swank <[email protected]> sig 416A1A35 Arnoud Engelfriet <[email protected]>
For a more detailed discussion of why you should sign your own key, see "Why you should sign your own key" by Walther Soldierer at http://www.stack.nl/~galactus/remailers/selfsign.html.
Note that PGP 2.6.3[i] automatically signs each user ID you add to your own key.
Some countries require respected professionals such as doctors or engineers to endorse passport photographs as proof of identity for a passport application - you should consider signing someone's key in the same light. Alternatively, when you come to sign someone's key, ask yourself if you would be prepared to swear in a court of law as to that person's identity.
Remember that signing a person's key says nothing about whether you actually like or trust that person or approve of his/her actions. It's just like someone pointing to someone else at a party and saying, "Yeah, that's Joe Blow over there." Joe Blow may be an ax murderer; you don't become tainted with his crime just because you can pick him out of a crowd.
If it is a key from someone you know well and whose voice you
recognize then it is sufficient to give them a phone call and have
them read their key's fingerprint (obtained with pgp -kvc <userid>).
To be sure, also ask them for the key size and its key ID. There are
ways to create a forged key with an identical fingerprint (see
question 4.10 for details).
You can of course also check these details in another way, for example
if he has printed it on his business card.
If you don't know the person very well then the only recourse is to exchange keys face-to-face and ask for some proof of identity. Don't be tempted to put your public key disk in their machine so they can add their key - they could maliciously replace your key at the same time. If the user ID includes an e-mail address, verify that address by exchanging an agreed encrypted message before signing. Don't sign any user IDs on that key except those you have verified.
A key signing party is a get-together with various other users of PGP for the purpose of meeting and signing keys. This helps to extend the "web of trust" to a great degree.
A keysigning party announcement page can be found at:
http://www.geocities.com/CapitolHill/3378/pgpparty.html.
Derek Atkins <[email protected]> has recommended this method:
There are many ways to hold a key-signing session. Many viable suggestions have been given. And, just to add more signal to this newsgroup, I will suggest another one which seems to work very well and also solves the N-squared problem of distributing and signing keys. Here is the process:
pgp -kvc
on that keyring, and save the output to a file.
pgp -kvc file onto hardcopy, and bring
this and the keyring on media to the meeting.
pgp -kvc on it themselves, and re-verify the
bits, and sign the keys at their own leisure.
Assuming you have a backup copy of your secret key ring, you should generate a key revocation certificate and upload the revocation to one of the public key servers. Prior to uploading the revocation certificate, you might add a new ID to the old key that tells what your new key ID will be. If you don't have a backup copy of your secret key ring, then it will be impossible to create a revocation certificate under the present version of PGP. This is another good reason for keeping a backup copy of your secret key ring.
The way to avoid this dilemma is to create a key revocation certificate at the same time that you generate your key pair. Put the revocation certificate away in a safe place and you will have it available should the need arise.
pgp -kd youruserid.
pgp -kxa youruserid.
This file is what the manual calls the "revocation certificate."
Alternatively, you can use a binary editor to change one of the user IDs on your public key to read "Key invalid; use key 0x12345678" or something to that effect. Keep in mind that the new user ID can't be longer than the old one, unless you know what you are doing. Then extract the key, and send it to the keyserver. It will think this is actually a new user ID, and add it to your key there.
However, since anyone can do the above, many people will not trust unsigned user IDs with such statements. As explained in question 6.3, all user IDs on your key should be self-signed. So again, make a key revocation certificate in advance and use that when necessary.
While a number of key servers exist, it is only necessary to send your key to one of them. The key server will take care of the job of sending your key to all other known servers.
You can access the keyserver in e-mail, by sending mail to [email protected] with the command (see 8.3 below) in the Subject line of your message. This message will be sent to one of the keyservers at random, which ensures that an individual server will not be overloaded.
If you have WWW access, you can also use the WWW interface at http://www.uk.pgp.net/pgpnet/pks-commands.html.
FOUR11 no longer certifies keys. Version 1.3 of the FAQ incorrectly claimed that pobox.com certified keys, but Pobox customer service says they don't.
ADD Your PGP public key (key to add is body of msg) (-ka) INDEX List all PGP keys the server knows about (-kv) VERBOSE INDEX List all PGP keys, verbose format (-kvv) GET Get the whole public key ring (-kxa *), in multiple messages GET <userid> Get just that one key (-kxa <userid>) LAST <n> Get all keys uploaded during last <n> days
Note that instead of a user ID, you can also use a key ID. In this case, you should put "0x" in front of it. By using a key ID rather than a user ID, name or e-mail address, you ensure that you get exactly the key you want. Please see question 4.5 for more information on how to use key IDs.
If you wish to get the entire key ring and have access to FTP, it would be a lot more efficient to use FTP rather than e-mail. Download an entire keyring from ftp://ftp.pgp.net/pub/pgp/keys/README.html
Post all of your bug reports concerning non-MIT versions of PGP to comp.security.pgp.tech, and forward a copy to me for possible inclusion in future releases of the FAQ. Please be aware that the authors of PGP might not acknowledge bug reports sent directly to them. Posting them on USENET will give them the widest possible distribution in the shortest amount of time.
#ifndef SYSV to#if !defined(SYSV) && !defined(__ELF__) and change
#ifdef SYSV toif defined(SYSV) ||
defined(__ELF__).
Myname = "your userid", and MacPGP will be able to
find your secret key. This has been fixed in FatMacPGP 2.6.2 and 2.6.3.
See also question 2.13.
<===== begin patch (cut here)
- --- crypto.c.orig Mon Mar 20 22:30:29 1995
+++ crypto.c Mon Mar 20 22:55:32 1995
@@ -685,7 +685,7 @@
byte class, unitptr e, unitptr d, unitptr p, unitptr q, unitptr u,
unitptr n)
{
- - byte inbuf[MAX_BYTE_PRECISION], outbuf[MAX_BYTE_PRECISION];
+ byte inbuf[MAX_BYTE_PRECISION], outbuf[MAX_BYTE_PRECISION+2];
int i, j, certificate_length, blocksize,bytecount;
word16 ske_length;
word32 tstamp; byte *timestamp = (byte *) &tstamp;
<===== end patch (cut here)
+makerandom command, which can generate a file full of
random data. Unfortunately, it does not work as intended, because the
random number generator is not initialized properly. This does not
affect normal PGP operation; the bug is only present when
+makerandom is used.
Stallings, William, Protect Your Privacy: A Guide for PGP Users, Prentice Hall, 1995, ISBN 0-13-185596-4. (Current errata at ftp://ftp.shore.net/members/ws/Errata-PGP-mmyy.txt)
Garfinkel, Simson, PGP: Pretty Good Privacy, O'Reilly & Associates, 1994, ISBN 1-56592-098-8.
Schneier, Bruce, E-Mail Security with PGP and PEM: How To Keep Your Electronic Messages Private, John Wiley & Sons, 1995, ISBN 0-471-05318-X.
Kahn, David, The Code Breakers, The Story of Secret Writing, The MacMillan Publishing Company (1968), ISBN: 0-02-560460-0.
Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, John Wiley & Sons, 1993
Dorothy Denning, Cryptography and Data Security, Addison-Wesley, Reading, MA 1982
Dorothy Denning, Protecting Public Keys and Signature Keys, IEEE Computer, Feb 1983
Martin E. Hellman, The Mathematics of Public-Key Cryptography, Scientific American, Aug 1979
Steven Levy, Crypto Rebels, WIRED, May/Jun 1993, page 54. (This is a "must-read" article on PGP and other related topics.)
Ronald Rivest, The MD5 Message Digest Algorithm, MIT Laboratory for Computer Science, 1991. Available from the net as RFC1321.
Xuejia Lai, On the Design and Security of Block Ciphers, Institute for Signal and Information Processing, ETH-Zentrum, Zurich, Switzerland, 1992
Xuejia Lai, James L. Massey, Sean Murphy, Markov Ciphers and Differential Cryptanalysis, Advances in Cryptology- EUROCRYPT'91
Philip Zimmermann, A Proposed Standard Format for RSA Cryptosystems, Advances in Computer Security, Vol III, edited by Rein Turn, Artech House, 1988
Paul Wallich, Electronic Envelopes, Scientific American, Feb 1993, page 30. (This is an article on PGP)
-i option will cause PGP to include more information
about the file in the encrypted message. With the -p option,
PGP restores the original filename when you decrypt the message, but
if this option is also used, and both sender and recipient are using
the same platform, then the original file permissions and timestamp will
also be restored.
-l option PGP gives lots more information
about what it is doing. During key generation, for example, you get to
see the actual numbers used in your public and secret key.
-km option will display the "web of trust" (see
question 4.7) in a nested list. This way you can see which
key introduces which.
encrypttoself=on in your configuration
file, all messages that you encrypt will always be encrypted with
your own public key as well. This way you will be able to decrypt
and read every message you send. This can be useful if you have PGP
set up to encrypt every outgoing message, and your "outbox" will
keep the encrypted versions. Note: if someone else ever manages to
obtain your secret key, he will be able to read every
encrypted message you ever sent out, if this option was enabled.
pgp filename +makerandom=n. There is a bug in the
international versions of PGP, which results in this random data
being a lot less random than normal.
Fido net mail is even more sensitive. You should only send encrypted net mail after checking that:
Don't sign someone's key just because someone else that you know has signed it. Confirm the identity of the individual yourself. Remember, you are putting your reputation on the line when you sign a key.
If you have a UNIX shell account, put a copy of your public key in a file called ".plan", so that other people can finger that account and get your public key in the process. See also question 4.8.
Also, send your public key to a keyserver. See question 8.1 for details.
Whatever method you choose to make your key available, make sure that it's clear for others how to get it. Usually, you just put instructions in your mail and news .signature file (something like "PGP public key available from keyservers" or "Finger me for public key"), or reference to it from your homepage.
It's also good practice to include key ID and fingerprint in your .signature. That way, people who want to have your key can be more certain they are actually getting yours, and not some other key with your name on it. And the fingerprint will be an even greater help in this.
But this is not proof that the key actually is yours. Remember, the message or post with this .signature can be a forgery.
If you have any other tips, please let me know.