PC-Online 1998 February/PCOnline_02_1998.iso/filesbbs/frei/pgpfaq.arj/PGPFAQ.TXT

PGP Signed Message | 1995-11-22 | 148KB | 3,465 lines

-----BEGIN PGP SIGNED MESSAGE-----

                     Frequently Asked Questions
                          alt.security.pgp
                            25 May 1995

========================================================================
                       IMPORTANT DISCLAIMER!

     The use of PGP raises  a number of political  and legal
     issues.  I AM NOT a lawyer and AM NOT qualified to give
     any legal opinions.  Nothing in this document should be
     interpreted  as legal advice.   If you  have any  legal
     questions concerning the use of PGP, you should consult
     an  attorney who  specializes in  patent and/or  export
     law.   In any case,  the law  will vary from country to
     country.
========================================================================

Introduction

This is the list of Frequently Asked Questions for the Pretty Good
Privacy (PGP) encryption program written by Phillip Zimmermann.  It
is one of two FAQ lists for the newsgroup alt.security.pgp.

The other FAQ list is the "Where to Get PGP" FAQ, which is written and
maintained by Michael Paul Johnson <[e-mail]>.  It covers many
topics this one does not; in particular, it contains more complete
information on sites that distribute PGP and the legal and technical
questions surrounding its distribution.  You may get a current copy
from:

  ftp://ftp.csn.net/mpj/getpgp.asc

This FAQ is slanted towards the DOS or Unix users of PGP and many of
the examples given may only apply to them.  For other systems, I would
like to direct your attention to the following documents:

  MAC: "Here's How to MacPGP!" by Xenon <[e-mail]>
  Archimedes PGP comes with its own PGPhints file.
  Send e-mail to [e-mail] for a list of PGP tips.

It should be noted that most of the questions and answers concerning
PGP apply equally well to the ViaCrypt(tm) version.

Material for this FAQ has come from many different sources.  It would
be difficult to name each of the contributors individually, but I
would like to thank them as a group for their assistance.

A current copy of this FAQ can be retrieved from my WWW home page:

  http://www.prairienet.org/~jalicqui/pgpfaq.txt

or via FTP:

  ftp://ftp.prairienet.org/pub/providers/pgp/pgpfaq.?

The ? indicates the file format: clearsigned text (txt), gzipped
version of clearsigned text (txt.gz), PGP-signed-and-compressed binary
(pgp), or ASCII armored PGP-signed-and-compressed file (asc).

The PGP FAQ is also posted to news.answers and alt.answers, and can be
found in any of the standard FAQ repositories in the three-part form
it is posted in.

Permission is granted to copy, archive, or otherwise make this FAQ
available in any way you please, with only the following restriction:
that in every place where this FAQ may be accessed, it must also be
reasonably easy for a user to access a copy of the FAQ with its PGP
signature(s) from me intact.  This ensures that uncorrupted copies of
the FAQ get propagated where those who care can check them, and also
preserves attributions, etc.  If you HTMLize this document, you can
tag the two links mentioned above if you want to avoid storing
multiple copies of the FAQ.

Future plans for the FAQ:

 - Mac section!
 - hypertexting it and making it available in various forms (LaTeX,
   HTML, texinfo, or some such)

Any corrections or suggestions should be sent to me.

Jeff Licquia
[e-mail]

========================================================================

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 alt.security.pgp?
  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.2 read my version 2.3 message?
  2.2.  Why can't a person using version 2.3 read my version 2.6 message?
  2.3.  Why does PGP complain about checking signatures every so often?
  2.4.  Why does it take so long to encrypt/decrypt messages?
  2.5.  How do I create a secondary key file?
  2.6.  How does PGP handle multiple addresses?
  2.7.  Where can I obtain scripts to integrate pgp with my email or news
        reading system?
  2.8.  How can I decrypt messages I've encrypted to others?
  2.9.  Why can't I generate a key with PGP for Unix?
  2.10. When I clearsign a document in PGP, it adds a "dash-space" to
        several of my lines.  What gives?

  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. Can I put PGP on a multi-user system like a network or a mainframe?
  3.18. Can I use PGP under a "swapping" operating system like Windows
        or OS/2?
  3.19. Why not use RSA alone rather than a hybrid mix of IDEA, MD5, & RSA?
  3.20. Aren't all of these security procedures a little paranoid?
  3.21. 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 different
        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 more
        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?

  5.  Message Signatures
  5.1.  What is message signing?
  5.2.  How do I sign a message while still leaving 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?

  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?

  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 of the key server commands?

  9.  Bugs

  10. Recommended Reading

  11. General Tips

  Appendix I    - PGP add-ons and Related Products
  Appendix II   - Glossary of Cryptographic Terms
  Appendix III  - Cypherpunks
  Appendix IV   - Testimony of Philip Zimmermann to Congress
  Appendix V    - Announcement of Philip Zimmermann Defense Fund
  Appendix VI   - A Statement from ViaCrypt Concerning ITAR

========

1.    Introductory Questions

========

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!  -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! (Compare to ViaCrypt PGP at $98!)

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 ViaCrypt 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 ViaCrypt PGP.
ViaCrypt PGP has other advantages as well, most notably a limited
license to export it to foreign branch offices.  See below, under
question 1.10, for information on how to contact ViaCrypt.

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]

  ++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, and Iraq.

*** NEWS FLASH ***

On April 3, 1995, Boris Yeltsin issued a decree formally banning
encryption with methods not approved by the state.  This would,
presumably, include PGP.  Thus, Russia must be added to the short list
above.

*** END NEWS FLASH ***

The legal status of encryption in many countries has been placed on
the World Wide Web.  You can access it from:

  http://web.cnam.fr/Network/Crypto/

========

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 and Canada. 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 recently been filed by the
EFF challenging the ITAR regulations; thus, they may be relaxed to
allow encryption technology to be exported.

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?

You would think that's an easy question to answer!

At the moment, there are four 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.

MIT PGP 2.6.2 is the current "official" freeware version.  It has been
developed both with Phil Zimmermann's approval and active involvement.
It contains several bug fixes and enhancements over 2.3a, and it
avoids the patent question surrounding other versions of PGP by using
the RSAREF library for some of its functions.  This library was
developed by RSA Data Security, Inc., and is (basically) free for
noncommercial use.  As part of MIT's agreement with RSADSI, all
versions of MIT PGP generate encrypted messages that cannot be
decrypted with PGP 2.3a or previous versions.

ViaCrypt PGP 2.7.1 is the current "official" commercial version.  It
is available from ViaCrypt, a company out of Arizona, and also has
Phil's approval and involvement.  See below for details on this
version.

PGP 2.6.2i ("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.

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.

========

1.8.  Is there an archive site for alt.security.pgp?

[e-mail] (Laszlo Baranyi) says:

"My memory says that ripem.msu.edu stores a backlog of both
alt.security.pgp, and sci.crypt. But that site is ONLY open for ftp
for those that are inside US."

========

1.9.  Is there a commercial version of PGP available?

Yes; by arrangement with the author of PGP, a company called ViaCrypt
is marketing a version of PGP that is almost identical to the freeware
version. Each can read or write messages which the other can
understand.

ViaCrypt reports:

- -----
If you are a commercial user of PGP in the USA or Canada, contact
Viacrypt in Phoenix, Arizona, USA.  The commercial version of PGP
is fully licensed to use the patented RSA and IDEA encryption
algorithms in commercial applications, and may be used in
corporate and government environments in the USA and Canada.  It
is fully compatible with, functionally the same as, and just as
strong as the freeware version of PGP. Due to limitations on
ViaCrypt's RSA distribution license, ViaCrypt only distributes
executable code and documentation for it, but they are working on
making PGP available for a variety of platforms.  Call or write
to them for the latest information.  The latest version number
for Viacrypt PGP is 2.7.  [Note: Since this statement was issued,
ViaCrypt has updated ViaCrypt PGP to 2.7.1.]

Here is a brief summary of Viacrypt's currently-available
products:

1. ViaCrypt PGP for Windows (3.1).   Prices start at $124.98

2. ViaCrypt PGP for Macintosh, 680x0 or PowerPC, System 6.04 or
   later.    Prices start at $124.98

3. ViaCrypt PGP for MS-DOS.  Prices start at $99.98

4. ViaCrypt PGP for UNIX.  Includes executables for the following
   platforms:

     SunOS 4.1.x (SPARC)
     Solaris 2.3
     IBM RS/6000 AIX
     HP 9000 Series 700/800 UX
     SCO 386/486 UNIX
     SGI IRIX
     AViiON DG-UX(88/OPEN)

   Prices start at $149.98

     Executables for the following additional platforms are
     available upon request for an additional $30.00 charge.

     BSD 386
     Ultrix MIPS DECstation 4.x
     DEC Alpha OSF/1
     NeXTSTEP

5. ViaCrypt PGP for WinCIM/CSNav.  A special package for users of
   CompuServe.  Prices start at $119.98

If you wish to place an order please call 800-536-2664 during the
hours of 8:30am to 5:00pm MST, Monday - Friday.  We accept VISA,
MasterCard, AMEX and Discover credit cards.

If you have further questions, please feel free to contact me.

Best Regards,
Paul E. Uhlhorn
Director of Marketing, ViaCrypt Products
Mail:       9033 N. 24th Avenue
            Suite 7
            Phoenix, AZ  85021-2847
Phone:      [phone]
Fax:        [phone]
Internet:   [e-mail]
Compuserve: 70304,41
- -----

They have also reported recently that they have gained a general
export license for exporting ViaCrypt PGP to foreign subsidiaries of
USA-based companies.  Contact ViaCrypt for details.

========

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

Not yet.  PGP 3.0, when it is released, is supposed to have support
for doing this.  The PGP development team has even released a
preliminary API for the library; you can get it from:

  ftp://ftp.netcom.com/pub/dd/ddt/crypto/crypto_info/950212_pgp3spec.txt

The development team has expressed that this is not a definitive spec;
some of it is already out of date.  It's good for getting the general
idea, though.  Send comments concerning the spec to [e-mail].

In the meantime, you can write your programs to call the PGP program
when necessary.  In C, for example, you would likely use the system()
or spawn...() functions to do this.

========

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, 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 2.6.2:

Due to the ITAR regulations (described above), 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

ViaCrypt PGP 2.7.1:

ViaCrypt PGP is not generally available for FTP; it is commercial
software.  It is, furthermore, not available outside the United States
or Canada except under special circumstances.  See above (question
1.9) for contact information.

PGP 2.6.2i:

As Norway is not limited by ITAR, no hoops are needed to get this
version:

  http://www.ifi.uio.no/~staalesc/PGP/home.html
  ftp://ftp.ox.ac.uk/pub/crypto/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.

PGP 2.6ui:

  ftp://ftp.mantis.co.uk/pub/cryptography/
  http://www.mantis.co.uk/pgp/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.

Web/Mosaic/Lynx:

    Fran Litterio's Crypto Page (from the Virtual Library)
      http://draco.centerline.com:8080/~franl/crypto.html
    Using Microsoft Windows with PGP
      http://www.lcs.com/winpgp.html
    Derek Atkins' Official Bug List for MIT PGP
      http://www.mit.edu:8001/people/warlord/pgp-faq.html
    The Phil Zimmermann Legal Defense Fund Page
      http://www.netresponse.com/zldf
    The MCIP/Macintosh Cryptography Page
      http://uts.cc.utexas.edu/~grgcombs/htmls/crypto.html
    Jeff Licquia's Home Page
      http://www.prairienet.org/~jalicqui

FTP Sites:

    ftp://ripem.msu.edu/pub/crypt/
    ftp://ftp.dsi.unimi.it/pub/security/crypt/
    ftp://ftp.csua.berkeley.edu/pub/cypherpunks/

News Groups:

    alt.anonymous               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
    alt.security.index          index to alt.security
    alt.security.pgp            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.compression            discussion of compression algorithms
    comp.org.eff.news           News reports from EFF
    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

========

2.   Very Common Questions and Problems

========

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

You might try adding "+pkcs_compat=0" to your command line as follows:
"pgp -seat +pkcs_compat=0 <filename>" By default, versions 2.3 and
later of PGP uses a different header format that is not compatible
with earlier versions of PGP. Inserting this option into the command
will force PGP to use the older header format. You can also set this
option in your config.txt file, but this is not recommended, as the
newer versions of PGP cannot understand the old signature format.

========

2.2. Why can't a person using version 2.x 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 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.

========

2.3. 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.  (See question 2.1.)  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.

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

========

2.5. 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.6. How does PGP handle multiple addreses?

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.7. 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.  See below, in Appendix I, for a list of such programs.

A set of scripts was distributed with PGP for doing this.  Since these
scripts were considered out of date, they have been removed from the
MIT distribution.

========

2.8. 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 regular encryption, it's impossible unless you encrypted to
yourself as well.  Sorry!

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

There are two solutions: set the PGPPASS environment variable to point
to the location of your key rings, or run a "mkdir $HOME/.pgp" before
generating your key.

========

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

========

3. Security Questions

========

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.

========

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.

========

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

========

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

One RSA-encrypted message has been cracked publicly.

When the inventors of RSA first published the algorithm, they
encrypted a sample message with it and made it available along with
the public key used to encrypt the message.  They offered $100 to the
first person to provide the plaintext message.  This challenge is
often called "RSA-129" because the public key used was 129 digits,
which translates to approximately 430 bits.

Recently, an international team coordinated by Paul Leyland, Derek
Atkins, Arjen Lenstra, and Michael Graff successfully factored the
public key used to encrypt the RSA-129 message 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.  (A MIPS-year is approximately the amount of computing
done by a 1 MIPS [million instructions per second] computer in one
year.)

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

========

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. I use the following technique:
I have a backup copy of my secret key ring on floppy, along with a
sealed envelope containing the pass phrase. I keep these two items in
separate safe locations, neither of which is my home or office. The
pass phrase used on this backup copy is different from the one that I
normally use on my computer. That way, even if some stumbles onto the
hidden pass phrase and can figure out who it belongs to, it still
doesn't do them any good, because it is not the one required to unlock
the key on my computer.

========

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

========

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. I don't do this myself
because I hate having to manipulate the shift key while entering a
pass phrase.

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.

A good treatise on the subject is available which discusses the use of
"shocking nonsense" in pass phrases.  It is written by Grady Ward, and
can be found on Fran Litterio's crypto page:

  http://draco.centerline.com:8080/~franl/pgp/pgp-passphrase-faq.html

========

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.

========

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, below, 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. 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.  As
an example of this, my own home computer runs Linux, a Unix clone.  As
I (and my wife) are the only users of the computer, I feel that the
risks of crackers invading my system and stealing my pass phrase are
minimal.

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.

========

3.18. 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.19. 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, or
to encode signatures.

========

3.20. 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.21. 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.  Please
see the disclaimer at the top of part 1.

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 precedence 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?

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.2i, 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!

========

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.

Gary Edstrom remarked (a long time ago):

I just recently added the entire 850KB public key ring form one of the
key servers to my local public key ring. Even on my 66MHz 486 system,
the process took over 10 hours.

========

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.

I would like to thank Robert Joop <[e-mail]> for
supplying the following method which is simpler than the method that I
had previously given.

solution 1:

pgp -kxaf uid1 >  extract
pgp -kxaf uid2 >> extract
pgp -kxaf uid3 >> extract

Someone who does a `pgp extract` processes the individual keys, one by
one. that's inconvinient.

solution 2:

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/csh
  foreach name (name1 name2 name3 ...)
  pgp -kx $name /tmp/keys.pgp <keyring>
  end

or:

  #!/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
different 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.

========

4.5.  How do I specify which key to use when an individual has 2 or
more 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.  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
work key:

    pgp -e <filename> "Jeff Licquia"
    pgp -e <filename> [e-mail]
    pgp -e <filename> 0xCF45DD0D

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 database. If at sometime in the future, you happen to add that
key to your database, then the signature line will read normally. It
is completely harmless to leave these non-checkable signatures in your
database. 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.  Ask your system administrator is you have problems with
this.

========

5.   Message Signatures

========

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 John was really the person who sent
you the letter and that someone else 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 while still leaving 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.

========

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's still too early to tell.  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.  Two USA states (Utah and Wyoming) have passed laws
recently giving digital signatures binding force for certain kinds of
transactions.  The Wyoming law is available from:

gopher://ferret.state.wy.us/00/wgov/lb/1995session/BILLS/1995/1995enr/
  House_Bills/HEA0072

(whew!)

This non-lawyerly mind sees two questions which need to be considered.
First, a "signature" is nothing more than an agreement to a contract;
verbal "signatures" have been upheld before in court.  It would seem
that, if such a dispute were to arise, that a valid digital signature
could be seen as evidence that such an agreement was made.  Second,
PGP keys are much easier to compromise than a person's handwritten
signature, so their evidential value will by necessity be less.

========

6.   Key Signatures

========

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. Be careful about keys that are several levels removed from
your immediate trust.

========

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.

It is not considered proper to send his updated key to a key server
yourself unless he has given you explicit permission to do so. After
all, he may not wish to have his key appear on a public server.  By
the same token, you should expect that any key that you give out will
probably find its way onto the public key servers, even if you really
didn't want it there, since anyone having your public key can upload
it.

========

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.  Anyone adding or
changing a user id on your key will be unable to sign the entry,
making it stand out like a sore thumb since all of the other entries
are signed.  Do this even if you are the only person signing your key.
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/0353E385 1994/06/17 Jeff Licquia <[e-mail]>
sig       0353E385             Jeff Licquia <[e-mail]>

========

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

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

   This seems to work well -- it worked well at the IETF meeting last
   month in Toronto, and I plan to try it at future dates.
- -----

========

7.   Revoking a key

========

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

YOU CAN'T, since the pass phrase is required to create the
certificate!

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. You need to be careful how you do
this, however, or you will end up revoking the key pair that you just
generated, and a revocation can't be reversed.

To do this, extract your public key to an ASCII file (using the "-kxa"
option) after you have generated your key pair. Next, create a key
revocation certificate and extract the revoked key to another ASCII
file using the -kxa option again. Finally, delete the revoked key from
your public key ring using the - kr option and put your non-revoked
version back in the ring using the -ka option. Save the revocation
certificate on a floppy so that you don't lose it if you crash your
hard disk sometime.

========

8.   Public Key Servers

========

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

Very recently, the number of keys reported on the key servers passed
10,000.

========

8.2. What public key servers are available?

The following is a list of all of the known public key servers active
as of the publication date of this FAQ.  Any changes to this list
should be posted to alt.security.pgp and a copy forwarded to me for
inclusion in future releases of the alt.security.pgp FAQ.

Sites accessible via mail:

    [e-mail]
    Derek Atkins <[e-mail]>

    [e-mail]
    Michael Graff <[e-mail]>

    [e-mail]
    Andy Howard <[e-mail]>

    [e-mail]
    Vesselin V. Bontchev <[e-mail]>

    [e-mail]
    Brian A. LaMacchia <[e-mail]>

    [e-mail]
    Paul Leyland <[e-mail]>

    [e-mail]
    David Vincenzetti <[e-mail]>

    [e-mail]
    Teun Nijssen <[e-mail]>

    [e-mail]
    Hironobu Suzuki <[e-mail]>

    [e-mail]
    Jeremy Fitzhardinge <[e-mail]>

    [e-mail]
    <[e-mail]>

    [e-mail]
    Cedomir Igaly <[e-mail]>

    [e-mail]
    Mark Turner <[e-mail]>

    [e-mail]
    Alvar Vinacua <[e-mail]>

    [e-mail]
    <[e-mail]>

Sites accessible via WWW:

    http://martigny.ai.mit.edu/~bal/pks-toplev.html
    http://ibd.ar.com/PublicKeys.html

Key server keyrings accessible via FTP:

    ftp://pgp.iastate.edu/pub/pgp/public-keys.pgp
    ftp://pgp.mit.edu/pub/keys/public-keys.pgp
    ftp://burn.ucsd.edu/Crypto/public-keys.pgp
    ftp://alex.sp.cs.cmu.edu/links/security/pubring.pgp
    ftp://ftp.informatik.uni-hamburg.de/pub/virus/misc/pubkring.pgp
    ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/public-keys.pgp
    ftp://jpunix.com/pub/PGP/

The following key servers are no longer in operation:

    [e-mail]
    [e-mail]
    [e-mail]

In addition to the "traditional" keyservers, there is a commercial key
registry in operation at four11.com.  Four11 Directory Services is set
up primarily as a directory service to assist in searching for people
or groups.  Members of the service may have their key certified by
Four11 and placed on their server; a key signature from Four11
indicates that you have met their signing requirements.  At the time
of this writing, they offer "SLED Silver Signatures", which require
identification of the key holder through one of the following:

 - a mailed or faxed driver's license
 - a mailed or faxed copy of a passport
 - payment for services with a preprinted personal check which cleared

Send mail to [e-mail] or connect to http://www.four11.com/ for
more information on SLED/Four11 or to search their server.  You can
request keys from their key server by sending E-mail to [e-mail]
or by fingering <email-addr>@publickey.com.  Their current
certification keys may be retrieved by sending mail to
[e-mail] or by looking up "SLED" on the other
keyservers.

===============

8.3. What is the syntax of 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 *)
GET <userid>  Get just that one key (-kxa <userid>)
MGET <userid> Get all keys which match <userid>
LAST <n>      Get all keys uploaded during last <n> days
- -------------------------------------------------------------

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. Using
e-mail, the entire key ring can generate a many part message, which
you will have to reconstruct into a single file before adding it to
your key ring.

========

9.  Bugs

========

9.1 Where should 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
alt.security.pgp.  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
alt.security.pgp, 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.

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.

========

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.

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.

Many of the versions of MacPGP (especially beta versions of MIT
MacPGP) have been reported to not handle text files and ASCII-armored
files correctly, causing some signatures not to validate.

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.

========

10.   Recommended Reading

========

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.

> The Code Breakers
      The Story of Secret Writing
      By David Kahn
      The MacMillan Publishing Company (1968)
      866 Third Avenue, New York, NY 10022
      Library of Congress Catalog Card Number: 63-16109

    ISBN: 0-02-560460-0

    This has been the unofficial standard reference book on the history of
    cryptography for the last 25 years. It covers the development of
    cryptography from ancient times, up to 1967. It is interesting to read
    about the cat and mouse games that governments have been playing with
    each other even to this day. I have been informed by Mats Lofkvist <d87-
    [e-mail]> that the book has been reissued since its original
    printing.  He found out about it from the 'Baker & Taylor Books'
    database.  I obtained my original edition from a used book store.  It is
    quite exhaustive in its coverage with 1164 pages.  When I was serving in
    the United States Navy in the early 1970's as a cryptographic repair
    technician, this book was considered contraband and not welcome around my
    work place, even though it was freely available at the local public
    library.  This was apparently because it mentioned several of the pieces
    of secret cryptographic equipment that were then in use in the military.

  > The following list was taken from the PGP documentation:

Dorothy Denning, "Cryptography and Data Security", Addison-Wesley,
Reading, MA 1982

Dorothy Denning, "Protecting Public Keys and Signature Keys", IEEE Computer,
Feb 1983

Martin E. Hellman, "The Mathematics of Public-Key Cryptography," Scientific
American, Aug 1979

Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54. (This is a "must-
read" article on PGP and other related topics.)

Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory for
Computer Science, 1991.  Available from the net as RFC1321.

Also available at ftp.dsi.unimi.it and its mirror at nic.funet.fi is:
IDEA_chapter.3.ZIP, a postscript text from the IDEA designer about
IDEA.

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

Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code
in C", John Wiley & Sons, 1993

Paul Wallich, "Electronic Envelopes", Scientific American, Feb 1993, page 30.
(This is an article on PGP)

========

11.   General Tips

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

      a) Your sysop permits it.
      b) Your recipient's sysop permits it.
      c) 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.

========================================================================
Appendix I - PGP add-ons and Related Programs
========================================================================

Due to the enormous size this FAQ has begun to take, I have condensed
this section, using a home-grown format that (I hope) will be easy to
machine-parse into whatever other formats I can manage.

This list is not exhaustive, nor is it even necessarily correct.  Much
of it is lifted from the old FAQ, and, as a result, some of the links
are probably out of date.  Hopefully, I will be able to weed out the
bad links and update this over time; the task was too great for me to
take immediately, however, especially given the pressing need.  I
present it in the hope that it will be helpful.

========
Amiga
========

PGP Mail Integration Project
Author: Peter Simons <[e-mail]>
ftp://ftp.uni-kl.de/pub/aminet/comm/mail/PGPMIP.lha
ftp://ftp.uni-kl.de/pub/aminet/comm/mail/PGPMIT.readme

Automatic PGP encryption for mail over UUCP and SMTP.
- -----
PGPAmiga-FrontEnd
Author: Peter Simons <[e-mail]>

GUI front end for Amiga PGP.
- -----
StealthPGP 1.0
ftp://ftp.uni-erlangen.de/pub/aminet/util/crypt/StealthPGP1_0.lha

Tool to remove any header stuff from PGP encrypted
messages, to make sure nobody recognizes it as
encrypted text. Source included.
- -----
PGPMore 2.3
ftp://ftp.uni-erlangen.de/pub/aminet/util/crypt/PGPMore2_3.lha

More-like tool which decrypts PGP encrypted blocks
included in the text before displaying them.
Useful for decrypting complete mail folders, etc...

========
Archimedes
========

PGPwimp
Author: Peter Gaunt
ftp://ftp.demon.co.uk/pub/archimedes/

A multi-tasking WIMP front-end for PGP (requires RISC OS 3).  Operates on
files - it has no hooks to allow integration with mailers/newsreaders.
- -----
RNscripts4PGP
Author: [e-mail] (Paul L. Allen)
ftp://ftp.demon.co.uk/pub/archimedes/

A collection of scripts and a small BASIC program which integrate PGP
with the ReadNews mailer/newsreader.  Provides encryp, decrypt, sign
signature- check, add key.

========
DOS (Windows utilities are in a separate section)
========

Offline AutoPGP
Author: Stale Schumacher <[e-mail]>
ftp://oak.oakland.edu/pub/msdos/security/apgp212.zip
http://www.ifi.uio.no/~staalesc/AutoPGP/

Integrates PGP with QWK and SOUP offline mail readers.
- -----
PGPSort
Author: Stale Schumacher <[e-mail]>
ftp://oak.oakland.edu/pub/msdos/security/pgpsort.zip
http://www.ifi.uio.no/~staalesc/PGP/PGPSort.html

Sorts your PGP public keyring.
- -----
HPack
ftp://garbo.uwasa.fi/pc/arcers/hpack79.zip
ftp://garbo.uwasa.fi/pc/doc-soft/hpack79d.zip
ftp://garbo.uwasa.fi/pc/source/hpack79s.zip
ftp://garbo.uwasa.fi/unix/arcers/hpack79src.tar.Z

Archiver program (like ZIP) which integrates PGP.
- -----
Menu
ftp://ghost.dsi.unimi.it/pub/crypt/menu.zip

Menu shell for PGP which uses 4DOS.
- -----
OzPKE
CompuServe: EFFSIG lib 15, OZCIS lib 7, EURFORUM lib 1

Integrates PGP into OzCIS, an automated access program for CompuServe.
- -----
PGP-Front
Author: Walter H. van Holst <[e-mail]>
ftp://ftp.dsi.unimi.it:/pub/security/crypt/PGP/pgpfront.zip

Interactive shell for PGP; has most functions.
- -----
PGPShell
Author:  James Still <[e-mail]>
ftp://oak.oakland.edu/pub/msdos/security/pgpshe33.zip
mailto:[e-mail] (subject "send shell")

Another PGP shell for DOS.
- -----
PGS
ftp://oak.oakland.edu/pub/msdos/security/

Pretty Good PGP Shell or PGS is a complete shell for Philip Zimmermann's
Pretty Good Privacy (PGP). PGS enables you to do anything that PGP can do
from the commandline from a, easy to use, front-end shell.
- -----
PGPUtils
ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/pgputils.zip

Batch files and PIF files for PGP.
- -----
PC Yarn
Author: Chin Huang <[e-mail]>
ftp://oak.oakland.edu/SimTel/msdos/offline/yarn_0xx.zip (xx is version number)

MS-DOS offline mail and news software (using the SOUP packet format)
that can clearsign or encrypt outgoing messages, and decrypt incoming
messages to the CRT, a text file, or a mail folder.

========
MAC
========

========
NeXT
========

CryptorBundle
ftp://ftp.informatik.uni-hamburg.de/pub/comp/platforms/next/Mail/apps/
  CryptorBundle-1.0.NI.b.tar.gz

Integrates PGP into Mail.app.

========
OS/2
========

EPM Macro for PGP
Author: John C. Frickson <[e-mail]>
ftp://ftp.gibbon.com/pub/gcp/gcppgp10.zip

Macro for EPM which places a PGP menu in the menu bar.

========
Unix
========

PGPsendmail
ftp://ftp.atnf.csiro.au/pub/people/rgooch/
ftp://ftp.dhp.com/pub/crypto/pgp/PGPsendmail/
ftp://ftp.ox.ac.uk/pub/crypto/pgp/utils/

Automatically encrypts by acting as a wrapper for sendmail.
- -----
PGPTalk
ftp://ftp.ox.ac.uk/src/security/pgptalk.zip

Integrates PGP into ytalk for secure private chatting.
- -----
Emacs Auto-PGP
Author: Ian Jackson <[e-mail]>

This is a package for integrating PGP into GNU Emacs.
- -----
Mailcrypt
Author: [e-mail] (Jin S Choi), [e-mail] (Patrick J. LoPresti)
ftp://cag.lcs.mit.edu/pub/patl/mailcrypt/

This is an elisp package for encrypting and decrypting mail.  I wrote this to
provide a single interface to the two most common mail encryption programs,
PGP and RIPEM. You can use either or both in any combination.
- -----
mail-secure.el
Author: Travis J. I. Corcoran ([e-mail])
mailto: [e-mail]

Complement to Mailcrypt which adds some new features.  Requires Mailcrypt.
- -----
PGPPAGER
Author: [e-mail] (Alessandro Bottonelli)

This program acts as a smart pager for mail, and can automatically
decrypt the body portion of a message if necessary.
- -----
mkpgp
mailto:[e-mail]
  (auto-replies the mkpgp program; use Subject: mkpgp)

Script for integrating pine and PGP.
- -----
PGP Elm
Author: Kenneth H. Cox <[e-mail]>
ftp://ftp.viewlogic.com/pub/elm-2.4pl24pgp3.tar.gz

Patched version of elm which is PGP-aware.
- -----
PGP Augmented Messaging (was PGP Enhanced Messaging)
Author: Rick Busdiecker <[e-mail]>
ftp://h.gp.cs.cmu.edu/usr/rfb/pem/

Another set of GNU Emacs PGP utilities.

========
VAX/VMS
========

ENCRYPT.COM
Author: [e-mail] (John O'Leary)

ENCRYPT.COM is a VMS mail script that works fine for
[e-mail] (John O'Leary)

========
Windows (v3, '95, NT)
========

PGP Help for the Windows Help engine
Author: Jeff Sheets <[e-mail]>
http://netaccess.on.ca/~rbarclay/pgp.html

PGP documentation and help in WinHelp format.
- -----
PGPWinFront (PWF)
Author: Ross Barclay <[e-mail]>
http://netaccess.on.ca/~rbarclay/index.html
mailto:[e-mail] (put GET PWF in subject)

Windows front end for PGP.  Includes most functions.
- -----
J's Windows PGP Shell (JWPS)
ftp://oak.oakland.edu/pub/msdos/security/

Another Windows front end for PGP.  Supports drag-n-drop, clipboard, etc.
- -----
PGP Windows
ftp://oak.oakland.edu/pub/msdos/security/pgpwin.zip

Still another Windows PGP front end.
- -----
WinPGP(tm)
ftp://ftp.firstnet.net/pub/windows/winpgp/pgpw40.zip
http://www.firstnet.net/~cwgeib/welcome.html

Another PGP Windows shell; this one is shareware.
- -----
ZMail Scripts for PGP
Author: Guy Berliner <[e-mail]>
ftp://ftp.netcom.com/pub/be/berliner/readme.html
ftp://kaiwan.com/user/mckinnon/pgp4zm.zip

Scripts for integrating PGP with ZMail, a popular graphical mailer.
- -----
Private Idaho
ftp://ftp.eskimo.com/joelm/pidaho21.zip
http://www.eskimo.com/~joelm/

A PGP integration tool for various Windows mailers.  Supports anonymous
remailers.
- -----
S-Tools
Author: Andy Brown <[e-mail]>
ftp://mirage.nexor.co.uk/pub/security/steganography/s-tools3.zip

A set of Windows steganography tools.

========================================================================
Appendix II - Glossary of Cryptographic Terms
========================================================================

========
Chosen Plain Text Attack
========

This is the next step up from the Known Plain Text Attack. In this
version, the cryptanalyst can choose what plain text message he wishes
to encrypt and view the results, as opposed to simply taking any old
plain text that he might happen to lay his hands on. If he can recover
the key, he can use it to decode all data encrypted under this key.
This is a much stronger form of attack than known plain text. The
better encryption systems will resist this form of attack.

========
Clipper
========

A chip developed by the United States Government that was to be used
as the standard chip in all encrypted communications. Aside from the
fact that all details of how the Clipper chip work remain classified,
the biggest concern was the fact that it has an acknowledged trap door
in it to allow the government to eavesdrop on anyone using Clipper
provided they first obtained a wiretap warrant. This fact, along with
the fact that it can't be exported from the United States, has led a
number of large corporations to oppose the idea.  Clipper uses an 80
bit key to perform a series of nonlinear transformation on a 64 bit
data block.

========
DES (Data Encryption Standard)
========

A data encryption standard developed by IBM under the auspices of the
United States Government.  It was criticized because the research that
went into the development of the standard remained classified.
Concerns were raised that there might be hidden trap doors in the
logic that would allow the government to break anyone's code if they
wanted to listen in. DES uses a 56 bit key to perform a series of
nonlinear transformation on a 64 bit data block.  Even when it was
first introduced a number of years ago, it was criticized for not
having a long enough key. 56 bits just didn't put it far enough out of
reach of a brute force attack.  Today, with the increasing speed of
hardware and its falling cost, it would be feasible to build a machine
that could crack a 56 bit key in under a day's time. It is not known
if such a machine has really been built, but the fact that it is
feasible tends to weaken the security of DES substantially.

I would like to thank Paul Leyland <[e-mail]> for the following
information relating to the cost of building such a DES cracking
machine:

      _Efficient DES Key Search_

      At Crypto 93, Michael Wiener gave a paper with the above title.  He
      showed how a DES key search engine could be built for $1 million which
      can do exhaustive search in 7 hours.  Expected time to find a key from
      a matching pair of 64-bit plaintext and 64-bit ciphertext is 3.5 hours.

      So far as I can tell, the machine is scalable, which implies that a
      $100M machine could find keys every couple of minutes or so.

      The machine is fairly reliable: an error analysis implies that the mean
      time between failure is about 270 keys.

      The final sentence in the abstract is telling: In the light of this
      work, it would be prudent in many applications to use DES in triple-
      encryption mode.

      I only have portions of a virtually illegible FAX copy, so please don't
      ask me for much more detail.  A complete copy of the paper is being
      snailed to me.

      Paul C. Leyland <[e-mail]>

Laszlo Baranyi <[e-mail]> says that the full paper is available
in PostScript from:

      ftp://ftp.eff.org/pub/crypto/des_key_search.ps
      ftp://cpsr.org/cpsr/crypto/des/des_key_search.ps
      (cpsr.org also makes it available via their Gopher service)

========
EFF (Electronic Frontier Foundation)
========

The Electronic Frontier Foundation (EFF) was founded in July, 1990, to assure
freedom of expression in digital media, with a particular emphasis on
applying the principles embodied in the Constitution and the Bill of Rights
to computer-based communication. For further information, contact:

      Electronic Frontier Foundation
      1001 G St., NW
      Suite 950 East
      Washington, DC 20001
      [phone]
      [phone] FAX
      Internet: [e-mail]

========
IDEA (International Data Encryption Algorithm)
========

Developed in Switzerland and licensed for non-commercial use in PGP.
IDEA uses a 128 bit user supplied key to perform a series of nonlinear
mathematical transformations on a 64 bit data block. Compare the
length of this key with the 56 bits in DES or the 80 bits in Clipper.

========
ITAR (International Traffic in Arms Regulations)
========

ITAR are the regulations covering the exporting of weapons and weapons
related technology from the United States. For some strange reason,
the government claims that data encryption is a weapon and comes under
the ITAR regulations. There is presently a move in Congress to relax
the section of ITAR dealing with cryptographic technology.

========
Known Plain Text Attack
========

A method of attack on a crypto system where the cryptanalyst has
matching copies of plain text, and its encrypted version. With weaker
encryption systems, this can improve the chances of cracking the code
and getting at the plain text of other messages where the plain text
is not known.

========
MD5 (Message Digest Algorithm #5)
========

The message digest algorithm used in PGP is the MD5 Message Digest
Algorithm, placed in the public domain by RSA Data Security, Inc.
MD5's designer, Ronald Rivest, writes this about MD5:

      "It is conjectured that the difficulty of coming up with two messages
      having the same message digest is on the order of 2^64 operations, and
      that the difficulty of coming up with any message having a given
      message digest is on the order of 2^128 operations.  The MD5 algorithm
      has been carefully scrutinized for weaknesses.  It is, however, a
      relatively new algorithm and further security analysis is of course
      justified, as is the case with any new proposal of this sort.  The
      level of security provided by MD5 should be sufficient for implementing
      very high security hybrid digital signature schemes based on MD5 and
      the RSA public-key cryptosystem."

========
MPILIB (Multiple Precision Integer Library)
========

This is the common name for the set of RSA routines used in PGP 2.3a
and previous, as well as the international versions of PGP.  It is
alleged to violate PKP's RSA patent in the USA, but is not otherwise
restricted in usage.  It retains its popularity abroad because it
outperforms RSAREF and has fewer legal restrictions as well.

========
NSA (National Security Agency)
========

The following information is from the sci.crypt FAQ:

The NSA is the official communications security body of the U.S.
government. It was given its charter by President Truman in the early
50's, and has continued research in cryptology till the present. The
NSA is known to be the largest employer of mathematicians in the
world, and is also the largest purchaser of computer hardware in the
world. Governments in general have always been prime employers of
cryptologists. The NSA probably possesses cryptographic expertise many
years ahead of the public state of the art, and can undoubtedly break
many of the systems used in practice; but for reasons of national
security almost all information about the NSA is classified.

========
One Time Pad
========

The one time pad is the ONLY encryption scheme that can be proven to
be absolutely unbreakable! It is used extensively by spies because it
doesn't require any hardware to implement and because of its absolute
security. This algorithm requires the generation of many sets of
matching encryption keys pads. Each pad consists of a number of random
key characters. These key characters are chosen completely at random
using some truly random process. They are NOT generated by any kind of
cryptographic key generator. Each party involved receives matching
sets of pads. Each key character in the pad is used to encrypt one and
only one plain text character, then the key character is never used
again. Any violation of these conditions negates the perfect security
available in the one time pad.

So why don't we use the one time pad all the time? The answer is that
the number of random key pads that need to be generated must be at
least equal to the volume of plain text messages to be encrypted, and
the fact that these key pads must somehow be exchanged ahead of time.
This becomes totally impractical in modern high speed communications
systems.

Among the more famous of the communications links using a one time pad
scheme is the Washington to Moscow hot line.

========
PEM (Privacy Enhanced Mail)
========

The following was taken from the sci.crypt FAQ:

How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...]?

Here's one popular method, using the des command:

cat file | compress | des private_key | uuencode | mail

Meanwhile, there is a de jure Internet standard in the works called
PEM (Privacy Enhanced Mail). It is described in RFCs 1421 through
1424. To join the PEM mailing list, contact [e-mail].
There is a beta version of PEM being tested at the time of this
writing.

There are also two programs available in the public domain for
encrypting mail: PGP and RIPEM. Both are available by FTP. Each has
its own news group: alt.security.pgp and alt.security.ripem. Each has
its own FAQ as well.  PGP is most commonly used outside the USA since
it uses the RSA algorithm without a license and RSA's patent is valid
only (or at least primarily) in the USA.

[ Maintainer's note: The above paragraph is not fully correct, as MIT
  PGP uses RSAREF as well now. ]

RIPEM is most commonly used inside the USA since it uses the RSAREF
which is freely available within the USA but not available for
shipment outside the USA.

Since both programs use a secret key algorithm for encrypting the body
of the message (PGP used IDEA; RIPEM uses DES) and RSA for encrypting
the message key, they should be able to interoperate freely. Although
there have been repeated calls for each to understand the other's
formats and algorithm choices, no interoperation is available at this
time (as far as we know).

========
PGP (Pretty Good Privacy)
========

The program we're discussing.  See question 1.1.

========
PKP (Public Key Partners)
========

A patent holding company that holds many public-key patents, including
(supposedly) the patent on public-key cryptography itself.  Several of
its patents are not believed by some to be valid, including their
patent on RSA (which affects PGP).

========
RIPEM
========

See PEM

========
RSA (Rivest-Shamir-Adleman)
========

RSA is the public key encryption method used in PGP. RSA are the
initials of the developers of the algorithm which was done at taxpayer
expense. The basic security in RSA comes from the fact that, while it
is relatively easy to multiply two huge prime numbers together to
obtain their product, it is computationally difficult to go the
reverse direction: to find the two prime factors of a given composite
number. It is this one-way nature of RSA that allows an encryption key
to be generated and disclosed to the world, and yet not allow a
message to be decrypted.

========
RSAREF
========

This is the free library RSA Data Security, Inc., made available for
the purpose of implementing freeware PEM applications.  It implements
several encryption algorithms, including (among others) RSA.  MIT PGP
uses RSAREF's RSA routines to avoid the alleged patent problems
associated with other versions of PGP.

========
Skipjack
========

See Clipper

========
TEMPEST
========

TEMPEST is a standard for electromagnetic shielding for computer
equipment. It was created in response to the fact that information can
be read from computer radiation (e.g., from a CRT) at quite a distance
and with little effort.  Needless to say, encryption doesn't do much
good if the cleartext is available this way.  The typical home
computer WOULD fail ALL of the TEMPEST standards by a long shot. So,
if you are doing anything illegal, don't expect PGP or any other
encryption program to save you. The government could just set up a
monitoring van outside your home and read everything that you are
doing on your computer.

Short of shelling out the ten thousand dollars or so that it would
take to properly shield your computer, a good second choice might be a
laptop computer running on batteries. No emissions would be fed back
into the power lines, and the amount of power being fed to the display
and being consumed by the computer is much less than the typical home
computer and CRT. This provides a much weaker RF field for snoopers to
monitor. It still isn't safe, just safer.  In addition, a laptop
computer has the advantage of not being anchored to one location.
Anyone trying to monitor your emissions would have to follow you
around, maybe making themselves a little more obvious.  I must
emphasize again that a laptop still is NOT safe from a tempest
standpoint, just safer than the standard personal computer.


========================================================================
Appendix III - Cypherpunks
========================================================================

========
What are Cypherpunks?
========

========
What is the cypherpunks mailing list?
========

Eric Hughes <[e-mail]> runs the "cypherpunk" mailing list
dedicated to "discussion about technological defenses for privacy in
the digital domain." Frequent topics include voice and data
encryption, anonymous remailers, and the Clipper chip.  Send e-mail to
[e-mail] with "subscribe cypherpunks" in the body to be
added or subtracted from the list.  The mailing list itself is
[e-mail]. You don't need to be a member of the list in
order to send messages to it, thus allowing the use of anonymous
remailers to post your more sensitive messages that you just as soon
would not be credited to you. (Traffic is sometimes up to 30-40
messages per day.)

========
What is the purpose of the Cypherpunk remailers?
========

The purpose of these remailers is to take privacy one level further.
While a third party who is snooping on the net may not be able to read
the encrypted mail that you are sending, he is still able to know who
you are sending mail to. This could possibly give him some useful
information. This is called traffic flow analysis. To counter this
type of attack, you can use a third party whose function is simply to
remail your message with his return address on it instead of yours.

Two types of remailers exist. The first type only accepts plain text
remailing headers. This type would only be used if your goal was only
to prevent the person to whom your are sending mail from learning your
identity. It would do nothing for the problem of net eavesdroppers
from learning to whom you are sending mail.

The second type of remailer accepts encrypted remailing headers. With
this type of remailer, you encrypt your message twice. First, you
encrypt it to the person ultimately receiving the message. You then
add the remailing header and encrypt it again using the key for the
remailer that you are using. When the remailer receives your message,
the system will recognize that the header is encrypted and will use
its secret decryption key to decrypt the message. He can now read the
forwarding information, but because the body of the message is still
encrypted in the key of another party, he is unable to read your mail.
He simply remails the message to the proper destination. At its
ultimate destination, the recipient uses his secret to decrypt this
nested encryption and reads the message.

Since this process of multiple encryptions and remailing headers can
get quite involved, there are several programs available to simplify
the process. FTP to soda.berkeley.edu and examine the directory
/pub/cypherpunks/remailers for the programs that are available.

========
Where are the currently active Cypherpunk remailers?
========

Raph Levien maintains a list of currently active remailers.  The list,
unfortunately, seems to change often as remailers are shut down for
whatever reasons; therefore, I am not printing a list here.  You can
get the list by fingering [e-mail].

========
Are there other anonymous remailers besides the cypherpunk remailers?
========

Yes, the most commonly used remailer on the Internet is in Finland. It
is known as anon.penet.fi. The syntax for sending mail through this
remailer is different from the cypherpunk remailers. For example, if
you wanted to send mail to me ([e-mail]) through anon.penet.fi,
you would send the mail to "[e-mail]". Notice that
the "@" sign in my Internet address is changed to a "%". Unlike the
cypherpunk remailers, anon.penet.fi directly supports anonymous return
addresses. Anybody using the remailer is assigned an anonymous id of
the form "an?????" where "?????" is filled in with a number
representing that user. To send mail to someone when you only know
their anonymous address, address your mail to "an?????@anon.penet.fi"
replacing the question marks with the user id you are interested in.
For additional information on anon.penet.fi, send a blank message to
"[e-mail]". You will receive complete instructions on how to
use the remailer, including how to obtain a pass phrase on the system.

========
What is the remailer command syntax?
========

The first non blank line in the message must start with two colons
(::). The next line must contain the user defined header
"Request-Remailing-To: <destination>". This line must be followed by a
blank line. Finally, your message can occupy the rest of the space. As
an example, if you wanted to send a message to me via a remailer, you
would compose the following message:

      ::
      Request-Remailing-To: [e-mail]

      [body of message]

You would then send the above message to the desired remailer. Note
the section labeled "body of message" may be either a plain text
message, or an encrypted and armored PGP message addressed to the
desired recipient. To send the above message with an encrypted header,
use PGP to encrypt the entire message shown above to the desired
remailer. Be sure to take the output in armored text form. In front of
the BEGIN PGP MESSAGE portion of the file, insert two colons (::) as
the first non-blank line of the file. The next line should say
"Encrypted: PGP". Finally the third line should be blank. The message
now looks as follows:

      ::
      Encrypted: PGP

      -----BEGIN PGP MESSAGE-----
      Version 2.3a

      [body of pgp message]
      -----END PGP MESSAGE-----

      You would then send the above message to the desired remailer
just as you did in the case of the non-encrypted header. Note that it
is possible to chain remailers together so that the message passes
through several levels of anonymity before it reaches its ultimate
destination.

========
Where can I learn more about Cypherpunks?
========

  ftp://ftp.csua.berkeley.edu/pub/cypherpunks

=======================================================================
Appendix IV - Testimony of Philip Zimmermann to Congress.
              Reproduced by permission.
=======================================================================

- From netcom.com!netcomsv!decwrl!sdd.hp.com!col.hp.com!csn!yuma!ld231782 Sun
Oct 10 07:55:51 1993
Xref: netcom.com talk.politics.crypto:650 comp.org.eff.talk:20832
alt.politics.org.nsa:89
~Newsgroups: talk.politics.crypto,comp.org.eff.talk,alt.politics.org.nsa
Path: netcom.com!netcomsv!decwrl!sdd.hp.com!col.hp.com!csn!yuma!ld231782
~From: [e-mail] (L. Detweiler)
~Subject: ZIMMERMANN SPEAKS TO HOUSE SUBCOMMITTEE
~Sender: [e-mail] (News Account)
Message-ID: <[e-mail]>
~Date: Sun, 10 Oct 1993 04:42:12 GMT
Nntp-Posting-Host: turner.lance.colostate.edu
Organization: Colorado State University, Fort Collins, CO  80523
~Lines: 281


~Date: Sat, 9 Oct 93 11:57:54 MDT
~From: Philip Zimmermann <[e-mail]>
~Subject: Zimmerman testimony to House subcommittee


            Testimony of Philip Zimmermann to
     Subcommittee for Economic Policy, Trade, and the Environment
               US House of Representatives
                    12 Oct 1993



Mr. Chairman and members of the committee, my name is Philip
Zimmermann, and I am a software engineer who specializes in
cryptography and data security.  I'm here to talk to you today about
the need to change US export control policy for cryptographic
software.  I want to thank you for the opportunity to be here and
commend you for your attention to this important issue.

I am the author of PGP (Pretty Good Privacy), a public-key encryption
software package for the protection of electronic mail.  Since PGP was
published domestically as freeware in June of 1991, it has spread
organically all over the world and has since become the de facto
worldwide standard for encryption of E-mail.  The US Customs Service
is investigating how PGP spread outside the US.  Because I am a target
of this ongoing criminal investigation, my lawyer has advised me not
to answer any questions related to the investigation.

I.  The information age is here.

Computers were developed in secret back in World War II mainly to
break codes.  Ordinary people did not have access to computers,
because they were few in number and too expensive.  Some people
postulated that there would never be a need for more than half a
dozen computers in the country.  Governments formed their attitudes
toward cryptographic technology during this period.  And these
attitudes persist today.  Why would ordinary people need to have
access to good cryptography?

Another problem with cryptography in those days was that cryptographic
keys had to be distributed over secure channels so that both parties
could send encrypted traffic over insecure channels. Governments
solved that problem by dispatching key couriers with satchels
handcuffed to their wrists.  Governments could afford to send guys
like these to their embassies overseas.  But the great masses of
ordinary people would never have access to practical cryptography if
keys had to be distributed this way.  No matter how cheap and powerful
personal computers might someday become, you just can't send the keys
electronically without the risk of interception. This widened the
feasibility gap between Government and personal access to cryptography.

Today, we live in a new world that has had two major breakthroughs
that have an impact on this state of affairs.  The first is the
coming of the personal computer and the information age.  The second
breakthrough is public-key cryptography.

With the first breakthrough comes cheap ubiquitous personal
computers, modems, FAX machines, the Internet, E-mail, digital
cellular phones, personal digital assistants (PDAs), wireless digital
networks, ISDN, cable TV, and the data superhighway.  This
information revolution is catalyzing the emergence of a global
economy.

But this renaissance in electronic digital communication brings with
it a disturbing erosion of our privacy.  In the past, if the
Government wanted to violate the privacy of ordinary citizens, it had
to expend a certain amount of effort to intercept and steam open and
read paper mail, and listen to and possibly transcribe spoken
telephone conversation.  This is analogous to catching fish with a
hook and a line, one fish at a time.  Fortunately for freedom and
democracy, this kind of labor-intensive monitoring is not practical
on a large scale.

Today, electronic mail is gradually replacing conventional paper
mail, and is soon to be the norm for everyone, not the novelty is is
today.  Unlike paper mail, E-mail messages are just too easy to
intercept and scan for interesting keywords.  This can be done
easily, routinely, automatically, and undetectably on a grand scale.
This is analogous to driftnet fishing-- making a quantitative and
qualitative Orwellian difference to the health of democracy.

The second breakthrough came in the late 1970s, with the mathematics
of public key cryptography.  This allows people to communicate
securely and conveniently with people they've never met, with no
prior exchange of keys over secure channels.  No more special key
couriers with black bags.  This, coupled with the trappings of the
information age, means the great masses of people can at last use
cryptography.  This new technology also provides digital signatures
to authenticate transactions and messages, and allows for digital
money, with all the implications that has for an electronic digital
economy.  (See appendix)

This convergence of technology-- cheap ubiquitous PCs, modems, FAX,
digital phones, information superhighways, et cetera-- is all part of
the information revolution.  Encryption is just simple arithmetic to
all this digital hardware.  All these devices will be using
encryption.  The rest of the world uses it, and they laugh at the US
because we are railing against nature, trying to stop it.  Trying to
stop this is like trying to legislate the tides and the weather. It's
like the buggy whip manufacturers trying to stop the cars-- even with
the NSA on their side, it's still impossible.  The information
revolution is good for democracy-- good for a free market and trade.
It contributed to the fall of the Soviet empire.  They couldn't stop
it either.

Soon, every off-the-shelf multimedia PC will become a secure voice
telephone, through the use of freely available software.  What does
this mean for the Government's Clipper chip and key escrow systems?

Like every new technology, this comes at some cost.  Cars pollute the
air.  Cryptography can help criminals hide their activities.  People
in the law enforcement and intelligence communities are going to look
at this only in their own terms.  But even with these costs, we still
can't stop this from happening in a free market global economy.  Most
people I talk to outside of Government feel that the net result of
providing privacy will be positive.

President Clinton is fond of saying that we should "make change our
friend".  These sweeping technological changes have big implications,
but are unstoppable.  Are we going to make change our friend?  Or are
we going to criminalize cryptography?  Are we going to incarcerate
our honest, well-intentioned software engineers?

Law enforcement and intelligence interests in the Government have
attempted many times to suppress the availability of strong domestic
encryption technology.  The most recent examples are Senate Bill 266
which mandated back doors in crypto systems, the FBI Digital
Telephony bill, and the Clipper chip key escrow initiative.  All of
these have met with strong opposition from industry and civil liberties
groups.  It is impossible to obtain real privacy in the information
age without good cryptography.

The Clinton Administration has made it a major policy priority to
help build the National Information Infrastructure (NII).  Yet, some
elements of the Government seems intent on deploying and entrenching
a communications infrastructure that would deny the citizenry the
ability to protect its privacy.  This is unsettling because in a
democracy, it is possible for bad people to occasionally get
elected-- sometimes very bad people.  Normally, a well-functioning
democracy has ways to remove these people from power.  But the wrong
technology infrastructure could allow such a future government to
watch every move anyone makes to oppose it.  It could very well be
the last government we ever elect.

When making public policy decisions about new technologies for the
Government, I think one should ask oneself which technologies would
best strengthen the hand of a police state.  Then, do not allow the
Government to deploy those technologies.  This is simply a matter of
good civic hygiene.

II.  Export controls are outdated and are a threat to privacy and
economic competitivness.

The current export control regime makes no sense anymore, given
advances in technology.

There has been considerable debate about allowing the export of
implementations of the full 56-bit Data Encryption Standard (DES).
At a recent academic cryptography conference, Michael Wiener of Bell
Northern Research in Ottawa presented a paper on how to crack the DES
with a special machine.  He has fully designed and tested a chip that
guesses DES keys at high speed until it finds the right one.
Although he has refrained from building the real chips so far, he can
get these chips manufactured for $10.50 each, and can build 57000 of
them into a special machine for $1 million that can try every DES key
in 7 hours, averaging a solution in 3.5 hours.  $1 million can be
hidden in the budget of many companies.  For $10 million, it takes 21
minutes to crack, and for $100 million, just two minutes.  That's
full 56-bit DES, cracked in just two minutes.  I'm sure the NSA can
do it in seconds, with their budget.  This means that DES is now
effectively dead for purposes of serious data security applications.
If Congress acts now to enable the export of full DES products, it
will be a day late and a dollar short.

If a Boeing executive who carries his notebook computer to the Paris
airshow wants to use PGP to send email to his home office in Seattle,
are we helping American competitivness by arguing that he has even
potentially committed a federal crime?

Knowledge of cryptography is becoming so widespread, that export
controls are no longer effective at controlling the spread of this
technology.  People everywhere can and do write good cryptographic
software, and we import it here but cannot export it, to the detriment
of our indigenous software industry.

I wrote PGP from information in the open literature, putting it into
a convenient package that everyone can use in a desktop or palmtop
computer.  Then I gave it away for free, for the good of our
democracy.  This could have popped up anywhere, and spread.  Other
people could have and would have done it.  And are doing it.  Again
and again.  All over the planet.  This technology belongs to
everybody.

III.  People want their privacy very badly.

PGP has spread like a prairie fire, fanned by countless people who
fervently want their privacy restored in the information age.

Today, human rights organizations are using PGP to protect their
people overseas.  Amnesty International uses it.  The human rights
group in the American Association for the Advancement of Science uses
it.

Some Americans don't understand why I should be this concerned about
the power of Government.  But talking to people in Eastern Europe, you
don't have to explain it to them.  They already get it-- and they
don't understand why we don't.

I want to read you a quote from some E-mail I got last week from
someone in Latvia, on the day that Boris Yeltsin was going to war
with his Parliament:

   "Phil I wish you to know: let it never be, but if dictatorship
   takes over Russia your PGP is widespread from Baltic to Far East
   now and will help democratic people if necessary.  Thanks."



Appendix -- How Public-Key Cryptography Works
- ---------------------------------------------

In conventional cryptosystems, such as the US Federal Data Encryption
Standard (DES), a single key is used for both encryption and
decryption.  This means that a key must be initially transmitted via
secure channels so that both parties have it before encrypted
messages can be sent over insecure channels.  This may be
inconvenient.  If you have a secure channel for exchanging keys, then
why do you need cryptography in the first place?

In public key cryptosystems, everyone has two related complementary
keys, a publicly revealed key and a secret key.  Each key unlocks the
code that the other key makes.  Knowing the public key does not help
you deduce the corresponding secret key.  The public key can be
published and widely disseminated across a communications network.
This protocol provides privacy without the need for the same kind of
secure channels that a conventional cryptosystem requires.

Anyone can use a recipient's public key to encrypt a message to that
person, and that recipient uses her own corresponding secret key to
decrypt that message.  No one but the recipient can decrypt it,
because no one else has access to that secret key.  Not even the
person who encrypted the message can decrypt it.

Message authentication is also provided.  The sender's own secret key
can be used to encrypt a message, thereby "signing" it.  This creates
a digital signature of a message, which the recipient (or anyone
else) can check by using the sender's public key to decrypt it.  This
proves that the sender was the true originator of the message, and
that the message has not been subsequently altered by anyone else,
because the sender alone possesses the secret key that made that
signature.  Forgery of a signed message is infeasible, and the sender
cannot later disavow his signature.

These two processes can be combined to provide both privacy and
authentication by first signing a message with your own secret key,
then encrypting the signed message with the recipient's public key.
The recipient reverses these steps by first decrypting the message
with her own secret key, then checking the enclosed signature with
your public key.  These steps are done automatically by the
recipient's software.



- --
  Philip Zimmermann
  3021 11th Street
  Boulder, Colorado 80304
  303 541-0140
  E-mail: [e-mail]



- --

[e-mail]

========================================================================
Appendix V - The Philip Zimmermann Defense Fund.
             All articles reproduced by permission.
========================================================================

Evidently, providing "free crypto for the masses" has its down side.

The government is investigating Phil Zimmermann, the original author
of PGP, for alleged violations of the ITAR export regulations
prohibiting the unlicensed export of cryptographic equipment.  They do
not seem to believe that Phil himself actually exported PGP; rather,
they claim that making the program available in a way that it could be
exported is itself export (such as giving it away without
restriction).

As of this writing, the investigation is just that.  In January,
Phil's lawyers met with the government lawyers to discuss the case.
The outcome of the meeting is unclear at this point, though the
meeting was described as "cordial" by Phillip Dubois, Phil
Zimmermann's lawyer.

Even though it's "just an investigation", it's been an expensive one.
Phil immediately had to go out and get legal representation to try to
combat this "investigation" and prepare for its possible result.  He's
got a really good legal team, and they have done a lot of their work
pro bono in support of the cause.  Unfortunately, there are still
costs associated with legal fights like this one.  Phil's got quite a
bill so far.

To help offset his costs, Phil and his legal team have set up a legal
defense fund for contributions.  It's currently way in the red, but
it's better than paying the whole bill outright.  If charges actually
get filed, the total bill could soar up into the millions; not a fun
thing to have happen to you after providing such a nice (if
controversial) public service.  And spending all these millions
doesn't guarantee that he won't be convicted and spend some time in
jail; that's something not even a legal defense fund can pay for.

Several companies who benefit from the use of PGP have indicated that
they will donate a portion of their profits from certain activities to
the legal defense fund.  Here is a partial list:

  First Virtual Holdings Incorporated
  Four11 Directory Services
  ViaCrypt
  Christopher Geib (the author of the shareware WinPGP)

Additions to this list would be appreciated.

More information can be had by sending E-mail to [e-mail] or by
visiting the information page set up for the fund:

  http://www.netresponse.com/zldf

Also, the legal team has also asked that anyone who has been
approached by a federal investigator and questioned about Phil
Zimmermann please contact Phillip Dubois [[e-mail],
303/444-3885, 2305 Broadway, Boulder, CO 80304-4132].

Here's the original article announcing the fund:

=====
- From [e-mail] Thu Oct 14 23:16:32 1993
Return-Path: <[e-mail]>
Received: from ncar.ucar.edu by mail.netcom.com (5.65/SMI-4.1/Netcom)
     id AA05680; Thu, 14 Oct 93 23:16:29 -0700
Received: from sage.cgd.ucar.edu by ncar.ucar.EDU (5.65/ NCAR Central Post
Office 03/11/93)
     id AA01642; Fri, 15 Oct 93 00:15:34 MDT
Received: from columbine.cgd.ucar.edu by sage.cgd.ucar.EDU (5.65/ NCAR Mail
Server 04/10/90)
     id AA22977; Fri, 15 Oct 93 00:14:08 MDT
Message-Id: <[e-mail]>
Received: by columbine.cgd.ucar.EDU (4.1/ NCAR Mail Server 04/10/90)
     id AA09815; Fri, 15 Oct 93 00:16:57 MDT
~Subject: PGP legal defense fund
To: [e-mail] (Gary Edstrom)
~Date: Fri, 15 Oct 93 0:16:56 MDT
~From: Philip Zimmermann <[e-mail]>
In-Reply-To: <[e-mail]>; from "Gary Edstrom" at
Oct 11, 93 1:13 pm
~From: Philip Zimmermann <[e-mail]>
~Reply-To: Philip Zimmermann <[e-mail]>
X-Mailer: ELM [version 2.3 PL0]
Status: OR


~Date: Fri, 24 Sep 1993 02:41:31 -0600 (CDT)
~From: [e-mail] (Hugh Miller)
~Subject: PGP defense fund

As you may already know, on September 14 LEMCOM Systems (ViaCrypt)
in Phoenix, Arizona was served with a subpoena issued by the US District
Court of Northern California to testify before a grand jury and produce
documents related to "ViaCrypt, PGP, Philip Zimmermann, and anyone or
any entity acting on behalf of Philip Zimmermann for the time period
June 1, 1991 to the present."

Phil Zimmermann has been explicitly told that he is the primary
target of the investigation being mounted from the San Jose office of
U.S. Customs.  It is not known if there are other targets.  Whether or
not an indictment is returned in this case, the legal bills will be
astronomical.

If this case comes to trial, it will be one of the most important
cases in recent times dealing with cryptography, effective
communications privacy, and the free flow of information and ideas in
cyberspace in the post-Cold War political order. The stakes are high,
both for those of us who support the idea of effective personal
communications privacy and for Phil, who risks jail for his selfless and
successful effort to bring to birth "cryptography for the masses,"
a.k.a. PGP.  Export controls are being used as a means to curtail
domestic access to effective cryptographic tools: Customs is taking the
position that posting cryptographic code to the Internet is equivalent
to exporting it.  Phil has assumed the burden and risk of being the
first to develop truly effective tools with which we all might secure
our communications against prying eyes, in a political environment
increasingly hostile to such an idea -- an environment in which Clipper
chips and Digital Telephony bills are our own government's answer to our
concerns.  Now is the time for us all to step forward and help shoulder
that burden with him.

Phil is assembling a legal defense team to prepare for the
possibility of a trial, and he needs your help.  This will be an
expensive affair, and the meter is already ticking. I call on all of us,
both here in the U.S. and abroad, to help defend Phil and perhaps
establish a groundbreaking legal precedent.  A legal trust fund has been
established with Phil's attorney in Boulder.  Donations will be accepted
in any reliable form, check, money order, or wire transfer, and in any
currency.  Here are the details:

To send a check or money order by mail, make it payable, NOT to Phil
Zimmermann, but to Phil's attorney, Philip Dubois.  Mail the check or money
order to the following address:

    Philip Dubois
    2305 Broadway
    Boulder, CO USA  80304
    (Phone #: [phone])

To send a wire transfer, your bank will need the following
information:

    Bank: VectraBank
    Routing #: 107004365
    Account #: 0113830
    Account Name: "Philip L. Dubois, Attorney Trust Account"

    Any funds remaining after the end of legal action will be returned
to named donors in proportion to the size of their donations.

    You may give anonymously or not, but PLEASE - give generously.  If
you admire PGP, what it was intended to do and the ideals which animated
its creation, express your support with a contribution to this fund.

- -----------------------------------------------------------------------

Posted to: alt.security.pgp; sci.crypt; talk.politics.crypto;
comp.org.eff.talk; comp.society.cu-digest; comp.society; alt.sci.sociology;
alt.security.index; alt.security.keydist; alt.security;
alt.society.civil-liberty; alt.society.civil-disob; alt.society.futures

- --

Hugh Miller       | Asst. Prof. of Philosophy |  Loyola University Chicago
FAX: [phone] |    Voice: 312-508-2727    |  [e-mail]
PGP 2.3A Key fingerprint: FF 67 57 CC 0C 91 12 7D  89 21 C7 12 F7 CF C5 7E
=====

European users of PGP may also make contributions to the fund, as
described in the following message posted to alt.security.pgp.  Note
that this fund is not endorsed or managed by the people managing the
real legal defense fund; it is intended as a medium for Europeans (and
others) to be able to contribute to the fund easily.

=====
- -----BEGIN PGP SIGNED MESSAGE-----

     This is a call for donations to support Philip Zimmermann, the
author of Pretty Good Privacy (PGP), directed especially to the
european users.

     To avoid the large bank fees when transferring money to the
United States or when issuing checks to overseas, I have established
an european legal trust fund for your convenience. First of all, I'd
like to inform you what this legal trust fund is all about in the
first place. If you already know Phil's situation, you might skip the
quoted message below. I am using parts of the "request for donations"
as it was posted by Philip Dubois, Zimmermann's lawyer.

 | As you may already know, on September 14 LEMCOM Systems (ViaCrypt)
 | in Phoenix, Arizona was served with a subpoena issued by the US
 | District Court of Northern California to testify before a grand
 | jury and produce documents related to "ViaCrypt, PGP, Philip
 | Zimmermann, and anyone or any entity acting on behalf of Philip
 | Zimmermann for the time period June 1, 1991 to the present."
 |
 | Phil Zimmermann has been explicitly told that he is the primary
 | target of the investigation being mounted from the San Jose office
 | of U.S.  Customs. It is not known if there are other targets.
 | Whether or not an indictment is returned in this case, the legal
 | bills will be astronomical.
 |
 | If this case comes to trial, it will be one of the most important
 | cases in recent times dealing with cryptography, effective
 | communications privacy, and the free flow of information and ideas
 | in cyberspace in the post-Cold War political order. The stakes are
 | high, both for those of us who support the idea of effective
 | personal communications privacy and for Phil, who risks jail for
 | his selfless and successful effort to bring to birth "cryptography
 | for the masses," a.k.a. PGP. Export controls are being used as a
 | means to curtail domestic access to effective cryptographic tools:
 | Customs is taking the position that posting cryptographic code to
 | the Internet is equivalent to exporting it. Phil has assumed the
 | burden and risk of being the first to develop truly effective tools
 | with which we all might secure our communications against prying
 | eyes, in a political environment increasingly hostile to such an
 | idea -- an environment in which Clipper chips and Digital Telephony
 | bills are our own government's answer to our concerns. Now is the
 | time for us all to step forward and help shoulder that burden with
 | him.
 |
 | Phil is assembling a legal defense team to prepare for the
 | possibility of a trial, and he needs your help. This will be an
 | expensive affair, and the meter is already ticking. I call on all
 | of us, both here in the U.S. and abroad, to help defend Phil and
 | perhaps establish a groundbreaking legal precedent. A legal trust
 | fund has been established with Phil's attorney in Boulder.


     If you wish to donate some money to Philip Zimmermann, you may
now transfer it to an account here in Germany -- what is usually quite
a lot cheaper than transferring it to overseas. Here is the
information you will need:

        Account owner: Peter Simons
        Bank         : Commerzbank Bonn, Germany
        Account No.  : 1112713/00
        Bank No.     : 380 400 07

     This is NOT my private account! It is only used to collect the
donations for Philip. Every single dollar I receive will be
transferred to the account in the States monthly, with minimum fees.
If you donate any money, you might want to send an e-mail to me
([e-mail]) and to Philip Dubois ([e-mail]) to let us
know. Sending a copy to Phil's lawyer will furthermore make sure that
I can by no means keep anything for myself as he knows exactly what
amount has been given.

     If you need any further information, please don't hesitate to
contact me under [e-mail] and I will happily try to help.
You may get my PGP public key from any keyserver or by fingering
[e-mail].

     Please be generous! Consider that PGP is completely free for you
to use and Phil got nothing but trouble in return. One can easily
imagine what a software company had charged you for a tool like that!

        Sincerely,

            Peter Simons <[e-mail]>


- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2i beta

iQCVAgUBL2YWuw9HL1s0103BAQEj9wP9EJwRtjcpCSCG/5p10rfPkgD3tlYs35ds
HwXOlCdRkFSfVOQ70xhgObgf6iZwv/OFQzfjf83CjLt5CxVpROMvMBGLnJkpTYEJ
JzXh/22O+E2guWMuGbDgoD83dPXbxWhPCqeJEIP1uNUaT4QQjxB8OOaCfpxLIbCa
2lnISYXKZuQ=
=WrGh
- -----END PGP SIGNATURE-----

========================================================================
Appendix VI - A Statement from ViaCrypt Concerning ITAR
              Reproduced by Permission
========================================================================

- -----BEGIN PGP SIGNED MESSAGE-----

The ITAR (International Traffic in Arms Regulations) includes
a regulation that requires a manufacturer of cryptographic
products to register with the U.S. State Department even if the
manufacturer has no intentions of exporting products.  It appears
that this particular regulation is either not widely known, or
is widely ignored.

While no pressure was placed upon ViaCrypt to register, it is the
Company's position to comply with all applicable laws and regulations.
In keeping with this philosophy, ViaCrypt has registered with the
U.S. Department of State as a munitions manufacturer.

- -----BEGIN PGP SIGNATURE-----
Version: 2.4

iQCVAgUBLQ+DfmhHpCDLdoUBAQGa+AP/YzLpHBGOgsU4b7DjLYj8KFC4FFACryRJ
CKaBzeDI30p6y6PZitsMRBv7y2dzDILjYogIP0L3FTRyN36OebgVCXPiUAc3Vaee
aIdLJ6emnDjt+tVS/dbgx0F+gB/KooMoY3SJiGPE+hUH8p3pNkYmhzeR3xXi9OEu
GAZdK+E+RRA=
=o13M
- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBL+kAD7nwkw8DU+OFAQEmFwP+NmfsjZk3RbvWgCE10zHL6dszGbDinFp8
Nh8hIPHI7lPXPi7CL7kcdoGoX8YPQxVp+HSROPE+tPIhDtshNtN3ek8yhWSCpXPo
6gyn0qkCPPU4DPfCg+6phBmA8T9UvbBCi/acbAQtLmuvXV6YfQIpwNJOzQOZJuts
2sTMvbRR8YE=
=X5VL
-----END PGP SIGNATURE-----