--- pgp/doc/pgpdoc1.txt 2018/04/24 16:42:46 1.1.1.4 +++ pgp/doc/pgpdoc1.txt 2018/04/24 16:44:56 1.1.1.6 @@ -1,4 +1,5 @@ + Phil's Pretty Good Software Presents @@ -11,14 +12,14 @@ -------------------------- - PGP(tm) User's Guide - Volume I: Essential Topics + PGP(tm) User's Guide + Volume I: Essential Topics -------------------------- - by Philip Zimmermann - Revised 22 May 94 + by Philip Zimmermann + Revised 11 October 94 - PGP Version 2.6 - 22 May 94 + PGP Version 2.6.2 - 11 Oct 94 Software by Philip Zimmermann, and many others. @@ -73,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 @@ -247,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 @@ -346,37 +349,43 @@ friend who will then add it to her key r Installing PGP ============== -The MSDOS PGP 2.6 release comes in a compressed archive file called -PGP26.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. +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. -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". +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 @@ -669,9 +678,10 @@ exposing it by storing it on a remote ti 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, read -the explanation of the NOMANUAL parameter in the section "Setting -Configuration Parameters" in the Special Topics volume. +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 @@ -1210,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. @@ -1228,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 @@ -1259,8 +1269,16 @@ the plaintext message. This makes it po 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. +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 @@ -1269,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 @@ -1285,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 @@ -1366,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 @@ -1424,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 @@ -1465,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 @@ -1610,13 +1692,13 @@ controls, see the "Legal Issues" section Volume II: Special Topics". PGP uses a public key algorithm claimed by U.S. patent #4,405,829. -The exclusive licensing rights to this patent are held by a -California company called Public Key Partners, 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. +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 @@ -1691,7 +1773,7 @@ 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. -Zbigniew Fiedorwicz did a Macintosh port. +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.