Part 2 of Jeff Licquia's PGP FAQ

• Table of Contents
  • Part 1 of PGP FAQ
  • Part 3 of PGP FAQ
  • Part 2 of PGP FAQ
    • 3. Security Questions
      • 3.1. How secure is PGP?
      • 3.2. Can't you break PGP by trying all of the possible keys?
      • 3.3. How secure is the conventional cryptography (-c) option?
      • 3.4. Can the NSA crack RSA?
      • 3.5. Has RSA ever been cracked publicly? What is RSA-129?
      • 3.6. How secure is the "for your eyes only" option (-m)?
      • 3.7. What if I forget my pass phrase?
      • 3.8. Why do you use the term "pass phrase" instead of "password"?
      • 3.9. What is the best way to crack PGP?
      • 3.10. If my secret key ring is stolen, can my messages be read?
      • 3.11. How do I choose a pass phrase?
      • 3.12. How do I remember my pass phrase?
      • 3.13. How do I verify that my copy of PGP has not been tampered with?
      • 3.14. I can't verify the signature on my new copy of MIT PGP with my old PGP 2.3a!
      • 3.15. How do I know that there is no trap door in the program?
      • 3.16. I heard that the NSA put a back door in MIT PGP, and that they only allowed it to be legal with the back door.
      • 3.17. Can I put PGP on a multi-user system like a network or a mainframe?
      • 3.18. Can I use PGP under a "swapping" operating system like Windows or OS/2?
      • 3.19. Why not use RSA alone rather than a hybrid mix of IDEA, MD5, & RSA?
      • 3.20. Aren't all of these security procedures a little paranoid?
      • 3.21. Can I be forced to reveal my pass phrase in any legal proceedings?
      
      
    • 4. Keys
      • 4.1. Which key size should I use?
      • 4.2. Why does PGP take so long to add new keys to my key ring?
      • 4.3. How can I extract multiple keys into a single armored file?
      • 4.4. I tried encrypting the same message to the same address two different times and got completely different outputs. Why is this?
      • 4.5. How do I specify which key to use when an individual has 2 or more public keys and the very same user ID on each, or when 2 different users have the same name?
      • 4.6. What does the message "Unknown signator, can't be checked" mean?
      • 4.7. How do I get PGP to display the trust parameters on a key?
      • 4.8. How can I make my key available via finger?
      
      
    • 5. Message Signatures
      • 5.1. What is message signing?
      • 5.2. How do I sign a message while still leaving it readable?
      • 5.3. Can't you just forge a signature by copying the signature block to another message?
      • 5.4. Are PGP signatures legally binding?
      
      
    • 6. Key Signatures
      • 6.1. What is key signing?
      • 6.2. How do I sign a key?
      • 6.3. Should I sign my own key?
      • 6.4. Should I sign X's key?
      • 6.5. How do I verify someone's identity?
      • 6.6. How do I know someone hasn't sent me a bogus key to sign?
      • 6.7. What's a key signing party?
      • 6.8. How do I organize a key signing party?
      
      
    • 7. Revoking a key
      • 7.1. My secret key ring has been stolen or lost, what do I do?
      • 7.2. I forgot my pass phrase. Can I create a key revocation certificate?
      
      
    • 8. Public Key Servers
      • 8.1. What are the Public Key Servers?
      • 8.2. What public key servers are available?
      • 8.3. What is the syntax of the key server commands?
      
      
    • 9. Bugs
    • 10. Recommended Reading
    • 11. General Tips
  • Part 3 of PGP FAQ
    • Appendix I - PGP add-ons and Related Products
    • Appendix II - Glossary of Cryptographic Terms
    • Appendix III - Cypherpunks
    • Appendix IV - Testimony of Philip Zimmermann to Congress
    • Appendix V - Announcement of Philip Zimmermann Defense Fund
    • Appendix VI - A Statement from ViaCrypt Concerning ITAR

• 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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/m ath/rsa129/rsa129.ps.gz
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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
      • ViaCrypt PGP 2.7.1 ViaCrypt
      • PGP 2.6.2i Stale Schumacher
      • PGP 2.6ui mathew
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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 u se (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!
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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).
    Go to Table of Contents
    
  • 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!)
    Go to Table of Contents
    
• 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!
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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 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
      • end
    • or:
      • #!/bin/sh
      • for name in name1 name2 name3 ... ; do
      • pgp -kx $name /tmp/keys.pgp
      • end
    • An equivalent DOS command would be:
      • for %a in (name1 name2 name3 ...) do pgp -kx %a keys.pgp
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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 "Jeff Licquia"
      • pgp -e licquia@cei.com
      • pgp -e 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
• 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.
    Go to Table of Contents
    
  • 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
    • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
• 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.
    Go to Table of Contents
    
  • 6.2. How do I sign a key?
    • Execute the following command from the command prompt:
      • PGP -ks [-u yourid]
    • 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 ").
    • 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.
    Go to Table of Contents
    
  • 6.3. Should I sign my own key?
    • Yes, you should sign each personal ID on y our 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
      • sig 0353E385 Jeff Licquia
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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 ).
    • 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
  • 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 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.
    Go to Table of Contents
    
• 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.
    Go to Table of Contents
    
  • 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.
    Go to Table of Contents
    
• 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.
    Go to Table of Contents
    
  • 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
      • pgp-public-keys@pgp.iastate.edu
      • Michael Graff
      • pgp-public-keys@burn.ucsd.edu
      • Andy Howard
      • pgp-public-keys@f bihh.informatik.uni-hamburg.de
      • Vesselin V. Bontchev
      • public-key-server@martigny. ai.mit.edu
      • Brian A. LaMacchia
      • pgp-public-keys@pgp.ox.ac.uk
      • Paul Leyland
      • pgp-public-keys@dsi.unimi.it
      • David Vincenzetti
      • pgp-public-keys@kub.nl
      • Teun Nijssen
      • pgp-public-keys@ext221.sra.co.jp
      • Hironobu Suzuki
      • pgp-public-keys@sw.oz.au
      • Jeremy Fitzhardinge
      • pgp-public-keys@kiae.su
      • blaster@rd.relcom.msk.su
      • pgp-public-keys@srce.hr
      • Cedomir Igaly
      • pgp-public-keys@pgp.pipex.net
      • Mark Turner
      • pgp-public-keys@goliat.upc.es
      • Alvar Vinacua
      • pgp-public-keys@gondolin.org
      • pgp-admin@gondolin.org
    • Sites accessible via WWW:
      • http://martigny.ai.mit.e du/~bal/pks-toplev.html
      • http://ibd.ar.com/PublicKeys.html< /b>
    • Key server keyrings accessible via FTP:
      • ftp://pgp.iastate.edu/pub/ pgp/public-keys.pgp
      • ftp://pgp.mit.edu/pub/keys/pu blic-keys.pgp
      • ftp://burn.ucsd.edu/Crypto/pu blic-keys.pgp
      • ftp://alex.sp.cs.cmu .edu/links/security/pubring.pgp
      • ftp://ft p.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.
    Go to Table of Contents
    
  • 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 Get just that one key (-kxa )
      • MGET Get all keys which match LAST Get all keys uploaded during last 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.
    Go to Table of Contents
    
• 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.
    Go to Table of Contents
    
• 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 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)
    Go to Table of Contents
    
• 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.
    Go to Table of Contents
    

  ---

  Go to Part One of PGP FAQ

  Go to Part Three of PGP FAQ

  Graphic Ideas' PGP Page

  Graphic Ideas' Home Page

  ---