home *** CD-ROM | disk | FTP | other *** search
- Path: senator-bedfellow.mit.edu!faqserv
- From: jalicqui@prairienet.org
- Newsgroups: alt.security.pgp,alt.answers,news.answers
- Subject: PGP Frequently Asked Questions with Answers, Part 2/3
- Supersedes: <pgp-faq/part2_801484722@rtfm.mit.edu>
- Followup-To: alt.security.pgp
- Date: 23 Jun 1995 12:33:09 GMT
- Organization: none
- Lines: 1308
- Approved: news-answers-request@MIT.EDU
- Expires: 17 Jul 1995 12:32:08 GMT
- Message-ID: <pgp-faq/part2_803910728@rtfm.mit.edu>
- References: <pgp-faq/part1_803910728@rtfm.mit.edu>
- Reply-To: jalicqui@prairienet.org
- NNTP-Posting-Host: bloom-picayune.mit.edu
- 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
- Originator: faqserv@bloom-picayune.MIT.EDU
- Xref: senator-bedfellow.mit.edu alt.security.pgp:36815 alt.answers:10167 news.answers:46905
-
- 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/rsa129.ps.gz
-
- ========
-
- 3.6. How secure is the "for your eyes only" option (-m)?
-
- It is not secure at all. There are many ways to defeat it. Probably
- the easiest way is to simply redirect your screen output to a file as
- follows:
-
- pgp [filename] > [diskfile]
-
- The -m option was not intended as a fail-safe option to prevent plain
- text files from being generated, but to serve simply as a warning to
- the person decrypting the file that he probably shouldn't keep a copy
- of the plain text on his system.
-
- ========
-
- 3.7. What if I forget my pass phrase?
-
- In a word: DON'T. If you forget your pass phrase, there is absolutely
- no way to recover any encrypted files. I use the following technique:
- I have a backup copy of my secret key ring on floppy, along with a
- sealed envelope containing the pass phrase. I keep these two items in
- separate safe locations, neither of which is my home or office. The
- pass phrase used on this backup copy is different from the one that I
- normally use on my computer. That way, even if some stumbles onto the
- hidden pass phrase and can figure out who it belongs to, it still
- doesn't do them any good, because it is not the one required to unlock
- the key on my computer.
-
- ========
-
- 3.8. Why do you use the term "pass phrase" instead of "password"?
-
- This is because most people, when asked to choose a password, select
- some simple common word. This can be cracked by a program that uses a
- dictionary to try out passwords on a system. Since most people really
- don't want to select a truly random password, where the letters and
- digits are mixed in a nonsense pattern, the term pass phrase is used
- to urge people to at least use several unrelated words in sequence as
- the pass phrase.
-
- ========
-
- 3.9. What is the best way to crack PGP?
-
- Currently, the best attack possible on PGP is a dictionary attack on
- the pass phrase. This is an attack where a program picks words out of
- a dictionary and strings them together in different ways in an attempt
- to guess your pass phrase.
-
- This is why picking a strong pass phrase is so important. Many of
- these cracker programs are very sophisticated and can take advantage
- of language idioms, popular phrases, and rules of grammar in building
- their guesses. Single-word "phrases", proper names (especially famous
- ones), or famous quotes are almost always crackable by a program with
- any "smarts" in it at all.
-
- ========
-
- 3.10. If my secret key ring is stolen, can my messages be read?
-
- No, not unless they have also stolen your secret pass phrase, or if
- your pass phrase is susceptible to a brute-force attack. Neither part
- is useful without the other. You should, however, revoke that key and
- generate a fresh key pair using a different pass phrase. Before
- revoking your old key, you might want to add another user ID that
- states what your new key id is so that others can know of your new
- address.
-
- ========
-
- 3.11. How do I choose a pass phrase?
-
- All of the security that is available in PGP can be made absolutely
- useless if you don't choose a good pass phrase to encrypt your secret
- key ring. Too many people use their birthday, their telephone number,
- the name of a loved one, or some easy to guess common word. While
- there are a number of suggestions for generating good pass phrases,
- the ultimate in security is obtained when the characters of the pass
- phrase are chosen completely at random. It may be a little harder to
- remember, but the added security is worth it. As an absolute minimum
- pass phrase, I would suggest a random combination of at least 8
- letters and digits, with 12 being a better choice. With a 12 character
- pass phrase made up of the lower case letters a-z plus the digits 0-9,
- you have about 62 bits of key, which is 6 bits better than the 56 bit
- DES keys. If you wish, you can mix upper and lower case letters in
- your pass phrase to cut down the number of characters that are
- required to achieve the same level of security. I don't do this myself
- because I hate having to manipulate the shift key while entering a
- pass phrase.
-
- A pass phrase which is composed of ordinary words without punctuation
- or special characters is susceptible to a dictionary attack.
- Transposing characters or mis-spelling words makes your pass phrase
- less vulnerable, but a professional dictionary attack will cater for
- this sort of thing.
-
- A good treatise on the subject is available which discusses the use of
- "shocking nonsense" in pass phrases. It is written by Grady Ward, and
- can be found on Fran Litterio's crypto page:
-
- http://draco.centerline.com:8080/~franl/pgp/pgp-passphrase-faq.html
-
- ========
-
- 3.12. How do I remember my pass phrase?
-
- This can be quite a problem especially if you are like me and have
- about a dozen different pass phrases that are required in your
- everyday life. Writing them down someplace so that you can remember
- them would defeat the whole purpose of pass phrases in the first
- place. There is really no good way around this. Either remember it, or
- write it down someplace and risk having it compromised.
-
- ========
-
- 3.13. How do I verify that my copy of PGP has not been tampered with?
-
- If you do not presently own any copy of PGP, use great care on where
- you obtain your first copy. What I would suggest is that you get two
- or more copies from different sources that you feel that you can
- trust. Compare the copies to see if they are absolutely identical.
- This won't eliminate the possibility of having a bad copy, but it will
- greatly reduce the chances.
-
- If you already own a trusted version of PGP, it is easy to check the
- validity of any future version. Newer binary versions of MIT PGP are
- distributed in popular archive formats; the archive file you receive
- will contain only another archive file, a file with the same name as
- the archive file with the extension .ASC, and a "setup.doc" file. The
- .ASC file is a stand-alone signature file for the inner archive file
- that was created by the developer in charge of that particular PGP
- distribution. Since nobody except the developer has access to his/her
- secret key, nobody can tamper with the archive file without it being
- detected. Of course, the inner archive file contains the newer PGP
- distribution.
-
- A quick note: If you upgrade to MIT PGP from an older copy (2.3a or
- before), you may have problems verifying the signature. See question
- 3.14, below, for a more detailed treatment of this problem.
-
- To check the signature, you must use your old version of PGP to check
- the archive file containing the new version. If your old version of
- PGP is in a directory called C:\PGP and your new archive file and
- signature is in C:\NEW (and you have retrieved MIT PGP 2.6.2), you may
- execute the following command:
-
- C:\PGP\PGP C:\NEW\PGP262I.ASC C:\NEW\PGP262I.ZIP
-
- If you retrieve the source distribution of MIT PGP, you will find two
- more files in your distribution: an archive file for the RSAREF
- library and a signature file for RSAREF. You can verify the RSAREF
- library in the same way as you verify the main PGP source archive.
-
- Non-MIT versions typically include a signature file for the PGP.EXE
- program file only. This file will usually be called PGPSIG.ASC. You
- can check the integrity of the program itself this way by running your
- older version of PGP on the new version's signature file and program
- file.
-
- Phil Zimmermann himself signed all versions of PGP up to 2.3a. Since
- then, the primary developers for each of the different versions of PGP
- have signed their distributions. As of this writing, the developers
- whose signatures appear on the distributions are:
-
- MIT PGP 2.6.2 Jeff Schiller <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/public-keys.pgp
- ftp://alex.sp.cs.cmu.edu/links/security/pubring.pgp
- ftp://ftp.informatik.uni-hamburg.de/pub/virus/misc/pubkring.pgp
- ftp://ftp.dsi.unimi.it/pub/security/crypt/PGP/public-keys.pgp
- ftp://jpunix.com/pub/PGP/
-
- The following key servers are no longer in operation:
-
- 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-----
-