--- pgp/doc/pgpdoc1.txt 2018/04/24 16:42:46 1.1.1.4 +++ pgp/doc/pgpdoc1.txt 2018/04/24 16:43:58 1.1.1.5 @@ -1,4 +1,6 @@ + + Phil's Pretty Good Software Presents @@ -11,14 +13,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 31 August 94 - PGP Version 2.6 - 22 May 94 + PGP Version 2.6.1 - 30 Aug 94 Software by Philip Zimmermann, and many others. @@ -76,6 +78,7 @@ Advanced Topics Setting Configuration Parameters: CONFIG.TXT Vulnerabilities Beware of Snake Oil +Notice to Macintosh Users PGP Quick Reference Legal Issues Acknowledgments @@ -247,12 +250,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,15 +350,17 @@ 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. @@ -1366,33 +1372,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 +1439,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 +1483,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 @@ -1691,7 +1756,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.