--- pgp/doc/pgpdoc1.txt 2018/04/24 16:40:35 1.1.1.2 +++ pgp/doc/pgpdoc1.txt 2018/04/24 16:44:56 1.1.1.6 @@ -1,43 +1,48 @@ + + Phil's Pretty Good Software Presents - === - PGP - === + ======= + PGP(tm) + ======= - Pretty Good Privacy + Pretty Good(tm) Privacy Public Key Encryption for the Masses -------------------------- - PGP User's Guide - Volume I: Essential Topics + PGP(tm) User's Guide + Volume I: Essential Topics -------------------------- - by Philip Zimmermann - Revised 14 Jun 93 + by Philip Zimmermann + Revised 11 October 94 - PGP Version 2.3a - 1 Jul 93 + PGP Version 2.6.2 - 11 Oct 94 Software by - Philip Zimmermann - with - Branko Lankester, Hal Finney, and Peter Gutmann + Philip Zimmermann, and many others. -Synopsis: PGP uses public-key encryption to protect E-mail and data -files. Communicate securely with people you've never met, with no -secure channels needed for prior exchange of keys. PGP is well +Synopsis: PGP(tm) uses public-key encryption to protect E-mail and +data files. Communicate securely with people you've never met, with +no secure channels needed for prior exchange of keys. PGP is well featured and fast, with sophisticated key management, digital signatures, data compression, and good ergonomic design. -Software and documentation (c) Copyright 1990-1992 Philip Zimmermann. -For information on PGP licensing, distribution, copyrights, patents, -trademarks, liability limitations, and export controls, see the -"Legal Issues" section in the "PGP User's Guide, Volume II: Special -Topics". +Software and documentation (c) Copyright 1990-1994 Philip Zimmermann. +All rights reserved. For information on PGP licensing, distribution, +copyrights, patents, trademarks, liability limitations, and export +controls, see the "Legal Issues" section in the "PGP User's Guide, +Volume II: Special Topics". Distributed by the Massachusetts +Institute of Technology. + + +"Whatever you do will be insignificant, but it is very important that +you do it." --Mahatma Gandhi Contents @@ -69,9 +74,10 @@ How to Use PGP Advanced Topics Sending Ciphertext Through E-mail Channels: Radix-64 Format Environmental Variable for Path Name - Setting Configuration Parameters: CONFIG.TXT + Setting Parameters in the PGP Configuration File Vulnerabilities Beware of Snake Oil +Notice to Macintosh Users PGP Quick Reference Legal Issues Acknowledgments @@ -79,7 +85,7 @@ About the Author Quick Overview -============= +============== Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a high security cryptographic software application for MSDOS, Unix, @@ -166,8 +172,8 @@ with high capacity fiber optic data netw increasingly ubiquitous personal computers. E-mail will be the norm for everyone, not the novelty it is today. The Government will protect our E-mail with Government-designed encryption protocols. -Probably most people will trust that. But perhaps some people will -prefer their own protective measures. +Probably most people will acquiesce to that. But perhaps some people +will prefer their own protective measures. Senate Bill 266, a 1991 omnibus anti-crime bill, had an unsettling measure buried in it. If this non-binding resolution had become real @@ -187,23 +193,24 @@ Congress. It would require all manufact equipment to build in special remote wiretap ports that would enable the FBI to remotely wiretap all forms of electronic communication from FBI offices. Although it never attracted any sponsors in -Congress because of citizen opposition, it will be reintroduced in -1993. +Congress in 1992 because of citizen opposition, it was reintroduced in +1994. Most alarming of all is the White House's bold new encryption policy -initiative, under development at NSA for four years, and unveiled -April 16th, 1993. The centerpiece of this initiative is a -Government-built encryption device, called the "Clipper" chip, -containing a new classified NSA encryption algorithm. The Government -is encouraging private industry to design it into all their secure -communication products, like secure phones, secure FAX, etc. AT&T is -now putting the Clipper into all their secure voice products. The -catch: At the time of manufacture, each Clipper chip will be loaded -with its own unique key, and the Government gets to keep a copy, -placed in escrow. Not to worry, though-- the Government promises -that they will use these keys to read your traffic only when duly -authorized by law. Of course, to make Clipper completely effective, -the next logical step would be to outlaw other forms of cryptography. +initiative, under development at NSA since the start of the Bush +administration, and unveiled April 16th, 1993. The centerpiece of +this initiative is a Government-built encryption device, called the +"Clipper" chip, containing a new classified NSA encryption +algorithm. The Government is encouraging private industry to design +it into all their secure communication products, like secure phones, +secure FAX, etc. AT&T is now putting the Clipper into their secure +voice products. The catch: At the time of manufacture, each Clipper +chip will be loaded with its own unique key, and the Government gets +to keep a copy, placed in escrow. Not to worry, though-- the +Government promises that they will use these keys to read your +traffic only when duly authorized by law. Of course, to make Clipper +completely effective, the next logical step would be to outlaw other +forms of cryptography. If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big @@ -242,12 +249,13 @@ inconvenient. If you have a secure chan why do you need cryptography in the first place? In public key cryptosystems, everyone has two related complementary -keys, a publicly revealed key and a secret key. Each key unlocks the -code that the other key makes. Knowing the public key does not help -you deduce the corresponding secret key. The public key can be -published and widely disseminated across a communications network. -This protocol provides privacy without the need for the same kind of -secure channels that a conventional cryptosystem requires. +keys, a publicly revealed key and a secret key (also frequently called +a private key). Each key unlocks the code that the other key makes. +Knowing the public key does not help you deduce the corresponding +secret key. The public key can be published and widely disseminated +across a communications network. This protocol provides privacy +without the need for the same kind of secure channels that a +conventional cryptosystem requires. Anyone can use a recipient's public key to encrypt a message to that person, and that recipient uses her own corresponding secret key to @@ -301,7 +309,7 @@ rings contain secret key certificates. The keys are also internally referenced by a "key ID", which is an "abbreviation" of the public key (the least significant 64 bits of the large public key). When this key ID is displayed, only the lower -24 bits are shown for further brevity. While many keys may share the +32 bits are shown for further brevity. While many keys may share the same user ID, for all practical purposes no two keys share the same key ID. @@ -341,39 +349,43 @@ friend who will then add it to her key r Installing PGP ============== -The MSDOS PGP 2.3 release comes in a compressed archive file called -PGP23.ZIP (each new release will have a name in the form "PGPxy.ZIP" -for PGP version number x.y). The archive can be decompressed with -the MSDOS shareware decompression utility PKUNZIP, or the Unix -utility "unzip". The PGP release package contains a README.DOC file -that you should always read before installing PGP. This README.DOC -file contains late-breaking news on what's new in this release of -PGP, as well as information on what's in all the other files included -in the release. - -If you already have PGP version 1.0 for MSDOS, you should probably -delete it, because no one else uses it anymore. If you don't want to -delete it, rename the old executable file to pgp1.exe, to avoid name -conflicts with the new PGP. - -To install PGP on your MSDOS system, you just have to copy the -compressed archive PGPxx.ZIP file into a suitable directory on your -hard disk (like C:\PGP), and decompress it with PKUNZIP. For best -results, you will also modify your AUTOEXEC.BAT file, as described -elsewhere in this manual, but you can do that later, after you've -played with PGP a bit and read more of this manual. If you haven't -run PGP before, the first step after installation (and reading this -manual) is to run the PGP key generation command "pgp -kg". +The MSDOS PGP release package comes in a compressed archive file with +a file named in this form: PGPxx.ZIP (each release version has a +different number for the "xx" in the filename). For example, the +release package for version 2.6 is called PGP26.ZIP. The archive can +be decompressed with the MSDOS shareware decompression utility +PKUNZIP, or the Unix utility "unzip". When the PGP release package +is decompressed, several files emerge from it. One such file, called +README.DOC, should always be read before installing PGP. This file +contains late-breaking news on what's new in this release of PGP, as +well as information on what's in all the other files included in the +release. + +If you already have an earlier version of PGP, you should rename it +or delete it, to avoid name conflicts with the new PGP. + +For full details on how to install PGP, see the separate PGP +Installation Guide, in the file SETUP.DOC included with this release +package. It fully describes how to set up the PGP directory and your +AUTOEXEC.BAT file and how to use PKUNZIP to install it. We will just +briefly summarize the installation instructions here, in case you are +too impatient to read the more detailed installation manual right now. + +To install PGP on your MSDOS system, you have to copy the compressed +archive PGPxx.ZIP file into a suitable directory on your hard disk +(like C:\PGP), and decompress it with PKUNZIP. For best results, you +should also modify your AUTOEXEC.BAT file, as described elsewhere in +this manual, but you can do that later, after you've played with PGP +a bit and read more of this manual. If you haven't run PGP before, +the first step after installation (and reading this manual) is to +make a pair of keys for yourself by running the PGP key generation +command "pgp -kg". Read the "RSA Key Generation" section of the +manual first. Installing on Unix and VAX/VMS is generally similar to installing on MSDOS, but you may have to compile the source code first. A Unix makefile is provided with the source release for this purpose. -For further details on installation, see the separate PGP -Installation Guide, in the file SETUP.DOC included with this -release. It fully describes how to set up the PGP directory and your -AUTOEXEC.BAT file and how to use PKUNZIP to install it. - How to Use PGP @@ -455,13 +467,41 @@ example is: This searches your secret key ring file "secring.pgp" for any secret key certificates that contain the string "Bob" anywhere in the user -ID field. The search is not case-sensitive. If it finds a matching -secret key, it uses it to sign the plaintext file "letter.txt", -producing a signature file called "letter.pgp". +ID field. Your name is Bob, isn't it? The search is not +case-sensitive. If it finds a matching secret key, it uses it to +sign the plaintext file "letter.txt", producing a signature file +called "letter.pgp". If you leave off the user ID field, the first key on your secret key ring is used as the default secret key for your signature. +PGP attempts to compress the message after signing it. Thus the +signed file will likely be smaller than the original file, which is +useful for archival applications. However, this renders the file +unreadable to the casual human observer, even if the original message +was ordinary ASCII text. It would be nice if you could make a signed +file that was still directly readable to a human. This would be +particularly useful if you want to send a signed message as E-mail. + +For signing E-mail messages, where you most likely do want the result +to be human-readable, it is probably most convenient to use the +CLEARSIG feature, explained later. This allows the signature to be +applied in printable form at the end of the text, and also disables +compression of the text. This means the text is still human-readable +by the recipient even if the recipient doesn't use PGP to check the +signature. This is explained in detail in the section entitled +"CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text", +in the Special Topics volume. If you can't wait to read that section +of the manual, you can see how an E-mail message signed this way +would look, with this example: + + pgp -sta message.txt + +This would create a signed message in file "message.asc", comprised +of the original text, still human-readable, appended with a printable +ASCII signature certificate, ready to send through an E-mail system. +This example assumes that you are using the normal settings for +enabling the CLEARSIG flag in the config file. Signing and then Encrypting @@ -575,10 +615,10 @@ size, type: pgp -kg -PGP shows you a menu of recommended key sizes (casual grade, -commercial grade, or military grade) and prompts you for what size -key you want, up to around a thousand bits. The bigger the key, the -more security you get, but you pay a price in speed. +PGP shows you a menu of recommended key sizes (low commercial grade, +high commercial grade, or "military" grade) and prompts you for what +size key you want, up to more than a thousand bits. The bigger the +key, the more security you get, but you pay a price in speed. It also asks for a user ID, which means your name. It's a good idea to use your full name as your user ID, because then there is less @@ -618,7 +658,8 @@ type. So don't just type repeated seque Note that RSA key generation is a lengthy process. It may take a few seconds for a small key on a fast processor, or quite a few minutes -for a large key on an old IBM PC/XT. +for a large key on an old IBM PC/XT. PGP will visually indicate its +progress during key generation. The generated key pair will be placed on your public and secret key rings. You can later use the -kx command option to extract (copy) @@ -636,11 +677,19 @@ pair. Always keep physical control of y exposing it by storing it on a remote timesharing computer. Keep it on your own personal computer. +If PGP complains about not being able to find the PGP User's Guide on +your computer, and refuses to generate a key pair without it, don't +panic. Just read the explanation of the NOMANUAL parameter in the +section "Setting Configuration Parameters" in the Special Topics +volume of the PGP User's Guide. Adding a Key to Your Key Ring ----------------------------- +Sometimes you will want to add to your keyring a key provided to you +by someone else, in the form of a keyfile. + To add a public or secret key file's contents to your public or secret key ring (note that [brackets] denote an optional field): @@ -654,11 +703,18 @@ different key ring file name, with the e If the key is already on your key ring, PGP will not add it again. All of the keys in the keyfile are added to the keyring, except for -duplicates. If the key being added has attached signatures +duplicates. + +Later in the manual, we will explain the concept of certifying keys +with signatures. If the key being added has attached signatures certifying it, the signatures are added with the key. If the key is already on your key ring, PGP just merges in any new certifying signatures for that key that you don't already have on your key ring. +PGP was originally designed for handling small personal keyrings. If +you want to handle really big keyrings, see the section on "Handling +Large Public Keyrings" in the Special Topics volume. + Removing a Key or User ID from Your Key Ring @@ -717,8 +773,9 @@ if you want to list secret keys. If you key ring file name, you can. The default key ring extension is ".pgp". -To see all the certifying signatures attached to each key, use the --kvv option: +Later in the manual, we will explain the concept of certifying keys +with signatures. To see all the certifying signatures attached to +each key, use the -kvv option: pgp -kvv [userid] [keyring] @@ -811,7 +868,7 @@ for key management. This whole business of protecting public keys from tampering is the single most difficult problem in practical public key applications. -It is the "Achilles heel" of public key cryptography, and a lot of +It is the Achilles' heel of public key cryptography, and a lot of software complexity is tied up in solving this one problem. You should use a public key only after you are sure that it is a good @@ -1142,13 +1199,14 @@ Many electronic mail systems only allow not the 8-bit raw binary data that ciphertext is made of. To get around this problem, PGP supports ASCII radix-64 format for ciphertext messages, similar to the Internet Privacy-Enhanced Mail -(PEM) format. This special format represents binary data by using -only printable ASCII characters, so it is useful for transmitting -binary encrypted data through 7-bit channels or for sending binary -encrypted data as normal E-mail text. This format acts as a form of -"transport armor", protecting it against corruption as it travels -through intersystem gateways on Internet. It also appends a CRC to -detect transmission errors. +(PEM) format, as well as the Internet MIME format. This special +format represents binary data by using only printable ASCII +characters, so it is useful for transmitting binary encrypted data +through 7-bit channels or for sending binary encrypted data as normal +E-mail text. This format acts as a form of "transport armor", +protecting it against corruption as it travels through intersystem +gateways on Internet. PGP also appends a CRC to detect transmission +errors. Radix-64 format converts the plaintext by expanding groups of 3 binary 8-bit bytes into 4 printable ASCII characters, so the file @@ -1162,7 +1220,7 @@ To produce a ciphertext file in ASCII ra pgp -esa message.txt her_userid This example produces a ciphertext file called "message.asc" that -contains data in a PEM-like ASCII radix-64 format. This file can be +contains data in a MIME-like ASCII radix-64 format. This file can be easily uploaded into a text editor through 7-bit channels for transmission as normal E-mail on Internet or any other E-mail network. @@ -1180,8 +1238,8 @@ ciphertext file in binary form. The fin plaintext form, just as it was in the original file "message.txt". Most Internet E-mail facilities prohibit sending messages that are -more than 50000 bytes long. Longer messages must be broken into -smaller chunks that can be mailed separately. If your encrypted +more than 50000 or 65000 bytes long. Longer messages must be broken +into smaller chunks that can be mailed separately. If your encrypted message is very large, and you requested radix-64 format, PGP automatically breaks it up into chunks that are each small enough to send via E-mail. The chunks are put into files named with extensions @@ -1199,18 +1257,28 @@ extracted a key, you may still directly radix-64 format by simply using the -a option alone, without any encryption specified. PGP converts it to a ".asc" file. -If you want to send through an E-mail channel a plaintext file that -is signed but not encrypted, PGP will normally convert it all into -radix-64 armor, rendering it unreadable to the casual human observer. -If the original plaintext message is in text (not binary) form, there -is a way to send it through an E-mail channel in such a way that the -ASCII armor is applied only to the binary signature certificate, but -not to the plaintext message. This makes it possible for the -recipient to read the signed message with human eyes, without the aid -of PGP. Of course, PGP is still needed to actually check the -signature. For further information on this feature, see the -explanation of the CLEARSIG parameter in the section "Setting -Configuration Parameters: CONFIG.TXT" in the Special Topics volume. +If you sign a plaintext file without encrypting it, PGP will normally +compress it after signing it, rendering it unreadable to the casual +human observer. This is a suitable way of storing signed files in +archival applications. But if you want to send the signed message as +E-mail, and the the original plaintext message is in text (not +binary) form, there is a way to send it through an E-mail channel in +such a way that the plaintext does not get compressed, and the ASCII +armor is applied only to the binary signature certificate, but not to +the plaintext message. This makes it possible for the recipient to +read the signed message with human eyes, without the aid of PGP. Of +course, PGP is still needed to actually check the signature. For +further information on this feature, see the explanation of the +CLEARSIG parameter in the section "Setting Configuration Parameters" +in the Special Topics volume. + +Sometimes you may want to send a binary data file through an E-mail +channel without encrypting or signing it with PGP. Some people use +the Unix uuencode utility for that purpose. PGP can also be used for +that purpose, by simply using the -a option alone, and it does a +better job than the uuencode utility. For further details, see the +section on "Using PGP as a Better Uuencode" in the Special Topics +volume. Environmental Variable for Path Name @@ -1219,10 +1287,11 @@ Environmental Variable for Path Name PGP uses several special files for its purposes, such as your standard key ring files "pubring.pgp" and "secring.pgp", the random number seed file "randseed.bin", the PGP configuration file -"config.txt", and the foreign language string translation file -"language.txt". These special files can be kept in any directory, by -setting the environmental variable "PGPPATH" to the desired pathname. -For example, on MSDOS, the shell command: +"config.txt" (or "pgp.ini", or ".pgprc"), and the foreign language +string translation file "language.txt". These special files can be +kept in any directory, by setting the environmental variable +"PGPPATH" to the desired pathname. For example, on MSDOS, the shell +command: SET PGPPATH=C:\PGP @@ -1235,16 +1304,20 @@ files are assumed to be in the current d -Setting Configuration Parameters: CONFIG.TXT --------------------------------------------- +Setting Parameters in the PGP Configuration File +------------------------------------------------ PGP has a number of user-settable parameters that can be defined in a -special configuration text file called "config.txt", in the directory -pointed to by the shell environmental variable PGPPATH. Having a -configuration file enables the user to define various flags and -parameters for PGP without the burden of having to always define +special PGP configuration text file called "config.txt", in the +directory pointed to by the shell environmental variable PGPPATH. +Having a configuration file enables the user to define various flags +and parameters for PGP without the burden of having to always define these parameters in the PGP command line. +In the interest of complying with local operating system file naming +conventions, for Unix systems this configuration file may also be +named ".pgprc", and on MSDOS systems it may also be named "pgp.ini". + With these configuration parameters, for example, you can control where PGP stores its temporary scratch files, or you can select what foreign language PGP will use to display its diagnostics messages and @@ -1316,33 +1389,42 @@ no cryptographic software at all. Perha discover your data has been compromised. Sometimes commercial packages use the Federal Data Encryption -Standard (DES), a good conventional algorithm recommended by the -Government for commercial use (but not for classified information, -oddly enough-- hmmm). There are several "modes of operation" the -DES can use, some of them better than others. The Government -specifically recommends not using the weakest simplest mode for -messages, the Electronic Codebook (ECB) mode. But they do recommend -the stronger and more complex Cipher Feedback (CFB) or Cipher Block -Chaining (CBC) modes. +Standard (DES), a fairly good conventional algorithm recommended by +the Government for commercial use (but not for classified +information, oddly enough-- hmmm). There are several "modes of +operation" the DES can use, some of them better than others. The +Government specifically recommends not using the weakest simplest +mode for messages, the Electronic Codebook (ECB) mode. But they do +recommend the stronger and more complex Cipher Feedback (CFB) or +Cipher Block Chaining (CBC) modes. Unfortunately, most of the commercial encryption packages I've looked at use ECB mode. When I've talked to the authors of a number of these implementations, they say they've never heard of CBC or CFB modes, and didn't know anything about the weaknesses of ECB mode. The very fact that they haven't even learned enough cryptography to -know these elementary concepts is not reassuring. These same -software packages often include a second faster encryption algorithm -that can be used instead of the slower DES. The author of the -package often thinks his proprietary faster algorithm is as secure as -the DES, but after questioning him I usually discover that it's just -a variation of my own brilliant scheme from college days. Or maybe -he won't even reveal how his proprietary encryption scheme works, but -assures me it's a brilliant scheme and I should trust it. I'm sure -he believes that his algorithm is brilliant, but how can I know that -without seeing it? - -In all fairness I must point out that in most cases these products do -not come from companies that specialize in cryptographic technology. +know these elementary concepts is not reassuring. And they sometimes +manage their DES keys in inappropriate or insecure ways. Also, these +same software packages often include a second faster encryption +algorithm that can be used instead of the slower DES. The author of +the package often thinks his proprietary faster algorithm is as +secure as the DES, but after questioning him I usually discover that +it's just a variation of my own brilliant scheme from college days. +Or maybe he won't even reveal how his proprietary encryption scheme +works, but assures me it's a brilliant scheme and I should trust it. +I'm sure he believes that his algorithm is brilliant, but how can I +know that without seeing it? + +In all fairness I must point out that in most cases these terribly +weak products do not come from companies that specialize in +cryptographic technology. + +Even the really good software packages, that use the DES in the +correct modes of operation, still have problems. Standard DES uses a +56-bit key, which is too small by today's standards, and may now be +easily broken by exhaustive key searches on special high-speed +machines. The DES has reached the end of its useful life, and so has +any software package that relies on it. There is a company called AccessData (87 East 600 South, Orem, Utah 84058, phone 1-800-658-5199) that sells a package for $185 that @@ -1374,7 +1456,10 @@ software. And why not? After all, it s so. And their software seems to work okay. Anyone who thinks they have devised an unbreakable encryption scheme -either is an incredibly rare genius or is naive and inexperienced. +either is an incredibly rare genius or is naive and inexperienced. +Unfortunately, I sometimes have to deal with would-be cryptographers +who want to make "improvements" to PGP by adding encryption +algorithms of their own design. I remember a conversation with Brian Snow, a highly placed senior cryptographer with the NSA. He said he would never trust an @@ -1396,7 +1481,7 @@ prevent the initial publication of the R they have squashed essentially all commercial efforts to develop effective secure telephones for the general public. -The principle job of the US Government's National Security Agency is +The principal job of the US Government's National Security Agency is to gather intelligence, principally by covertly tapping into people's private communications (see James Bamford's book, "The Puzzle Palace"). The NSA has amassed considerable skill and resources for @@ -1415,17 +1500,64 @@ secure? It's not that hard for NSA to d that only they can crack, if no one else can review the algorithm. Are they deliberately selling snake oil? +There are three main factors that have undermined the quality of +commercial cryptographic software in the US. The first is the +virtually universal lack of competence of implementors of commercial +encryption software (although this is starting to change since the +publication of PGP). Every software engineer fancies himself a +cryptographer, which has led to the proliferation of really bad +crypto software. The second is the NSA deliberately and +systematically suppressing all the good commercial encryption +technology, by legal intimidation and economic pressure. Part of +this pressure is brought to bear by stringent export controls on +encryption software which, by the economics of software marketing, +has the net effect of suppressing domestic encryption software. The +other principle method of suppression comes from the granting all the +software patents for all the public key encryption algorithms to a +single company, affording a single choke point to suppress the spread +of this technology. The net effect of all this is that before PGP +was published, there was almost no highly secure general purpose +encryption software available in the US. + I'm not as certain about the security of PGP as I once was about my brilliant encryption software from college. If I were, that would be a bad sign. But I'm pretty sure that PGP does not contain any -glaring weaknesses. The crypto algorithms were developed by people -at high levels of civilian cryptographic academia, and have been -individually subject to extensive peer review. Source code is -available to facilitate peer review of PGP and to help dispel the -fears of some users. It's reasonably well researched, and has been -years in the making. And I don't work for the NSA. I hope it -doesn't require too large a "leap of faith" to trust the security of -PGP. +glaring weaknesses (although it may contain bugs). The crypto +algorithms were developed by people at high levels of civilian +cryptographic academia, and have been individually subject to +extensive peer review. Source code is available to facilitate peer +review of PGP and to help dispel the fears of some users. It's +reasonably well researched, and has been years in the making. And I +don't work for the NSA. I hope it doesn't require too large a "leap +of faith" to trust the security of PGP. + + +Notice to Macintosh Users +========================= + +PGP was originally developed for MSDOS and Unix machines. There is +also an Apple Macintosh version of PGP. This manual is written for +the MSDOS/Unix versions of PGP, which use a command-line interface +for all the PGP functions. On the Mac, all the PGP functions are +accessed through pull-down menus and dialog boxes. There is also +on-line help on the Mac for how to use MacPGP, and there should be +some Mac-specific user documentation included in the MacPGP release +package, in addition to this manual. + +Almost all good Mac software applications are written from scratch +for the Mac, not simply ported there from other operating systems. +Unfortunately, the current Mac version of PGP was not designed for +the Mac from scratch. It was ported from the MSDOS/Unix version to +the Mac by Zbigniew Fiedorwicz. Since the MSDOS/Unix version of PGP +was not designed for a GUI (graphical user interface), porting to the +Mac was not an easy task, and many bugs still remain. An all-new +version of PGP is under development, designed for easy adaptation to +a GUI. A new Mac version will be developed from this new PGP source +code. It will be more Mac-like, and more reliable. Despite the bugs +in the current version of MacPGP, it is important to note that if +Zbigniew had waited for this all-new version of PGP to be developed +before he ported PGP to the Mac, the world would have been deprived +of a Mac version of PGP for far too long. PGP Quick Reference @@ -1440,6 +1572,10 @@ To encrypt a plaintext file with the rec To sign a plaintext file with your secret key: pgp -s textfile [-u your_userid] +To sign a plaintext ASCII text file with your secret key, producing a +signed plaintext message suitable for sending via E-mail: + pgp -sta textfile [-u your_userid] + To sign a plaintext file with your secret key, and then encrypt it with the recipient's public key: pgp -es textfile her_userid [-u your_userid] @@ -1550,25 +1686,50 @@ writing to standard output, add the -f o Legal Issues ============ -For detailed information on PGP licensing, distribution, copyrights, -patents, trademarks, liability limitations, and export controls, see -the "Legal Issues" section in the "PGP User's Guide, Volume II: -Special Topics". +For detailed information on PGP(tm) licensing, distribution, +copyrights, patents, trademarks, liability limitations, and export +controls, see the "Legal Issues" section in the "PGP User's Guide, +Volume II: Special Topics". PGP uses a public key algorithm claimed by U.S. patent #4,405,829. -The exclusive rights to this patent are held by a California company -called Public Key Partners, and you may be infringing this patent if -you use PGP in the USA. This is explained in the Volume II manual. +The exclusive licensing rights to this patent are held by a company +called Public Key Partners (PKP), and you may be infringing the +patent if you use PGP in the USA without a license. These issues are +detailed in the Volume II manual, and in the RSAREF license that +comes with the freeware version of PGP. PKP has licensed others to +practice the patent, including a company known as ViaCrypt, in +Phoenix, Arizona. ViaCrypt sells a fully licensed version of PGP. +ViaCrypt may be reached at 602-944-0773. PGP is "guerrilla" freeware, and I don't mind if you distribute it -widely. Just don't ask me to send you a copy. Instead, you can get -it yourself from many BBS systems and a number of Internet FTP sites. +widely. Just don't ask me to send you a copy. Instead, you can look +for it yourself on many BBS systems and a number of Internet FTP +sites. But before you distribute PGP, it is essential that you +understand the U.S. export controls on encryption software. Acknowledgments ================ +Formidable obstacles and powerful forces have been arrayed to stop +PGP. Dedicated people are helping to overcome these obstacles. PGP +has achieved notoriety as "underground software", and bringing PGP +"above ground" as fully licensed freeware has required patience and +persistence. I'd especially like to thank Hal Abelson, Jeff +Schiller, Brian LaMacchia, and Derek Atkins at MIT for their +determined efforts. I'd also like to thank Jim Bruce and David +Litster in the MIT administration and Bob Prior and Terry Ehling at +the MIT Press. And I'd like to thank my entire legal defense team, +whose job is not over yet. I used to tell a lot of lawyer jokes, +before I encountered so many positive examples of lawyers in my legal +defense team, most of whom work pro bono. + +The development of PGP has turned into a remarkable social +phenomenon, whose unique political appeal has inspired the collective +efforts of an ever-growing number of volunteer programmers. Remember +that children's story called "Stone Soup"? + I'd like to thank the following people for their contributions to the creation of Pretty Good Privacy. Although I was the author of PGP version 1.0, major parts of later versions of PGP were implemented by @@ -1577,9 +1738,7 @@ contributors, under my design guidance. Branko Lankester, Hal Finney and Peter Gutmann all contributed a huge amount of time in adding features for PGP 2.0, and ported it to Unix -variants. Hal and Branko made Herculean efforts in implementing my -new key management protocols. Branko has spent more time on it than -any other contributor to PGP. +variants. Hugh Kennedy ported it to VAX/VMS, Lutz Frank ported it to the Atari ST, and Cor Bosman and Colin Plumb ported it to the Commodore Amiga. @@ -1614,19 +1773,15 @@ Various contributions of coding effort a Derek Atkins, and Castor Fu. Other contributions of effort, coding or otherwise, have come from Hugh Miller, Eric Hughes, Tim May, Stephan Neuhaus, and too many others for me to remember right now. -Two Macintosh porting projects have been underway, headed by Zbigniew -Fiedorwicz and Blair Weiss. +Zbigniew Fiedorwicz did the first Macintosh port. Since the release of PGP 2.0, many other programmers have sent in patches and bug fixes and porting adjustments for other computers. There are too many to individually thank here. -The development of PGP has turned into a remarkable social -phenomenon, whose unique political appeal has inspired the collective -efforts of an ever-growing number of volunteer programmers. Remember -that children's story called "Stone Soup"? It is getting harder to -peer through the thick soup to see the stone at the bottom of the pot -that I dropped in to start it all off. +Just as in the "Stone Soup" story, it is getting harder to peer +through the thick soup to see the stone at the bottom of the pot that +I dropped in to start it all off. @@ -1649,6 +1804,7 @@ consulting firm's address is: Boulder Software Engineering 3021 Eleventh Street Boulder, Colorado 80304 USA -Phone 303-541-0140 (voice or FAX) (10:00am - 7:00pm Mountain Time) +Phone: 303-541-0140 (10:00am - 7:00pm Mountain Time) +Fax: arrange by phone Internet: prz@acm.org