home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / pc / crypto / ipgp0202.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  23.6 KB  |  528 lines

  1.  
  2.    Info-PGP: PGP Digest   Wednesday 16 December 1992  Volume 2 : Number 2
  3.                 Hugh Miller, List Manager / Moderator
  4.  
  5.     Info-PGP is a digested mailing list dedicated to discussion of Philip
  6. Zimmermann's `Pretty Good Privacy' (PGP) public-key encryption program for
  7. MS-DOS, Unix, VMS, Atari, Amiga, SPARC, Macintosh, and (hopefully) other
  8. operating systems.  It is primarily intended for users on Internet sites
  9. without access to the `alt.security.pgp' newsgroup.  Most submissions to
  10. alt.security.pgp will be saved to Info-PGP, as well as occasional relevant
  11. articles from sci.crypt or other newsgroups.  Info-PGP will also contain
  12. mailings directed to the list address.
  13.     To SUBSCRIBE to Info-PGP, please send a (polite) note to
  14. info-pgp-request@lucpul.it.luc.edu.  This is not a mailserver; there is a
  15. human being on the other end, and bodiless messages with "Subject:" lines
  16. reading "SUBSCRIBE INFO-PGP" will be ignored until the sender develops
  17. manners.  To SUBMIT material for posting to Info-PGP, please mail to
  18. info-pgp@lucpul.it.luc.edu.  In both cases, PLEASE include your name and
  19. Internet "From:" address.  Submissions will be posted pretty well as received,
  20. although the list maintainer / moderator reserves the right to omit redundant
  21. messages, trim bloated headers & .sigs, and other such minor piffle.  I will
  22. not be able to acknowledge submissions, nor, I regret, will I be able to pass
  23. posts on to alt.security.pgp for those whose sites lack access.
  24.     Due to U.S. export restrictions on cryptographic software, I regret that I
  25. cannot include postings containing actual source code (or compiled binaries)
  26. of same.  For the time being at least I am including patches under the same
  27. ukase.  I regret having to do this, but the law, howbeit unjust, is the law.
  28. If a European reader would like to handle that end of things, perhaps run a
  29. "Info-PGP-Code" digest or somesuch, maybe this little problem could be worked
  30. around.
  31.     I have received a promise of some space on an anonymous-ftp'able Internet
  32. site for back issues of Info-PGP Digest.  Full details as soon as they firm
  33. up.
  34.     Oh, yes: ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; STANDARD
  35. DISCLAIMERS APPLY.
  36.  
  37. Hugh Miller       | Asst. Prof. of Philosophy |  Loyola University Chicago
  38. FAX: 312-508-2292 |    Voice: 312-508-2727    |  hmiller@lucpul.it.luc.edu
  39.  Signed PGP v.2.1 public key certificate available by e-mail & finger(1)
  40.  
  41. =-=-=-=-=-=
  42.  
  43. From: ujacampbe@memstvx1.memst.edu (James Campbell)
  44. Newsgroups: alt.security.pgp
  45. Subject: Re: pgp2.1 signed announcement botched by usenet?
  46. Date: 11 Dec 92 16:06:09 -0600
  47.  
  48. In article <1992Dec10.052939.692@colnet.cmhnet.org>, res@colnet.cmhnet.org 
  49.    (Rob Stampfli) writes:
  50.  
  51. > I missed the official announcement of pgp2.1 which was apparently posted
  52. > here several days ago, but I found a copy of it posted to alt.privacy.
  53. > The message was signed by Phil with the new pgp "+clearsig=on" option.
  54. > Unfortunately, Phil's concern about mailers slightly corrupting the message
  55. > in innocuous ways so that it no longer matches the original, and therefore
  56. > no longer has a valid signature, appears to be borne out by the posting to
  57. > alt.privacy:  All empty lines in that post have one space added to them.
  58. > The signature only checks out when one edits the posted file and ":%s/^ $//".
  59. > BTW, excellent job on the 2.1 release -- a clean compile the first time.
  60. > -- 
  61. > Rob Stampfli  rob@colnet.cmhnet.org      The neat thing about standards:
  62. > 614-864-9377  HAM RADIO: kd8wk@n8jyv.oh  There are so many to choose from.
  63. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  64. > Here's a copy of the actual (bad) message:
  65. > Path: colnet!n8emr!zaphod.mps.ohio-state.edu!malgudi.oar.net!caen!uunet!cs.utexas.edu!wupost!emorys2!memstvx1!ujacampbe
  66. > From: ujacampbe@memstvx1.memst.edu (James Campbell)
  67. > Newsgroups: alt.privacy
  68. > Subject: PGP v. 2.1 Released
  69. > Message-ID: <1992Dec9.013038.4470@memstvx1.memst.edu>
  70. > Date: 9 Dec 92 01:30:38 -0600
  71. > Organization: MSU Cryptosystems
  72. > Lines: 54
  73. >
  74.   [Bad Message Omitted]
  75.  
  76. Sorry, USENET ain't the culprit; Procomm Plus and I were.  Unbeknownst to me
  77. (but knownst to everyone in alt.privacy), Procomm's ASCII Upload feature was
  78. secretly adding an ASCII 32 to each blank line in the post.  It's a big help
  79. when posting to bulletin boards which interpret a blank line as the end of a
  80. post, but a royal pain in the neck when posting signed cleartext messages, I
  81. see.  Please, don't send messages on how to fix it; I know how, but I didn't
  82. think about it before posting.  Sorry, folks.
  83.  
  84.  ===========================================================================
  85.  James Campbell, Math Sciences Department, MSU; ujacampbe@memstvx1.memst.edu
  86.  ---------------------------------------------------------------------------
  87.  
  88. =-=-=-=-=-=
  89.  
  90. From: palmer@icat.larc.nasa.gov (Michael T. Palmer)
  91. Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc,talk.politics.guns
  92. Subject: Re: PGP v. 2.1 Released
  93. Date: 11 Dec 92 17:49:40 GMT
  94.  
  95. cme@ellisun.sw.stratus.com (Carl Ellison) writes:
  96.  
  97. >Sounds like a good reason to switch from PGP to RIPEM.
  98.  
  99. Okay, could you please point us to where we can find a PGP-type program
  100. that uses RIPEM?  I would love to not have to even *consider* patent stuff
  101. when using a crypt program.
  102.  
  103. Ftp sites are preferable!  Thanks.
  104.  
  105. -- 
  106. Michael T. Palmer, M/S 152, NASA Langley Research Center, Hampton, VA 23681
  107. Voice: 804-864-2044,   FAX: 804-864-7793,   Email: m.t.palmer@larc.nasa.gov
  108. PGP 2.0 Public Key now available -- Consider it an envelope for your e-mail
  109.  
  110. =-=-=-=-=-=
  111.  
  112. Newsgroups: alt.security.pgp
  113. From: rlglende@netcom.com (Robert Lewis Glendenning)
  114. Subject: Re: PGP v. 2.1 Released
  115. Date: Fri, 11 Dec 1992 18:41:27 GMT
  116.  
  117. In article <101547@netnews.upenn.edu> yee@mipg.upenn.edu (Conway Yee) writes:
  118. >>Would it be possible to to devise a public key
  119. >>encryption program that would, when used to encrypt a message with
  120. >>someone's private key, emit a series of bytes that would appear to be
  121. >>essentially random?  
  122. >
  123. >If a series of bytes were to be random, no message could possibly be
  124. >encoded within it.  The question, then becomes, is it possible that
  125. >two entirely different encoding schemes would produces bytestreams
  126. >which are statistically indistinguishable from each other.
  127.  
  128. I think this is wrong.  Shannon's Information Theory says that a perfectly
  129. non-redundant message is statistically random.
  130.  
  131. Compression engines remove redundancy.  Scrambling the output (randomly
  132. re-assigning the bytes into another file) produces a pretty good cypher.
  133. Scrambling at the bit level might be better, but the problem of decoding
  134. is of O(n!) complexity where N is the length of the message.  If you add
  135. some random padding, it pushes up n as large as you want.
  136.  
  137. I believe that different compression schemes will produce identical
  138. statistics to the extent that they are "perfect" and to the extent that
  139. the "compression information bytes" are scrambled into the rest of the
  140. compressed information.
  141.  
  142. Lew
  143. -- 
  144. Lew Glendenning         rlglende@netcom.com
  145. "Perspective is worth 80 IQ points."    Nils Bohr (or somebody like that).
  146.  
  147. =-=-=-=-=-=
  148.  
  149. From: speth@cats.ucsc.edu (James Gustave)
  150. Newsgroups: alt.security.pgp
  151. Subject: Re: PGP v. 2.1 Released
  152. Date: 11 Dec 1992 18:48:16 GMT
  153.  
  154. The concern over the PGP tag-lines raises two questions in my mind.
  155.   First, can you distinguish between a PGP file encrypted using RSA and one
  156. encrypted using the plain encryption (IDEA only)?
  157.   Second, how public is IDEA?  Are there copyright or import/export laws
  158. governing its use?
  159.  
  160. As far as I can tell, the two types of encryption look the same to the naked
  161. eye (ie. both have those tag-lines).  If there are no restrictions on IDEA,
  162. then we can all just plead that we are only using the standard encryption
  163. option of PGP, not the RSA stuff.
  164. ________________________________________________________________________________
  165. james speth          finger for pgp 2.0 public-key           speth@cats.ucsc.edu
  166.  
  167. =-=-=-=-=-=
  168.  
  169. Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc,talk.politics.guns
  170. From: uri@watson.ibm.com (Uri Blumenthal,35-016,8621267,)
  171. Subject: Re: PGP v. 2.1 Released
  172. Date: Fri, 11 Dec 1992 20:07:37 GMT
  173.  
  174. From article <1992Dec11.030807.29118@shearson.com>, by pmetzger@snark.shearson.com (Perry E. MetzgerWhy does PGP has those ugly lines "----BEGIN PGP...."
  175. >>and so on? PGP-2.1 is much better than PGP-2.0. Let's
  176. >>make it really good now -  GET RID OF THOSE BETRAYING
  177. >>TAGS! NOW!
  178. > I guess you never read the docs. Those "betraying tags" have a purpose
  179. > -- they allow the system to automatically find the beginning and end
  180. > of messages. 
  181.  
  182. I guess you
  183.         a) are deprived of sense of humor;
  184.         b) have too little experience with real crypto...
  185.  
  186. > You can feed mail messages into PGP without even
  187. > stripping the headers. 
  188.  
  189. Ge, thanks for explaining! And I was sure they are there
  190. just to attract feds' attention... Oh, my...
  191.  
  192. > Its all very well engineered, and the feds can
  193. > tell you are using PGP anyway by looking at the magic numbers in the
  194. > Radix 64 text. 
  195.  
  196. And what sense would a hexadecimal number prepended to an
  197. encrypted (hexadecimal) data make to an eavesdropper?
  198.  
  199. > I don't think there is any point in stripping them,
  200. > since it adds no security for you and will make the program a lot more
  201. > inconvenient to use. 
  202.  
  203. I do, since it can increase security via making it 
  204. "unprovable" that the message is encrypted/created
  205. my PGP. Yes, this will prohibit one from simply
  206. piping the whole message through PGP and 
  207. getting plaintext. Well, it depends
  208. on which concern is bigger - to
  209. have to strip head/tail off
  210. the arriving e-mail,  or
  211. fear to get caught with 
  212. using "guerilla" PGP... (:-)
  213.  
  214. > Its inconvenient enough already....
  215.  
  216. It depends. For me, PGP-2.1 is perfectly convenient and nice.
  217. If only it didn't advertise itself so loudly with "---BEGIN"... (:-)
  218. -- 
  219. Regards,
  220. Uri.            uri@watson.ibm.com
  221. ------------
  222. <Disclaimer>
  223.  
  224. =-=-=-=-=-=
  225.  
  226. Newsgroups: alt.security.pgp
  227. From: uri@watson.ibm.com (Uri Blumenthal,35-016,8621267,)
  228. Subject: Re: PGP v. 2.1 Released
  229. Date: Fri, 11 Dec 1992 20:21:36 GMT
  230.  
  231. From article <1g7ubgINNfb7@transfer.stratus.com>, by cme@ellisun.sw.stratus.com (Carl Ellison):
  232. >>----BEGIN PGP *  along with the usual mundane stuff?  Then go after    
  233. >>people for patent infringement; confiscating burglary tools, a.k.a 
  234. >>citizens' computers.....
  235. > Sounds like a good reason to switch from PGP to RIPEM.
  236.  
  237. A) Since RIPEM doesn't have and [probably] isn't going to have
  238.    key management [other than your favorite text editor :-],
  239.    and since Public Key Servers are far from reality for
  240.    many of us - RIPEM still has too long a way to go
  241.    before it becomes even close to usable. [I'm not
  242.    even starting to talk about other lacks of PEM].
  243.  
  244. B) RSAREF license is a funny thing: Jim Bidzos promised to
  245.    release his new license for RSAREF first Tuesday after
  246.    Thanksgiving (in his personal e-mail to me). Well,
  247.    I don't have to tell you, that several Tuesdays 
  248.    came, but no license arrived (:-). Therefore,
  249.    concerns Mr. Atkins had about modifying
  250.    RSAREF are still valid...
  251.  
  252. > More to the point, someone should publish an interface description for
  253. > PGP so that someone else can write a totally legal program which sends
  254. > and receives in PGP format but uses RSAREF and its individual license.
  255.  
  256. As Mr. Atkins showed, it's not possible, because RSAREF doesn't
  257. have granularity fine enough to do it, and while PKP *draft*
  258. license allows modification, their *legal* *real* one does
  259. not. And the "relaxed" license is "about to be released",
  260. but that about can take forever.
  261.  
  262. On the other hand, I could envision development of PGP turning
  263. the way real "guerilla" software should go - achieving stealth
  264. capabilities (:-).
  265. -- 
  266. Regards,
  267. Uri.            uri@watson.ibm.com
  268. ------------
  269. <Disclaimer>
  270.  
  271. =-=-=-=-=-=
  272.  
  273. From: mathew <mathew@mantis.co.uk>
  274. Newsgroups: alt.security.pgp
  275. Subject: Re: PGP-compatible archiver released
  276. Date: Fri, 11 Dec 92 13:21:56 GMT
  277.  
  278. pgut1@cs.aukuni.ac.nz (Peter Gutmann) writes:
  279. > In <5TXiVB38w165w@mantis.co.uk> mathew <mathew@mantis.co.uk> writes:
  280. > >pgut1@cs.aukuni.ac.nz (Peter Gutmann) writes:
  281. > >>   - Quality Postscript documentation (600K worth)
  282. > >Any chance of making the documentation available in some sort of document
  283. > >format, rather than as a printer dump file?  I mean, how would you like it i
  284. > >I posted this article in HPGL?
  285. > There's a flat ASCII file included with the source code and executables if
  286. > you can't handle Postscript (that's why I put the PS docs in a seperate file 
  287. > not everyone will want them.  You get the ASCII docs by default, and if you
  288. > want better-quality ones you can grab the PS stuff).
  289.  
  290. OK, thanks.  When you said "Quality Postscript documentation" I thought you
  291. meant that it was *only* in Postscript -- I've seen quite a few packages with
  292. ps-only documentation.
  293.  
  294. But can't you provide some nice documentation in some sort of editable and
  295. portable format?  TeX, LaTeX, RTF, ...?
  296.  
  297. mathew
  298. -- 
  299. You can communicate with me securely via PGP 2.1.  For information, send mail
  300. to pgpinfo@mantis.co.uk.  For a big block of keys, mail pgpkeys@mantis.co.uk.
  301. PGP public key fingerprint = B2 41 30 5F 5B 20 B9 D5  7C 8F 75 88 7C DA D8 C5
  302.  
  303. =-=-=-=-=-=
  304.  
  305. Date: Sat, 12 Dec 92 17:52:51 EST
  306. From: gray@antaire.com (Gray Watson)
  307. To: info-pgp@lucpul.it.luc.edu
  308. Subject: Info-PGP licensing...
  309.  
  310. Excuse me if this has been discussed before.  I'm new to the group.
  311.  
  312. So PKP does not want to distribute licenses to PGP.  But PGP is
  313. spreading all around.  PKP is missing an opportunity and we in the
  314. U.S. are missing the use of PGP or are using it illegally.
  315.  
  316. So, question: How much would you pay for a license to use PGP?  $20,
  317. $50, $100, less, more?  Be realistic because no one will give a
  318. license for $5 (and maybe not even for $100).
  319.  
  320. If PGP users settled on a certain amount and then put some money into
  321. a pool to hire a decent legal representative/negotiater, I would be
  322. surprised if PKP was not at least a tiny bit interested.
  323.  
  324. Let's say $50.  I would bet a couple of hundred computer professionals
  325. might be interested in being able to use PGP.  I know that I would.
  326. So PKP gets $10k or so for generating some paperwork maybe more if
  327. people saw legal PGP keys flying around.
  328.  
  329. Anyone know if there are pressures on PKP from the NSA or other
  330. organizations to not generate licenses for PGP?
  331.  
  332. gray
  333.  
  334. =-=-=-=-=-=
  335.  
  336. From: cme@ellisun.sw.stratus.com (Carl Ellison)
  337. Newsgroups: sci.crypt,alt.security.pgp
  338. Subject: PKP/RSA comments on PGP legality
  339. Date: 11 Dec 92 18:16:23 GMT
  340.  
  341. I went to the horse's mouth and asked some folks at PKP & RSA to comment
  342. on PGP legality.  Here's their reply.  I have permission to post it.
  343.  
  344. This was inspired by my original question, to them, whether I could buy
  345. an individual license to permit me to use PGP.  [I have since concluded
  346. that I would like to get a copy of the PGP interface spec so that I could
  347. write a program, using RSAREF, which interoperates with PGP.  I see PGP
  348. as setting a kind of new standard format -- an alternative to PEM.]
  349.  
  350. So -- on to the reply from PKP (much from a lawyer there) and RSA:
  351.  
  352. - - -----------------------------------------------------
  353.  
  354. Risks of using pgp
  355.  
  356. One should be careful about assuming that the documentation in
  357. electronically distributed software is accurate, especially where
  358. law is concerned.  
  359.  
  360. There is much that the documentation for pgp does not tell you about
  361. patent and export law that you should be aware of.  Some of the
  362. statements and interpretations of patent and export law are simply
  363. false. This note will attempt to offer some clarification and accurate
  364. information.
  365.  
  366. pgp seems to be an attempt to mislead netters into joining an
  367. illegal activity that violates patent and export law, letting them
  368. believe that they run no serious risk in doing so.  
  369.  
  370. PATENTS
  371.  
  372. Patent law prohibits anyone from making, using, or selling a device
  373. that practices methods described in a U.S. patent.  pgp admits
  374. practicing methods described in US patent #4,405,829, issued to the
  375. Massachusetts Institute of Technology, and licensed by Public Key
  376. Partners.
  377.  
  378. Those who send signed or encrypted messages, post the pgp program, 
  379. or encourage others to do so are inducing infringement. Under 
  380. patent law, there is no distinction between inducement to infringe and 
  381. direct infringement. You are just as liable.  
  382.  
  383. Being aware of the RSA patent makes infringement willful and
  384. deliberate. Under patent law, a patent holder is entitled to seek
  385. triple damages and legal fees from deliberate infringers.  While the
  386. pgp documentation suggests you that you probably won't get sued, it
  387. doesn't tell you what can happen when patent holders assert their
  388. rights against infringement.
  389.  
  390. Free and legal RSA software is available. RSA Data Security has
  391. released a program, including source code, called RSAREF. This program
  392. is available free to any U.S. person for non-commercial use.
  393. Applications may be built on RSAREF and freely distributed, subject to
  394. export law.  An application that provides email privacy, based on
  395. RSAREF, which uses the RSA and DES algorithms, called RIPEM is an
  396. example. For information, send email to rsaref-info@rsa.com or
  397. rsaref-users@rsa.com.  
  398.  
  399. NOTE: The pgp documentation states that PKP acquired the patent rights
  400. to RSA "... which was developed with your tax dollars..." This is very
  401. misleading.  U.S. tax dollars only partially funded researchers at MIT
  402. who developed RSA. The U.S. government itself received royalty-free
  403. use in return.  This is standard practice whenever the government
  404. provides financial assistance.  The patents on public-key are no
  405. different and were handled no differently than any others developed at
  406. universities with partial government funding. In fact, almost every
  407. patent granted to a major university includes government support,
  408. returns royalty-free rights to the government, and is then licensed
  409. commercially by the universities to private parties.
  410.  
  411. EXPORT LAW
  412.  
  413. pgp leads users to believe that it has circumvented export controls
  414. when it says "...there are no import restrictions on bringing
  415. cryptographic technology into the USA."  You are led to believe that
  416. since you didn't import it, it's legal for you to use it in the US.
  417. The "no import restrictions" claim has been made so many times, many
  418. people probably believe it.
  419.  
  420. One would be well advised not to accept this legal opinion.  While
  421. stated as if it were a well-known fact, the claim that "there are no
  422. import restrictions" is simply false.  Section 123.2 of the ITAR
  423. (International Traffic in Arms Regulations) reads:
  424.  
  425. "123.2 Imports. No defense article may be imported into the United
  426. States unless (a) it was previously exported temporarily under a
  427. license issued by the Office of Munitions Control; or (b) it
  428. constitutes a temporary import/intransit shipment licensed under
  429. Section 123.3; or (c) its import is authorized by the Department of
  430. the Treasury (see 27 CFR parts 47, 178, and 179)."
  431.  
  432. Was pgp illegally exported? Was pgp illegally imported?  Of course.
  433. It didn't export or import itself.  pgp 1 was illegally exported from
  434. the U.S., and pgp 2, based on pgp 1, is illegally imported into the
  435. U.S.  Is a license required? According to the ITAR, it is.  ITAR
  436. Section 125.2, "Exports of unclassified technical data," paragraph (c)
  437. reads:
  438.  
  439. "(c) Disclosures. Unless otherwise expressly exempted in this
  440. subchapter, a license is required for the oral, visual, or documentary
  441. disclosure of technical data...  A license is required regardless of
  442. the manner in which the technical data is transmitted (e.g., in
  443. person, by telephone, correspondence, electronic means, telex, etc.)."
  444.                 
  445. What is "export?" Section 120.10, "Export," begins:
  446.  
  447. "'Export' means, for purposes of this subchapter: ...(c) Sending or
  448. taking technical data outside of the United States in any manner
  449. except that by mere travel outside of the United States by a person
  450. whose technical knowledge includes technical data; or..."
  451.  
  452. Is pgp subject to the ITAR? See Part 121, the Munitions List, in
  453. particular Category XIII, of which paragraph (b) reads, in part,
  454. "...privacy devices, cryptographic devices and software (encoding and
  455. decoding), and components specifically designed or modified
  456. therefore,..."
  457.  
  458. A further definition in 121.8, paragraph (f) reads: "Software 
  459. includes but is not limited to the system functional design, 
  460. logic flow, algorithms, application programs, ..."
  461.  
  462. pgp encourages you to post it on computer bulletin boards.  Anybody
  463. who considers following this advice is taking quite a risk.  When you
  464. make a defense item available on a BBS, you have exported it.
  465.  
  466. pgp's obvious attempts to downplay any risk of violating export law
  467. won't help you a bit if you're ever charged under the ITAR.
  468.  
  469. Penalties under the ITARs are quite serious.  The ITARs were clearly
  470. designed to put teeth into laws that make exporting munitions illegal.
  471. It's unfortunate that cryptography is on the munitions list. But it
  472. is.  pgp is software tainted by serious ITAR violations.
  473.  
  474. These points on patent and export law are straightforward and can
  475. easily be confirmed with legal advice. However, there are other
  476. statements in the pgp documentation that should not go unchallenged.
  477.  
  478. In pgp 2.0, the author says, "I did not steal any software from PKP."
  479. (PKP is the patent holder for the RSA patent.)  Of course not; PKP
  480. doesn't make any software. However, not mentioned is a software
  481. product by RSA Data Security called MailSafe.  This product was first
  482. shipped in July of 1986.  Features such as a digital signatures on the
  483. program itself for verification, internal self-check for virus
  484. detection, compression of plaintext and ASCII recoding of encrypted
  485. binary files, direct and extended trust of public keys through
  486. certification, including the publisher's public key in the
  487. distribution, display of a message digest, security and password
  488. advice, and many others are in MailSafe and are carefully documented
  489. in the user manual.  The authors of pgp have had a copy of MailSafe
  490. and the user manual since 1987.
  491.  
  492. There may be nothing illegal about using ideas from another product,
  493. but there's something dishonest about misleading people into believing 
  494. these ideas were your own in the interest of recruiting "fans."
  495.  
  496. pgp calls itself "public-key for the masses." Even this isn't
  497. original.  The September 12, 1986 issue of the Christian Science
  498. Monitor contains a page one story on cryptography, and discusses
  499. MailSafe. In that story, an RSA spokesman is quoted as saying
  500. "MailSafe is public-key for the masses." Reprints of this story were
  501. widely circulated in RSA press kits, and received by the pgp authors
  502. in 1987.
  503.  
  504. The documentation to pgp would have readers believe that pgp was the
  505. result of a noble desire to save everyone from an evil government
  506. threatening to deny rights to privacy; that users and distributors of
  507. pgp have little or nothing to fear from the patent holders, who, it is
  508. implied, are probably dishonest anyway; and that one shouldn't be
  509. concerned about export controls because pgp beat the system for
  510. everyone by having been developed overseas and imported legally.  The
  511. facts simply don't support these claims.
  512. - - -----------------------------------------------------
  513. -- <<Disclaimer: All opinions expressed are my own, of course.>>
  514. -- Carl Ellison                                         cme@sw.stratus.com
  515. -- Stratus Computer Inc.        M3-2-BKW                TEL: (508)460-2783
  516. -- 55 Fairbanks Boulevard ; Marlborough MA 01752-1298   FAX: (508)624-7488
  517.  
  518. ***** End Info-PGP Digest *****
  519.  
  520.  
  521.