The comp.security.pgp FAQ

The comp.security.pgp FAQ

Wouter Slegers

Copyright � 1996, 1997, 1998, 1999, 2000, 2001 by Arnoud Engelfriet

Copyright � 2002 by Wouter Slegers


This FAQ is copyright � 2001 by Wouter Slegers.

It may be distributed freely in online electronic form, provided the copyright
notice is left intact. Since this FAQ is always available from USENET and the
PGP network, there should be no problems getting access to it. However mirrors
with outdated versions can confuse the users, so I request you not to mirror
this FAQ elsewhere.

If you want to distribute this FAQ on a CD-ROM or similar medium, please
contact me for permission first (at <faq-admin@mail.pgp.net>). The same applies
for offline distribution as well as use in printed matter.

-------------------------------------------------------------------------------
Table of Contents
Preface
    1. About this FAQ
    2. Finding the FAQ
    3. Revision history


1. General questions and introduction
2. Common Problems in using PGP
3. Security Questions
4. Keys
5. Message Signatures
6. Key Signatures
7. Revoking a key
8. Public Key Servers
9. Bugs
Glossary of cryptographic terms
Colophon

-------------------------------------------------------------------------------
Preface

1. About this FAQ

This comp.security.pgp FAQ is based on Arnoud "Galactus" Engelfriet's FAQ which
in turn was based on Jeff Licquia's original alt.security.pgp FAQ.

This FAQ is since 2002 maintained by Wouter Slegers, Your Creative Solutions. I
welcome any comments, suggestions or additions for this FAQ. As always, you can
send them to <faq-admin@mail.pgp.net>.
-------------------------------------------------------------------------------

2. Finding the FAQ

This FAQ is posted monthly to all comp.security.pgp newsgroups, and the latest
version will always be available from pgp.net.
-------------------------------------------------------------------------------

3. Revision history

Revision History
Revision 1.6                           30 Jan 2002
The FAQ's maintainer changed from Arnoud "Galactus" Engelfriet to Wouter
Slegers. As part of the new maintainership I'm starting a major overhoal of the
whole FAQ. Including:

��*�Converted sourcefile of FAQ from the HTML+Orb construct it was to DocBook.
    This allows easier conversion to popular output formats.

��*�Removed many obsolete entries.

��*�Added information on GNU Privacy Guard, PGP 5.x and higher, OpenPGP and
    other news since the last version.

��*�Checked and updated the references.

��*�Reordered the remaining questions.

��*�Removed all email adresses of contributers from the FAQ (thanks to
    spammers, such a tribute is now a curse). Should you wish to contact one of
    these people, email me.


The upgrading and restructuring is still far from complete, but the FAQ should
be usable in this state. In particular what needs to be done at least:

��*�The questions need to be reordered.

��*�The keyserver chapter needs extensive updates.

��*�The outputformats need some cosmetic changes.


Expect an updated version soon. Feedback to <faq-admin@mail.pgp.net> is very
welcome.
-------------------------------------------------------------------------------

Chapter 1. General questions and introduction

Q: What is PGP?
Q: Why should I encrypt my mail? I'm not doing anything illegal!
Q: What's the current version of PGP?
Q: How much does PGP cost?
Q: Is encryption legal?
Q: Is PGP legal?
Q: What's with the patent on IDEA?
Q: What's with the patent on RSA?
Q: Is there an archive site for the comp.security.pgp groups?
Q: Is PGP available as a programming library, so I can write programs that use
    it?
Q: What platforms has PGP been ported to?
Q: Where can I obtain PGP?
Q: I want to find out more!

Q: What is PGP?

A: 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 verify 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 seems (and according to many of its users 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 and ASCII armor a message, it will not encrypt it. Even though the output
looks like it is encrypted, it really isn't (it is the ASCII armor that looks
so though). Anybody in the world would be able to recover the original text
with a simple pgp <encryptedfilename>.

The graphical userinterface of PGP 5.x and higher also has its pittfalls, as
Alma Whitten describes in Why Johnny Can't Encrypt - A Usability Evaluation of
PGP 5.0: even with manuals and an introduction, three of the twelve
participants accidently sent "secret" information unencrypted.

    WarningMake sure you thoroughly understand how to operate PGP prior to
    using it for confidential information.



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

A: 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, your mail is handled by
postal workers. 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, as
do all systems that can listen in on the communication between these nodes.
Encryption in no way implies illegal activity. It is simply intended to keep
personal thoughts personal.

Xenon 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 <an48138@anon.penet.fi>(Copyright 1993, Xenon) �


Q: What's the current version of PGP?

A: There are three different "product-lines" for PGP: PGP 2.x, PGP 5.x and
higher, and GNU Privacy Guard.

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

All versions of PGP after 2.3 produce messages that cannot be read by 2.3 or
earlier (for patent-legal purposes, see Why can't a person using version 2.3
read my version 2.6 message?>), although the "international" versions have a
switch to enable the creation of messages in a compatible format. This is the
legal_kludge=on option in the configuration file.

PGP 2.6.3i ("international") is a version of PGP developed from the source code
of MIT PGP, which was exported illegally from the United States at some point.
Basically, it is MIT PGP 2.6.2, but it uses the old encryption routines from
PGP 2.3a; these routines perform better than RSAREF and in addition do not have
the usage restrictions in the RSAREF copyright license. It also contains some
fixes for bugs discovered since the release of MIT PGP 2.6.2, as well as
several small enhancements. For more information, see the International PGP
homepage

PGP 2.6ui ("unofficial international") is PGP 2.3a with minor modifications
made so it can decrypt files encrypted with MIT PGP. It does not contain any of
the MIT fixes and improvements; it does, however, have other improvements, most
notably in the Macintosh version.

The 2.6.3(i)n version was developed to fullfill the policy of the Individual
Network e.V. Certification Hierarchy.

A: The PGP 5.x and higher series include OpenPGP compatibility. Most versions
include both a command line version (for all platforms) and one with a
graphical user interface (for the Microsoft Windowses and Mac OS 8.x and 9.x).
The most recent version is 7.1.2 .

A: GNU Privacy Guard is an OpenPGP compatible program, written from scratch and
not based on the 2.x sources. For normal uses it is compatible with both the
PGP 2.x and the PGP 5.x and higher versions. It mostly targets UNIX-like
systems. The most recent version is 1.0.4.

Q: How much does PGP cost?

A: The PGP 2.x series are freely available as open source software under the
GNU General Public License, with no real limits on its use, at no cost (except
the IDEA patent should you opt to include support for it, see What's with the
patent on IDEA?).

A: GNU Privacy Guard is freely available as open source software, with no real
limits on its use, at no cost (except the IDEA patent should you opt to include
support for it, see What's with the patent on IDEA?). The website of the GNU
Privacy Guard Project is the primary distribution point.

A: PGP 5.x and higher are commercial products. Network Associates bought PGP
Inc., a company founded by Phil Zimmerman, and sells a whole range of products
under the brand "PGP". The "original" email and file encryption PGP are called
PGPmail and PGPfile respectively. See NAI for pricing and availability. There
is a version available at no cost for strictly non-commercial use on http://
www.pgp.com/products/freeware/.

Note that the free versions of PGP are free only for noncommercial use. If you
need to use PGP in a commercial setting you should buy a copy of PGP from NAI.
This version of PGP has other advantages as well, most notably its integration
with common MS Windows and Mac OS applications, a limited license to export it
to foreign branch offices and a license for IDEA. See below, under question
Where can I obtain PGP?>, for information on how to contact them.

Q: Is encryption legal?

A: In much of the civilized world, the use of 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 the use of encryption is illegal are France, Iran, Russia and
Iraq.

Export, import or sale of products that contain strong encryption is usually
also subject to restrictions. These laws are usual implementations of the
Wassenaar Arrangement, for example the International Traffic in Arms Regulation
(ITAR). Check the laws of the relevant countries for more details.

The legal status of encryption in many countries has been gathered by Bert-Jaap
Koops in the Crypto Law Survey.

Q: Is PGP legal?

A: In addition to the comments about encryption listed above (Is encryption
legal?>) and the licence on the PGP software package you are using, the major
point of importance is the status of the patents on technologies used in PGP.
The patent on IDEA is still valid, see What's with the patent on IDEA?>. The
patent on RSA has expired, but had a significant impact on the development and
distribution of PGP, see What's with the patent on RSA?.

Q: What's with the patent on IDEA?

A: IDEA is patented in the USA (US 5,214,703), Europe (EP-B-0482154)and Japan
(JP 3225440) by Ascom Systec AG. This patent expires 25 May 2010 (USA) or 16
May 2011 (Europe and Japan). For strictly non-commercial use, the licence fee
is waved by MediaCrypt AG.

If you need to use PGP 2.x or GPG with IDEA (i.e. for compatibility with the
2.x versions) for commercial use, you should contact MediaCrypt AG who are the
distributor for the IDEA algorithm license for Ascom Systec AG, the patent
holders for IDEA. They sell individual and site licenses for using IDEA in PGP.
Contact:

MediaCrypt�AG
Technoparkstrasse 1
8005�Zurich
Switzerland
<IDEA@mediacrypt.com>
Tel ++41 1 445 3070
Fax ++41 1 445 3071

Q: What's with the patent on RSA?

A: 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 was only valid in the United States. This was never tested in court,
however, and later 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, were still considered in violation by PKP. If you were in the USA, you
used them at your own risk!

However, the patent has since expired, so there are no known patent issues with
RSA now.

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

A: Not really.

Of course, you can try using Google Groups if you are looking for articles
about specific topics.

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

A: The GNU Privacy Guard project has a C-library for integrating GnuPG in
applications called GPGME (GnuPG Made Easy). This is mostly targetted at
UNIX-like platforms.

The CTC program includes a freeware PGP-interoperable C-library called CTClib
and a Java crypto component called CTCjava.

There is an older PGP 2.x-compatible C-library that can be used in programs
called PGPlib.

NAI has a PGPsdk. available, but this not a software developer kit! The license
explicitly restricts the use of the sourcecode to peer review only, development
of programs with this source is not allowed. As a side note, also note that the
license forbids you to make public bugs, errors, architecture issues and/or
other problems with the source or compiled program without prior written
permission of NAI.

Alternatively, you could write your programs to call the PGP program when
necessary. In C, for example, you would use the system() or spawn...()
functions to do this. This is fairly complex to do securely, so make sure you
know what you are doing.

Q: What platforms has PGP been ported to?

A: PGP 2.x in its many versions has been ported successfully to many different
platforms, including the various Microsoft Windows versions, DOS, Mac OS, OS/2,
Unix (just about all flavors), VMS, Atari ST, Acorn RISC OS (Archimedes),
Commodore Amiga, EPOC and Palm OS. Most are listed on the International PGP
product page.

For Mac OS 8.x and 9.x there is a freeware PGP-interoperable program called
MacCTC.

For the EPOC operating system (as run by the Psion 5/5mx/Revo/S7/netBook and
Nokia 9210) there is a port of PGP 2.6.3ia for EPOC.

If you don't see your favorite platform above, don't despair! It's likely that
porting PGP 2.x to your platform won't be 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 to port it yourself!

A: PGP 5.x and later is available for the various Microsoft Windows versions
and the Mac OS 8.x/9.x. It is commercially available from NAI.

Note that PGP 7.x does not support Microsoft Windows XP (yet).

A: GNU Privacy Guard mostly targets UNIX-like systems and is known to work on
GNU/Linux, GNU/Hurd, FreeBSD, OpenBSD, NetBSD and various commercial UNIX-like
systems. There is also a commandline version for the various Microsoft Windows
versions.

Q: Where can I obtain PGP?

A: PGP is very widely available, so much so that a separate FAQ has been
written by Micheal Paul Johnson 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 online.

In short however:

��*�The PGP 2.x versions can be found at Wiretapped.net and PGPi.net.

��*�The PGP 5.x and later versions are available for download and purchase via
    NAI.

��*�The GNU Privacy Guard can be found from the GNU Privacy Guard project page.

��*�Many of the previously mentioned versions, as well as older versions, are
    widely mirrored, for example at Zedz.net.




Q: I want to find out more!

A: If this FAQ doesn't answer your question, there are several places for
finding out information about PGP. Above all, the accompanying documentation of
PGP and GPG should not be missed.

World Wide Web

��*�NAI, the company currently selling PGP 5.x through 7.x for commercial use

��*�http://www.stack.nl/~galactus/remailers/bg2pgp.txt

��*�Although the documentation that comes with PGP is very complete, you might
    also want to read this guide. It covers all the basic steps needed to
    install and use PGP, and also gives you tips on how to use it more
    effectively.

��*�http://www.stack.nl/~galactus/remailers/passphrase-faq.html

��*�Your pass phrase is used to protect your PGP secret key. Here's how to
    generate and manage strong pass phrases. This may also be useful for
    creating passwords for other purposes.

��*�PGP-related resources

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

��*�http://www.stack.nl/~galactus/remailers/attack-faq.html

��*�A very detailed analysis on the security of PGP and possible attacks.



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

Chapter 2. Common Problems in using PGP

Q: Are PGP 2.6.x, PGP 5.x and higher, and GNU Privacy Guard interoperable?
Q: Why does it take so long to encrypt/decrypt messages?
Q: How do I create a secondary key file?
Q: Where can I obtain scripts and programs to integrate pgp with my email or
    news reading system?
Q: How can I decrypt messages I've encrypted to others?
Q: Why can't I generate a key with PGP for Unix?
Q: When I clearsign a document in PGP, it adds a "dash-space" to several of my
    lines. Why?
Q: How do I encrypt more than one file at a time with the commandline version?
Q: How can I give my passphrase to the commandline PGP automatically?
Q: How come randseed.bin got "infected" by a virus?
Q: How do I determine if the PGP commandline worked?
Q: Why does PGP no longer ask for random keystrokes?
Q: Why can't a person using version 2.3 read my version 2.6 message?
Q: Why does PGP 2.x complain about checking signatures every so often?

Q: Are PGP 2.6.x, PGP 5.x and higher, and GNU Privacy Guard interoperable?

A: By and large, all PGP 2.x, 5.x and GPGs kan interoperate if:

 1. Only RSA keys are used, of at most 2048 bits length,

 2. MD5 is used as hash algorithm

 3. IDEA is used for the symmetrical algorithm.


For GNU Privacy Guard, this usually means that you need to add the IDEA module
as detailed in the GPG FAQ. RSA support is included by default as of version
1.0.3. Newer GPG versions include a --pgp2 option to restrict the output to
things that PGP 2.x understands.

A: GNU Privacy Guard and PGP 5.x and higher are by and large OpenPGP compliant
and interoperable.

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

A: This problem can arise when you have placed the entire public key ring from
one of the servers into your local pubring.pgp file. PGP may have to search
through several thousand keys to find the one that it is after. If you need to
have these large keyrings (e.g. because you cannot count on being able to
contact the keyservers to look up new keys), the solution to this dilemma is to
maintain 2 public key rings (See How do I create a secondary key file?). The
first ring, the normal pubring.pgp file, should contain only those individuals
that you send messages to quite often. The second key ring can contain all of
the keys for those occasions when the key you need isn't in your short ring.
You will, of course, need to specify the key file name whenever encrypting
messages using keys in your secondary key ring. Now, when encrypting or
decrypting messages to individuals in your short key ring, the process will be
a lot faster.

A: Encryption and decryption time also increases with the key size. A 2048 bits
key will take much longer to work with than, for example, a 512 bits key.

A: It is also possible, although fairly unprobable, that the random pool has
run empty and PGP is waiting for enough randomness to amass. Remember that PGP
needs randomness to create cryptographic keys, if these are not sufficiently
random they could be guessed by an attacker. So to be sure, PGP (or the OS
supplying it via /dev/random) waits until enough randomness is available. As
this random pool is filled by events from among others keyboard and mouse,
wriggling the mouse or tapping keys helps (use the control, alt and shift keys
if you are worried that the keystrokes might trigger something). As usually
enough randomness is gathered during normal operation and only a little is used
each time, this is occurs mostly when large amounts of encryptions are done.

Q: How do I create a secondary key file?

A: First, let's assume that you have all of the mammoth public key ring in your
default pubring.pgp file. First, you will need to extract all of your commonly
used keys into separate key files using the -kx option. Next, rename
pubring.pgp to some other name. For this example, I will use the name
pubring.big. Next, add each of the individual key files that you previously
created to a new pubring.pgp using the -ka option. To encrypt a message to
someone in the short default file, use the command pgp -e <file> <userid>. To
encrypt a message to someone in the long ring, use the command pgp -e +pubring=
c:\pgp\pubring.big <file> <userid>. Note that you need to specify the complete
path and file name for the secondary key ring. It will not be found if you only
specify the file name.

Q: Where can I obtain scripts and programs to integrate pgp with my email or
news reading system?

A: There are many scripts and programs available for making PGP 2.x easier to
use. There is an index to all of these at http://www.hauert.net/pgpmain.html
and at PGPi.org.

A: Plugins and configurations to use GNU Privacy Guard can be found on the GNU
Privacy Guard Project website, under Frontends.

A: PGP 5.x and higher already includes a number of plugins for other programs.
More are listed on at PGPi.org.

Q: How can I decrypt messages I've encrypted to others?

A: With conventional encryption, you can read the message by running PGP on the
encrypted file and giving the pass phrase you used to encrypt.

A: With PGP's public key encryption, it's only possible if you encrypted to
yourself as well.

With the PGP 5.x and higher versions, it is the default setting to also encrypt
to the default key. You can change this under PGP options / General / Always
encrypt to default key.

For PGP 2.x there is an undocumented setting, EncryptToSelf, which you can set
in your config.txt or on the command line to on if you want PGP to always
encrypt your messages to yourself.

Be warned, though; if your secret key is compromised, this means that the
attacker will be able to decode all the messages you sent as well as the ones
you've received. Similarly if you are forced to reveal decrypt your data (see
Can I be forced to reveal my pass phrase in any legal proceedings?>), you can
now also decrypt the messages you sent, instead of only those you received! On
the other hand, it allows you to read back the messages you sent in the past.

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

A: Most likely this is caused because PGP can't create the public and private
key ring files. If the environment variable PGPPATH isn't defined, PGP will try
to put those files in the subdirectory .pgp off your home directory. It will
not create the directory if needed, so if the directory's not there already,
PGP will abort after generating the key. This also happens if PGPPATH points to
a directory for which you don't have write permission.

There are two solutions: set the PGPPATH environment variable to point to the
location of your key rings, or run mkdir $HOME/.pgp; chmod 700 $HOME/.pgp
before generating your key.

Q: When I clearsign a document in PGP, it adds a "dash-space" to several of my
lines. Why?

A: PGP does this because of the "-----BEGIN PGP MESSAGE-----" (and related)
headers it uses to mark the beginning of PGP messages. To keep it from getting
confused, it tacks a "- " to the beginning of every line in the regular text
which has a dash at the start. It strips the extra dash and space when you
check the message's signature, and writes the original text to the output.

This also happens with several lines that start with "special" phrases, such as
"From", because those lines are otherwise escaped by mail programs, as required
by the mail standard. This would change the body of the mail and thereby
invalidate the signature.

If you use PGP/MIME type signatures, the signature is presented as an
attachement to receivers that do not have PGP.

For signing files, the accepted method is to use a seperate signature file.

Q: How do I encrypt more than one file at a time with the commandline version?

A: PGP will normally only accept one file to encrypt on the command line. Many
platforms allow you to call a program in a "batch" sequence. You can use this
to call PGP on multiple files automatically.

Under MS-DOS and OS/2, this works as follows:
    for %a in (*.*) do pgp -ea %a userid

You can also do conventional encryption this way, using the undocumented -z
option to specify the passphrase to encrypt all these files with:
    for %a in (*.*) do pgp -c %a -z"the passphrase"

Under UNIX, this would be done like this:
    for a in *
    do
      pgp -ea "$a" userid
    done

Several shells and front-ends will also let you encrypt multiple files at once,
usually.

Q: How can I give my passphrase to the commandline PGP automatically?

A:


    WarningStoring your passphrase like this is very dangerous! Remember that
    your passphrase is all that protects your secret keys from an attacker
    snooping around in your system.

There are three ways to do this. The easiest way is probably to set the
environment variable PGPPASS to contain your pass phrase. Under DOS and UNIX,
you can just type set PGPPASS=My secret pass phrase to do this.

    WarningThis is very insecure, as anyone who has access to your environment
    can see what your passphrase is. This includes people who come along during
    your lunch break and type set at a prompt on your computer. Under several
    variations of UNIX, it is possible to examine someone else's environment as
    well.

Another option, especially useful for shells, is to use the -z option. You just
add the option -z"My secret passphrase" to the PGP command line. Include the
passphrase in quotes if there are any spaces or "special" characters in it,
such as a "<" or ">" character which may confuse the command shell.

    WarningThis is even more insecure on a multi-user system as most allow
    other users to see the command options of programs run by another user.

Everyone else can see what programs you are running, including all the options
passed to it.

The best, but also the most complicated way is using the PGPPASSFD environment
variable. This variable should contain a "file descriptor number" pointing to a
file which contains the passphrase. This will protect the passphrase from
anyone but the superuser, if you properly set the file's permissions.

�       You can find something on this in the appnotes file in the pgp262  �
        distribution. If you set PGPPASSFD to 0, pgp will read the
        passphrase from stdin as soon it starts.

            PGPPASSFD=0; export PGPPASSFD
            echo "PassPhraseHere" | pgp -east file recipient1 recipient2..
                                 --Thanks to Jack Gostl for the following. �

�      You could also use funky shell redirection to make PGP get the          �
       passphrase from an arbitrary file. The exact command to define a
       variable depends on the shell; ksh and the likes use export PGPPASSFD=3
       , and csh and derivates use setenv PGPPASSFD 3.
           setenv PGPPASSFD 3; pgp -eat file recipient 3 < /my/passphrase/file
                                                        --Patrick J. LoPresti: �
This last example has the added advantage that standard input is still
available to the user, for example to answer Yes or No to certain questions.

Q: How come randseed.bin got "infected" by a virus?

A: The file randseed.bin is used by PGP to store and generate randomness, which
is used to create new random session keys every time you encrypt something.
Afterwards, it is filled with new random data. A virus or integrity checker
will then of course detect that the file has changed. Since the file has a .bin
extension, some checkers think that it is an executable, and so will inform you
they have detected a possible virus.

However, this file is only used by PGP to read some random data and will never
be executed. It is therefore safe to put it in the "exclusion" list of your
virus scanner, so it will be skipped in future. An alternative is to instruct
PGP to use a file with another extension, e.g. random.rnd. For the 2.6 versions
this is done by puttting Randseed=C:\PGP\RANDOM.RND in your config.txt file.
The PGP 5.x and higher GUI has a similar setting for Random Seed File.

Deleting the random seed file will not do any harm; PGP will just ask you for
some random keystrokes and generate the file again next time you encrypt
something.

Q: How do I determine if the PGP commandline worked?

A: Normally, PGP runs in "interactive" mode, and so you can always read on the
screen what went wrong, where and hopefully why. But if you want to use PGP in
a batch file, or in the background, you need to find out if the operation was
successful in another way. The usual approach for this is to use the "exit
code" returned by PGP.

To be able to detect if PGP could do what you asked, you need to add the
+batchmode option to the command line. (To avoid getting "stuck" at prompts
asking you to choose "yes" or "no", add the +force option). PGP will then
return 0 if everything went ok, and non-zero if something went wrong.

The PGP source contains a list of exit codes that are supposed to be returned
when the associated events occur. It seems that this does not always work as
expected. For example, PGP should return exit code 31 when no passphrase was
specified to decrypt the file, but if you try to check a signature, exit code 1
is used to indicate any error, including "No key to check signature" and "Bad
signature".

Q: Why does PGP no longer ask for random keystrokes?

A: The random keystrokes were necessary to generate random events, but newer
PGPs acquire these events automatically. PGP 5.x and up for the Microsoft
Windowses and Mac OS uses (the timing of) system events that go on all the time
to constantly update the random seed file randseed.bin file. These events
include disk access, keystrokes, mouse movements and other things that are
reasonably random. If you check, you will see that the randseed.bin's last
modified date often changes, even if you are not using PGP.

Under UNIX-like systems, PGP 5.x and GNU Privacy Guard use the output of the
random device /dev/random when available, which gathers randomness in a similar
way.

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

A: You are probably using MIT PGP, or possibly some other version of PGP with
the legal_kludge option turned off.

As part of the agreement made to settle PGP's patent problems, MIT PGP changed
its format slightly to prevent PGP 2.4 and older versions from decrypting its
messages. This format change was written into MIT PGP to happen on September 1,
1994. Thus, all messages encrypted with MIT PGP after that date are unreadable
by 2.4 (and earlier). The idea was that people using 2.4 and earlier would be
forced to upgrade, and so the patent violating version would no longer be used
(see What's with the patent on RSA?).

The best route here is for your friend to upgrade to a newer version of PGP.
Alternatively, if you are using a non-MIT version, look up the legal_kludge
option in your documentation; you should be able to configure your copy of PGP
to generate old-style messages. In 2.6.2i and 2.6.3i, this is done by putting
Legal_Kludge=off in your config.txt file for PGP.

Note that the "old" output can be read perfectly well by newer versions, so if
you are corresponding with MIT and 2.3 users, you will be best off with the
Legal_Kludge=off statement in your config.txt.

Q: Why does PGP 2.x complain about checking signatures every so often?

A: Version 2.3a introduced the "pkcs_compat" option, allowing the format of
signatures to change slightly to make them more compatible with industry
standards. MIT PGP, because it uses the RSAREF library, is unable to understand
the old signature format, so it therefore ignores the signature and warns you
that it is doing so.

This problem comes up mostly with old key signatures. If your key contains such
old signatures, try to get those people who signed your key to resign it with a
newer version of PGP.

If an old signature is still vitally important to check, get a non-MIT version
of PGP to check it with, such as ViaCrypt's.
-------------------------------------------------------------------------------

Chapter 3. Security Questions

Q: How secure is PGP?
Q: Can't you break PGP by trying all of the possible keys?
Q: How secure is the conventional cryptography option?
Q: Can the NSA crack PGP (or RSA, DSS, IDEA, 3DES,...)?
Q: Has RSA ever been cracked publicly?
Q: What is the best way to crack PGP?
Q: What if I forget my pass phrase?
Q: Why do you use the term "pass phrase" instead of "password"?
Q: If my secret key ring is stolen, can my messages be read?
Q: How do I choose a pass phrase?
Q: How do I remember my pass phrase?
Q: How do I verify that my copy of PGP has not been tampered with?
Q: How do I know that there is no trap door in the program?
Q: 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.
Q: Is there a back door in the international version?
Q: Can I put PGP on a multi-user system like a UNIX machine or a mainframe?
Q: Can I use PGP under a "swapping" operating system like Windows, OS/2 or
    UNIX?
Q: Aren't all of these security procedures a little paranoid?
Q: Can I be forced to reveal my pass phrase in any legal proceedings?
Q: How secure is the "for your eyes only" option?

Q: How secure is PGP?

A: Very secure against eavesdroppers.

The cryptographic algorithms used for encryption and signing in PGP are very
well researched and have shown no practical weaknesses (see Can't you break PGP
by trying all of the possible keys?>).

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.

A: PGP does not protect you if you use your secret key on a compromised system,
i.e. you type your passphrase and sign or decrypt something, or if you stored
the passphrase in plaintext on the compromised system (as described in How can
I give my passphrase to the commandline PGP automatically?).

If you use PGP on a compromised system, the attacker can capture your
passphrase as you type it. In combination with you secret keyring, this is
sufficient to decode all messages that where encrypted with your public key and
signing documents in your name thus impersonating you.

Make sure you keep your system secure from such compromises!

A: These are the most important attacks you should be aware of. It would be
beyond the goal of this FAQ to discuss all possible attacks against or possible
flaws in PGP. If you want to know more than what is available in here, see
infiNity's PGP Attack FAQ.

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

A: 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 2128
possible combinations would be legal as a key, and only that one key would
successfully decrypt the message. 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
a well researched algorithm, and although work still needs to be done on it as
it relates to complexity theory, 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 to be unworkable.

Similarly all of the symmetrical algorithms additionally available in the 5.x
and GNU Privacy Guard are not known to have significant flaws:

��*�3DES is probably the most studied cryptographic algorithm ever. It offers
    the strength equivalent to a 112-bit block cipher. The best attacks
    published require massive amounts of storage and still take more than 2108
    operations.

��*�CAST is a well studied 128-bit algorithm. There is no known way of breaking
    it faster then brute force.

��*�AES or Rijndael is a newcomer in crypto-algorithms, chosen to replace DES/
    3DES with larger keys (128, 192 or 256 bit) and higher performance.
    Although there is a lot of attention to all the AES-contestants and
    finalists in general and Rijndael in particular, it hasn't had nearly as
    much scrutiny as the previously mentioned algorithms.

��*�Blowfish and its newer cousin (and AES-finalist) Twofish have gotten much
    (media) attention but are both still relatively new. Because of they do not
    seem encumbered by patents and there are no serious, publicly known
    attacks, these algorithms are popular with many open source projects.




Q: How secure is the conventional cryptography option?

A: 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 inperson meeting or
trusted courier.

This option is especially useful if you want to back up sensitive files, or
want to take an encrypted file to another system where you will decrypt it. Now
you don't have to take your secret key with you. It will also be useful when
you lose your secret key. And you can even pick a different passphrase for each
file you encrypt, so that an attacker who manages to get one file decrypted
can't decrypt all the other files as well.

Q: Can the NSA crack PGP (or RSA, DSS, IDEA, 3DES,...)?

A: This question has been asked many times. If the NSA were able to crack RSA
or any of the other well known cryptographic algorithms, you would probably
never hear about it from them. Now that RSA and the other algorithms are very
widely used, it would be a very closely guarded secret.

The best defense against this is the fact the algorithms are 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 one of the algorithms, I'm sure that we would hear about
it from them via a paper in one of the cryptography conferences.

For this reason, when you read messages saying that "someone told them" that
the NSA is able to break PGP, take it with a grain of salt and ask for some
documentation on exactly where the information is coming from. In particular,
the story called NSA Can Break PGP Encryption is a joke.

Q: Has RSA ever been cracked publicly?

A: Several messages RSA-encrypted with small (< 513 bits) keys have been
cracked publicly. Further effort is still ongoing, RSA Security offers prizes
for their RSA factoring challenges.

First was the RSA-129 key. The inventors of RSA published a message encrypted
with a 129-digits (430 bits) RSA public key, and offered $100 to the first
person who could decrypt the message. In 1994, an international team
coordinated by Paul Leyland, Derek Atkins, Arjen Lenstra, and Michael Graff
successfully factored this public key and recovered the plaintext. The message
read: "THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE"

They headed a huge volunteer effort in which work was distributed via E-mail,
fax, and regular mail to workers on the Internet, who processed their portion
and sent the results back. About 1600 machines took part, with computing power
ranging from a fax machine to Cray supercomputers. They used the best known
factoring algorithm of the time; better methods have been discovered since
then, but the results are still instructive in the amount of work required to
crack a RSA-encrypted message.

The coordinators have estimated that the project took about eight months of
real time and used approximately 5000 MIPS-years of computing time.

What does all this have to do with PGP? The RSA-129 key is approximately equal
in security to a 426-bit PGP key. This has been shown to be easily crackable by
this project. PGP used to recommend 384-bit keys as "casual grade" security;
recent versions offer 768 bits as a recommended minimum security level.

Note that this effort cracked only a single RSA key. If this had been a PGP
key, it would have allowed them to decrypt all messages encrypted to that key.
Nothing was discovered during the course of the experiment to cause any other
keys to become less secure than they had been, i.e. it would not make it any
easier to read messages encrypted to other keys.

A year later, the first real PGP key was cracked. It was the infamous Blacknet
key, a 384-bits key for the anonymous entity known as "Blacknet". A team
consisting of Alec Muffett, Paul Leyland, Arjen Lenstra and Jim Gillogly
managed to use enough computation power (approximately 1300 MIPS) to factor the
key in three months. It was then used to decrypt a publicly-available message
encrypted with that key.

The most important thing in this attack is that it was done in almost complete
secrecy. Unlike with the RSA-129 attack, there was no publicity on the crack
until it was complete. Most of the computers only worked on it in spare time,
and the total power is well within reach of a large, perhaps even a medium
sized organization.

Q: What is the best way to crack PGP?

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

This is why picking a strong pass phrase is so important. Many of these cracker
programs are very sophisticated and can take advantage of language idioms,
popular phrases, and rules of grammar in building their guesses. Single-word
"phrases" proper names (especially famous ones), or famous quotes are almost
always crackable by a program with any "smarts" in it at all.

There is a program available which can "crack" conventionally encrypted files
by guessing the passphrase. It does not do any cryptanalysis and works on the
2.x-format only, so if you pick a strong passphrase your files will still be
safe. Unfortunately the original website has vanished. The program is still
widely available, e.g. at zedz.net.

There are also other methods to get at the contents of an encrypted message,
such as bribery, tapping your keyboard, installing trojan horses, snooping of
electronic emanation from the computers processing the message (often called a
TEMPEST attack), blackmail, or rubber-hose cryptoanalysis (beating you with a
rubber hose until you give the passphrase or similar, see Can I be forced to
reveal my pass phrase in any legal proceedings?).

Q: What if I forget my pass phrase?

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

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

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

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

A: No, not unless they have also stolen your secret pass phrase or you
foolishly put it in plaintext on the same disk (see How can I give my
passphrase to the commandline PGP automatically?), 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 just to be sure. 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.

Q: How do I choose a pass phrase?

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

A pass phrase which is composed of ordinary words without punctuation or
special characters is susceptible to a dictionary attack. Transposing
characters or mis-spelling words makes your pass phrase less vulnerable, but a
professional dictionary attack will cater for this sort of thing.

See Randall T. Williams' Passphrase FAQ for a more detailed analysis.

Q: How do I remember my pass phrase?

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

It may be a good idea to periodically try out all the passphrases, or to
iterate them in your mind. Repeating them often enough will help keep them from
being completely blanked out when the time comes that you need them.

If you use long passphrases, it may be possible to write down the initial
portion without risking compromising it, so that you can read the "hint" and
remember the rest of the passphrase. If you chose to write down these (partial)
passphrases, consider putting them in an tamper evident, non-transparent
enveloppe and storing them in a secure place.

For a simple way to pick provably strong passphrases that are easy to remember,
please see Arnold Reinhold's Diceware website.

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

A: 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 versions of 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.

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

A: 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 compile the program yourself
and use the resulting executable.

For the PGP 5.x and higher versions based on the PGPsdk so its sourcecode can
be verified, but the use of "home-compiled" binaries seems to be forbidden by
the license, even when you bought a commercial license for the same product.
Only comparison between a "home-compiled" binary and the binaries as provided
in the commercial package seems to be allowed, but this very hard and has not
been succesfully done as far as I know (even if exactly the same compiler with
exactly the same options would be used, the resulting binary would differ in
non-trivial ways). Bottom line: if you do not trust NAI to have sold you the
untampered version, you should be using one of the open source versions whose
license does allow compilation from source and use of the subsequent binary.

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

A: 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 was). 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!

Q: Is there a back door in the international version?

A: No. The international version of PGP is based on an illegally exported
version of PGP, and uses an RSA encryption/decryption library (MPILIB) which
may have violated the RSA patent which is only valid in the USA (see What's
with the patent on RSA?).

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

Q: Can I put PGP on a multi-user system like a UNIX machine or a mainframe?

A: Yes. PGP will compile and run on 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. Also do not
leave the passphrase around (see How can I give my passphrase to the
commandline PGP automatically?).

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, IPSec or SSH), you
are the only user, you take reasonable system security measures to prevent
unauthorized access, and you are aware of the risks above, you can securely use
PGP on one of these systems.

You can still use PGP on multi-user systems or networks without a secret key
for checking signatures and encrypting. As long as you don't process a private
key or type a pass phrase on the multiuser system, you can use PGP securely
there.

Of course, it all comes down to how important you consider your secret key. If
it's only used to sign posts to Usenet, and not for important private
correspondence, you don't have to be as paranoid about guarding it. If you
trust your system administrators, then you can protect yourself against
malicious users by making the directory in which the keyrings are only
accessible by you.

Q: Can I use PGP under a "swapping" operating system like Windows, OS/2 or
UNIX?

A: Yes. PGP 2.x 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.

Because swapfiles shrink, and many applications (e.g. Microsoft Word and
Microsoft compilers) grab disk space (and unused memory) and don't always fill
it all out, you will regularly get fragments of other work embedded in files
unrelated to it.

Disabling swapping (after getting more memory) will help, but you should also
be cautious about sending binary attachments (like Word DOCs). If you wish to
keep your hard-drive more secure, you should consider a sector-level encryptor
(such as Scramdisk, SFS or PGPdisk).

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. Many of them perform not nearly as well as claimed in the documentation
though. Under OpenBSD you can configure the OS to encrypt the swap, preventing
this altogether.

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

A: 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, including the old "Caligula"-virus that sends the PGP secret keyring
to the codebreakers.org site. Even when it doesn't involve money, some people
are obsessed with breaking into systems. Once a system is compromised, use of
PGP on that system will expose both your pass phrase and secret keyring, giving
the attacker everything to he needs to read your secret mail.

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

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

A: Bert-Jaap Koops has a Crypto and Self-Incrimination FAQ adressing this
issue. The ultra-short version is that no country is known to have a law
requiring suspects to decrypt under legal warrant, with the exception of the UK
and the Regulation of Investigatory Powers Act 2000.

Note that the GNU Privacy Guard has a --show-session-key option specifically
for those under the obligation to provide the decryption key. It allows one to
disclose the individual session keys of encrypted messages instead of the
longlived secret keys. Without disclosure of your secret keys, newly encrypted
messages are still safe from all prying eyes.

Note that law enforcement agencies have been known to install means to capture
your passphrase and/or plaintext, such as keyboard sniffers and trojans, making
the self-incrimination question irrelevant.

Q: How secure is the "for your eyes only" option?

A: 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 "for your eyes" 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.
-------------------------------------------------------------------------------

Chapter 4. Keys

Q: Which key size should I use?
Q: Can a public key be forged?
Q: How do I detect a forged key?
Q: Why does PGP take so long to add new keys to my key ring?
Q: How can I extract multiple keys into a single armored file with the command
    line PGP?
Q: I tried encrypting the same message to the same address two times and got
    completely different outputs. Why is this?
Q: What does the message "Unknown signator, can't be checked" mean?
Q: How do I get PGP to display the trust parameters on a key?
Q: Should I include my key in every message (e.g. by putting it in my
    .signature)?
Q: How can I make my key available via finger?
Q: How do I specify which key to use when an individual has 2 public keys and
    the very same user ID on each, or when 2 different users have the same
    name?

Q: Which key size should I use?

A: PGP gives you choices for RSA and DSA key size ranging from 512 to 2048 or
even 4096 bits. The larger the key, the more secure the RSA/DSA 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 the symmetrical algorithm (IDEA, 3DES, CAST etcetera). The main body of
the message is totally unaffected by the choice of RSA key size.

Dr Lenstra and Dr Verheul offer their recommendations for keylengths. In their
calculation, a 2048 bit key should keep your secrets safe at least until 2020
against very highly funded and knowledgable adversaries (i.e. you have the NSA
working against you). Against lesser adversaries such as mere multinationals
your secret should be safe against bruteforce cryptoanalysis much longer, even
with 1024 bit keys.

So unless you have a very good reason for doing otherwise, select the 1024 or
2048 bit key size. Using currently available algorithms for factoring and
available computing power, the 384 and 512 bit keys are known to be within
reach of adversaries and 768 is questionable (see also Can't you break PGP by
trying all of the possible keys?>).

Q: Can a public key be forged?

A: In short: not completely, but parts may be.

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

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

It is possible to create a key with a chosen key ID.
�        A PGP key ID is just the bottom 64 bits of the public modulus �
         (but only the bottom 32 bits are displayed with pgp -kv). It
         is easy to select two primes which when multiplied together
         have a specific set of low-order bits.
                                              --Paul Leyland explains: �
This makes it possible to create a fake key with the same key ID as an existing
one. The fingerprint will still be different, though.

By the way, this attack is sometimes referred to as a DEADBEEF attack. This
term originates from an example key with key ID 0xDEADBEEF which was created to
demonstrate that this was possible.

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

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

�        Inside a PGP key, the public modulus and encryption exponent  �
         are each represented as the size of the quantity in bits,
         followed by the bits of the quantity itself. The key
         fingerprint, displayed by pgp -kvc, is the MD5 hash of the
         bits, but NOT of the lengths. By transferring low-order bits
         from the modulus to the high-order portion of the exponent
         and altering the two lengths accordingly, it is possible to
         create a new key with exactly the same fingerprint.
          --Paul Leyland provided the following technical explanation: �


Q: How do I detect a forged key?

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

For this reason, you should always verify that key ID, fingerprint, and key
size correspond when you are about to use someone's key. And when you sign a
user ID, make sure it is signed by the key's owner!

Similarly, if you want to provide information about your key, include key ID,
fingerprint and key size.

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

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

In this case, it might be faster to rename your public keyring to something
else, then name the keyserver's keyring pubring.pgp and add your own keyring to
the big one. There is a danger to this, though; the trust parameters to your
old keys will be lost, and you will be using the trust parameters from this big
keyring. See also How do I create a secondary key file?>.

A: If your keyring has been damaged, PGP can also take a while to process it.

Q: How can I extract multiple keys into a single armored file with the command
line PGP?

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

Unfortunately, the present version of PGP does not allow you to do this
directly. Fortunately, there is an indirect way to do it.
    pgp -kx uid1 extract
    pgp -kx uid2 extract
    pgp -kx uid3 extract

This puts all three keys into extract.pgp. To get an ascii amored file, call:
pgp -a extract.pgp

You get an extract.asc. Someone who does a pgp extract and has either file
processes all three keys simultaneously.

A Unix script to perform the extraction with a single command would be as
follows:
      #!/bin/sh
      for name in name1 name2 name3 ... ; do
      pgp -kx "$name" /tmp/keys.pgp <keyring>
      end
An equivalent DOS command would be:

for %a in (name1 name2 name3 ...) do pgp -kx %a keys.pgp <keyring>

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

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

To generate this random session key, PGP will try to use information from a
file called randseed.bin. If this file does not exist, or for some reason isn't
random enough, you are asked to type in some random keystrokes which will then
be used as a "seed" for the random number generator.

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

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

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

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

Q: Should I include my key in every message (e.g. by putting it in my
.signature)?

A: No. Although it is important to spread your key as far as possible, it is a
lot better to send it to a keyserver (see What are the Public Key Servers?>) or
to make it available via finger (see How can I make my key available via
finger?>>), or perhaps as a link off your WWW homepage. This way, people who
need your key will be able to get it, and you don't send it out to a lot of
uninterested people every time you email or post something.

Additionally, keep in mind a snooper reading your outgoing mail can easily
switch the public key in there with his own fake key. If this substituted key
is used, the snooper can still read the messages sent to you. If the other
party gets your key from a different location with a different method, it is a
lot harder for that snooper to change the keys. Note that signing the message
containing the key will not help; the snooper can easily re-sign the message
with his key, see Can a public key be forged?>. So always check the fingerprint
as described in How do I detect a forged key?>.

Q: How can I make my key available via finger?

A: 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 your home directory called .plan. If your computer
supports this, you can put your public key in this file. Make sure the file is
world-readable, use chmod 644 $HOME/.plan if other people can't get at your
plan. The home directory also has to be accessible. Use chmod +x $HOME in your
home directory to do this. Contact your system administrator if you have
further problems with this.

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

A: Instead of specifying the user's name in the ID field of the PGP command,
you can use the key ID number. The format is 0xNNNNNNNN where NNNNNNNN is the
user's 8 character key ID number. It should be noted that you don't need to
enter the entire ID number, a few consecutive digits from anywhere in the ID
should do the trick. The key ID shows up directly after the key size when you
do pgp -kv userid.

Be careful: If you enter 0x123, you will be matching key IDs 0x12393764,
0x64931237, or 0x96412373. Any key ID that contains 123 anywhere in it will
produce a match. They don't need to be the starting characters of the key ID.
You will recognize that this is the format for entering hex numbers in the C
programming language. For example, any of the following commands could be used
to encrypt a file to my public key:
        pgp -e <filename> "Wouter Slegers"
        pgp -e <filename> wouter@yourcreativesolutions.nl
        pgp -e <filename> 0x5217C2AF
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.
-------------------------------------------------------------------------------

Chapter 5. Message Signatures

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

Q: What is message signing?

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

Q: How do I sign a message and keep it readable?

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

pgp -sat +clearsig=on <filename>

The output file will contain your original unmodified text, along with section
headers and an armored PGP signature. In this case, PGP is not required to read
the file, only to verify the signature.

You should be careful when you "clearsign" a text file like this. Some mail
programs might alter your message when it is being sent, for example because
there are very long lines in the message. This will invalidate the signature on
the message. Also, using 8-bit characters in your message can cause problems;
some versions of PGP will think the file is actually a binary file, and refuse
to clearsign it.

For this reason, PGP 2.6.3i will automatically ASCII armor messages with very
long lines in it.

When using PGP/MIME, the signature is sent as an attachment to the message.
This keeps the signed text readable like usual, even to MIME-compatible email
programs that do not support PGP.

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

A: No. The reason for this is that the signature contains information (called a
message digest or a one-way hash) about the whole 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.

Q: Are PGP signatures legally binding?

A: Simone van der Hof maintains the Digital Signature Law Survey adressing
these issues. In short: digital signatures (such as provided by PGP) are only
legally binding on their own under very specific situations in a few countries,
if at all. In many countries this is rapidly changing though.

Even if the digital signature is not binding in itself, in many jurisdictions
one can arrange to accept valid digital signatures as binding via a prior
agreement in writing. If you are going to be swapping many digitally-signed
agreements with another party, this approach may be useful. You might want to
check with a lawyer in your country if the digital signatures will be used for
important or valuable contracts.

Q: Is the date on a PGP signature reliable?

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

For this reason, you can use a so-called "digital notary" or time-stamping
service. This is a system that does nothing but sign documents you send to it,
after inserting a date and time somewhere in the text. The service uses a
numbering scheme which makes it impossible to insert timestamps at a later
time. One such service is run by Matthew Richardson. For more information about
it, please see the PGP Digital Timestamping Service website.
-------------------------------------------------------------------------------

Chapter 6. Key Signatures

Q: What is key signing?
Q: How do I sign a key?
Q: Should I sign my own key?
Q: Should I sign X's key?
Q: How do I verify someone's identity?
Q: How do I know someone hasn't sent me a bogus key to sign?
Q: What's a key signing party?
Q: How do I organize a key signing party?

Q: What is key signing?

A: 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. If you trust Joe to identify John, 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 over exactly how many levels this chain of trust is allowed to
proceed.

The options in PGP's configuration to control this are:

��*�Cert_Dept = n

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

��*�Completes_Needed = n

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

��*�Marginals_Needed = n

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


You can display the trust parameters for a key with pgp -kc. See also question
How do I get PGP to display the trust parameters on a key?>. Be careful about
keys that are several levels removed from your immediate trust.

The PGP trust model is discussed in more detail by Alfarez Abdul-Rahman.

Q: How do I sign a key?

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

Q: Should I sign my own key?

A: Yes, you should sign each personal ID on your key, which is why in PGP 5.x+
and GNU Privacy Guard newly generated keys are signed by default. This will
help to prevent anyone from placing a phony address in the ID field of the key
and possibly having your mail diverted to them. Of course they can't read the
encrypted mail, but you won't see it at all. And even worse, adding a fake user
ID reading "Please use key 0x416A1A35 from now on" can mean someone else will
use the imposter's key with your name on it, rather than your own.

It is very easy to add user IDs to someone else's key. All it takes is a binary
editor or some knowledge of the PGP public key format. But since you are the
only person who can sign your own user IDs, the fake ones will not be signed,
and so anyone who gets the key can immediately spot the fake ones. For example,
my entry in the public key ring now appears as follows if you use the -kvv
command:
    Type Bits/KeyID    Date       User ID
    pub  1024/416A1A35 1994/10/01 Arnoud Engelfriet <galactus@stack.nl>
    sig       416A1A35             Arnoud Engelfriet <galactus@stack.nl>
                                  *** <galactus@stack.urc.tue.nl> now INVALID!
    sig       416A1A35             Arnoud Engelfriet <galactus@stack.nl>
                                  Galactus <galactus@stack.urc.tue.nl>
    sig       3602A619             Stephen Hopkins <shopkins@coventry.ac.uk>
    sig       DD63EF3D             Frank Castle <Frank_Castle@panther.pphost.nl>
    sig       416A1A35             Arnoud Engelfriet <galactus@stack.nl>
                                  Arnoud Engelfriet <galactus@stack.urc.tue.nl>
    sig       390E3FB1             Martijn Heemels <M.A.L.Heemels@stud.tue.nl>
    sig       DA87C0C7             Edgar W. Swank   <EdgarSwank@Juno.com>
    sig       416A1A35             Arnoud Engelfriet <galactus@stack.nl>

For a more detailed discussion of why you should sign your own key, see "Why
you should sign your own key" by Walther Soldierer.

Note that PGP 2.6.3[i], PGP 5.x and GNU Privacy Guard automatically sign each
user ID you add to your own key.

Q: Should I sign X's key?

A: 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 Mallet over
there." Mallet may be an ax murderer; you don't become tainted with his crime
just because you can pick him out of a crowd.

Q: How do I verify someone's identity?

A: 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 passport. Do make sure to observe the standard
keysigning security steps described in How do I know someone hasn't sent me a
bogus key to sign?>.

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

A: 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 or keyservers are bit harder to tamper with,
but not impossible.

If it is a key from someone you know well and whose voice you recognize then it
is sufficient to give them a phone call and have them read their key's
fingerprint (obtained with pgp -kvc <userid>). To be sure, also ask them for
the key size and its key ID. There are ways to create a forged key with an
identical fingerprint (see question Can a public key be forged?> for details).
You can of course also check these details in another way, for example if he
has printed it on his business card.

If you don't know the person very well then the only recourse is to exchange
keys face-to-face and ask for some proof of identity. Don't be tempted to put
your public key disk in their machine so they can add their key, they could
maliciously replace your key at the same time. If the user ID includes an
e-mail address, verify that address by exchanging an agreed encrypted message
before signing. Don't sign any user IDs on that key except those you have
verified.

Q: What's a key signing party?

A: 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, making it easier for you to find one or more trusted paths
to someone whose public key you didn't have.

Kevin Herron has an example of a keysigning party announcement page.

Q: How do I organize a key signing party?

A: 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 has recommended this method:

There are many ways to hold a key-signing session. Many viable suggestions have
been given. And, just to add more signal to this newsgroup, I will suggest
another one which seems to work very well and also solves the N-squared problem
of distributing and signing keys. Here is the process:

 1. You announce the keysigning session, and ask everyone who plans to come to
    send you (or some single person who will be there) their public key. The
    RSVP also allows for a count of the number of people for step 3.

 2. You compile the public keys into a single keyring, run pgp -kvc on that
    keyring, and save the output to a file.

 3. Print out N copies of the pgp -kvc file onto hardcopy, and bring this and
    the keyring on media to the meeting.

 4. At the meeting, distribute the printouts, and provide a site to retreive
    the keyring (an ftp site works, or you can make floppy copies, or whatever
    -- it doesn't matter).

 5. When you are all in the room, each person stands up, and people vouch for
    this person (e.g., "Yes, this really is Derek Atkins -- I went to school
    with him for 6 years, and lived with him for 2").

 6. Each person securely obtains their own fingerprint, and after being vouched
    for, they then read out their fingerprint out loud so everyone can verify
    it on the printout they have.

 7. After everyone finishes this protocol, they can go home, obtain the
    keyring, run pgp -kvc on it themselves, and re-verify the bits, and sign
    the keys at their own leisure.

 8. To save load on the keyservers, you can optionally send all signatures to
    the original person, who can coalate them again into a single keyring and
    propagate that single keyring to the keyservers and to each individual.



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

Chapter 7. Revoking a key

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

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

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

Assuming you have a key revocation certificate previously made (or a backup
copy of your secret key ring with which you can generate one now), 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 (or at the very least generate a revocation certificate).

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

A: As Phil Zimmermann put it: "I'm sorry, you're hosed."

You can't, since the pass phrase unlocks the secret key which is required to
create the certificate (for signing it).

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.

Q: How do I create a key revocation certificate?

A: The easiest way to do this is:

 1. Make a backup of your public and secret keyrings.

 2. Revoke your key with pgp -kd youruserid.

 3. Extract the revoked key to a file with pgp -kxa youruserid. This file is
    what the manual calls the "revocation certificate."

 4. Store the certificate in a safe location, for example on a floppy which you
    keep someplace else.

 5. Restore the backed-up keyrings.




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

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

A: First of all, generate a new key with one of the user IDs stating that Old
key 0x12345678 no longer valid: lost secret key. Get this key signed by
(preferbly the same) friends and collegues. Add this key to the keyservers so
people can start using your new key as soon as possible.

To discourage use of your old key, you can use a binary editor to change one of
the user IDs on your public key to read "Key invalid; use key 0x12345678" or
something to that effect. Keep in mind that the new user ID can't be longer
than the old one, unless you know what you are doing. Then extract the key, and
send it to the keyserver. It will think this is actually a new user ID, and add
it to your key there.

However, since anyone can do the above, many people will not trust unsigned
user IDs with such statements. As explained in question Should I sign my own
key?>, all user IDs on your key should be self-signed. So again, make a key
revocation certificate in advance and use that when necessary.
-------------------------------------------------------------------------------

Chapter 8. Public Key Servers

Q: What are the Public Key Servers?
Q: What public key servers are available?
Q: What is the syntax for the key server commands?

Q: What are the Public Key Servers?

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

While a number of key servers exist, it is only necessary to send your key to
one of them. The key server will take care of the job of sending your key to
all other known servers.

Q: What public key servers are available?

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

You can access the keyserver in e-mail, by sending mail to <
pgp-public-keys@keys.pgp.net> with the command (see What is the syntax for the
key server commands?> below) in the Subject line of your message. This message
will be sent to one of the keyservers at random, which ensures that an
individual server will not be overloaded.

If you have WWW access, you can also use the WWW interface.

Q: What is the syntax for the key server commands?

A: The key server expects to see one of the following commands placed in the
subject field. Note that only the ADD command uses the body of the message.
    ADD           Your PGP public key (key to add is body of msg) (-ka)
    INDEX         List all PGP keys the server knows about (-kv)
    VERBOSE INDEX List all PGP keys, verbose format (-kvv)
    GET           Get the whole public key ring (-kxa *), in multiple messages
    GET <userid>  Get just that one key (-kxa <userid>)
    LAST <n>      Get all keys uploaded during last <n> days

Note that instead of a user ID, you can also use a key ID. In this case, you
should put "0x" in front of it. By using a key ID rather than a user ID, name
or e-mail address, you ensure that you get exactly the key you want. Please see
question How do I specify which key to use when an individual has 2 public keys
and and the very same user ID on each?> for more information on how to use key
IDs.

If you wish to get the entire key ring and have access to FTP, it would be a
lot more efficient to use FTP rather than e-mail. Download an entire keyring
from PGP.net.
-------------------------------------------------------------------------------

Chapter 9. Bugs

Q: Where do I send bug reports?
Q: What bugs have been found in PGP?

Q: Where do I send bug reports?

A: Bugs related to MIT PGP should be sent to pgp-bugs@mit.edu. You will want to
check the MIT PGP FAQ with the complete bug list for MIT PGP before reporting a
bug to make sure that the bug hasn't been reported already. If it is a serious
bug, you should also post it to comp.security.pgp.announce or .tech. Serious
bugs are bugs that affect the security of the program, not compile errors or
small logic errors.

Post all of your bug reports concerning non-MIT versions of PGP to
comp.security.pgp.tech, and forward a copy to me for possible inclusion in
future releases of the FAQ. Please be aware that the authors of PGP might not
acknowledge bug reports sent directly to them. Posting them on USENET will give
them the widest possible distribution in the shortest amount of time.

Q: What bugs have been found in PGP?

A: 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, as well as the Mac versions.

��*�PGP 2.6ui continues to exhibit the bug in 2.3a where conventionally
    encrypted messages, when encrypted twice with the same pass phrase, produce
    the same ciphertext.

��*�The initial release of PGP 2.6.2i contained a bug related to clearsigned
    messages; signed messages containing international characters would always
    fail. For that reason, it was immediately pulled from distribution and
    re-released later, minus the bug. If you have problems with 2.6.2i, make
    sure you downloaded your copy after 7 May 1995.

��*�As reported by Steven Markowitz, the following bugs exist in PGP 4.0
    Business Edition (the commercial version):

     1. Signature retirement does not work. When I retire a key signature, PGP
        still treats the key as signed. If I remove the signature from
        pubring.pgp, but leave the retirement certificate in the keyring, PGP
        still treats the key as signed.

     2. Although encrypt-only keys cannot be used to sign documents, PGP allows
        them to be used to make key signatures.


��*�The international version of PGP has the undocumented +makerandom command,
    which can generate a file full of random data. Unfortunately, it does not
    work as intended, because the random number generator is not initialized
    properly. This does not affect normal PGP operation; the bug is only
    present when +makerandom is used.




Glossary of cryptographic terms

Advanced Encryption Standard (AES)
    The Advanced Encryption Standard will be the new standard cryptographic
    algorithm for use by U.S. government organizations to protect sensitive
    (unclassified) information. The algorithm Rijndael was chosen out of a
    group of contending algorithms. It is intended as the successor for DES.
    Newer versions of PGP and GPG feature support for AES.

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.

Data Encryption Standard (DES)
    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 is feasible to build a machine
    that could crack a 56 bit key in under a day's time as demonstrated by
    EFF's DES Cracker Project.

    For this reason, triple-DES or 3DES is introduced. It uses single-DES to
    encrypt the data, then to "decrypt" it with another key and encrypt the
    result again with another key. The resulting encryption is as strong as a
    hypothetical 112-bit DES.

Electronic Frontier Foundation (EFF)
    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
    United States of America
    <eff@eff.org>
    +1 202 347 5400
    +1 202 393 5509

International Data Encryption Algorithm (IDEA)
    Developed in Switzerland and used in PGP 2.x as the symmetrical encryption
    algorithm. For non-commercial use in PGP licensing fees are waved, for
    commercial use licenses must be purchased (see What's with the patent on
    IDEA?>). IDEA uses a 128 bit user supplied key to perform a series of
    nonlinear mathematical transformations on a 64 bit data block.

International Traffic in Arms Regulations (ITAR)
    ITAR are the regulations covering the export of weapons and weapons related
    technology from the United States.

Key Escrow
    In general, key escrow means that a copy of the secret key needed to
    decrypt something is stored with a third party. This can be a notary or a
    bank, who will keep it safely for you, in case you lose your key, or when
    you die, in which case your relatives might need access to your encrypted
    material.

    It is also common in business. When an employee has encrypted material on
    his company computer, and he leaves, gets fired, or dies unexpectedly, the
    company might not be able to decrypt the material. This can cost them a lot
    of money, especially when the employee was working on something very
    important. For this reason, a copy of the secret key is usually kept by one
    or more supervisors, who can then decrypt the material if necessary. To
    ensure that a supervisor does not abuse this power, the key can be split
    amongst several persons, who have to work together to restore the key.

    Thanks to the US Clipper initiative, this term is now more or less
    synonymous with government key escrow, where the government keeps a copy of
    all the secret keys in the country. This allows them to read all encrypted
    messages being sent, usually for reasons of national security. Many people
    object to this type of key escrow, as it can be used to invade people's
    privacy very easily.

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.

Message Digest Algorithm #5 (MD5)
    The message digest algorithm used in PGP is the MD5 Message Digest
    Algorithm, placed in the public domain by RSA Data Security, Inc.
    �       It is conjectured that the difficulty of coming up with two �
            messages having the same message digest is on the order of
            264 operations, and that the difficulty of coming up with
            any message having a given message digest is on the order
            of 2128 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.
                --MD5's designer, Ronald Rivest, writes this about MD5: �

Million Instructions Per Second (MIPS)
    MIPS stands for Million Instructions Per Second. Usually, this is an
    indicator of the computer's brute force power. A MIPS-year is approximately
    the amount of computing done by a 1 MIPS computer in one year.

Multiple Precision Integer Library (MPILIB)
    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.

National Security Agency (NSA)
    �       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.
                 --The following information is from the sci.crypt FAQ: �

One Time Pad (OTP)
    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.

Pretty Good Privacy (PGP)
    The program we're discussing. See question What is PGP?>.

Rivest-Shamir-Adleman (RSA)
    RSA is the public key encryption method used in PGP. RSA are the initials
    of the developers of the algorithm. 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.

Rubber-hose cryptoanalysis
    A term coined by Marcus J. Ranum to describe the method of breaking a
    cryptographic key by beating the owner with a rubber hose until he reveals
    his key, a method practiced in many repressive regimes. It is also used for
    describing other, less brutal, situations where the owner is forced to give
    up his keys (see Can I be forced to reveal my pass phrase in any legal
    proceedings?>).

Skipjack

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.

PGP/MIME
    To be done.

Blowfish
    To be done.

Twofish
    To be done.

CAST
    To be done.


-------------------------------------------------------------------------------
Colophon

This FAQ is compiled from a DocBook source file, because managing such a large
amount of information over longer periods of time is impossible without a
stable and proven file format. The DocBook source is converted to its output
formats with proven, open-source tools such as N. Walsh's DocBook stylesheets,
OpenJade, tidy, w3m and LaTeX, together a custom Makefile and FreeBSD's
doc.docbook.mk Makefiles. This allows me to easily maintain a consistent look
throughout this FAQ, and to make sure that internal references stay correct.
-------------------------------------------------------------------------------