PGP Frequently Asked Questions with Answers, Part 2/3

From: jalicqui@prairienet.org
Newsgroups: alt.security.pgp
Subject: PGP Frequently Asked Questions with Answers, Part 2/3
Date: 23 Jun 1995 12:33:09 GMT
Message-ID: <pgp-faq/part2_803910728@rtfm.mit.edu>
Reply-To: jalicqui@prairienet.org
Summary: This posting seeks to answer most of the common questions people
         ask about the Pretty Good Privacy (PGP) encryption program.
X-Last-Updated: 1995/06/23

Archive-name: pgp-faq/part2
Posting-Frequency: monthly
Last-modified: 22 June 1995

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

========

3. Security Questions

========

3.1. How secure is PGP?

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

========

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

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

The only type of attack that might succeed is one that tries to solve
the problem from a mathematical standpoint by analyzing the
transformations that take place between plain text blocks, and their
cipher text equivalents. IDEA is still a fairly new algorithm, and
work still needs to be done on it as it relates to complexity theory,
but so far, it appears that there is no algorithm much better suited
to solving an IDEA cipher than the brute force attack, which we have
already shown is unworkable. The nonlinear transformation that takes
place in IDEA puts it in a class of extremely difficult to solve
mathmatical problems.

========

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

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

========

3.4. Can the NSA crack RSA?

This question has been asked many times. If the NSA were able to crack
RSA, you would probably never hear about it from them. The best
defense against this is the fact the algorithm for RSA is known
worldwide. There are many competent mathematicians and cryptographers
outside the NSA and there is much research being done in the field
right now. If any of them were to discover a hole in RSA, I'm sure
that we would hear about it from them. I think that it would be hard
to hide such a discovery.  For this reason, when you read messages on
USENET saying that "someone told them" that the NSA is able to break
pgp, take it with a grain of salt and ask for some documentation on
exactly where the information is coming from.

========

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

One RSA-encrypted message has been cracked publicly.

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

Recently, an international team coordinated by Paul Leyland, Derek
Atkins, Arjen Lenstra, and Michael Graff successfully factored the
public key used to encrypt the RSA-129 message and recovered the
plaintext.  The message read:

  THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE

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

The coordinators have estimated that the project took about eight
months of real time and used approximately 5000 MIPS-years of
computing time.  (A MIPS-year is approximately the amount of computing
done by a 1 MIPS [million instructions per second] computer in one
year.)

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

Note that this effort cracked only a single RSA key.  Nothing was
discovered during the course of the experiment to cause any other keys
to become less secure than they had been.

For more information on the RSA-129 project, see:

  ftp://ftp.ox.ac.uk/pub/math/rsa129/

========

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

It is not secure at all. There are many ways to defeat it. Probably
the easiest way is to simply redirect your screen output to a file as
follows:

    pgp [filename] > [diskfile]

The -m option was not intended as a fail-safe option to prevent plain
text files from being generated, but to serve simply as a warning to
the person decrypting the file that he probably shouldn't keep a copy
of the plain text on his system.

========

3.7. What if I forget my pass phrase?

In a word: DON'T. If you forget your pass phrase, there is absolutely
no way to recover any encrypted files. I use the following technique:
I have a backup copy of my secret key ring on floppy, along with a
sealed envelope containing the pass phrase. I keep these two items in
separate safe locations, neither of which is my home or office. The
pass phrase used on this backup copy is different from the one that I
normally use on my computer. That way, even if some stumbles onto the
hidden pass phrase and can figure out who it belongs to, it still
doesn't do them any good, because it is not the one required to unlock
the key on my computer.

========

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

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

========

3.9. What is the best way to crack PGP?

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

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

========

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

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

========

3.11. How do I choose a pass phrase?

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

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

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

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

========

3.12. How do I remember my pass phrase?

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

========

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

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

If you already own a trusted version of PGP, it is easy to check the
validity of any future version.  Newer binary versions of MIT PGP are
distributed in popular archive formats; the archive file you receive
will contain only another archive file, a file with the same name as
the archive file with the extension .ASC, and a "setup.doc" file.  The
.ASC file is a stand-alone signature file for the inner archive file
that was created by the developer in charge of that particular PGP
distribution.  Since nobody except the developer has access to his/her
secret key, nobody can tamper with the archive file without it being
detected.  Of course, the inner archive file contains the newer PGP
distribution.

A quick note: If you upgrade to MIT PGP from an older copy (2.3a or
before), you may have problems verifying the signature.  See question
3.14, below, for a more detailed treatment of this problem.

To check the signature, you must use your old version of PGP to check
the archive file containing the new version.  If your old version of
PGP is in a directory called C:\PGP and your new archive file and
signature is in C:\NEW (and you have retrieved MIT PGP 2.6.2), you may
execute the following command:

    C:\PGP\PGP C:\NEW\PGP262I.ASC C:\NEW\PGP262I.ZIP

If you retrieve the source distribution of MIT PGP, you will find two
more files in your distribution: an archive file for the RSAREF
library and a signature file for RSAREF.  You can verify the RSAREF
library in the same way as you verify the main PGP source archive.

Non-MIT versions typically include a signature file for the PGP.EXE
program file only.  This file will usually be called PGPSIG.ASC.  You
can check the integrity of the program itself this way by running your
older version of PGP on the new version's signature file and program
file.

Phil Zimmermann himself signed all versions of PGP up to 2.3a.  Since
then, the primary developers for each of the different versions of PGP
have signed their distributions.  As of this writing, the developers
whose signatures appear on the distributions are:

MIT PGP 2.6.2                Jeff Schiller <jis@mit.edu>
ViaCrypt PGP 2.7.1           ViaCrypt
PGP 2.6.2i                   Stale Schumacher <staalesc@ifi.uio.no>
PGP 2.6ui                    mathew <mathew@mantis.co.uk>

========

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

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

You may, first of all, not verify the signature and follow other
methods for making sure you aren't getting a bad copy.  This isn't as
secure, though; if you're not careful, you could get passed a bad copy
of PGP.

If you're intent on checking the signature, you may do an intermediate
upgrade to MIT PGP 2.6.  This older version was signed before the
"time bomb" took effect, so its signature is readable by the older
versions of PGP.  Once you have validated the signature on the
intermediate version, you can then use that version to check the
current version.

As another alternative, you may upgrade to PGP 2.6.2i or 2.6ui,
checking their signatures with 2.3a, and use them to check the
signature on the newer version.  People living in the USA who do this
may be violating the RSA patent in doing so; then again, you may have
been violating it anyway by using 2.3a, so you're not in much worse
shape.

========

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

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

========

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

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

Second, all the freeware versions of PGP are released with full source
code to both PGP and to the RSAREF library they use (just as every
other freeware version before them were).  Thus, it is subject to the
same peer review mentioned in the question above.  If there were an
intentional hole, it would probably be spotted.  If you're really
paranoid, you can read the code yourself and look for holes!

========

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

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

You should be very careful, however.  Your pass phrase may be passed
over the network in the clear where it could be intercepted by network
monitoring equipment, or the operator on a multi-user machine may
install "keyboard sniffers" to record your pass phrase as you type it
in. Also, while it is being used by PGP on the host system, it could
be caught by some Trojan Horse program.  Also, even though your secret
key ring is encrypted, it would not be good practice to leave it lying
around for anyone else to look at.

So why distribute PGP with directions for making it on Unix and VMS
machines at all?  The simple answer is that not all Unix and VMS
machines are network servers or "mainframes."  If you use your machine
only from the console (or if you use some network encryption package
such as Kerberos), you are the only user, you take reasonable system
security measures to prevent unauthorized access, and you are aware of
the risks above, you can securely use PGP on one of these systems.  As
an example of this, my own home computer runs Linux, a Unix clone.  As
I (and my wife) are the only users of the computer, I feel that the
risks of crackers invading my system and stealing my pass phrase are
minimal.

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

========

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

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

The problem with using PGP on a system that swaps is that the system
will often swap PGP out to disk while it is processing your pass
phrase.  If this happens at the right time, your pass phrase could end
up in cleartext in your swap file.  How easy it is to swap "at the
right time" depends on the operating system; Windows reportedly swaps
the pass phrase to disk quite regularly, though it is also one of the
most inefficient systems.  PGP does make every attempt to not keep the
pass phrase in memory by "wiping" memory used to hold the pass phrase
before freeing it, but this solution isn't perfect.

If you have reason to be concerned about this, you might consider
getting a swapfile wiping utility to securely erase any trace of the
pass phrase once you are done with the system.  Several such utilities
exist for Windows and Linux at least.

========

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

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

========

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

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

In addition, don't forget that private keys are useful for more than
decrypting.  Someone with your private key can also sign items that
could later prove to be difficult to deny.  Keeping your private key
secure can prevent, at the least, a bit of embarassment, and at most
could prevent charges of fraud or breach of contract.

Besides, many of the above procedures are also effective against some
common indirect attacks.  As an example, the digital signature also
serves as an effective integrity check of the file signed; thus,
checking the signature on new copies of PGP ensures that your computer
will not get a virus through PGP (unless, of course, the PGP version
developer contracts a virus and infects PGP before signing).

========

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

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

- -----
The following information applies only to citizens of the United
States in U.S. Courts.  The laws in other countries may vary.  Please
see the disclaimer at the top of part 1.

There have been several threads on Internet concerning the question of
whether or not the fifth amendment right about not being forced to
give testimony against yourself can be applied to the subject of being
forced to reveal your pass phrase.  Not wanting to settle for the many
conflicting opinions of armchair lawyers on usenet, I asked for input
from individuals who were more qualified in the area.  The results
were somewhat mixed.  There apparently has NOT been much case history
to set precedence in this area.  So if you find yourself in this
situation, you should be prepared for a long and costly legal fight on
the matter.  Do you have the time and money for such a fight?  Also
remember that judges have great freedom in the use of "Contempt of
Court".  They might choose to lock you up until you decide to reveal
the pass phrase and it could take your lawyer some time to get you
out.  (If only you just had a poor memory!)
- -----

========

4. Keys

========

4.1.  Which key size should I use?

PGP gives you three choices for key size: 512, 768, or 1024 bits.  You
can also specify the number of bits your key should have if you don't
like any of those numbers.  The larger the key, the more secure the
RSA portion of the encryption is. The only place where the key size
makes a large change in the running time of the program is during key
generation. A 1024 bit key can take 8 times longer to generate than a
384 bit key. Fortunately, this is a one time process that doesn't need
to be repeated unless you wish to generate another key pair. During
encryption, only the RSA portion of the encryption process is affected
by key size. The RSA portion is only used for encrypting the session
key used by the IDEA. The main body of the message is totally
unaffected by the choice of RSA key size. So unless you have a very
good reason for doing otherwise, select the 1024 bit key size.  Using
currently available algorithms for factoring, the 384 and 512 bit keys
are just not far enough out of reach to be good choices.

If you are using MIT PGP 2.6.2, ViaCrypt PGP 2.7.1, or PGP 2.6.2i, you
can specify key sizes greater than 1024 bits; the upper limit for
these programs is 2048 bits.  Remember that you have to tell PGP how
big you want your key if you want it to be bigger than 1024 bits.
Generating a key this long will take you quite a while; however, this
is, as noted above, a one-time process.  Remember that other people
running other versions of PGP may not be able to handle your large
key!

========

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

The time required to check signatures and add keys to your public key
ring tends to grow as the square of the size of your existing public
key ring. This can reach extreme proportions. 

Gary Edstrom remarked (a long time ago):

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

========

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

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

Unfortunately, the present version of PGP does not allow you to do
this directly. Fortunately, there is an indirect way to do it.

I would like to thank Robert Joop <rj@rainbow.in-berlin.de> for
supplying the following method which is simpler than the method that I
had previously given.

solution 1:

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

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

solution 2:

pgp -kx uid1 extract
pgp -kx uid2 extract
pgp -kx uid3 extract

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

pgp -a extract.pgp

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

A Unix script to perform the extraction with a single command would be
as follows:

  #!/bin/csh
  foreach name (name1 name2 name3 ...)
  pgp -kx $name /tmp/keys.pgp <keyring>
  end

or:

  #!/bin/sh
  for name in name1 name2 name3 ... ; do
  pgp -kx $name /tmp/keys.pgp <keyring>
  end

An equivalent DOS command would be:

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

========

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

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

========

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

Instead of specifying the user's name in the ID field of the PGP
command, you can use the key ID number. The format is 0xNNNNNNNN where
NNNNNNNN is the user's 8 character key ID number. It should be noted
that you don't need to enter the entire ID number, a few consecutive
digits from anywhere in the ID should do the trick.  Be careful: If
you enter "0x123", you will be matching key IDs 0x12393764,
0x64931237, or 0x96412373.  Any key ID that contains "123" anywhere in
it will produce a match.  They don't need to be the starting
characters of the key ID.  You will recognize that this is the format
for entering hex numbers in the C programming language. For example,
any of the following commands could be used to encrypt a file to my
work key:

    pgp -e <filename> "Jeff Licquia"
    pgp -e <filename> licquia@cei.com
    pgp -e <filename> 0xCF45DD0D

This same method of key identification can be used in the config.txt
file in the "MyName" variable to specify exactly which of the keys in
the secret key ring should be used for encrypting a message.

========

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

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

========

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

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

========

4.8.  How can I make my key available via finger?

The first step is always to extract the key to an ASCII-armored text
file with "pgp -kxa".  After that, it depends on what type of computer
you want your key to be available on.  Check the documentation for
that computer and/or its networking software.

Many computers running a Unix flavor will read information to be
displayed via finger from a file in each user's home directory called
".plan".  If your computer supports this, you can put your public key
in this file.  Ask your system administrator is you have problems with
this.

========

5.   Message Signatures

========

5.1. What is message signing?

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

========

5.2. How do I sign a message while still leaving it readable?

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

    pgp -sat +clearsig=on <filename>

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

========

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

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

========

5.4. Are PGP signatures legally binding?

It's still too early to tell.  At least one company is using PGP
digital signatures on contracts to provide "quick agreement" via
E-mail, allowing work to proceed without having to wait for the paper
signature.  Two USA states (Utah and Wyoming) have passed laws
recently giving digital signatures binding force for certain kinds of
transactions.  The Wyoming law is available from:

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

(whew!)

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

========

6.   Key Signatures

========

6.1. What is key signing?

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

========

6.2. How do I sign a key?

Execute the following command from the command prompt:

    PGP -ks [-u yourid] <keyid>

This adds your signature (signed with the private key for yourid, if
you specify it) to the key identified with keyid.  If keyid is a user
ID, you will sign that particular user ID; otherwise, you will sign
the default user ID on that key (the first one you see when you list
the key with "pgp -kv <keyid>").

Next, you should extract a copy of this updated key along with its
signatures using the "-kxa" option. An armored text file will be
created. Give this file to the owner of the key so that he may
propagate the new signature to whomever he chooses.

Be very careful with your secret keyring.  Never be tempted to put a
copy in somebody else's machine so you can sign their public key -
they could have modified PGP to copy your secret key and grab your
pass phrase.

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

========

6.3. Should I sign my own key?

Yes, you should sign each personal ID on your key. This will help to
prevent anyone from placing a phony address in the ID field of the key
and possibly having your mail diverted to them.  Anyone adding or
changing a user id on your key will be unable to sign the entry,
making it stand out like a sore thumb since all of the other entries
are signed.  Do this even if you are the only person signing your key.
For example, my entry in the public key ring now appears as follows if
you use the "-kvv" command:

Type bits/keyID    Date       User ID
pub  1024/0353E385 1994/06/17 Jeff Licquia <jalicqui@prairienet.org>
sig       0353E385             Jeff Licquia <jalicqui@prairienet.org>

========

6.4.  Should I sign X's key?

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

Some countries require respected professionals such as doctors or
engineers to endorse passport photographs as proof of identity for a
passport application - you should consider signing someone's key in
the same light. Alternatively, when you come to sign someone's key,
ask yourself if you would be prepared to swear in a court of law as to
that person's identity.

Remember that signing a person's key says nothing about whether you
actually like or trust that person or approve of his/her actions.
It's just like someone pointing to someone else at a party and saying,
"Yeah, that's Joe Blow over there."  Joe Blow may be an ax murderer;
you don't become tainted with his crime just because you can pick him
out of a crowd.

========

6.5. How do I verify someone's identity?

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

========

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

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

If it is a key from someone you know well and whose voice you
recognize then it is sufficient to give them a phone call and have
them read their key's fingerprint (obtained with PGP -kvc <userid>).

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

========

6.7. What's a key signing party?

A key signing party is a get-together with various other users of PGP
for the purpose of meeting and signing keys.  This helps to extend the
"web of trust" to a great degree.

========

6.8. How do I organize a key signing party?

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

Derek Atkins <warlord@mit.edu> has recommended this method:

- -----
   There are many ways to hold a key-signing session. Many viable
   suggestions have been given. And, just to add more signal to this
   newsgroup, I will suggest another one which seems to work very well
   and also solves the N-squared problem of distributing and signing
   keys. Here is the process:
   
    1. You announce the keysinging session, and ask everyone who plans to
       come to send you (or some single person who *will* be there) their
       public key. The RSVP also allows for a count of the number of
       people for step 3.
       
    2. You compile the public keys into a single keyring, run "pgp -kvc"
       on that keyring, and save the output to a file.
       
    3. Print out N copies of the "pgp -kvc" file onto hardcopy, and bring
       this and the keyring on media to the meeting.
       
    4. At the meeting, distribute the printouts, and provide a site to
       retreive the keyring (an ftp site works, or you can make floppy
       copies, or whatever -- it doesn't matter).
       
    5. When you are all in the room, each person stands up, and people
       vouch for this person (e.g., "Yes, this really is Derek Atkins --
       I went to school with him for 6 years, and lived with him for 2").
       
    6. Each person securely obtains their own fingerprint, and after
       being vouched for, they then read out their fingerprint out loud
       so everyone can verify it on the printout they have.
       
    7. After everyone finishes this protocol, they can go home, obtain
       the keyring, run "pgp -kvc" on it themselves, and re-verify the
       bits, and sign the keys at their own leisure.
       
    8. To save load on the keyservers, you can optionally send all
       signatures to the original person, who can coalate them again into
       a single keyring and propagate that single keyring to the
       keyservers and to each individual.
       
   This seems to work well -- it worked well at the IETF meeting last
   month in Toronto, and I plan to try it at future dates.
- -----

========

7.   Revoking a key

========

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

Assuming that you selected a good solid random pass phrase to encrypt
your secret key ring, you are probably still safe. It takes two parts
to decrypt a message, the secret key ring, and its pass phrase.
Assuming you have a backup copy of your secret key ring, you should
generate a key revocation certificate and upload the revocation to one
of the public key servers. Prior to uploading the revocation
certificate, you might add a new ID to the old key that tells what
your new key ID will be. If you don't have a backup copy of your
secret key ring, then it will be impossible to create a revocation
certificate under the present version of PGP. This is another good
reason for keeping a backup copy of your secret key ring.

========

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

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

The way to avoid this dilemma is to create a key revocation
certificate at the same time that you generate your key pair.  Put the
revocation certificate away in a safe place and you will have it
available should the need arise. You need to be careful how you do
this, however, or you will end up revoking the key pair that you just
generated, and a revocation can't be reversed.

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

========

8.   Public Key Servers

========

8.1. What are the Public Key Servers?

Public Key Servers exist for the purpose of making your public key
available in a common database where everybody can have access to it
for the purpose of encrypting messages to you. While a number of key
servers exist, it is only necessary to send your key to one of them.
The key server will take care of the job of sending your key to all
other known servers.

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

========

8.2. What public key servers are available?

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

Sites accessible via mail:

    pgp-public-keys@pgp.mit.edu
    Derek Atkins <warlord@mit.edu>

    pgp-public-keys@pgp.iastate.edu
    Michael Graff <explorer@iastate.edu>

    pgp-public-keys@burn.ucsd.edu
    Andy Howard <ahoward@ucsd.edu>

    pgp-public-keys@fbihh.informatik.uni-hamburg.de
    Vesselin V. Bontchev <bontchev@fbihh.informatik.uni-hamburg.de>

    public-key-server@martigny.ai.mit.edu
    Brian A. LaMacchia <public-key-server-request@martigny.ai.mit.edu>

    pgp-public-keys@pgp.ox.ac.uk
    Paul Leyland <pcl@ox.ac.uk>

    pgp-public-keys@dsi.unimi.it
    David Vincenzetti <vince@dsi.unimi.it>

    pgp-public-keys@kub.nl
    Teun Nijssen <teun@kub.nl>

    pgp-public-keys@ext221.sra.co.jp
    Hironobu Suzuki <hironobu@sra.co.jp>

    pgp-public-keys@sw.oz.au
    Jeremy Fitzhardinge <jeremy@sw.oz.au>

    pgp-public-keys@kiae.su
    <blaster@rd.relcom.msk.su>

    pgp-public-keys@srce.hr
    Cedomir Igaly <cigaly@srce.hr>

    pgp-public-keys@pgp.pipex.net
    Mark Turner <markt@pipex.net>

    pgp-public-keys@goliat.upc.es
    Alvar Vinacua <alvar@turing.upc.es>

    pgp-public-keys@gondolin.org
    <pgp-admin@gondolin.org>

Sites accessible via WWW:

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

Key server keyrings accessible via FTP:

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

The following key servers are no longer in operation:

    pgp-public-keys@phil.utmb.edu
    pgp-public-keys@proxima.alt.za
    pgp-public-keys@demon.co.uk

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

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

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

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

8.3. What is the syntax of the key server commands?

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

- -------------------------------------------------------------
ADD           Your PGP public key (key to add is body of msg) (-ka)
INDEX         List all PGP keys the server knows about (-kv)
VERBOSE INDEX List all PGP keys, verbose format (-kvv)
GET           Get the whole public key ring (-kxa *)
GET <userid>  Get just that one key (-kxa <userid>)
MGET <userid> Get all keys which match <userid>
LAST <n>      Get all keys uploaded during last <n> days
- -------------------------------------------------------------

If you wish to get the entire key ring and have access to FTP, it
would be a lot more efficient to use FTP rather than e-mail. Using
e-mail, the entire key ring can generate a many part message, which
you will have to reconstruct into a single file before adding it to
your key ring.

========

9.  Bugs

========

9.1 Where should I send bug reports?

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

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

The following list of bugs is limited to version 2.4 and later, and is
limited to the most commonly seen and serious bugs. For bugs in
earlier versions, refer to the documentation included with the
program.  If you find a bug not on this list, follow the procedure
above for reporting it.

========

MIT PGP 2.6 had a bug in the key generation process which made keys
generated by it much less random.  Fixed in 2.6.1.

All versions of PGP except MIT PGP 2.6.2 are susceptible to a "buglet"
in clearsigned messages, making it possible to add text to the
beginning of a clearsigned message.  The added text does not appear in
the PGP output after the signature is checked.  MIT PGP 2.6.2 now does
not allow header lines before the text of a clearsigned message and
enforces RFC 822 syntax on header lines before the signature.  Since
this bug appears at checking time, however, you should be aware of
this bug even if you use MIT PGP 2.6.2 - the reader may check your
signed message with a different version and not read the output.

MIT PGP 2.6.1 was supposed to handle keys between 1024 and 2048 bits
in length, but could not.  Fixed in 2.6.2.

MIT PGP 2.6.2 was supposed to enable the generation of keys up to 2048
bits after December 25, 1994; a one-off bug puts that upper limit at
2047 bits instead.  It has been reported that this problem does not
appear when MIT PGP is compiled under certain implementations of Unix.
The problem is fixed in versions 2.7.1 and 2.6.2i.

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

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

ViaCrypt has reported a bug in freeware PGP affecting at least PGP
2.3a and MIT PGP 2.6, 2.6.1, and 2.6.2.  This bug affects signatures
made with keys between 2034 and 2048 bits in length, causing them to
be corrupted.  Practically speaking, this bug only affects versions of
PGP that support the longer key lengths.  ViaCrypt reports that this
only seems to be a problem when running PGP on a Sun SPARC-based
workstation.  ViaCrypt PGP 2.7.1 and PGP 2.6.2i do not suffer from
this bug.  The following patch will fix the problem in MIT PGP 2.6.2:

<===== begin patch (cut here)
- --- crypto.c.orig	Mon Mar 20 22:30:29 1995
+++ crypto.c	Mon Mar 20 22:55:32 1995
@@ -685,7 +685,7 @@
    byte class, unitptr e, unitptr d, unitptr p, unitptr q, unitptr u,
 			       unitptr n)
 {
- -	byte inbuf[MAX_BYTE_PRECISION], outbuf[MAX_BYTE_PRECISION];
+	byte inbuf[MAX_BYTE_PRECISION], outbuf[MAX_BYTE_PRECISION+2];
 	int i, j, certificate_length, blocksize,bytecount;
 	word16 ske_length;
 	word32 tstamp; byte *timestamp = (byte *) &tstamp;
<===== end patch (cut here)

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

========

10.   Recommended Reading

========

Stallings, William, "Protect Your Privacy: A Guide for PGP Users",
Prentice Hall, 1995, ISBN 0-13-185596-4.
(Current errata at ftp://ftp.shore.net/members/ws/Errata-PGP-mmyy.txt)

Garfinkel, Simson, "PGP: Pretty Good Privacy", O'Reilly & Associates,
1994, ISBN 1-56592-098-8.

Schneier, Bruce, "E-Mail Security with PGP and PEM: How To Keep Your
Electronic Messages Private", John Wiley & Sons, 1995, ISBN
0-471-05318-X.

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

    ISBN: 0-02-560460-0

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

  > The following list was taken from the PGP documentation:

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

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

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

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

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

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

Xuejia Lai, "On the Design and Security of Block Ciphers", Institute for
Signal and Information Processing, ETH-Zentrum, Zurich, Switzerland, 1992

Xuejia Lai, James L. Massey, Sean Murphy, "Markov Ciphers and Differential
Cryptanalysis", Advances in Cryptology- EUROCRYPT'91

Philip Zimmermann, "A Proposed Standard Format for RSA Cryptosystems",
Advances in Computer Security, Vol III, edited by Rein Turn, Artech House,
1988

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

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

========

11.   General Tips

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

  > Fido net mail is even more sensitive.  You should only send encrypted net
    mail after checking that:

      a) Your sysop permits it.
      b) Your recipient's sysop permits it.
      c) The mail is routed through nodes whose sysops also permit it.

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

  > Don't sign someone's key just because someone else that you know has
    signed it.  Confirm the identity of the individual yourself.  Remember,
    you are putting your reputation on the line when you sign a key.


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

iQCVAwUBL+kBB7nwkw8DU+OFAQHbYAP8DJpJi+Th6cV/YTxsTYJ+FOcxsd5pRAph
y6lygvQQX+dpGpipgmc79yBfQ9x7bLYw8qzJJhJQ156/dahLzBa6mo9UclphHXbe
1PJNgABAkLnJ9od4pFIrzrjAx5588fm0ipwGlmnL9rAd+F2FkeVc439lRcbxc49i
aV8I4tw6lJY=
=kHjJ
-----END PGP SIGNATURE-----