textfiles/programming/CRYPTOGRAPHY/pgp.faq

1726 lines
82 KiB
Plaintext

Frequently Asked Questions about PGP
--------------------------------------------------------------------------
Frequently Asked Questions
alt.security.pgp
Version 0.3
19-Dec-93
Well, here is the second posting of a preliminary FAQ for alt.security.pgp.
I would like to thank all of those who sent me feedback on my previous
posting. I received over a hundred replies concerning it. There were so
many changes, typos, and additions that I decided to still call this a
preliminary release. Once I am able to post a final version, I will start a
history list to detail all changes from previous releases. In addition,
the final version will contain an "Expires:" field in the message header
that will hopefully keep it on your local host for a little longer. I will
then post updates about once a month. I plan on posting the next version
in about two weeks. Please read this FAQ over and let me know if I have
any of my facts wrong (There were plenty in the previous version!) Also let
me know if there is some question that I should have answered but didn't,
or if any of my answers were unclear It should be noted that most of the
questions and answers concerning PGP apply equally well to the ViaCrypt(tm)
version as well. All additions, deletions, or corrections to this list
should be directed to me at gbe@netcom.com (Gary Edstrom). I will
acknowledge all e-mail.
If you sent me mail about some error in my previous version and it still
does not appear corrected, your mail may have slipped through the cracks
someplace. With over a hundred responses, I probably missed a few. Please
be patient and send them again.
This FAQ is slanted towards the DOS users of PGP and many of the examples
given may only apply to the DOS version. For other systems, I would like
to direct your attention to the following documents:
MAC: "Here's How to MacPGP!" by Xenon <an48138@anon.penet.fi>
Archimedes: "PGPhints" by Paul L. Allen" <pla@sktb.demon.co.uk>
Send e-mail to pgpinfo@mantis.co.uk for a list of PGP tips.
The files making up this FAQ are available via anonymous FTP at netcom.com
in /pub/gbe. The file names are pgpfaq03.as<n> and are in simple ASCII text
format. In addition, the file pgpfaq03.doc is available which is in the
original Microsoft Word for Windows format under which this FAQ was
created..
This release of the FAQ is being distributed in 4 parts. Parts 3 & 4 will
be of interest primarily to users in the United States and are therefore on
US distribution only. All parts are available by FTP, however.
Part 1/4 General FAQ
1. Introductory Questions
1.1. What is PGP?
1.2. Why should I encrypt my mail? I'm not doing anything illegal!
1.3. What are public keys and private keys?
1.4. How much does PGP cost?
1.5. Is encryption legal?
1.6. Is PGP legal?
1.7. Where can I get translations of the language.txt file?
1.8. Where can I get translations of the PGP documentation?
1.9. Is there an archive site for alt.security.pgp?
1.10. Is there a commercial version of PGP available?
1.11. What platforms has PGP been ported to?
1.12. Where can I obtain PGP?
2. General Questions
2.1. Why can't a person using version 2.2 read my version 2.3 message?
2.2. Why does it take so long to encrypt/decrypt messages?
2.3. How do I create a secondary key file?
2.4. How does PGP handle multiple addresses?
3. Keys
3.1. Which key size should I use?
3.2. Why does PGP take so long to add new keys to my key ring?
3.3. How can I extract multiple keys into a single armored file?
3.4. I tried encrypting the same message to the same address two
different times and got completely different outputs. Why is this?
3.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?
3.6. What does the message "Unknown signator, can't be checked" mean?
3.7. How do I get PGP to display the trust parameters on a key?
4. Security Questions
4.1. How secure is PGP?
4.2. Can't you break PGP by trying all of the possible keys?
4.3. How secure is the conventional cryptography (-c) option?
4.4. Can the NSA crack RSA?
4.5. How secure is the "for your eyes only" option (-m)?
4.6. What if I forget my pass phrase?
4.7. Why do you use the term "pass phrase" instead of "password"?
4.8. If someone steals my secret key ring, can they decrypt my files?
4.9. How do I choose a pass phrase?
4.10. How do I remember my pass phrase?
4.11. How do I verify that my copy of PGP has not been tampered with?
4.12. How do I know that there is no trap door in the program?
4.13. Can I put PGP on a multi-user system like a network or amainframe?
4.14. Why not use RSA alone rather than a hybrid mix of IDEA, MD5, & RSA?
4.15. Aren't all of these security procedures a little paranoid?
5. Message Signatures
5.1. What is message signing?
5.2. How do I sign a message while still leaving it readable?
6. Key Signatures
6.1. What is key signing?
6.2. How do I sign a key?
6.3. Should I sign my own key?
7. Revoking a key
7.1. My secret key ring has been stolen or lost, what do I do?
7.2. I forgot my pass phrase. Can I create a key revocation certificate?
Part 2/4 General FAQ & Appendix
8. Public Key Servers
8.1. What are the Public Key Servers?
8.2. Where are the Public Key Servers?
8.3. What is the syntax of the key server commands?
9. Bugs
10. Related News Groups
11. Recommended Reading
12. General Tips
Appendix I - PGP add-ons and Related Products
Appendix II - Glossary of Cryptographic Terms
Appendix III - Cypherpunks
Part 3/4 (U.S. Distribution Only)
Appendix IV - Testimony of Philip Zimmermann to Congress
Appendix V - Announcement of Philip Zimmermann Defense Fund
Appendix VI - A Statement from ViaCrypt Concerning ITAR
Part 4/4 (U.S. Distribution Only)
Appendix VII - Unites States Congress Phone and FAX List
========================================================================
Revision History
Ver Date Description
--- ---- -----------
0.1 08-Dec-93 Proof Reading Copy - Limited Distribution
0.2 11-Dec-93 First Preliminary USENET Posting (Many changes)
0.3 18-Dec-93 Second Preliminary USENET Posting (Many changes)
========================================================================
Gary B. Edstrom | Sequoia Software | PGP fingerprint:
Internet: gbe@netcom.com | Programming Services | 2F F6 1B 28 6E A6 09 6C
CompuServe: 72677,564 | P.O. Box 9573 | B0 EA 9E 4C C4 C6 7D 46
Fax: 1-818-247-6046 | Glendale, CA 91226 | Key available via finger
What is PGP? Subscribe to alt.security.pgp and find out!
========================================================================
1. Introductory Questions
1.1. What is PGP?
PGP is a program that gives your electronic mail something that it
otherwise doesn't have: Privacy. It does this by encrypting your mail
so that nobody but the intended person can read it. When encrypted, the
message looks like a meaningless jumble of random characters. PGP has
proven itself quite capable of resisting even the most sophisticated
forms of analysis aimed at reading the encrypted text.
PGP can also be used to apply a digital signature to a message without
encrypting it. This is normally used in public postings where you
don't want to hide what you are saying, but rather want to allow others
to confirm that the message actually came from you. Once a digital
signature is created, it is impossible for anyone to modify either the
message or the signature without the modification being detected by
PGP.
While PGP is easy to use, it does give you enough rope so that you can
hang yourself. You should become thoroughly familiar with the various
options in PGP before using it to send serious messages. For example,
giving the command "PGP -sat <filename>" will only sign a message, it
will not encrypt it. Even though the output looks like it is encrypted,
it really isn't. Anybody in the world would be able to recover the
original text.
1.2. Why should I encrypt my mail? I'm not doing anything illegal!
You should encrypt your e-mail for the same reason that you don't write
all of your correspondence on the back of a post card. E-mail is
actually far less secure than the postal system. With the post office,
you at least put your letter inside an envelope to hide it from casual
snooping. Take a look at the header area of any e-mail message that you
receive and you will see that it has passed through a number of nodes
on its way to you. Every one of these nodes presents the opportunity
for snooping. Encryption in no way should imply illegal activity. It
is simply intended to keep personal thoughts personal.
Xenon <an48138@anon.penet.fi> puts it like this:
Crime? If you are not a politician, research scientist, investor, CEO,
lawyer, celebrity, libertarian in a repressive society, investor, or
person having too much fun, and you do not send e-mail about your
private sex life, financial/political/legal/scientific plans, or gossip
then maybe you don't need PGP, but at least realize that privacy has
nothing to do with crime and is in fact what keeps the world from
falling apart. Besides, PGP is FUN. You never had a secret decoder
ring? Boo! -Xenon (Copyright 1993, Xenon)
1.3. What are public keys and private keys?
With conventional encryption schemes, keys must be exchanged with
everyone you wish to talk to by some other secure method such as face
to face meetings, or via a trusted courier. The problem is that you
need a secure channel before you can establish a secure channel! With
conventional encryption, either the same key is used for both
encryption and decryption or it is easy to convert either key to the
other. With public key encryption, the encryption and decryption keys
are different and it is impossible for anyone to convert one to the
other. Therefore, the encryption key can be made public knowledge, and
posted in a database somewhere. Anyone wanting to send you a message
would obtain your encryption key from this database or some other
source and encrypt his message to you. This message can't be decrypted
with the encryption key. Therefore nobody other than the intended
receiver can decrypt the message. Even the person who encrypted it can
not reverse the process. When you receive a message, you use your
secret decryption key to decrypt the message. This secret key never
leaves your computer. In fact, your secret key is itself encrypted to
protect it from anyone snooping around your computer.
1.4. How much does PGP cost?
Nothing! (Compare to ViaCrypt PGP at $98!)
1.5. Is encryption legal?
In much of the civilized world, encryption is either legal, or at least
tolerated. However, there are a some countries where such activities
could put you in front of a firing squad! Check with the laws in your
own country before using PGP or any other encryption product. A couple
of the countries where encryption is illegal are Iran and Iraq.
1.6. Is PGP legal?
In addition to the comments about encryption listed above, there are a
couple of additional issues of importance to those individuals residing
in the United States or Canada.
First, there is a question as to whether or not PGP falls under ITAR
regulations with govern the exporting of cryptographic technology from
the United States and Canada. This despite the fact that technical
articles on the subject of public key encryption have been available
legally world wide for a number of years. Any competent programmer
would have been able to translate those articles into a workable
encryption program. There is the possibility that ITAR regulations may
be relaxed to allow for encryption technology.
Second, a company called Public Key Partners (PKP) claims that it owns
the patent to the RSA encryption algorithm in the United States. The
idea of getting a patent on an algorithm is currently being challenged.
Keep an eye on USENET in alt.security.pgp and talk.politics.crypto for
the latest information.
1.7. Where can I get translations of the language.txt file?
The language.txt file included with PGP includes translations for
French and Spanish. For other languages, try the following locations:
1.8. Where can I get translations of the PGP documentation?
Spanish: Armando Ramos <armando@clerval.org>
1.9. Is there an archive site for alt.security.pgp?
laszlo@instrlab.kth.se (Laszlo Baranyi) says:
"My memory says that ripem.msu.edu stores a backlog of both
alt.security.pgp, and sci.crypt. But that site is ONLY open for ftp for
those that are inside US."
1.10. Is there a commercial version of PGP available?
Yes, by arrangement with the author of PGP, a company called ViaCrypt
is marketing a version of PGP that is almost identical to the version
currently available on Internet. Each can read or write messages to the
other. ViaCrypt has all the appropriate licenses for using the various
algorithms in PGP in a commercial environment. The list price of
ViaCrypt PGP is $98 (US) for a single user license and is NOT available
for export from the United States. In addition, it is presently
available only for MS-DOS. Versions for other platforms are under
development. While the present product is 100% compatible with free
PGP, it is not known if this will remain the case in the future. The
address of ViaCrypt is:
ViaCrypt
David A. Barnhart
Product Manager
2104 West Peoria Avenue
Phoenix, Arizona 85029
Tel: (602) 944-0773
Fax: (602) 943-2601
E-Mail: 70304.41@compuserve.com
E-Mail: wk01965@worldlink.com
Credit card orders only. (800)536-2664 (8-5 MST M-F)
1.11. What platforms has PGP been ported to?
DOS: 2.3a
MAC: 2.3
OS/2: 2.3a
Unix: 2.3a (Variations exist for many different systems.)
VAX/VMS:
Atari ST: 2.3a
Archimedes: 2.3a subversion 1.18b
Commodore Amiga: 2.3a
1.12. Where can I obtain PGP?
FTP sites:
soda.berkeley.edu
/pub/cypherpunks/pgp (DOS, MAC)
Verified: 12-Dec-93
ftp.demon.co.uk
/pub/amiga/pgp
/pub/archimedes
/pub/pgp
/pub/mac/MacPGP
ftp.informatik.tu-muenchen.de
ftp.funet.fi
ghost.dsi.unimi.it
/pub/crypt
Verified: 12-Dec-93
ftp.tu-clausthal.de (139.174.2.10)
wuarchive.wustl.edu
/pub/aminet/util/crypt
src.doc.ic.ac.uk (Amiga)
/aminet
/amiga-boing
ftp.informatik.tu-muenchen.de
/pub/comp/os/os2/crypt/pgp23os2A.zip (OS/2)
black.ox.ac.uk (129.67.1.165)
/src/security (Unix)
iswuarchive.wustl.edu
pub/aminet/util/crypt (Amiga)
nic.funet.fi (128.214.6.100)
van-bc.wimsey.bc.ca (192.48.234.1)
ftp.uni-kl.de (131.246.9.95)
gate.demon.co.uk (158.152.2.65)
qiclab.scn.rain.com (147.28.0.97)
pc.usl.edu (130.70.40.3)
leif.thep.lu.se (130.235.92.55)
goya.dit.upm.es (138.4.2.2)
tupac-amaru.informatik.rwth-aachen.de (137.226.112.31)
ftp.etsu.edu (192.43.199.20)
princeton.edu (128.112.228.1)
pencil.cs.missouri.edu (128.206.100.207)
Also, try an archie search for PGP using the command:
archie -s pgp23 (DOS Versions)
archie -s pgp2.3 (MAC Versions)
ftpmail:
For those individuals who do not have access to FTP, but do have
access to e-mail, you can get FTP files mailed to you. For
information on this service, send a message saying "Help" to
ftpmail@decwrl.dec.com. You will be sent in instruction sheet on how
to use the ftpmail service.
BBS sites:
The GRAPEVINE BBS in Little Rock Arkansas has set up a special
account for people to download PGP for free. The SYSOP is Jim
Wenzel, at jim.wenzel@grapevine.lrk.ar.us. The following phone
numbers are applicable and should be dialed in the order presented
(i.e., the first one is the highest speed line): (501) 753-6859,
(501) 753-8121, (501) 791-0124. When asked to login use the following
information:
name: PGP USER ('PGP' is 1st name, 'USER' is 2nd name)
password: PGP
2. General Questions
2.1. Why can't a person using version 2.2 read my version 2.3 message?
Try uncommenting the line "pkcs_compat = 0" line in the config.txt
file. By default, version 2.3 of PGP uses a different header format
that is not compatible with earlier versions of PGP. Inserting this
line into the config.txt file will force PGP to use the older header
format.
2.2. Why does it take so long to encrypt/decrypt messages?
This problem can arise when you have placed the entire public key ring
from one of the servers into the pubring.pgp file. PGP may have to
search through several thousand keys to find the one that it is after.
The solution to this dilemma is to maintain 2 public key rings. The
first ring, the normal pubring.pgp file, should contain only those
individuals that you send messages to quite often. The second key ring
can contain ALL of the keys for those occasions when the key you need
isn't in your short ring. You will, of course, need to specify the key
file name whenever encrypting messages using keys in your secondary key
ring. Now, when encrypting or decrypting messages to individuals in
your short key ring, the process will be a LOT faster.
2.3. How do I create a secondary key file?
First, let's assume that you have all of the mammoth public key ring in
your default pubring.pgp file. First, you will need to extract all of
your commonly used keys into separate key files using the -kx option.
Next, rename pubring.pgp to some other name. For this example, I will
use the name pubring.big. Next, add each of the individual key files
that you previously created to a new pubring.pgp using the -ka option.
You now have your 2 key rings. To encrypt a message to someone in the
short default file, use the command "pgp -e <userid>". To encrypt a
message to someone in the long ring, use the command "pgp -e <userid>
c:\pgp\pubring.big". Note that you need to specify the complete path
and file name for the secondary key ring. It will not be found if you
only specify the file name.
2.4. How does PGP handle multiple addresses?
When encrypting a message to multiple addresses, you will notice that
the length of the encrypted file only increases by a small amount for
each additional address. The reason that the message only grows by a
small amount for each additional key is that the body of the message is
only encrypted once using a random session key and the IDEA. It is only
necessary then to encrypt this session key once for each address and
place it in the header of the message. Therefore, the total length of a
message only increases by the size of a header segment for each
additional address.
3. Keys
3.1. Which key size should I use?
PGP gives you 4 choices of key size: 384, 512, 1024, or a user selected
number of bits. 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 bit key is just
not far enough out of reach to be a good choice.
3.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. 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.
3.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. First,
extract each of the desired keys into separate key files using the
command "pgp -kxa <key>". It doesn't matter at this point if these
temporary files are binary or armored. Next, create a new key file by
adding the individual key files one by one using the command "pgp -ka
<keyfile> <new-key-ring>". This new key file will still be a binary
file with a .pgp suffix and will contain only the keys that you are
interested in. Finally, execute the command "pgp -a <new-key-ring>" to
convert it to an armored file. This armored file now contains all of
the desired keys just as if pgp had had a built in command to do it in
the first place.
3.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 for the 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.
3.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 0xNNNNNN where
NNNNNN is the user's 6 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. 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 me.
pgp -e <filename> "Gary Edstrom"
pgp -e <filename> gbe@netcom.com
pgp -e <filename> 0x90A9C9
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.
3.6. What does the message "Unknown signator, can't be checked" mean?
It means that the person who created that signature does not exist in
your database. If at sometime in the future, you happen to add that
individual 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.
3.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. Security Questions
4.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 than 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.
4.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 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 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 the IDEA algorithm puts it in a class of extremely difficult
to solve problems.
4.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.
4.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 world wide.
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.
4.5. 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.
4.6. What if I forget my pass phrase?
In a word: DON'T. If you lose 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.
4.7. 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.
4.8. If someone steals my secret key ring, can they decrypt my files?
No, not unless they have also stolen you secret pass phrase. 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 you old key, you might want to ad another user ID that states
what your new key id is so that others can know of your new address.
4.9. 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,
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.
4.10. 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 every
day 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.
4.11. 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. There is a file called PGPSIG.ASC
included with all new releases. It is a stand alone signature file for
the contents of PGP.EXE. The signature file was created by the author
of the program. Since nobody except the author has access to his secret
key, nobody can tamper with either PGP.EXE or PGPSIG.ASC without it
being detected. To check the signature, you MUST be careful that you
are executing the OLD version of PGP to check the NEW. If not, the
entire check is useless. Let's say that your existing copy of PGP is in
sub directory C:\PGP and your new copy is in C:\NEW. You should execute
the following command:
\PGP\PGP C:\NEW\PGPSIG.ASC C:\NEW\PGP.EXE
This will force your old copy of PGP to be the one that is executed. If
you simply changed to the C:\NEW directory and executed the command
"PGP PGPSIG.ASC PGP.EXE" you would be using the new version to check
itself, and this is an absolutely worthless check.
Once you have properly checked the signature of your new copy of PGP,
you can copy all of the files to your C:\PGP directory.
4.12. How do I know that there is no trap door in the program?
The fact that the entire source code for PGP is available makes it just
about impossible for there to be some hidden trap door. The source code
has been examined my 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. I did this with the DOS version 2.3a and the Borland C++ 3.1
compiler and found that the output exactly matched byte for byte the
distributed executable file.
4.13. Can I put PGP on a multi-user system like a network or a
mainframe?
You can, but you should not, because this greatly reduces the security
of your secret key/pass phrase. This is because your pass phrase may be
passed over the network in the clear where it could be intercepted by
network monitoring equipment. 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.
4.14. 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 it's weakest link, it
is believed that RSA is actually the weakest part of the PGP - 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.
4.15. 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. Just about
week ago, I saw a posting on alt.security.pgp where the return address
had been altered to say "president@whitehouse.gov". In this case, the
content of the message showed that it was obviously fake, but what
about some of those other not so obvious cases.
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.
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?
From the command prompt, execute the following command:
PGP -ks [-u userid] <keyid>
A signature will be appended to already existing on the specified key.
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 changing a user
id to your key will be unable to sign the entry, making it stand out
like a sort 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/90A9C9 1993/09/13 Gary Edstrom <gbe@netcom.com>
sig 90A9C9 Gary Edstrom <gbe@netcom.com>
Gary Edstrom <72677.564@compuserve.com>
sig 90A9C9 Gary Edstrom <gbe@netcom.com>
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 not be reversed. After you have generated your key pair
initially, extract your key to an ASCII file using the -kxa option.
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.
-----BEGIN PGP SIGNATURE-----
Version: 2.3a
iQCVAgUBLRS700HZYsvlkKnJAQG8DQQAlQ5jsIhRRdWyoWk1FyxfMGqGCskD/Pu/
6WvXmzbOl+maXLKnrCvdY5s2GOWCgkT4c7MNqQSGrSJczjuJt1Gd+8prO0F8NbWQ
88b9//MU9id+ioZi1k7upd7Npjj3GqBv0gMjQFKIUMSa5dWWnCI430u3IIU321pt
ewbMDdwCzYI=
=PHnW
-----END PGP SIGNATURE-----
--
Gary B. Edstrom | Sequoia Software | PGP fingerprint:
Internet: gbe@netcom.com | Programming Services | 2F F6 1B 28 6E A6 09 6C
CompuServe: 72677,564 | P.O. Box 9573 | B0 EA 9E 4C C4 C6 7D 46
Fax: 1-818-247-6046 | Glendale, CA 91226 | Key available via finger
What is PGP? Subscribe to alt.security.pgp and find out!
Let's imagine that you received a letter in the mail from someone you
<*>
Origin: BCS - 0795 - Ia-ScryPgp
From: GARY EDSTROM Public
To: ALL
Date: 12/19/93
Re: PGP FAQ (2/4) General FAQ
--------------------------------------------------------------------------
From: gbe@netcom.com (Gary Edstrom)
Newsgroups: alt.security.pgp
Subject: PGP FAQ (2/4) General FAQ & Appendix
Date: Sun, 19 Dec 1993 21:03:15 GMT
Message-ID: <gbeCIAvtF.39@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
-----BEGIN PGP SIGNED MESSAGE-----
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. As of 12/6/93 there are about 2,600 keys on the
key servers. The rate of growth is increasing rapidly.
8.2. Where are the Public Key Servers?
By its nature, the list of public key servers is subject to much
change. Therefore, the following list may be out of date by the time
you read it. Keep an eye on alt.security.pgp for announcements relating
to the addition and deletion of key servers. Any additions, deletions,
or corrections to this list should be posted to alt.security.pgp and
mailed to me for inclusion in future releases of the FAQ.
Internet sites:
pgp-public-keys@demon.co.uk
Mark Turner <mark@demon.co.uk>
FTP: ftp.demon.co.uk:/pub/pgp/pubring.pgp
Verified: 15-Dec-93
pgp-public-keys@fbihh.informatik.uni-hamburg.de
Vesselin V. Bontchev <bontchev@fbihh.informatik.uni-hamburg.de>
FTP: ftp.informatik.uni-hamburg.de:/pub/virus/misc/pubkring.pgp
Verified: 17-Dec-93
public-key-server@martigny.ai.mit.edu
Brian A. LaMacchia <public-key-server-request@martigny.ai.mit.edu>
Verified: 14-Dec-93
pgp-public-keys@kiae.su
Verified: 17-Dec-93
pgp-public-keys@pgp.ox.ac.uk
Paul Leyland <pcl@ox.ac.uk>
No FTP Available
Verified: 14-Dec-93
I have been unable to verify the existance following key servers. If
anyone has any information concerning them, please forward it to me
so that I can update this list.
pgp-public-keys@chao.sw.oz.au
Jeremy Fitzhardinge <jeremy@sw.oz.au>
pgp-public-keys@dsi.unimi.it
The following public key servers are no longer in operation:
pgp-public-keys@junkbox.cc.iastate.edu
pgp-public-keys@toxicwaste.mit.edu
pgp-public-keys@phil.utmb.edu
BBS sites:
8.3. What is the syntax of the key server commands?
The remailer 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)
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
GET userid Get just that one key
MGET regexp Get all keys which match /regexp/
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
> Where should I send bug reports?
Post all of your bug reports concerning PGP to alt.security.pgp and
forward a copy to me for possible inclusion in future releases of the
FAQ. Please be a 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.2 and later. For
bugs in earlier versions, refer to the documentation included with the
program.
> Version 2.3 for DOS has a problem with clear signing messages. Anyone
using version 2.3 for DOS should upgrade to version 2.3a.
> Version 2.2 for DOS has a problem of randomly corrupting memory, which
can (and sometimes does) make DOS to trash your hard disk.
10. Related News Groups
alt.privacy.clipper Clipper, Capstone, Skipjack, Key Escrow
alt.security general security discussions
alt.security.index index to alt.security
alt.security.pgp discussion of PGP
alt.security.ripem discussion of RIPEM
alt.society.civil-liberty general civil liberties, including privacy
comp.compression discussion of compression algorithms and
code
comp.org.eff.news News reports from EFF
comp.org.eff.talk discussion of EFF related issues
comp.patents discussion of S/W patents, including RSA
comp.risks some mention of crypto and wiretapping
comp.society.privacy general privacy issues
comp.security.announce announcements of security holes
misc.legal.computing software patents, copyrights, computer laws
sci.crypt methods of data encryption/decryption
sci.math general math discussion
11. Recommended Reading
> 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 recently. 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 recommended reading list was lifted unedited except for
formatting 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
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 (coming in November)
Paul Wallich, "Electronic Envelopes", Scientific American, Feb 1993,
page 30. (This is an article on PGP)
12. General Tips
> Some BBS sysops may not permit you to place encrypted mail or files on
their boards. Just because they have PGP in their file area, that
doesn't necessarily mean they tolerate you uploading encrypted mail or
files - so *do* check first.
> Fido net mail is even more sensitive. You should only send encrypted
net mail after checking that:
a) Your sysop permits it.
b) Your recipient's sysop permits it.
c) The mail is routed through nodes whose sysops also permit it.
> Get your public key signed by as many individuals as possible. It
increases the chances of another person finding a path of trust from
himself to you.
> Don't sign someone's key just because someone else that you know has
signed it. Confirm the identity of the individual yourself. Remember,
you are putting your reputation on the line when you sign a key.
========================================================================
Appendix I - PGP add-ons and Related Programs
========================================================================
Much of this section was lifted, unedited from an old FAQ supplied to me
for the development of this list. This section will hopefully grow to
contain a list of every utility that has been written. I would appreciate
it if the authors of the various utilities could send me mail about their
latest version, a description, if source code is available, and where to
get it. I will then include the information in the next release of the FAQ.
If you have a utility, but don't know how to make it widely available, send
mail to David Vincenzetti <vince@dsi.unimi.it> who is crypto collection
maintainer at ghost.dsi.unimi.it. That ftp-site is weekly mirrored at
nic.funet.fi in area: /pub/crypt/ghost.dsi.unimi.it
========================================================================
> There are utilities in the source code for PGP. Get pgp23srcA.zip and
unpack with 'pkunzip -d pgp23srcA.zip' to get them all come up nicely
sorted in subdirectorys.
> PBBS
Public Bulletin Board System (PBBS) ver 1.0 is a privacy-oriented host
BBS application designed with the "anonymous movement's" diverse needs
in mind. PBBS is a compact application at 75K, allowing it to be run
off of a floppy disk if desired, and requires no telecommunications
experience to operate. Installation of PBBS takes about 2 minutes
flat, and is easy to set up and maintain. Don't let the size fool you
however, it packs a powerful set of Zmodem, Ymodem, and Xmodem assembly-
language protocols, supports speeds up to 57,600 bps, door support,
full ANSI-emulation, and many more features!
Public BBS is an eclectic and powerful BBS and also the first bulletin
board system designed to work with Pretty Good Privacy (PGP), the
public-key encryption program. A unique Post Office within PBBS allows
users to send each other private "postcards" or to upload and download
PGP-encrypted messages to other user's mail boxes. PBBS also contains
a comprehensive public message base with "anonymous" read, write, and
reply options. PBBS has a built in emergency self-destruct sequence
for the sysop that desires an extra level of security. The ESD option
will completely shred all PBBS-related files on disk, assuring the
sysop that his or her BBS will not be compromised in any way. Look for
Public BBS to be released on all I Internet sites and FidoNet BBS's as
PBBS10.ZIP in October 1993. PBBS will change the face of cyber-fringe
telecommunications forever! Questions or comments please e-mail James
Still at <still@kailua.colorado.edu>.
> rat-pgp.el
rat-pgp.el is a GNU Emacs interface to the PGP public key system. It
lets you easily encrypt and decrypt message, sign messages with your
secret key (to prove that it really came from you). It does
signature verification, and it provides a number of other
functions. The package is growing steadily as more is added. It is
my intention that it will eventually allow as much functionality as
accessing PGP directly. The most recent version of rat-pgp.el is always
available via anonymous FTP at ftp.ccs.neu.edu, directory
/pub/ratinox/emacs-lisp/rat-pgp.el.
> mailcrypt.el
From: jsc@mit.edu (Jin S Choi)
Current Version: 1.3
Where Available: gnu.emacs.sources
Info Updated: 12-Dec-93
This is an elisp package for encrypting and decrypting mail. I wrote
this to provide a single interface to the two most common mail
encryption programs, PGP and RIPEM. You can use either or both in any
combination.
Includes:
VM mailreader support.
Support for addresses with spaces and <>'s in them.
Support for using an explicit path for the encryption executables.
Key management functions.
The ability to avoid some of the prompts when encrypting.
Assumes mc-default-scheme unless prefixed.
Includes menubar support under emacs 19 and gnus support.
> PGPPAGER ver. 1.1
Newsgroups: alt.security.pgp
From: abottone@minerva1.bull.it (Alessandro Bottonelli)
Subject: pgppager 1.1 sources
Date: Tue, 6 Jul 1993 11:37:06 GMT
pgppager, designed to be possibly integrated with elm mail reader.
This programs reads from a specified file or from stdin if no file is
specified and creates three temporary files i(header, encrypted, and
trailer) as needed, in order to store the header portion in clear text,
the encrypted portion still in cipher text, and the trailer portion of
the clear text. Then, if applicable, the clear text header is
outputted, the encrypted portion is piped through pgp as needed, then
the trailer (if any) is outputted. THIS PROCESS IS TRANSPARENT TO NON
PGP ENCRYPTED TEXTS
> PGPSHE22
PGPShell v2.2 is a dramatic update to this easy-to-use program that
makes using Philip Zimmermann's Pretty Good Privacy (PGP) public-key
encryption software easy. Supports all of PGP's command-line arguments
with a graphical user interface (GUI), mouse, windowed popup boxes with
scroll bars for easy UserID, footprint, and signature key viewing on
your public key ring. Built-in file viewer for reading decrypted
messages. Use your favorite text editor to compose messages then
automatically encrypt them. Requires PGP (ver 2.0 or higher), can run
on any PC XT, AT, 286+, mono or color. Mouse optional. Freeware.
available as 65430 Aug 3 11:40 garbo.uwasa.fi [128.214.87.1]
/pc/crypt/pgpshe22.zip and Hieroglyphic Voodoo Machine BBS at
1.303.443.2457
> MENU.ZIP
Menushell for MSDOS. (Requires 4DOS or Norton's NDOS) You can customize
the menu for your own preferences. The name 'MENU' violates file
naming conventions on ftp-sites, so I guess it's hard to find this
program somewhere else. Exists at ghost.dsi.unimi.it area: /pub/crypt/
(ask archie about 4DOS, a comand.com replacement)
> PGP-NG.ZIP
At nic.funet.fi; /pub/crypt/pgp-ng.zip. A norton Guide database for PGP
ver 2.0. Easy to find info for programmers about all the functions in
the source code, and users can more easily find their subject. Is any
update for the current version planned? Ask archie about the 2 Norton
guide clones that are out on the net.
> Subject: Front End Announcement: PGP with TAPCIS
Sender: usenet@ttinews.tti.com (Usenet Admin)
Reply-To: 72027.3210@compuserve.com
Date: Tue, 3 Aug 1993 00:58:17 GMT
TAPCIS is a popular navigator/offline message reader used on PCs to
access CompuServe. An add-on program, TAPPKE (TAPcis Public Key
Encryption), has been uploaded to the CompuServe TAPCIS Support Forum
library under "scripts and tools;" this program is an interface between
TAPCIS message-writing facilities and PGP.
When you compose messages in TAPCIS, they get collected into a batch in
a .SND file along with some control information about where and how the
messages are to be posted or mailed; next time you go on-line to
CompuServe, TAPCIS processes any messages waiting in its .SND files.
The TAPPKE add-on can be run before you do this transmission step.
TAPPKE scans messages in a .SND file, and any message that contains a
keyword (##PRIVATE## or ##SIGNATURE##) is extracted and just that
message is handed to PGP for encryption or signature, then reinserted
into the .SND file for transmission.
All this is a simplified interface to make it more convenient to
encrypt/sign messages while still using the normal (and
familiar)message composition features of TAPCIS. TAPPKE doesn't do any
encryption itself, it merely invokes an external encryption engine to
perform the indicated tasks; you can even use it with encryption
programs other than PGP if you set up a few environment variables so
TAPPKE will know what encryption program to run and what command-line
arguments to feed it. The default configuration assumes PGP.
I don't see any point in posting TAPPKE anywhere besides on CompuServe,
since the only people who would have any use for it are TAPCIS users,
and they by definition have access to the CompuServe TAPCIS forum
libraries. However, it's free (I released it to the public domain,
along with source code), so anyone who wants to propagate it is welcome
to do so.
Some mailers apparently munge my address; you might have to use
bsmart@bsmart.tti.com -- or if that fails, fall back to
72027.3210@compuserve.com. Ain't UNIX grand? "
> HPACK79 PGP-compatible archiver
114243 Nov 20 07:08 garbo.uwasa.fi:/pc/arcers/hpack79.zip
146470 Dec 3 01:01 garbo.uwasa.fi:/pc/doc-soft/hpack79d.zip
511827 Dec 3 14:46 garbo.uwasa.fi:/pc/source/hpack79s.zip
667464 Dec 5 16:43 garbo.uwasa.fi:/unix/arcers/hpack79src.tar.Z
where hpack79.zip is the MSDOS executable, hpack79d.zip is the
Postscript documentation, hpack79s.zip is the source code, and
hpack79src.tar.Z is the source code again but in tar.Z format (note
that the latter is a tiny bit more recent that hpack79s.zip and
contains changes for the NeXT). There is a (rather primitive)
Macintosh executable somewhere on garbo as well, possibly
/mac/arcers/hpack79mac.cpt. OS/2 32-bit versions of HPACK available for
anonymous FTP from the UK. `ftp.demon.co.uk' [158.152.1.65] in
~/pub/ibmpc/pgp
pgut1@cs.aukuni.ac.nz
p_gutmann@cs.aukuni.ac.nz
gutmann_p@kosmos.wcc.govt.nz
peterg@kcbbs.gen.nz
peter@nacjack.gen.nz
peter@phlarnschlorpht.nacjack.gen.nz
(In order of preference - one of 'ems bound to work)
> PGPUTILS.ZIP at ghost.dsi.unimi.it /pub/crypt/ is a collection of BAT-
files, and PIF-files for windows.
> ENCRYPT.COM is a VMS mail script that works fine for
joleary@esterh.wm.estec.esa.nl (John O'Leary)
> PWF12 A Windows front end for PGP
For all those MS Windows users who want a point and click PGP front
end, PGP WinFront 1.2 (PWF12) is for you. This program is an easy to
use Windows front end for PGP. You can access main PGP features more
easily than from DOS. This program features:
> A simple file management system
> The ability to create plaintext files to encrypt very easily using
the editor of your choice
> A quick way to shell to DOS to access esoteric PGP features
> Allows you to edit the command line to access the more specialised
features of PGP
> Plus more
Check it out; IT'S FREE and available by email.
TO GET THIS PROGRAM (PWF12.ZIP):
1) Send an email message to rbarclay@trentu.ca
2) The subject MUST READ: GET PWF
3) The body can be left blank.
You will be sent a two part signed Radix-64 ASCII Armoured zip file.
Use PGP to de-armour it. Read the document file fully. This program
has a number of features not mentioned here and you wouldn't want to
miss them.
--
ross barclay
========================================================================
Appendix II - Glossary of Cryptographic Terms
========================================================================
Chosen Plain Text Attack
This is the next step up from the Known Plain Text Attack. In this
version, the cryptoanalysit 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 lead a
number of large corporations to oppose the idea. Clipper uses an 80
bit key to perform a series of nonlinear transformation on a 64 bit
data block.
DES (Data Encryption Standard)
A data encryption standard developed by 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 it. DES uses a 56 bit
key to perform a series of nonlinear transformation on a 64 bit data
block. Even when it was first introduced a number of years ago, it was
criticized for not having a long enough key. 56 bits just didn't put it
far enough out of reach of a brute force attack. Today, with the
increasing speed of hardware and its falling cost, it would be
feasible, to build a machine that could crack a 56 bit key in under a
day's time. It is not known if such a machine has really been built,
but the fact that it is feasible tends to weaken the security of DES
substantially.
EFF (Electronic Frontier Foundation)
The Electronic Frontier Foundation (EFF) was founded in July, 1990, to
assure freedom of expression in digital media, with a particular
emphasis on applying the principles embodied in the Constitution and
the Bill of Rights to computer-based communication. For further
information, contact:
Electronic Frontier Foundation
1001 G St., NW
Suite 950 East
Washington, DC 20001
+1 202 347 5400
+1 202 393 5509 FAX
Internet: eff@eff.org
IDEA (International Data Encryption Algorithm)
Developed in Switzerland and licensed for non commercial use in PGP.
IDEA uses a 128 bit user supplied key to perform a series of nonlinear
mathematical transformations on a 64 bit data block. Compare the length
of this key with the 56 bits in DES or the 80 bits in Clipper.
ITAR (International Traffic in Arms Regulations)
ITAR are the regulations covering the exporting of weapons and weapons
related technology from the United States. For some strange reason, the
government claims that data encryption is a weapon and comes under the
ITAR regulations. There is presently a move in congress to relax the
section of ITAR dealing with cryptographic technology.
Known Plain Text Attack
A method of attack on a crypto system where the cryptoanalysit has
matching copies of plain text, and its encrypted version. With weaker
encryption systems, this can improve the chances of cracking the code
and getting at the plain text of other messages where the plain text is
not known.
MD5 (Message Digest Algorithm #5)
The message digest algorithm used in PGP is the MD5 Message Digest
Algorithm, placed in the public domain by RSA Data Security, Inc. MD5's
designer, Ronald Rivest, writes this about MD5:
"It is conjectured that the difficulty of coming up with two messages
having the same message digest is on the order of 2^64 operations,
and that the difficulty of coming up with any message having a given
message digest is on the order of 2^128 operations. The MD5
algorithm has been carefully scrutinized for weaknesses. It is,
however, a relatively new algorithm and further security analysis is
of course justified, as is the case with any new proposal of this
sort. The level of security provided by MD5 should be sufficient for
implementing very high security hybrid digital signature schemes
based on MD5 and the RSA public-key cryptosystem."
NSA (National Security Agency)
The following was lifted unedited except for formatting from the
sci.crypt FAQ:
The NSA is the official communications security body of the U.S.
government. It was given its charter by President Truman in the early
50's, and has continued research in cryptology till the present. The
NSA is known to be the largest employer of mathematicians in the world,
and is also the largest purchaser of computer hardware in the world.
Governments in general have always been prime employers of
cryptologists. The NSA probably possesses cryptographic expertise many
years ahead of the public state of the art, and can undoubtedly break
many of the systems used in practice; but for reasons of national
security almost all information about the NSA is classified.
One Time Pad
The one time pad is the ONLY encryption scheme that can be proven to be
absolutely unbreakable! It is used extensively by spies because it
doesn't require any hardware to implement and because of its absolute
security. This algorithm requires the generation of many sets of
matching encryption keys pads. Each pad consists of a number of random
key characters. These key characters are chosen completely at random
using some truly random process. They are NOT generated by any kind of
cryptographic key generator. Each party involved receives matching sets
of pads. Each key character in the pad is used to encrypt one and only
one plain text character, then the key character is never used again.
Any violation of these conditions negates the perfect security
available in the one time pad.
So why don't we use the one time pad all the time? The answer is that
the number of random key pads that need to be generated must be at
least equal to the volume of plain text messages to be encrypted, and
the fact that these key pads must somehow be exchanged ahead of time.
This becomes totally impractical in modern high speed communications
systems.
PEM (Privacy Enhanced Mail)
The following was lifted unedited except for formatting from the
sci.crypt FAQ:
How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...]?
Here's one popular method, using the des command:
cat file | compress | des private_key | uuencode | mail
Meanwhile, there is a de jure Internet standard in the works called PEM
(Privacy Enhanced Mail). It is described in RFCs 1421 through 1424. To
join the PEM mailing list, contact pem-dev-request@tis.com. There is a
beta version of PEM being tested at the time of this writing.
There are also two programs available in the public domain for
encrypting mail: PGP and RIPEM. Both are available by FTP. Each has its
own news group: alt.security.pgp and alt.security.ripem. Each has its
own FAQ as well. PGP is most commonly used outside the USA since it
uses the RSA algorithm without a license and RSA's patent is valid only
(or at least primarily) in the USA.
RIPEM is most commonly used inside the USA since it uses the RSAREF
which is freely available within the USA but not available for shipment
outside the USA.
Since both programs use a secret key algorithm for encrypting the body
of the message (PGP used IDEA; RIPEM uses DES) and RSA for encrypting
the message key, they should be able to interoperate freely. Although
there have been repeated calls for each to understand the other's
formats and algorithm choices, no interoperation is available at this
time (as far as we know).
PGP (Pretty Good Privacy)
PKP (Public Key Partners)
Claim to have a patent on RSA.
RIPEM
See PEM
RSA (Rivest-Shamir-Adleman)
RSA is the public key encryption method used in PGP. RSA are the
initials of the developers of the algorithm which was done at tax payer
expense. The basic security in RSA comes from the fact that, while it
is relatively easy to multiply two huge prime numbers together to
obtain their product, it is computationally difficult to go the reverse
direction: to find the two prime factors of a given composite number.
It is this one-way nature of RSA that allows an encryption key to be
generated and disclosed to the world, and yet not allow a message to be
decrypted.
Skipjack
See Clipper
TEMPEST
TEMPEST is a standard for electromagnetic shielding for computer
equipment. It was created in response to the discovery 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. It is a
good bet that 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 to save you. The government could just set up a monitoring
van outside your home and read everything that you are doing on your
computer.
Short of shelling out the ten thousand dollars or so that it would take
to properly shield your computer, a good second choice would probably
be a laptop computer running on batteries. No emissions would be fed
back into the power lines, and the amount of power being fed to the
display and being consumed by the computer is much less than the
typical home computer and CRT. This provides a much weaker RF field for
snoopers to monitor. It still isn't safe, just safer.
========================================================================
Appendix III - Cypherpunks
========================================================================
> What are Cypherpunks?
> What is the cypherpunks mailing list?
Eric Hughes <hughes@toad.com> runs the "cypherpunk" mailing list
dedicated to "discussion about technological defenses for privacy in
the digital domain." Frequent topics include voice and data
encryption, anonymous remailers, and the Clipper chip. Send e-mail to
cypherpunks-request@toad.com to be added or subtracted from the list.
The mailing list itself is cypherpunks@toad.com. You don't need to be a
member of the list in order to send messages to it, thus allowing the
use of anonymous remailers to post your more sensitive messages that
you just as soon would not be credited to you. (Traffic is sometimes up
to 30-40 messages per day.)
> What is the purpose of the Cypherpunk remailers?
The purpose of these remailers is to take privacy one level further.
While a third party who is snooping on the net may not be able to read
the encrypted mail that you are sending, he is still able to know who
you are sending mail to. This could possibly give him some useful
information. This is called traffic flow analysis. To counter this type
of attack, you can use a third party whose function is simply to remail
your message with his return address on it instead of yours.
Two types of remailers exist. The first type only accepts plain text
remailing headers. This type would only be used if your goal was only
to prevent the person to whom your are sending mail from learning your
identity. It would do nothing for the problem of net eavesdroppers from
learning to whom you are sending mail.
The second type of remailer accepts encrypted remailing headers. With
this type of remailer, you encrypt your message twice. First, you
encrypt it to the person ultimately receiving the message. You then add
the remailing header and encrypt it again using the key for the
remailer that you are using. When the remailer receivers your message,
the system will recognize that the header is encrypted and will use its
secret decryption key to decrypt the message. He can now read the
forwarding information, but because the body of the message is still
encrypted in the key of another party, he is unable to read your mail.
He simply remails the message to the proper destination. At its
ultimate destination, the recipient uses his secret to decrypt this
nested encryption and reads the message.
Since this process of multiple encryptions and remailing headers can
get quite involved, there are several programs available to simplify
the process. FTP to soda.berkeley.edu and examine the directory
/pub/cypherpunks/remailers for the programs that are available.
> Where are the currently active Cypherpunk remailers?
Any additions, deletions, or corrections to the following list should
be posted on alt.security.pgp and forwarded to me for inclusion in a
future release of the FAQ. The number appearing in the first column
has the following meaning:
1: Remailer accepts only plain text headers.
2: Remailer accepts both plain text and encrypted headers.
3: Remailer accepts only encrypted headers.
Only remailers whose operational status has been verified by me appear
on this list. Remember, however, that this list is subject to change
quite often. Always send yourself a test message through the Remailer
before starting to use it for real.
1 hh@pmantis.berkeley.edu
1 hh@cicada.berkeley.edu
1 hh@soda.berkeley.edu
1 nowhere@bsu-cs.bsu.edu
1 remail@tamsun.tamu.edu
2 ebrandt@jarthur.claremont.edu
2 hal@alumni.caltech.edu [Fwd: hfinney@shell.portal.com]
2 elee7h5@rosebud.ee.uh.edu
2 hfinney@shell.portal.com
2 remailer@utter.dis.org
1 00x@uclink.berkeley.edu [Fwd: hh@soda.berkeley.edu]
2 remailer@rebma.mn.org
3 remail@extropia.wimsey.com
The following former Cypherpunk remailers are no longer in service.
Either a message stating that the system had been shutdown was
received, or the test message was returned due to an invalid address,
or no test message was returned after three attempts.
phantom@mead.u.washington.edu [Shutdown message returned]
remail@tamaix.tamu.edu [Mail returned, invalid address]
> Are there other anonymous remailers besides the cypherpunk remailers?
Yes, the most commonly used remailer on the Internet is in Finland. It
is known as anon.penet.fi. The syntax for sending mail through this
remailer is different from the cypherpunk remailers. For example, if
you wanted to send mail to me (gbe@netcom.com) through anon.penet.fi,
you would send the mail to "gbe%netcom.com@anon.penet.fi". Notice that
the "@" sign in my Internet address is changed to a "%". Unlike the
cypherpunk remailers, anon.penet.fi directly supports anonymous return
addresses. Anybody using the remailer is assigned an anonymous id of
the form "an?????" where "?????" is filled in with a number
representing that user. To send mail to someone when you only know
their anonymous address, address your mail to "an?????@anon.penet.fi"
replacing the question marks with the user id you are interested in.
For additional information on anon.penet.fi, send a blank message to
"help@anon.penet.fi". You will receive complete instructions on how to
use the remailer, including how to obtain a pass phrase on the system.
> Where can I learn more about Cypherpunks?
FTP: soda.berkeley.edu Directory: /pub/cypherpunks
> What is the command syntax?
The first non blank line in the message must start with two colons
(::). The next line must contain the user defined header "Request-
Remailing-To: <destination>". This line must be followed by a blank
line. Finally, your message can occupy the rest of the space. As an
example, if you wanted to send a message to me via a remailer , you
would compose the following message:
::
Request-Remailing-To: gbe@netcom.com
[body of message]
You would then send the above message to the desired remailer. Note
the section labeled "body of message" may be either a plain text
message, or an encrypted and armored PGP message addressed to the
desired recipient. To send the above message with an encrypted header,
use PGP to encrypt the entire message shown above to the desired
remailer. Be sure to take the output in armored text form. In front of
the BEGIN PGP MESSAGE portion of the file, insert two colons (::) as
the first non- blank line of the file. The next line should say
"Encrypted: PGP". Finally the third line should be blank. The message
now looks as follows:
::
Encrypted: PGP
-----BEGIN PGP MESSAGE-----
Version 2.3a
[body of pgp message]
-----END PGP MESSAGE-----
You would then send the above message to the desired remailer just
as you did in the case of the non-encrypted header. Note that it is
possible to chain remailers together so that the message passes
through several levels of anonymity before it reaches its ultimate
destination.