Chip 1998 May/CHIPCD5_98.iso/offline/security/pgpfaq/pgpfaq.txt

Text File | 1998-03-25 | 121KB | 2,486 lines

Archive-name: pgp-faq/index
Version: 1.4

                         The comp.security.pgp FAQ

   This is the list of Frequently Asked Questions for the Pretty Good
   Privacy (PGP) encryption program written by Phillip Zimmermann. It is
   posted to all comp.security.pgp newsgroups once a month, and is also
   available on the World-Wide Web at http://www.pgp.net/pgpnet/pgp-faq/.

   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.
     _________________________________________________________________

                             Table of Contents

1. Introductory Questions

     1.1 What is PGP?
     1.2 Why should I encrypt my mail? I'm not doing anything illegal!
     1.3 What are public keys and private keys?
     1.4 How much does PGP cost?
     1.5 Is encryption legal?
     1.6 Is PGP legal?
     1.7 What's the current version of PGP?
     1.8 Is there an archive site for the comp.security.pgp groups?
     1.9 Is there a commercial version of PGP available?
     1.10 Is PGP available as a programming library, so I can write
       programs that use it?
     1.11 What platforms has PGP been ported to?
     1.12 Where can I obtain PGP?
     1.13 I want to find out more!

2. Very Common Questions and Problems

     2.1 Why can't a person using version 2.3 read my version 2.6
       message?
     2.2 Why does PGP complain about checking signatures every so often?
     2.3 Why does it take so long to encrypt/decrypt messages?
     2.4 How do I create a secondary key file?
     2.5 How does PGP handle multiple addresses?
     2.6 Where can I obtain scripts to integrate pgp with my email or
       news reading system?
     2.7 How can I decrypt messages I've encrypted to others?
     2.8 Why can't I generate a key with PGP for Unix?
     2.9 When I clearsign a document in PGP, it adds a "dash-space" to
       several of my lines. What gives?
     2.10 How do I encrypt more than one file at a time?
     2.11 How can I give my passphrase to PGP automatically?
     2.12 How come 'randseed.bin' got infected by a virus?
     2.13 Why can't MacPGP find my secret key?
     2.14 How do I set the TZ variable?
     2.15 How do I determine if the PGP command worked?
     2.16 Why does PGP 5.0 no longer ask for random keystrokes?
     2.17 Are PGP 5.0/5.5 and PGP 2.6.x interoperable?

3. Security Questions

     3.1 How secure is PGP?
     3.2 Can't you break PGP by trying all of the possible keys?
     3.3 How secure is the conventional cryptography (-c) option?
     3.4 Can the NSA crack RSA?
     3.5 Has RSA ever been cracked publicly? What is RSA-129?
     3.6 How secure is the "for your eyes only" option (-m)?
     3.7 What if I forget my pass phrase?
     3.8 Why do you use the term "pass phrase" instead of "password"?
     3.9 What is the best way to crack PGP?
     3.10 If my secret key ring is stolen, can my messages be read?
     3.11 How do I choose a pass phrase?
     3.12 How do I remember my pass phrase?
     3.13 How do I verify that my copy of PGP has not been tampered with?
     3.14 I can't verify the signature on my new copy of MIT PGP with my
       old PGP 2.3a!
     3.15 How do I know that there is no trap door in the program?
     3.16 I heard that the NSA put a back door in MIT PGP, and that they
       only allowed it to be legal with the back door.
     3.17 Is there a back door in the international version?
     3.18 Can I put PGP on a multi-user system like a network or a
       mainframe?
     3.19 Can I use PGP under a "swapping" operating system like Windows
       or OS/2?
     3.20 Why not use RSA alone rather than a hybrid mix of IDEA, MD5, &
       RSA?
     3.21 Aren't all of these security procedures a little paranoid?
     3.22 Can I be forced to reveal my pass phrase in any legal
       proceedings?

4. Keys

     4.1 Which key size should I use?
     4.2 Why does PGP take so long to add new keys to my key ring?
     4.3 How can I extract multiple keys into a single armored file?
     4.4 I tried encrypting the same message to the same address two
       times and got completely different outputs. Why is this?
     4.5 How do I specify which key to use when an individual has 2 or
       public keys and the very same user ID on each, or when 2 different
       users have the same name?
     4.6 What does the message "Unknown signator, can't be checked" mean?
     4.7 How do I get PGP to display the trust parameters on a key?
     4.8 How can I make my key available via finger?
     4.9 Should I put my key in my .signature?
     4.10 Can a public key be forged?
     4.11 How do I detect a forged key?

5. Message Signatures

     5.1 What is message signing?
     5.2 How do I sign a message and keep it readable?
     5.3 Can't you just forge a signature by copying the signature block
       to another message?
     5.4 Are PGP signatures legally binding?
     5.5 Is the date on a PGP signature reliable?

6. Key Signatures

     6.1 What is key signing?
     6.2 How do I sign a key?
     6.3 Should I sign my own key?
     6.4 Should I sign X's key?
     6.5 How do I verify someone's identity?
     6.6 How do I know someone hasn't sent me a bogus key to sign?
     6.7 What's a key signing party?
     6.8 How do I organize a key signing party?

7. Revoking a key

     7.1 My secret key ring has been stolen or lost, what do I do?
     7.2 I forgot my pass phrase. Can I create a key revocation
       certificate?
     7.3 How do I create a key revocation certificate?
     7.4 How do I indicate that my key is invalid when I don't have the
       secret key anymore?

8. Public Key Servers

     8.1 What are the Public Key Servers?
     8.2 What public key servers are available?
     8.3 What is the syntax for the key server commands?

9. Bugs

     9.1 Where do I send bug reports?
     9.2 What bugs have been found in PGP?

10. Recommended Reading

11. General Tips
     _________________________________________________________________

1. Introductory Questions

     1.1 What is PGP?
     1.2 Why should I encrypt my mail? I'm not doing anything illegal!
     1.3 What are public keys and private keys?
     1.4 How much does PGP cost?
     1.5 Is encryption legal?
     1.6 Is PGP legal?
     1.7 What's the current version of PGP?
     1.8 Is there an archive site for the comp.security.pgp groups?
     1.9 Is there a commercial version of PGP available?
     1.10 Is PGP available as a programming library, so I can write
       programs that use it?
     1.11 What platforms has PGP been ported to?
     1.12 Where can I obtain PGP?
     1.13 I want to find out more!
     _________________________________________________________________

  1.1 What is PGP?

   PGP is a program that gives your electronic mail something that it
   otherwise doesn't have: Privacy. It does this by encrypting your mail
   so that nobody but the intended person can read it. When encrypted,
   the message looks like a meaningless jumble of random characters. PGP
   has proven itself quite capable of resisting even the most
   sophisticated forms of analysis aimed at reading the encrypted text.

   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.

  1.2 Why should I encrypt my mail? I'm not doing anything illegal!

   You should encrypt your e-mail for the same reason that you don't
   write all of your correspondence on the back of a post card. E-mail is
   actually far less secure than the postal system. With the post office,
   you at least put your letter inside an envelope to hide it from casual
   snooping. Take a look at the header area of any e-mail message that
   you receive and you will see that it has passed through a number of
   nodes on its way to you. Every one of these nodes presents the
   opportunity for snooping. Encryption in no way should imply illegal
   activity. It is simply intended to keep personal thoughts personal.

   Xenon <[e-mail]> 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!

     CREDIT: -Xenon (Copyright 1993, Xenon)

  1.3 What are public keys and private keys?

   With conventional encryption schemes, keys must be exchanged with
   everyone you wish to talk to by some other secure method such as face
   to face meetings, or via a trusted courier. The problem is that you
   need a secure channel before you can establish a secure channel! With
   conventional encryption, either the same key is used for both
   encryption and decryption or it is easy to convert either key to the
   other. With public key encryption, the encryption and decryption keys
   are different and it is impossible for anyone to convert one to the
   other. Therefore, the encryption key can be made public knowledge, and
   posted in a database somewhere. Anyone wanting to send you a message
   would obtain your encryption key from this database or some other
   source and encrypt his message to you. This message can't be decrypted
   with the encryption key. Therefore nobody other than the intended
   receiver can decrypt the message. Even the person who encrypted it can
   not reverse the process. When you receive a message, you use your
   secret decryption key to decrypt the message. This secret key never
   leaves your computer. In fact, your secret key is itself encrypted to
   protect it from anyone snooping around your computer.

  1.4 How much does PGP cost?

   Nothing!

   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
    Ascom Systec AG
    Dep't. CMVV
    Gewerbepark
    CH-5506 Maegenwil
    Switzerland
    [e-mail]
    Tel ++41 64 56 59 83
    Fax ++41 64 56 59 90

  1.5 Is encryption legal?

   In much of the civilized world, encryption is either legal, or at
   least tolerated. However, there are a some countries where such
   activities could put you in front of a firing squad! Check with the
   laws in your own country before using PGP or any other encryption
   product. A couple of the countries where encryption is illegal are
   France, Iran, Russia and Iraq.

   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.

  1.6 Is PGP legal?

   In addition to the comments about encryption listed above, there are a
   couple of additional issues of importance to those individuals
   residing in the United States or Canada.

   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!

  1.7 What's the current version of PGP?

   At the moment, there are five different "current" versions of PGP. All
   of these are derived, more or less, from a common source base: PGP
   2.3a, the last "guerillaware" version of PGP. Negotiations to make PGP
   legal and "legitimate" have resulted in the differing versions
   available; all of them, for the most part, are approximately
   equivalent in functionality, and they can all work with each other in
   most respects.

   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:
     * expire of keys
     * support of certificate revokation certificates. You can revoke
       your ID without loosing your key.
     * While certifying a key the certifier can specify how he checked
       the users real identity. This question is quite different to the
       question if the key was presented by this person or not!

   It fixed announing bugs of PGP:
     * certificates of compromised keys are invalid now

   Furthermore it adds:
     * support SIGN/ENCR keys
     * support of a seperate encrypt to self id

   References:
     * http://www.in-ca.individual.net/
     * ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/software/pgp/

  1.8 Is there an archive site for the comp.security.pgp groups?

   Not really.

   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.

  1.9 Is there a commercial version of PGP available?

   Yes. Until recently, Viacrypt was marketing the only commercially
   licensed version of PGP. The company was bought by PGP Inc., a company
   founded by Phil Zimmerman. This company offers two versions of PGP:
   PGPmail 4.5 for corporate use, and PGP 5.0 for personal use. It is not
   entirely clear if the license for RSA that Viacrypt had is still
   valid.

   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.)

  1.10 Is PGP available as a programming library, so I can write programs that
  use it?

   There is a PGP library that can be used in programs:
   ftp://dslab1.cs.uit.no/pub/PGPlib.tar.gz.

   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.

  1.11 What platforms has PGP been ported to?

   PGP has been ported successfully to many different platforms,
   including DOS, the Macintosh, OS/2, Unix (just about all flavors),
   VMS, the Atari ST, Acorn RISC OS (Archimedes), and the Commodore
   Amiga. A Windows NT port is reportably in the works as well.

   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).

  1.12 Where can I obtain PGP?

   PGP is very widely available, so much so that a separate FAQ has been
   written for answering this question. It is called, "WHERE TO GET THE
   PRETTY GOOD PRIVACY PROGRAM (PGP)"; it is posted in alt.security.pgp
   regularly, is in the various FAQ archive sites, and is also available
   from ftp://ftp.csn.net/mpj/getpgp.asc

   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.

MIT PGP:

   Due to the ITAR regulations, MIT has found it necessary to place PGP
   in an export-controlled directory to prevent people outside the United
   States from downloading it. If you are in the USA, you may follow
   these directions:

   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

PGPmail and PGP 5.0:

   The freeware version of PGP 5.0 is available from MIT (see above).
   Other versions are commercial software and must be bought from PGP,
   Inc. They are, furthermore, not available outside the United States or
   Canada except under special circumstances. See above (question 1.9)
   for contact information.

PGP 2.6.3i:

   As Norway is not limited by ITAR, no hoops are needed to get this
   version: http://www.ifi.uio.no/pgp/

   You may also get it via mail by sending a message to
   [e-mail] 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.

PGP 2.6ui:

     * ftp://ftp.mantis.co.uk/pub/cryptography/
     * http://thegate.gamers.org/~tony/pgp.html

   This link is also an excellent resource for other information about
   PGP.

   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
     [e-mail]. You will be sent an instruction
     sheet on how to use the ftpmail service.

  1.13 I want to find out more!

   If this FAQ doesn't answer your question, there are several places for
   finding out information about PGP.

World Wide Web

   http://sun1.bham.ac.uk/N.M.Queen/pgp/pgp.html
          A good place to start, includes pointers on where to download
          PGP.

   http://www.stack.nl/~galactus/remailers/bg2pgp.txt
          Although the documentation that comes with PGP is very
          complete, you might also want to read this guide. It covers all
          the basic steps needed to install and use PGP, and also gives
          you tips on how to use it more effectively.

   http://www.hkn.de/user/raven/pgp5kurs.html
          This is a German manual for PGP 5.0 for beginners, written by
          Kai Raven.

   http://www.stack.nl/~galactus/remailers/passphrase-faq.html
          Your pass phrase is used to protect your PGP secret key. Here's
          how to generate and manage strong pass phrases. This may also
          be useful for creating passwords for other purposes.

   PGP-related resources
          A large collection of PGP-related Web sites, links to
          front-ends, and more.

   http://www.stack.nl/~galactus/remailers/attack-faq.html
          A very detailed analysis on the security of PGP and possible
          attacks.

FTP Sites:

     * ftp://ftp.pgp.net/pub/pgp/
     * ftp://ftp.ox.ac.uk/pub/crypto/
     * ftp://ripem.msu.edu/pub/crypt/
     * ftp://ftp.csua.berkeley.edu/pub/cypherpunks/

   Also see part 10, "Recommended Reading".
     _________________________________________________________________

2. Very Common Questions and Problems

     2.1 Why can't a person using version 2.3 read my version 2.6
       message?
     2.2 Why does PGP complain about checking signatures every so often?
     2.3 Why does it take so long to encrypt/decrypt messages?
     2.4 How do I create a secondary key file?
     2.5 How does PGP handle multiple addresses?
     2.6 Where can I obtain scripts to integrate pgp with my email or
       news reading system?
     2.7 How can I decrypt messages I've encrypted to others?
     2.8 Why can't I generate a key with PGP for Unix?
     2.9 When I clearsign a document in PGP, it adds a "dash-space" to
       several of my lines. What gives?
     2.10 How do I encrypt more than one file at a time?
     2.11 How can I give my passphrase to PGP automatically?
     2.12 How come 'randseed.bin' got infected by a virus?
     2.13 Why can't MacPGP find my secret key?
     2.14 How do I set the TZ variable?
     2.15 How do I determine if the PGP command worked?
     2.16 Why does PGP 5.0 no longer ask for random keystrokes?
     2.17 Are PGP 5.0/5.5 and PGP 2.6.x interoperable?
     _________________________________________________________________

  2.1 Why can't a person using version 2.3 read my version 2.6 message?

   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.

  2.2 Why does PGP complain about checking signatures every so often?

   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.

  2.3 Why does it take so long to encrypt/decrypt messages?

   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.

  2.4 How do I create a secondary key file?

   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.

  2.5 How does PGP handle multiple addresses?

   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.)

  2.6 Where can I obtain scripts to integrate pgp with my email or news reading
  system?

   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, <[e-mail]>), not to me.

  2.7 How can I decrypt messages I've encrypted to others?

   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.

  2.8 Why can't I generate a key with PGP for Unix?

   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.

  2.9 When I clearsign a document in PGP, it adds a "dash-space" to several of
  my lines. What gives?

   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.

  2.10 How do I encrypt more than one file at a time?

   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.

  2.11 How can I give my passphrase to PGP automatically?

   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 <[e-mail]> 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 <[e-mail]> 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.

  2.12 How come 'randseed.bin' got infected by a virus?

   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.

  2.13 Why can't MacPGP find my secret key?

   Zbigniew Fiedorowicz <[e-mail]> 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"".

  2.14 How do I set the TZ variable?

   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

  2.15 How do I determine if the PGP command worked?

   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".

  2.16 Why does PGP 5.0 no longer ask for random keystrokes?

   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.

  2.17 Are PGP 5.0/5.5 and PGP 2.6.x interoperable?

   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.
     _________________________________________________________________

3. Security Questions

     3.1 How secure is PGP?
     3.2 Can't you break PGP by trying all of the possible keys?
     3.3 How secure is the conventional cryptography (-c) option?
     3.4 Can the NSA crack RSA?
     3.5 Has RSA ever been cracked publicly? What is RSA-129?
     3.6 How secure is the "for your eyes only" option (-m)?
     3.7 What if I forget my pass phrase?
     3.8 Why do you use the term "pass phrase" instead of "password"?
     3.9 What is the best way to crack PGP?
     3.10 If my secret key ring is stolen, can my messages be read?
     3.11 How do I choose a pass phrase?
     3.12 How do I remember my pass phrase?
     3.13 How do I verify that my copy of PGP has not been tampered with?
     3.14 I can't verify the signature on my new copy of MIT PGP with my
       old PGP 2.3a!
     3.15 How do I know that there is no trap door in the program?
     3.16 I heard that the NSA put a back door in MIT PGP, and that they
       only allowed it to be legal with the back door.
     3.17 Is there a back door in the international version?
     3.18 Can I put PGP on a multi-user system like a network or a
       mainframe?
     3.19 Can I use PGP under a "swapping" operating system like Windows
       or OS/2?
     3.20 Why not use RSA alone rather than a hybrid mix of IDEA, MD5, &
       RSA?
     3.21 Aren't all of these security procedures a little paranoid?
     3.22 Can I be forced to reveal my pass phrase in any legal
       proceedings?
     _________________________________________________________________

  3.1 How secure is PGP?

   The big unknown in any encryption scheme based on RSA is whether or
   not there is an efficient way to factor huge numbers, or if there is
   some backdoor algorithm that can break the code without solving the
   factoring problem. Even if no such algorithm exists, it is still
   believed that RSA is the weakest link in the PGP chain.

   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.

  3.2 Can't you break PGP by trying all of the possible keys?

   This is one of the first questions that people ask when they are first
   introduced to cryptography. They do not understand the size of the
   problem. For the IDEA encryption scheme, a 128 bit key is required.
   Any one of the 2^128 possible combinations would be legal as a key,
   and only that one key would successfully decrypt all message blocks.
   Let's say that you had developed a special purpose chip that could try
   a billion keys per second. This is FAR beyond anything that could
   really be developed today. Let's also say that you could afford to
   throw a billion such chips at the problem at the same time. It would
   still require over 10,000,000,000,000 years to try all of the possible
   128 bit keys. That is something like a thousand times the age of the
   known universe! While the speed of computers continues to increase and
   their cost decrease at a very rapid pace, it will probably never get
   to the point that IDEA could be broken by the brute force attack.

   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.

  3.3 How secure is the conventional cryptography (-c) option?

   Assuming that you are using a good strong random pass phrase, it is
   actually much stronger than the normal mode of encryption because you
   have removed RSA which is believed to be the weakest link in the
   chain. Of course, in this mode, you will need to exchange secret keys
   ahead of time with each of the recipients using some other secure
   method of communication, such as an in- person meeting or trusted
   courier.

   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.

  3.4 Can the NSA crack RSA?

   This question has been asked many times. If the NSA were able to crack
   RSA, you would probably never hear about it from them. Now that RSA is
   getting more and more popular, it would be a very closely guarded
   secret. The best defense against this is the fact the algorithm for
   RSA is known worldwide. There are many competent mathematicians and
   cryptographers outside the NSA and there is much research being done
   in the field right now. If any of them were to discover a hole in RSA,
   I'm sure that we would hear about it from them. I think that it would
   be hard to hide such a discovery.

   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.

  3.5 Has RSA ever been cracked publicly? What is RSA-129?

   Two RSA-encrypted messages have been cracked publicly.

   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.

  3.6 How secure is the "for your eyes only" option (-m)?

   It is not secure at all. There are many ways to defeat it. Probably
   the easiest way is to simply redirect your screen output to a file as
   follows:
   "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.

  3.7 What if I forget my pass phrase?

   In a word: don't. If you forget your pass phrase, there is absolutely
   no way to recover any encrypted files. If you're concerned about
   forgetting your passphrase, you could make a copy of your secret
   keyring, then change the passphrase to something else, and then store
   the secret keyring with the changed passphrase in a safe location.

  3.8 Why do you use the term "pass phrase" instead of "password"?

   This is because most people, when asked to choose a password, select
   some simple common word. This can be cracked by a program that uses a
   dictionary to try out passwords on a system. Since most people really
   don't want to select a truly random password, where the letters and
   digits are mixed in a nonsense pattern, the term pass phrase is used
   to urge people to at least use several unrelated words in sequence as
   the pass phrase.

  3.9 What is the best way to crack PGP?

   Currently, the best attack possible on PGP itself is a dictionary
   attack on the pass phrase. This is an attack where a program picks
   words out of a dictionary and strings them together in different ways
   in an attempt to guess your pass phrase.

   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.

  3.10 If my secret key ring is stolen, can my messages be read?

   No, not unless they have also stolen your secret pass phrase, or if
   your pass phrase is susceptible to a brute-force attack. Neither part
   is useful without the other. You should, however, revoke that key and
   generate a fresh key pair using a different pass phrase. Before
   revoking your old key, you might want to add another user ID that
   states what your new key id is so that others can know of your new
   address.

  3.11 How do I choose a pass phrase?

   All of the security that is available in PGP can be made absolutely
   useless if you don't choose a good pass phrase to encrypt your secret
   key ring. Too many people use their birthday, their telephone number,
   the name of a loved one, or some easy to guess common word. While
   there are a number of suggestions for generating good pass phrases,
   the ultimate in security is obtained when the characters of the pass
   phrase are chosen completely at random. It may be a little harder to
   remember, but the added security is worth it. As an absolute minimum
   pass phrase, I would suggest a random combination of at least 8
   letters and digits, with 12 being a better choice. With a 12 character
   pass phrase made up of the lower case letters a-z plus the digits 0-9,
   you have about 62 bits of key, which is 6 bits better than the 56 bit
   DES keys. If you wish, you can mix upper and lower case letters in
   your pass phrase to cut down the number of characters that are
   required to achieve the same level of security.

   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.

  3.12 How do I remember my pass phrase?

   This can be quite a problem especially if you are like me and have
   about a dozen different pass phrases that are required in your
   everyday life. Writing them down someplace so that you can remember
   them would defeat the whole purpose of pass phrases in the first
   place. There is really no good way around this. Either remember it, or
   write it down someplace and risk having it compromised.

   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.

  3.13 How do I verify that my copy of PGP has not been tampered with?

   If you do not presently own any copy of PGP, use great care on where
   you obtain your first copy. What I would suggest is that you get two
   or more copies from different sources that you feel that you can
   trust. Compare the copies to see if they are absolutely identical.
   This won't eliminate the possibility of having a bad copy, but it will
   greatly reduce the chances.

   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 <[e-mail]>
ViaCrypt PGP 2.7.1           ViaCrypt
PGP 2.6.2i                   Stale Schumacher <[e-mail]>
PGP 2.6ui                    mathew <[e-mail]>

  3.14 I can't verify the signature on my new copy of MIT PGP with my old PGP
  2.3a!

   The reason for this, of course, is that the signatures generated by
   MIT PGP (which is what Jeff Schiller uses to sign his copy) are no
   longer readable with PGP 2.3a.

   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.

  3.15 How do I know that there is no trap door in the program?

   The fact that the entire source code for the free versions of PGP is
   available makes it just about impossible for there to be some hidden
   trap door. The source code has been examined by countless individuals
   and no such trap door has been found. To make sure that your
   executable file actually represents the given source code, all you
   need to do is to re-compile the entire program.

  3.16 I heard that the NSA put a back door in MIT PGP, and that they only
  allowed it to be legal with the back door.

   First of all, the NSA had nothing to do with PGP becoming "legal". The
   legality problems solved by MIT PGP had to do with the alleged patent
   on the RSA algorithm used in PGP.

   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!

  3.17 Is there a back door in the international version?

   No. The international version of PGP is based on an illegally exported
   version of PGP, and uses an RSA encryption/decryption library (MPILIB)
   which may violate a patent which is only valid in the USA.

   There are no intentional backdoors of any kind in the international
   version, nor is the encryption strength reduced in any way.

  3.18 Can I put PGP on a multi-user system like a network or a mainframe?

   Yes. PGP will compile for several high-end operating systems such as
   Unix and VMS. Other versions may easily be used on machines connected
   to a network.

   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.

  3.19 Can I use PGP under a "swapping" operating system like Windows or OS/2?

   Yes. PGP for DOS runs OK in most "DOS windows" for these systems, and
   PGP can be built natively for many of them as well.

   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.

   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.

  3.20 Why not use RSA alone rather than a hybrid mix of IDEA, MD5, & RSA?

   Two reasons: First, the IDEA encryption algorithm used in PGP is
   actually much stronger than RSA given the same key length. Even with a
   1024 bit RSA key, it is believed that IDEA encryption is still
   stronger, and, since a chain is no stronger than its weakest link, it
   is believed that RSA is actually the weakest part of the RSA - IDEA
   approach. Second, RSA encryption is much slower than IDEA. The only
   purpose of RSA in most public key schemes is for the transfer of
   session keys to be used in the conventional secret key algorithm, and
   to encode signatures.

  3.21 Aren't all of these security procedures a little paranoid?

   That all depends on how much your privacy means to you! Even apart
   from the government, there are many people out there who would just
   love to read your private mail. And many of these individuals would be
   willing to go to great lengths to compromise your mail. Look at the
   amount of work that has been put into some of the virus programs that
   have found their way into various computer systems. Even when it
   doesn't involve money, some people are obsessed with breaking into
   systems.

   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).

  3.22 Can I be forced to reveal my pass phrase in any legal proceedings?

   Gary Edstrom reported the following in earlier versions of this FAQ:

     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!)
     _________________________________________________________________

4. Keys

     4.1 Which key size should I use?
     4.2 Why does PGP take so long to add new keys to my key ring?
     4.3 How can I extract multiple keys into a single armored file?
     4.4 I tried encrypting the same message to the same address two
       times and got completely different outputs. Why is this?
     4.5 How do I specify which key to use when an individual has 2 or
       public keys and the very same user ID on each, or when 2 different
       users have the same name?
     4.6 What does the message "Unknown signator, can't be checked" mean?
     4.7 How do I get PGP to display the trust parameters on a key?
     4.8 How can I make my key available via finger?
     4.9 Should I put my key in my .signature?
     4.10 Can a public key be forged?
     4.11 How do I detect a forged key?
     _________________________________________________________________

  4.1 Which key size should I use?

   PGP gives you three choices for key size: 512, 768, or 1024 bits. You
   can also specify the number of bits your key should have if you don't
   like any of those numbers. The larger the key, the more secure the RSA
   portion of the encryption is. The only place where the key size makes
   a large change in the running time of the program is during key
   generation. A 1024 bit key can take 8 times longer to generate than a
   384 bit key. Fortunately, this is a one time process that doesn't need
   to be repeated unless you wish to generate another key pair.

   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.

  4.2 Why does PGP take so long to add new keys to my key ring?

   The time required to check signatures and add keys to your public key
   ring tends to grow as the square of the size of your existing public
   key ring. This can reach extreme proportions, especially if you are
   trying to add the entire public keyring you retrieved from a keyserver
   (see question 8.1) to your own keyring.

   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.

  4.3 How can I extract multiple keys into a single armored file?

   A number of people have more than one public key that they would like
   to make available. One way of doing this is executing the "-kxa"
   command for each key you wish to extract from the key ring into
   separate armored files, then appending all the individual files into a
   single long file with multiple armored blocks. This is not as
   convenient as having all of your keys in a single armored block.

   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>
  end

   An equivalent DOS command would be:
   " for %a in (name1 name2 name3 ...) do pgp -kx %a keys.pgp <keyring> "

  4.4 I tried encrypting the same message to the same address two times and got
  completely different outputs. Why is this?

   Every time you run PGP, a different session key is generated. This
   session key is used as the key for IDEA. As a result, the entire
   header and body of the message changes. You will never see the same
   output twice, no matter how many times you encrypt the same message to
   the same address. This adds to the overall security of PGP.

   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.

  4.5 How do I specify which key to use when an individual has 2 or public keys
  and the very same user ID on each, or when 2 different users have the same
  name?

   Instead of specifying the user's name in the ID field of the PGP
   command, you can use the key ID number. The format is 0xNNNNNNNN where
   NNNNNNNN is the user's 8 character key ID number. It should be noted
   that you don't need to enter the entire ID number, a few consecutive
   digits from anywhere in the ID should do the trick. The key ID shows
   up directly after the key size when you do "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> [e-mail]
    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.

  4.6 What does the message "Unknown signator, can't be checked" mean?

   It means that the key used to create that signature does not exist in
   your public keyring. If at sometime in the future, you happen to add
   that key to your public keyring, then the signature line will read
   normally. It is completely harmless to leave these non-checkable
   signatures in your public keyring. They neither add to nor take away
   from the validity of the key in question.

  4.7 How do I get PGP to display the trust parameters on a key?

   You can only do this when you run the -kc option by itself on the
   entire database. The parameters will not be shown if you give a
   specific ID on the command line. The correct command is: "pgp -kc".
   The command "pgp -kc smith" will not show the trust parameters for
   smith.

  4.8 How can I make my key available via finger?

   The first step is always to extract the key to an ASCII-armored text
   file with "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.

  4.9 Should I put my key in my .signature?

   No. Although it is important to spread your key as far as possible, it
   is a lot better to send it to a keyserver (see 8.1) or to make it
   available via finger (see 4.8), or perhaps as a link off your WWW
   homepage. This way, people who need your key will be able to get it,
   and you don't send it out to a lot of uninterested people every time
   you mail or post something.

   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).

  4.10 Can a public key be forged?

   There are four components in a public key, each of which has its own
   weaknesses. The four components are user IDs, key IDs, signatures and
   the key fingerprint.

The user ID

   It is quite easy to create a fake user ID. If a user ID on a key is
   changed, and the key is then added to another keyring, the changed
   user ID will be seen as a new user ID and so it gets added to the ones
   already present. This implies that an unsigned user ID should never be
   trusted. Question 6.3 discusses this in more detail.

The key ID

   It is possible to create a key with a chosen key ID. Paul Leyland
   <[e-mail]> explains:

     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.

Signatures

   There are currently no methods to create a fake signature for a user
   ID on someone's key. To create a signature for a user ID, you need the
   signatory's secret key. A signature actually signs a hash of the user
   ID it applies to, so you can't copy a signature from one user ID to
   another or modify a signed user ID without invalidating the signature.

The key fingerprint

   Yes, it is possible to create a public key with the same fingerprint
   as an existing one, thanks to a design misfeature in PGP. The fake key
   will not be of the same length, so it should be easy to detect.
   Usually such keys have odd key lengths.

   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.

  4.11 How do I detect a forged key?

   As explained in question 4.10, each component of the public key can be
   faked. It is, however, not possible to create a fake key for which all
   the components match.

   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.
     _________________________________________________________________

5. Message Signatures

     5.1 What is message signing?
     5.2 How do I sign a message and keep it readable?
     5.3 Can't you just forge a signature by copying the signature block
       to another message?
     5.4 Are PGP signatures legally binding?
     5.5 Is the date on a PGP signature reliable?
     _________________________________________________________________

  5.1 What is message signing?

   Let's imagine that you received a letter in the mail from someone you
   know named John Smith. How do you know that it was really John who
   sent you the letter and not someone else who simply forged his name?
   With PGP, it is possible to apply a digital signature to a message
   that is impossible to forge. If you already have a trusted copy of
   John's public encryption key, you can use it to check the signature on
   the message. It would be impossible for anybody but John to have
   created the signature, since he is the only person with access to the
   secret key necessary to create the signature. In addition, if anybody
   has tampered with an otherwise valid message, the digital signature
   will detect the fact. It protects the entire message.

  5.2 How do I sign a message and keep it readable?

   Sometimes you are not interested in keeping the contents of a message
   secret, you only want to make sure that nobody tampers with it, and to
   allow others to verify that the message is really from you. For this,
   you can use clear signing. Clear signing only works on text files, it
   will not work on binary files. The command format is:
   " 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.

  5.3 Can't you just forge a signature by copying the signature block to
  another message?

   No. The reason for this is that the signature contains information
   (called a "message digest" or a "one-way hash") about the message it's
   signing. When the signature check is made, the message digest from the
   message is calculated and compared with the one stored in the
   encrypted signature block. If they don't match, PGP reports that the
   signature is bad.

  5.4 Are PGP signatures legally binding?

   It has become legal in many places now. At least one company is using
   PGP digital signatures on contracts to provide "quick agreement" via
   E-mail, allowing work to proceed without having to wait for the paper
   signature.

   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 is available from:
   http://access.wa.net/sb6423_info/index.html

   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.

  5.5 Is the date on a PGP signature reliable?

   No. The date and time you see when you verify a PGP signature on a
   file (often called a timestamp) is the time and date the computer was
   set to when the signature was created. On most computers, it is
   extremely easy to reset the date and time to any time you want, so you
   can generate documents with a forged timestamp.

   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.
     _________________________________________________________________

6. Key Signatures

     6.1 What is key signing?
     6.2 How do I sign a key?
     6.3 Should I sign my own key?
     6.4 Should I sign X's key?
     6.5 How do I verify someone's identity?
     6.6 How do I know someone hasn't sent me a bogus key to sign?
     6.7 What's a key signing party?
     6.8 How do I organize a key signing party?
     _________________________________________________________________

  6.1 What is key signing?

   OK, you just got a copy of John Smith's public encryption key. How do
   you know that the key really belongs to John Smith and not to some
   impostor? The answer to this is key signatures. They are similar to
   message signatures in that they can't be forged. Let's say that you
   don't know that you have John Smith's real key. But let's say that you
   DO have a trusted key from Joe Blow. Let's say that you trust Joe Blow
   and that he has added his signature to John Smith's key. By inference,
   you can now trust that you have a valid copy of John Smith's key. That
   is what key signing is all about. This chain of trust can be carried
   to several levels, such as A trusts B who trusts C who trusts D,
   therefore A can trust D. You have control in the PGP configuration
   file over exactly how many levels this chain of trust is allowed to
   proceed.

   The options (which can be set in PGP's configuration file, CONFIG.TXT)
   to control this are

   "Cert_Dept = n"
          This indicates the maximum depth of your "web of trust". A key
          which is n keys "away" from your own key will not be used to
          introduce other keys.

   "Completes_Needed = n"
          This indicates the number of completely trusted keys required
          to make a key valid. A key is completely trusted if it is
          valid, and you choose option "4. Yes, always" when PGP asked
          you if you trust this person to introduce others.

   "Marginals_Needed = n"
          This indicates the number of marginally trusted keys required
          to make a key valid. A key is marginally trusted if you
          answered "3. Sometimes" to the question above. In all other
          cases, the key is not trusted at all.

   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/.

  6.2 How do I sign a key?

   Execute the following command from the command prompt:
   "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.

  6.3 Should I sign my own key?

   Yes, you should sign each personal ID on your key. This will help to
   prevent anyone from placing a phony address in the ID field of the key
   and possibly having your mail diverted to them. Of course they can't
   read the encrypted mail, but you won't see it at all. And even worse,
   adding a fake user ID reading "Please use key 0x416A1A35 from now on"
   can mean someone else will use the imposter's key with your name on
   it, rather than your own.

   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 <[e-mail]>
sig       416A1A35             Arnoud Engelfriet <[e-mail]>
                              *** <[e-mail]> now INVALID!
sig       416A1A35             Arnoud Engelfriet <[e-mail]>
                              Galactus <[e-mail]>
sig       3602A619             Stephen Hopkins <[e-mail]>
sig       DD63EF3D             Frank Castle <[e-mail]>
sig       416A1A35             Arnoud Engelfriet <[e-mail]>
                              Arnoud Engelfriet <[e-mail]>
sig       390E3FB1             Martijn Heemels <[e-mail]>
sig       DA87C0C7             Edgar W. Swank   <[e-mail]>
sig       416A1A35             Arnoud Engelfriet <[e-mail]>

   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.

  6.4 Should I sign X's key?

   Signing someone's key is your indication to the world that you believe
   that key to rightfully belong to that person, and that person is who
   he purports to be. Other people may rely on your signature to decide
   whether or not a key is valid, so you should not sign capriciously.

   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.

  6.5 How do I verify someone's identity?

   It all depends on how well you know them. Relatives, friends and
   colleagues are easy. People you meet at conventions or key-signing
   sessions require some proof like a driver's license or credit card.

  6.6 How do I know someone hasn't sent me a bogus key to sign?

   It is very easy for someone to generate a key with a false ID and send
   e-mail with fraudulent headers, or for a node which routes the e-mail
   to you to substitute a different key. Finger servers are harder to
   tamper with, but not impossible. The problem is that while public key
   exchange does not require a secure channel (eavesdropping is not a
   problem) it does require a tamper-proof channel (key-substitution is a
   problem).

   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.

  6.7 What's a key signing party?

   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.

  6.8 How do I organize a key signing party?

   Though the idea is simple, actually doing it is a bit complex, because
   you don't want to compromise other people's private keys or spread
   viruses (which is a risk whenever floppies are swapped willy-nilly).
   Usually, these parties involve meeting everyone at the party,
   verifying their identity and getting key fingerprints from them, and
   signing their key at home.

   Derek Atkins <[e-mail]> 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:
    1. You announce the keysigning session, and ask everyone who plans to
       come to send you (or some single person who will be there) their
       public key. The RSVP also allows for a count of the number of
       people for step 3.
    2. You compile the public keys into a single keyring, run "pgp -kvc"
       on that keyring, and save the output to a file.
    3. Print out N copies of the "pgp -kvc" file onto hardcopy, and bring
       this and the keyring on media to the meeting.
    4. At the meeting, distribute the printouts, and provide a site to
       retreive the keyring (an ftp site works, or you can make floppy
       copies, or whatever -- it doesn't matter).
    5. When you are all in the room, each person stands up, and people
       vouch for this person (e.g., "Yes, this really is Derek Atkins --
       I went to school with him for 6 years, and lived with him for 2").
    6. Each person securely obtains their own fingerprint, and after
       being vouched for, they then read out their fingerprint out loud
       so everyone can verify it on the printout they have.
    7. After everyone finishes this protocol, they can go home, obtain
       the keyring, run "pgp -kvc" on it themselves, and re-verify the
       bits, and sign the keys at their own leisure.
    8. To save load on the keyservers, you can optionally send all
       signatures to the original person, who can coalate them again into
       a single keyring and propagate that single keyring to the
       keyservers and to each individual.
     _________________________________________________________________

7. Revoking a key

     7.1 My secret key ring has been stolen or lost, what do I do?
     7.2 I forgot my pass phrase. Can I create a key revocation
       certificate?
     7.3 How do I create a key revocation certificate?
     7.4 How do I indicate that my key is invalid when I don't have the
       secret key anymore?
     _________________________________________________________________

  7.1 My secret key ring has been stolen or lost, what do I do?

   Assuming that you selected a good solid random pass phrase to encrypt
   your secret key ring, you are probably still safe. It takes two parts
   to decrypt a message, the secret key ring, and its pass phrase. The
   secret key is encrypted with the passphrase before it is stored in the
   secret keyring.

   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.

  7.2 I forgot my pass phrase. Can I create a key revocation certificate?

   As Phil Zimmermann put it: "I'm sorry, you're hosed."
   You can't, since the pass phrase is required to create the
   certificate. You must decrypt the secret key to sign the revocation
   statement, and for that you need your pass phrase.

   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.

  7.3 How do I create a key revocation certificate?

   The easiest way to do this is:
    1. Make a backup of your public and secret keyrings.
    2. Revoke your key with "pgp -kd youruserid".
    3. Extract the revoked key to a file with "pgp -kxa youruserid". This
       file is what the manual calls the "revocation certificate."
    4. Store the certificate in a safe location, for example on a floppy
       which you keep someplace else.
    5. Restore the backed-up keyrings.

  7.4 How do I indicate that my key is invalid when I don't have the secret key
  anymore?

   This is a very tricky situation, and should be avoided at all costs.
   The easiest way is to prepare a key revocation certificate (See 7.3
   for details on how to do this) before you need it, so you can always
   revoke the key, even without the secret key.

   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.
     _________________________________________________________________

8. Public Key Servers

     8.1 What are the Public Key Servers?
     8.2 What public key servers are available?
     8.3 What is the syntax for the key server commands?
     _________________________________________________________________

  8.1 What are the Public Key Servers?

   Public Key Servers exist for the purpose of making your public key
   available in a common database where everybody can have access to it
   for the purpose of encrypting messages to you. Anyone who wants to
   write you a message, or to check a signature on a message from you,
   can get your key from the keyserver, so he doesn't have to bother you
   with it.

   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.

  8.2 What public key servers are available?

   There is now a clean interface to key servers. The pgp.net domain was
   founded for this purpose, and offers an easy and fast way to obtain
   people's public keys.

   You can access the keyserver in e-mail, by sending mail to
   [e-mail] 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.

  8.3 What is the syntax for the key server commands?

   The key server expects to see one of the following commands placed in
   the subject field. Note that only the ADD command uses the body of the
   message.

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>)
MGET <userid> Get all keys which match regular expression <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. Examples for the MGET command:

MGET michael            Gets all keys which have "michael" in them
MGET iastate            All keys which contain "iastate"
MGET bill.*@msn.com     All keys from MSN with usernames starting with "bill"
MGET E8F605A5|5F3E38F5  Those two keyid's

   Note that in the MGET command, you don't have to use the "0x" prefix
   if you want specific keys.

   One word about regexps: These are not the same as the wildcards Unix
   shells and MSDOS uses. a * isn't ``match anything'' it means ``match
   zero or more of the previous character'' like:

        a.*  matches anything beginning with an a
        ab*c matches ac, abc, abbc, etc.

   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
     _________________________________________________________________

9. Bugs

     9.1 Where do I send bug reports?
     9.2 What bugs have been found in PGP?

  9.1 Where do I send bug reports?

   Bugs related to MIT PGP should be sent to [e-mail]. You will
   want to check http://www.mit.edu:8001/people/warlord/pgp-faq.html
   before reporting a bug to make sure that the bug hasn't been reported
   already. If it is a serious bug, you should also post it to
   comp.security.pgp.announce or .tech. Serious bugs are bugs that affect
   the security of the program, not compile errors or small logic errors.

   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.

  9.2 What bugs have been found in PGP?

   The following list of bugs is limited to version 2.4 and later, and is
   limited to the most commonly seen and serious bugs. For bugs in
   earlier versions, refer to the documentation included with the
   program. If you find a bug not on this list, follow the procedure
   above for reporting it.
     * The PGP 2.6.2 sources do not build under Linux/ELF. To build an
       ELF binary for PGP 2.6.2, two changes to source files 80386.S and
       zmatch.S are necessary. Both files contain an #ifdef directive
       that needs to be changed. Change "#ifndef SYSV" to
       "#if !defined(SYSV) && !defined(__ELF__)" and change "#ifdef SYSV"
       to
       "if defined(SYSV) || defined(__ELF__)".
     * MIT PGP 2.6 had a bug in the key generation process which made
       keys generated by it much less random. Fixed in 2.6.1.
     * All versions of PGP except MIT PGP 2.6.2 are susceptible to a
       "buglet" in clearsigned messages, making it possible to add text
       to the beginning of a clearsigned message. The added text does not
       appear in the PGP output after the signature is checked. MIT PGP
       2.6.2 now does not allow header lines before the text of a
       clearsigned message and enforces RFC 822 syntax on header lines
       before the signature. Since this bug appears at checking time,
       however, you should be aware of this bug even if you use MIT PGP
       2.6.2 - the reader may check your signed message with a different
       version and not read the output.
     * MIT PGP 2.6.1 was supposed to handle keys between 1024 and 2048
       bits in length, but could not. Fixed in 2.6.2.
     * MIT PGP 2.6.2 was supposed to enable the generation of keys up to
       2048 bits after December 25, 1994; a one-off bug puts that upper
       limit at 2047 bits instead. It has been reported that this problem
       does not appear when MIT PGP is compiled under certain
       implementations of Unix. The problem is fixed in versions 2.7.1
       and 2.6.2i, as well as the Mac versions.
     * PGP 2.6ui continues to exhibit the bug in 2.3a where
       conventionally encrypted messages, when encrypted twice with the
       same pass phrase, produce the same ciphertext.
     * MIT MacPGP cannot find your secret key when your user ID is not
       specified, even though it can find the secret keyring. This is due
       to an uninitialized pointer, which is supposed to point to your
       user ID. The workaround is simple: edit the configuration file so
       it has "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.
     * ViaCrypt has reported a bug in freeware PGP affecting at least PGP
       2.3a and MIT PGP 2.6, 2.6.1, and 2.6.2. This bug affects
       signatures made with keys between 2034 and 2048 bits in length,
       causing them to be corrupted. Practically speaking, this bug only
       affects versions of PGP that support the longer key lengths.
       ViaCrypt reports that this only seems to be a problem when running
       PGP on a Sun SPARC-based workstation. ViaCrypt PGP 2.7.1 and PGP
       2.6.2i do not suffer from this bug. The following patch will fix
       the problem in MIT PGP 2.6.2:

<===== 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)
     * The initial release of PGP 2.6.2i contained a bug related to
       clearsigned messages; signed messages containing international
       characters would always fail. For that reason, it was immediately
       pulled from distribution and re-released later, minus the bug. If
       you have problems with 2.6.2i, make sure you downloaded your copy
       after 7 May 1995.
     * As reported by Steven Markowitz <[e-mail]>, the
       following bugs exist in PGP 4.0 Business Edition (the commercial
       version):
         1. Signature retirement does not work. When I retire a key
            signature, PGP still treats the key as signed. If I remove
            the signature from pubring.pgp, but leave the retirement
            certificate in the keyring, PGP still treats the key as
            signed.
         2. Although encrypt-only keys cannot be used to sign documents,
            PGP allows them to be used to make key signatures.
     * The international version of PGP has the undocumented
       "+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.
     _________________________________________________________________

10. Recommended Reading

  Books on PGP

   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.

  Books on cryptography in general

   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

  PGP- or cryptograph-related articles

   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)

  Usenet newsgroups

   alt.anonymous
   alt.privacy.anon-server
          Discussion of anonymity and anon remailers
   alt.anonymous.messages
          For anonymous encrypted message transfer
   alt.privacy.clipper
          Clipper, Capstone, Skipjack, Key Escrow
   alt.security
          General security discussions
   comp.security.pgp.announce
          New PGP versions, utilities, bug reports and such. (Moderated)
   comp.security.pgp.discuss
          PGP and its implications.
   comp.security.pgp.tech
          Use of PGP, bug reports and help.
   comp.security.pgp.resources
          PGP related resources, information and more.
   alt.security.pgp
          General discussion of PGP
   alt.security.ripem
          Discussion of RIPEM
   alt.security.keydist
          Key distribution via Usenet
   alt.society.civil-liberty
          General civil liberties, including privacy
   comp.org.eff.news
          News reports from the Electronic Frontier Foundation
   comp.org.eff.talk
          Discussion of EFF related issues
   comp.patents
          Discussion of S/W patents, including RSA
   comp.risks
          Some mention of crypto and wiretapping
   comp.society.privacy
          General privacy issues
   comp.security.announce
          Announcements of security holes
   misc.legal.computing
          Software patents, copyrights, computer laws
   sci.crypt
          Methods of data encryption/decryption
   sci.math
          General math discussion
   talk.politics.crypto
          General talk on crypto politics
     _________________________________________________________________

11. General Tips

  11.1 Are there undocumented features in PGP?

   Several undocumented command-line switches exist. Peter Simons
   <[e-mail]> has provided a comprehensive list:
     * The "-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.
     * With the "-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.
     * The "-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.
     * By putting "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.
     * To create a file containing n random bytes, use the "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.

  11.2 Can I use PGP on a BBS?

   Some BBS sysops may not permit you to place encrypted mail or files on
   their boards. Just because they have PGP in their file area, that
   doesn't necessarily mean they tolerate you uploading encrypted mail or
   files - so do check first.

   Fido net mail is even more sensitive. You should only send encrypted
   net mail after checking that:
    1. Your sysop permits it.
    2. Your recipient's sysop permits it.
    3. The mail is routed through nodes whose sysops also permit it.

   Get your public key signed by as many individuals as possible. It
   increases the chances of another person finding a path of trust from
   himself to you.

   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.
     _________________________________________________________________

   Last updated: 17 Dec 1997.
   Copyright (C) 1996 by Arnoud Engelfriet. Comments, additions and
   suggestions can be sent to <[e-mail]>.
   Generated by Orb v1.3 for OS/2
   (http://www.cinenet.net/users/cberry/orbinfo.html).