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

  1.  
  2. ─ Area: altsecpgp ────────────────────────────────────────────────────────────
  3.   Msg#: 28                                           Date: 08-08-93  17:26
  4.   From: Laszlo Baranyi                               Read: Yes    Replied: No 
  5.     To: All                                          Mark:                     
  6.   Subj: Hints & Tricks using PGP
  7. ──────────────────────────────────────────────────────────────────────────────
  8. Path:
  9. tatertot!netcomsv!netcom.com!netcomsv!decwrl!olivea!news.bu.edu!bloom-beacon.mi
  10. t.edu!eru.mt.luth.se!kth.se!kth.se!laszlo
  11. From: laszlo@kth.se (Laszlo Baranyi)
  12. Newsgroups: alt.security.pgp
  13. Subject: Hints & Tricks using PGP 1(2)
  14. Message-ID: <1993Aug8.172620.12979@kth.se>
  15. Date: Sun, 8 Aug 1993 17:26:20 GMT
  16. Sender: usenet@kth.se (Usenet)
  17. Reply-To: laszlo@kth.se (Laszlo Baranyi)
  18. Organization: Royal Institute of Technology, Stockholm, Sweden
  19. Lines: 1353
  20. Nntp-Posting-Host: kth.se
  21.  
  22.  
  23. Hello pgp-fans. Here comes my attempt to become a global fool.
  24. These 2 postings are a release of
  25.  
  26.     Hints & Tricks using PGP   (ver. 00) beta
  27.     selected topics from alt.security.pgp
  28.  
  29.  
  30. ---------------------------- cut here -------------------
  31. Suggested archive filename:
  32. MSDOS: HTPGP00    
  33. UNIX : hint_trick_pgp00
  34. wich consists of:
  35. HTPGP00.1 
  36. HTPGP00.2 
  37. --
  38.  
  39.         Hints & Tricks using PGP   (ver. 00) beta
  40.         selected topics from alt.security.pgp
  41.  
  42.     
  43.     6 Aug -93   laszlo@instrlab.kth.se
  44.  
  45. Content
  46.  
  47.     Part 1 (2) (this file)
  48.     
  49. 10.    Introduction
  50.  
  51.         Keymanegment
  52. 11.    I forgot the passphrase to my keyring. Is that bad ?
  53. 12.    My secret keyring has been copied. Is that bad ?
  54. 13.    How much effort is required to find out my passphrase ?
  55. 14.    Can i create a sparekey, IF i should forgot my passphrase ?
  56. 15.    (dis)advantages with several keys and key sizes.
  57. 16.    What is the speed / key size ratio ?
  58. 17.    Why on earth should i encrypt files to myself ?
  59. 18.    Why do some people sign their own keys ?
  60. 19.    Some ways to get your key signed. (remotly)
  61.  
  62.         Key servers
  63. 20.    Can i avoid to be added to the public key servers ?
  64. 21.    Where are those key servers ?
  65. 22.    What can be known about me from the key servers ?
  66. 23.    Can my BBS act like a key server ? 
  67. 24.    Statistics about all the keys.
  68.  
  69.         Procedures
  70. 30.    How to verify your PGP version.
  71. 31.    My signature looks so dull. Can i fix that ?
  72. 32.    Signed archive against virus.
  73. 33.    Voting with PGP.
  74. 34.    I have changed e-mail address, how can i let the world know ?
  75. 35.    How do i make a BIG distribution list ?
  76. 36.    Using non-English characters between MAC, PC, AMIGA, UNIX.
  77. 37.    How do i set up a RAM-drive, and why ? (MSDOS)
  78. 38.    Can i hide PGP on my PC ? (MSDOS)
  79. 39.    How to override the randomnumbers. (randseed.bin) 
  80.  
  81.         Unsorted
  82. 40.    Can the Public Key concept be explained without any math ?
  83. 42.    What is a rubber house attack ?
  84. 43.    How safe is "for your eyes only" ?
  85. 44.    What can a wiretapper find out about a message ?
  86. 45.    Where should problems be reported ?
  87. 46.    A list of non-bugs
  88. 47.    What's a proper PGP-add. ?
  89.  
  90.  
  91.     Part 2 (2) (next file)
  92.  
  93.         Files/programs
  94. 50.    Existing utilities.     
  95. 51.    patches, and utilities in pipeline
  96. 52.    Where are the latest version ?
  97. 53.    Which is the minimum files needed ?
  98. 54.    Where are the language files ?
  99. 59.    ftp-able additional readings.
  100.  
  101.      Yet unanswered questions
  102. Anything official about what comes in next version ? "curious"
  103. Where can i read old postings from alt.security.pgp ?
  104. Does it exists a place where all utility's are stored ?
  105. How can i activate this "kill file" thing ?
  106. Whats that "regexp" on the keyservers ? 
  107.  
  108. 10) Introduction. 
  109.  
  110. This started as a collection of note's on topics from 
  111. alt.security.pgp. An easier way to find information than 
  112. storing and searching in backlogs. Also, new readers don't
  113. have any backlog, so goodies are lost into the digital grave.
  114. If i have misunderstood some topic, or if you have some 
  115. additional information, just let me know, so we can improve 
  116. the quality in the next version. 
  117. Sneakpreviews has been sent out, all answers are not yet in, but
  118. if we should wait for a perfect version, then it wont ever get out.
  119. So, instead, find all errors, and those answer the questions that
  120. are un the text, and we will by time get something 
  121. with quality.    Any topics that should be added/removed ?
  122.  
  123. The doc's for PGP is still the bible. This is just
  124. additional comments, or rephrased questions about what's 
  125. already answered in the doc's.
  126. There is more text in pipeline, but first i wanted to check 
  127. if this is interesting at all. 
  128. English is not my primary language, so corrections on phrasing
  129. is also wanted.
  130. And:
  131. to let you weight the information in a correct way:
  132. i have no formal education on cryptography,
  133. is not part of the PGP development team, 
  134. and thus have no inside information. 
  135. Just yet another PGP-fan.
  136. So off to work we go.
  137. --
  138.  
  139.             Keymanegment
  140.             
  141. 11) I forgot my password to my keyring. Is that bad ?
  142.  
  143. Yes. Check PGPDOC1.DOC, "What If You Lose Your Secret Key?"
  144. for details.
  145.  
  146. Actions:
  147.  
  148. * Destroy copies of your old secret keyring (secring.pgp)
  149.   Thus avoid a massive password attack on it. 
  150.  
  151. * Create a new keypair.
  152.  
  153. * Now, here comes the catch 22.
  154.   How can you convince the rest of the world that you
  155.   no longer are yourself ?
  156.   Why should they believe you ?
  157.   Are you trying to take over anothers identity ?
  158.  
  159.       Some attempts to get around.
  160.   You need a bunch of friends to sign your new key. Their total
  161.   trustworthiness should preferably be higher than your own
  162.   single trustworthiness. (the majority wins)
  163.   If your old key was signed, then preferably it should be the 
  164.   same persons who sign's your new key. 
  165.   Or try this.
  166.   Send them (encrypted with your new key) parts of your earlier
  167.   conversation. Things that could not have been collected by a
  168.   wiretapper. If your net friend believes that you store information
  169.   in decrypted form, then this wont work, since someone could have
  170.   taken a copy of your harddisk.
  171.  
  172.   check "Some ways to get your key signed. (remotly)" for more ideas.
  173.  
  174. * On your new key, maybe you even can use the field which is 
  175.   normally used for your alias, by adding a short notice there instead.
  176.   Like "KeyID: 123abcxyz is invalid from <date>
  177.   or   "Disable KeyID: 123abcxyz"
  178.  
  179. * Publish the new key and a signed statement that your old key
  180.   is no longer valid. Also send it to everybody you have
  181.   correspondence with and tell them to disable your key. 
  182.   Note; The key should be disabled, (pgp -kd) not removed. 
  183.   A removed key will most probably come back again from some 
  184.   other sources that has not received your message.
  185.   and/or 
  186.   publish your statement in some news group where you are active.
  187.   Your correspondent can assume that if nobody complains, then
  188.   maybe you really are yourself. It might be a good idea to not accept
  189.   such a key immediately. The real owner could be on vacation.
  190.   
  191. * Upload the new key to the key server.
  192.  
  193. Currently there is nothing that automatically invalidates
  194. a key by the time, so your old key will stay disabled on a lot
  195. of key rings, or float around as a useless piece of data.
  196. You might even receive messages encrypted with your old key, 
  197. which you naturally cant read. 
  198.  
  199. --
  200. 12) My secret keyring has been copied. Is that bad ?
  201.  
  202. The secret keyring is stored in encrypted form and is 
  203. only useful together with your passphrase. If you have 
  204. a lousy passphrase, start swetting now.
  205. However, the secret keyring is 1/2 of your protection.
  206. And that is now lost. The passphrase is the other half.  
  207. To regain full protection, Issue a "Key Compromise Certificate"
  208. Check PGPDOC1.DOC section; "How to protect Secret keys from
  209. Disclosure" for details.
  210.  
  211. If you want to make your revoked key real fancy.
  212. Before you revoke your old key, you add a message
  213. in the alias field wich says "new keyID: 123abc from <date>"
  214. Then whenever somone sees your revoked key, he thus have
  215. a convenient pointer of what the new key is.
  216.  
  217. --
  218. 13) How much effort is required to find out my passphrase ?
  219.  
  220. That depends on if you have selected a good passphrase.
  221. The list below is from the manual to PKZIP, ver 2.04g.
  222. section; "Using Data Encryption"
  223.  
  224. "All forms of encryption, including the one used by PKZIP, are open to "brute
  225. force" attacks.  This form of attack is simply the trying of many passwords
  226. until you find one that works.
  227.  
  228. In order to help you protect your data from this sort of attack we present
  229. figures on how long a brute force attack, using a computer, would take.  The
  230. scenario we present here assumes that your encrypted .ZIP file is being
  231. assaulted by a program which is designed specifically to do this.
  232.  
  233. An encryption key may contain any valid ASCII character, not just A-Z in upper
  234. and lower case and punctuation marks.  However, most people will just use the
  235. latter.  The following table is indexed by the complexity of the password.
  236. Across the top is the range of characters used.  The simplest assumes that 
  237. only lower case letters from a to z were used.  
  238. The next column assumes that all printable characters were used
  239. (a to z in upper and lower case, punctuation, brackets, etc.).  The last
  240. column assumes a password containing the complete range of ASCII characters.
  241.  
  242. The vertical index is the length of the password used.  This impacts the
  243. strength of the password greatly.  Think of it as a combination lock.  A
  244. combination lock with only two numbers would be much easier to break than one
  245. with three or four numbers.
  246.  
  247. We recommend that if you need a truly secure encrypted file, use an encryption
  248. key of at least six characters.
  249.  
  250. The last assumption made is about the speed of the attacking program.  For the
  251. purposes of this table, we assume that 10,000 possible keys are being
  252. attempted per second.
  253.  
  254.  
  255.                 Password "Hacking" Time
  256. --------------------------------------------------------------
  257. |  Key   | 26 characters | 96 characters |   256 characters   |
  258. | Length |    (a-z)      | (a-z,A-Z,etc) |    (All ASCII)     |
  259. ---------------------------------------------------------------
  260. |    3   | 2 seconds     | 1 minute      |  27 minutes        |
  261. ---------------------------------------------------------------
  262. |    4   | 1 minute      | 2.35 hours    |  4 days            |
  263. ---------------------------------------------------------------
  264. |    5   | 19 minutes    | 9 days        |  3 years           |
  265. ---------------------------------------------------------------
  266. |    6   | 8.6 hours     | 2 years       |  891 years         |
  267. ---------------------------------------------------------------
  268. |    7   | 9 days        | 238 years     |  2283 centuries    |
  269. ---------------------------------------------------------------
  270. |    8   | 241 days      | 228 centuries |  584,546 cent.     |
  271. ---------------------------------------------------------------
  272. |    9   | 17 years      | 21,945 cent.  |  149,643,989 cent. |
  273. ---------------------------------------------------------------
  274. |   10   | 447 years     | 2,106,744     |  38,308,861,211    |
  275. |        |               |  centuries    |   centuries        |
  276. ---------------------------------------------------------------
  277.  
  278.  
  279. Choose the complexity that you feel meets your needs, but keep in mind all
  280. that has been mentioned about losing and forgetting passwords.
  281.  
  282. These figures represent the state of technology today.  PKWARE Inc. cannot
  283. predict future technologies which may allow faster attempts at decryption of a
  284. .ZIP file.
  285.  
  286. Note that the above figures do not include the time needed to actually try all
  287. valid passwords.  This would increase the time by several hundred percent,
  288. dependent upon the length of the file. "
  289.  
  290. [I don't understand PKZIP's phrase:
  291. "...above figures do not include the time needed to actually try all
  292. valid passwords." Isn't a brute force attack meant to try all
  293. combinations ?]
  294.   
  295. Note the different advises you get for your passphrase;
  296. PKZIP has a big sign saying:
  297. "DO NOT TRUST YOUR MEMORY ALONE.  WRITE IT DOWN."
  298. And PGPDOC2.DOC, section "Compromised Pass Phase and Secret Key"
  299. Says that a written down passphrase is probably the simplest
  300. attack. Do also check PGPDOC1, section;
  301. "How to Protect Secret Keys from Disclosure" 
  302.   
  303. --
  304. 14) Can i create a sparekey, IF i should forgot my passphrase ?
  305.  
  306. Yes. Create an extra keypair, where you user name is reversed 
  307. (or something similar, umique for you). 
  308. So if your name is say, Joe Public, then use Public Joe 
  309. as your userID on that spare key.
  310. Let your normal userID; Joe Public, certify that
  311. Public Joe really exists. Store the spare key at some safe place.
  312. Maybe encrypt it and send it to a god friend.
  313. If you forgot the passphrase to your normal key,
  314. then contact your friend to get the spare key. Hopefully
  315. you have not forgot that passphrase too. Now you can
  316. continue as usual. You can also now create yet another spare
  317. key. Just in case ...
  318.  
  319. The key size of your sparekey should preferably not be shorter
  320. than your ordinary key. Check section; "(dis)advantages with
  321. several keys." about how the shortest key can become the weakest
  322. link.
  323.  
  324. For an example on this method, check Zimmermans both keys
  325. with the commands 
  326. pgp -kc prz@acm
  327. pgp -kc prz@sage
  328.  
  329. An edited output will show you this.
  330.     
  331.     Key ring: 'pubring.pgp', looking for user ID "prz@acm".
  332. Type bits/keyID   Date       User ID
  333. pub  1024/A966DD 1993/05/21  Philip R. Zimmermann <prz@acm.org>
  334. searching key ring file 'pubring.pgp' for keyID 67F70B
  335. sig!      67F70B 1993/05/21    Philip R. Zimmermann <prz@sage.cgd.ucar.edu>
  336.  
  337.     Key ring: 'pubring.pgp', looking for user ID "prz@sage".
  338. pub  1024/67F70B 1992/07/22  Philip R. Zimmermann <prz@sage.cgd.ucar.edu>
  339.  
  340.  
  341. An interpretation of this means that Zimmerman has used his 
  342. good old key,  <prz@sage.cgd.ucar.edu>
  343. to certify this newer one,  <prz@acm.org>
  344.  
  345. And what if i lose the spare key ?
  346. Then you could convince everybody (with a signed statement) 
  347. from your ordinary key, that the sparekey should be disabled.
  348.  
  349. If the sparekey is not used, then don't register it on the key 
  350. servers. It just adds unneccecary confusion, like mail encrypted
  351. to your sparekey.
  352.  
  353. [Is there any advantage to not let the two keys certify
  354. each other ?]
  355.  
  356. --
  357. 15)  (dis)advantages with several keys and key sizes.
  358.  
  359. Besides of being guarded against a lost passphrase, 
  360. here is a more farfetched application.
  361.  
  362. If you are in an unexpected situation where your signature
  363. is needed, but you have your keypair at home.
  364. Then create a new keypair and sign that urgent thing with it.
  365. When you get home, certify your newly created keypair with
  366. your ordinary key, and upload the certified new keypair
  367. to the key servers.
  368.  
  369. One disadvantage by playing with to many keypair's, is the
  370. need to remember even more pass phrases. 
  371.  
  372. But if you have several keys with different sizes,
  373. there are more aspects to think of.
  374.  
  375. If a short key, sign's a statement where the owners 
  376. longer key should be disabled, should we trust that 
  377. shorter key ? 
  378. or rephrased:
  379. If it becomes accepted, that keys could ask for 
  380. (your) other key to be disabled, then the shortest key 
  381. is a weak link.
  382.  
  383. Signing postings to discussion meetings, could have
  384. a shorter, faster, and less secure key, than the one you 
  385. use to encrypt private mail with. The shorter key might 
  386. even be on the owners UNIX account. The owner could have
  387. made this trade off between security/convenience.
  388. Since you don't know this, his convenience becomes your
  389. insecurity.
  390.  
  391. People who wants to send you a private mail will probably
  392. use that shorter key. But if they knew that you had a
  393. longer key, they might have preferred to use that one.
  394.  
  395. You could also expect some irritation from your correspondents.
  396. They must keep track of which of your say, 5, keys that should 
  397. be used in what situation. You could give them a hint
  398. by using the alias field for messages. Like:
  399.     userID: Joe Public
  400.         alias:  This one is for Usenet postings 
  401.         alias:  get <keyID> for private mail.
  402. --
  403. 16) What is the speed / key size ratio ?
  404.  
  405.  > Newsgroups: alt.security.pgp
  406.  > From: res@colnet.cmhnet.org (Rob Stampfli)
  407.  > Subject: Re: Shorter keys and faster encryption
  408.  > Date: Tue, 13 Jul 1993 04:29:18 GMT
  409.  > ...
  410.  >> What is the difference (ratio) in encryption time (roughly) 
  411.  >> between, say, a 384 byte and 1024 byte key. 2x, 4x, 1000x?
  412.  >
  413.  > Doubling the number of bits in the key theoretically doubles 
  414.  > the time it takes to perform the RSA step in the encryption
  415.  > process or verification of signature.  It quadruples the RSA
  416.  > decryption time, and the time it takes to sign a file.  It 
  417.  > increases by a factor of 8 the time it takes to generate a key.
  418.  
  419. and another answer.
  420.  
  421.  > From: seggers@semyam.dinoco.de (Stefan Eggers)
  422.  > Date: 13 Jul 93 18:09:56 +0200
  423.  > Subject: Re: Shorter keys and faster encryption
  424.  > Newsgroups: alt.security.pgp
  425.  > ...
  426.  > I tried it on my Amiga 500 (68000, 7 MHz).
  427.  >
  428.  > 384 bits  15 seconds
  429.  > 512 bits  25 seconds
  430.  > 768 bits  60 seconds
  431.  >
  432.  > These  results  are  for  a short text (I may have used 
  433.  > different text when I tried it with 768 bits) and are not exact.
  434.  >
  435.  > I  didn't  try it with 1024 bits because the key generations 
  436.  > takes far too much time and this key would be unusable for me.
  437.  
  438. Are there more benchmarks out there ?
  439.  
  440. And now comes a sidestep to "strange keysizes" that can be seen in
  441. "Statistics about all the keys."
  442.  
  443.  >> Where did the keys less than 384 bits come from? PGP2.3 won't even
  444.  >> create these; maybe an earlier version would.
  445.  >
  446.  > Change  the  limits in the source and recompile.  Then you should be
  447.  > able to create keys with 256 bits and 1240 bits.
  448.  >
  449.  > seggers@semyam.dinoco.de
  450.  
  451.  
  452. --
  453. 17) Why on earth should i encrypt files to myself ?
  454.  
  455. To protect against a situation where your harddisk has been 
  456. stolen/copied. If you store all your outgoing mail and
  457. replies in plain text, It should not be to hard to figure 
  458. out the subjects of your incoming mail.
  459.  
  460. It also good for administrative purposes to keep an identical
  461. copy of messages that has been sent. 
  462.  
  463. To always encrypt a copy of outgoing mail and replies to yourself,
  464. check PGPDOC2.DOC, section;  
  465. "Encrypting a Message to Multiple Recipients"
  466.  
  467. The most convenient way is to append these lines in your CONFIG.TXT:
  468.  
  469. # Make every encrypted message also readable by sender.
  470. EncryptToSelf=ON
  471. # An undocumented feature. (In ver 2.3A)
  472.  
  473. --
  474. 18)  Why do some people sign their own keys ?
  475.  
  476. There was a bug in ver. 2.1, which made it possible for someone
  477. else to change your userID, and spread a false key. By signing 
  478. your own key, the userID was "locked" . It's now fixed. But the
  479. signatures are still around and keeps new users wondering. 
  480.  
  481. 19)    Some ways to get your key signed. (remotly)
  482.  
  483. The best is to find a friend. But in this networld, the
  484. friends are more often at the other end of a long cable. 
  485. We dont even know how they look like.
  486.  
  487. Ask the keyserver for PGP users that might live near you
  488. and ask for a meeting. They are easiest to find if your e-mail
  489. address ends with a .country. Or if you live near a Univerity,
  490. search for <univerity>.edu.  Check "Statistics about all the keys."
  491. and you will se that the chances to find a pgp user nearby
  492. are good.
  493.    
  494. Exchange a symbolic amount of money through a bank. Then both 
  495. netter's trusts the bank to really check the identity of the
  496. receiver. In advance, you have both exchanged your accountnumber
  497. in a signed messages. Archive that signed message. If there 
  498. later is any doubt about the real identity, you at least
  499. have a theoretical chanse to ask the bank who the owner is to
  500. that account.
  501.  
  502. The notarie method.
  503. You want your key signed by your netfriend. He checks in the
  504. phone book for a notarius publicus in your city, and selects
  505. one on random. You go there with a printout of your key's 
  506. fingerprint. (pgp -kvc your_name > outfile)
  507. You identify yourself, notaire verifies that your name is
  508. the same on the printout, and your identificationpapers.
  509. You handsign your printout, wich he verifies against your
  510. identification papers.
  511. He puts on a big oldfashion timestamp, and signs it.
  512. Send these handsigned papers to your netfriends who now
  513. can sign your key.
  514.  
  515. While you are at the office, why not have him stamp a 
  516. few more papers. You maybe even can trade the expense
  517. for an explanation of how that fingerprint can be locked
  518. to your identity. 
  519.  
  520. In PGPDOC2.DOC, "Verifying a Public Key Over the Phone" 
  521. there are details on how to do if your net friends recognises
  522. your voice. But why is this method is limited to voice 
  523. recognition ? 
  524. Could we not ask the phone company or the phonebook about
  525. the owners name and address, and then just send a snail
  526. to that address ? If he can repeat the content in the mail,
  527. then he has physical acsess to the address and phone. 
  528.  
  529.  
  530.         Key servers
  531. --
  532. 20)  Can i avoid to be added to the public key servers ?
  533.  
  534. Technically. No. You cant prevent someone to add your public 
  535. key there.  Instead, if you don't want your public key to become
  536. "public"  tell your net friends to keep it tight. 
  537.  
  538. --
  539. 21)  Where are those key servers ?
  540.  
  541. To get more info, send an empty mail with the word
  542. HELP in the subject line to any of these sites.
  543.  
  544. PGP Public Key servers  which allow one to exchange public
  545. keys running through the Internet and UUCP mail systems.
  546.  
  547. As of 15-Jun-93, these sites are running this system:
  548.  
  549. Internet connected sites:
  550.         pgp-public-keys@pgp.iastate.edu
  551.         pgp-public-keys@toxicwaste.mit.edu
  552.         pgp-public-keys@phil.utmb.edu
  553.         pgp-public-keys@demon.co.uk
  554.         pgp-public-keys@cs.tamu.edu
  555.         pgp-public-keys@chao.sw.oz.au
  556.  
  557.  
  558. UUCP connected site:
  559.         pgp-public-keys@jpunix.com
  560.         pgp-public-keys@proxima.alt.za
  561.  
  562. --
  563. 22) What can be known about me from the key servers ?
  564.  
  565.  - The date when you started using PGP.
  566.  - If you are currently using PGP. (by fingering your .plan)
  567.  
  568.    Assumptions about who trusts who, like:
  569.  - Which your friends are. If your key is signed, it's 
  570.    probably done by your friends.
  571.  - The hierarchy within a group by checking who is signing
  572.    who's key. (psychologists has made this to an art)
  573.  - How the hierarchy changes, by repeatedly checking
  574.    if you have got any additional signatures.
  575.  - If a group is isolated, or if there are signature links
  576.    to other groups.
  577.  - The growing rate of a group, by checking the date of when
  578.    the members created their keys.
  579.  - The geographical spreading of the group by the email addresses.
  580.  
  581. What happened to those cypherpunk signing sessions in England ?
  582. A neutral trusted person, who signs keys, would remove 
  583. most of the assumptions above.
  584. --
  585.  
  586. 23)    Can my BBS act like a key server ? 
  587.  
  588. You might choose not to do so, after this reading.
  589.  
  590. The source code from the real key servers are free, but it's
  591. written in pearl, and uses UNIX shells. A BBS is usually 
  592. using MSDOS, so you must rewrite the code.
  593.  
  594. Having independent, standalone, key servers would remove
  595. the big benefits with them. Namely ONE big keyring which
  596. always is up to date, and mirrored at several ftp-sites. For 
  597. that, your BBS should also be fully connected to Internet, 
  598. and be included in their mirroring scheme for the frequently
  599. exchange of keys.  That's more coding work.
  600. Now you now longer have a BBS, you are an ftp-site.
  601. That sounds expensive.
  602.  
  603. And finally; There seems to be work going on in PGP's 
  604. keymanegment which might change the way keymanegment 
  605. are handled. There maybe is some clever way after all to make
  606. the BBS environment be able to also use something like key servers.
  607.  
  608. So; The cheapest and easiest way for now is to have a connection 
  609. from one BBS in your network, as a link to the existing key servers. 
  610.  
  611. --
  612. 24)    Statistics about all the keys.
  613.  
  614. The question about how many pgp users there is comes and goes.
  615. These figures below dont answers;
  616. How many keys are abandomed ?
  617. How many keys are used, but not registered ?
  618. How big is the use outside internet ? on BBS:es ?
  619.  
  620. Just an example. In Stockholms BBS:world there is a discussion
  621. meeting on, TCL-net, echotag: TCL_KRYPTO,
  622. There are a handful of keys and voices. But 14 BBS:es are 
  623. receiving it, just listening. So there is an interest from the
  624. silent mass, but it's impossible to measure it.
  625.  
  626.  
  627. "
  628. From: mikeingl@news.delphi.com (MIKEINGLE@DELPHI.COM)
  629. Subject: Server stats, signature bug?
  630. Date: 4 Aug 1993 05:27:57 -0400
  631. ...
  632.  
  633. Key server statistics as of 8/2/93
  634.  
  635. Total public keys: 1582
  636. Total signatures:  1962
  637. Total revocations:   48
  638. ...
  639. Common domains:   
  640.  
  641.     Name   # keys      Name   # keys     Name    # keys
  642.     .edu      455      .gov       20      .ch         7
  643.     .com      332      .net       16      .il         5
  644.     .uk       105      .se        15      .fr         3
  645.     .org       97      .su        15      .bitnet     3
  646.     .de        54      .it        14      .mil        3
  647.     .au        39      .dk        11      .at         3
  648.     .ca        34      .no        10      .br         2
  649.     .fi        32      .za         9      .pl         2
  650.     .nl        31      .lv         9
  651.     .us        23      .uucp       8
  652.  
  653. Signatures:   
  654.  
  655. Although some keys have numerous signatures, over half of all keys
  656. are still unsigned.
  657.  
  658.       # sigs   # keys            # sigs   # keys
  659.            0      855                12        5
  660.            1      353                13        4
  661.            2      148                14        2
  662.            3       77                15        1
  663.            4       48                16        1
  664.            5       26                17        2
  665.            6       27                19        1
  666.            7        6                20        2
  667.            8        6                30        1
  668.            9        7                32        1
  669.           10        5                36        1
  670.           11        3
  671.  
  672. Key sizes:   
  673.  
  674. Most users have stuck with the default sizes, especially the 1024-
  675. bit key. There are some odd sizes as well. Why are 510 and 1022
  676. bits so popular? Is there some particular advantage to these?
  677. Where did the keys less than 384 bits come from? PGP2.3 won't even
  678. create these; maybe an earlier version would.
  679.  
  680.      Size    #    Size    #   Size    #   Size    #
  681.       376    1     510   50    777    1   1022   77
  682.       379    3     512  408    800    1   1023    9
  683.       380    1     524    1    896    1   1024  858
  684.       381    1     600    4    959    1   1026    1
  685.       382    6     640    1    997    2   1029    1
  686.       384   72     666    1    998    1   1032    1
  687.       500    1     700    4    999    1   1035    1
  688.       504    1     709    1   1016    1   1048    1
  689.       505    6     716    1   1017    4   1116    1
  690.       506    4     750    1   1018    1   1119    1
  691.       507    4     756    1   1019    7   1136    2
  692.       508    4     766    1   1020   11   1250    1
  693.       509    1     768    8   1021    9
  694.  
  695. "
  696. --
  697.  
  698.         Procedures
  699.  
  700. 30)    How to verify your PGP version.
  701.  
  702. type  
  703. pgp keys.asc            (appends a sample of keys to your keyring.)
  704. pgp keys.asc pgp.exe    (verifies pgp.exe itself)
  705.  
  706. The archives itself is also protected by a signature so you can 
  707. be sure you have got the real one. 
  708.  
  709. They are in a file named; pgp23sigA.asc.  Here it is. 
  710. --
  711. Here are the byte sizes and signatures on the PGP distribution files:
  712.  
  713.  221332 pgp23A.zip
  714. -----BEGIN PGP MESSAGE-----
  715. Version: 2.3a
  716.  
  717. iQBgAgUALDamv8o9of2GWqfzAQGvxwJY1JGKdQjcPSjV1CUU1AxcMvVwzKcVO4QO
  718. vxHL0839qW/P+Sj2YmRot4bsh48PbmW2KsUJ72L7mIu/i6GiLCYaNM00yXRWwjkI
  719. uocX
  720. =tHOr
  721. -----END PGP MESSAGE-----
  722.  
  723.  547178 pgp23srcA.zip
  724. -----BEGIN PGP MESSAGE-----
  725. Version: 2.3a
  726.  
  727. iQBgAgUALDanLco9of2GWqfzAQFhWwJXYF+1/vgA7kAEwWNKaLnAhFmAHgM9RDpf
  728. nJXOJCYD7zhHHegS4hMSro/E5fcshcPNmrpZSOpbooa7pV+Q7Dql6EXb4heweplf
  729. nWYL
  730. =n6A2
  731. -----END PGP MESSAGE-----
  732.  
  733.  680985 pgp23A.tar.Z
  734. -----BEGIN PGP MESSAGE-----
  735. Version: 2.3a
  736.  
  737. iQBgAgUALDanZco9of2GWqfzAQEjBAJYuwyfs8rauWOmxuEJ8uXCk5SExkp1aQpN
  738. Onby3PCZ0z4KXw82D3EDk1yKc37BRb5soz/7iGYzWkHMAI3tcHq9HxnW0bkXJyEY
  739. 28eK
  740. =JlB2
  741. -----END PGP MESSAGE-----
  742.  
  743.   88070 pgp23docA.zip
  744. -----BEGIN PGP MESSAGE-----
  745. Version: 2.3a
  746.  
  747. iQBgAgUALDangso9of2GWqfzAQHrsQJYq4HWvuenOBJ0PpVd3CnwdvtHo4H7EVvF
  748. CqLNk//TIB+mkGQMgN8i8RuPwcDQ75dBFMPYLzslnBy4ECNITngLzxyNqp0/4jqo
  749. lKJg
  750. =euMl
  751. -----END PGP MESSAGE-----
  752.  
  753.  
  754. If you want verify even more, you will se that there is a signature
  755. link that goes like this.
  756.  
  757. Colin Plumb (colin@nyx.cs.du.edu)     (who signed the archives)
  758. is certified by 
  759. <prz@acm.org>                (Zimmermans new key)
  760. wich in turn is certified by
  761. <prz@sage.cgd.ucar.edu>            (Zimmermans old key)
  762. This last key exists on every keyring since ver 2.0. so just
  763. get an older version and check if it matches.
  764. (I don't remember any conversion utility between ver 1.0 -> 2.0)
  765. We end up with that it is the same Zimmerman through all versions.
  766.  
  767. If this sounds complicated, then just imagine the math behind.
  768.  
  769.  
  770. Info about how to verify the MAC-source code.
  771. Do also check for an additional file which should contain the
  772. signature for the MAC-version.
  773.  
  774.  > Newsgroups: alt.security.pgp,sci.crypt,comp.sys.mac.apps
  775.  > From: grady@netcom.com (Grady Ward)
  776.  > Subject: Re: MacPGP2.3 source available
  777.  > Date: Tue, 20 Jul 1993 14:13:09 GMT
  778.  >
  779.  > Remember that if do *not* use PGP to verify the digital
  780.  > signature for the BinHexed file, you will need to globally
  781.  > change all occurrences of '- -' (hyphen space hyphen) to
  782.  > simply '-' (hyphen) when the - - occurs at the beginning
  783.  > of a line.
  784.  > 
  785.  > Otherwise you will be unable to de-BinHex the source.
  786.  > -- 
  787.  > grady@netcom.com  Moby lexicons  voice/fax (707) 826-7715 
  788.  
  789.        
  790. -- 
  791. 31)    My signature looks so dull. Can i fix that ?
  792.  
  793. The signature below, with the initials in it, belongs to 
  794. edgar@spectrx.saigon.com (Edgar W. Swank) On a question
  795. of how he did, here's his method.
  796.  
  797.  > The strange "Version" in my post is because I recompiled PGP and
  798.  > I wanted to differentiate that version from any published version.
  799.  > I had only wanted to affect the initial console message, but Version
  800.  > is a global variable and affects armored file output as well.
  801.  > 
  802.  > You can add any text you like (except -----END PGP ...?) after
  803.  > BEGIN PGP SIGNATURE (either before or after Version) and before
  804.  > the blank line.  Try it. You can also enter any text you want after
  805.  > the END PGP SIGNATURE line.
  806.  
  807. Would a personal touch on the signature interfere with
  808. other PGP-utilities ? 
  809.  
  810. -----BEGIN PGP SIGNATURE-----
  811. Version: 2.3a.1/EWS
  812.  
  813. iQCVAgUBLEkCet4nNf3ah8DHAQE53AP/ecGsGp09rX1y1CqcMI02utJ4hdcRTCTk
  814. tUYOnyCIo4drPEZQ7oPaR0XN+IaU9mSTDouO6z3PszuVj+AZVlBum6GTNw5wFaZu
  815. K38pLHTUyTIJc/nxf2mhXo1Xv3gU1eWvhgnpxI8qrih8N8xZimE0vKWHL26SIWOS
  816. uRJl0FwSQtw=
  817. =M37F
  818. -----END PGP SIGNATURE-----
  819.  
  820. 32) Signed archive against virus.
  821.  
  822.   Suggestion to ftp-site's and BBS:es.
  823.   They already have routines that scans uploaded archives
  824.   for any virus.  If it's clean, then that
  825.   archive is placed in some public area for download.
  826.   If PGP is involved in this routines, then whenever
  827.   a trusted site has verified that the archive is good, then
  828.   why not also sign it ? I do. I have BAT-files that puts my
  829.   signature into an extra ZIP-file which goes into the archive. 
  830.  
  831.   + No renaming of the original filename.
  832.   + If the unpacker don't care about verifying, he just unpacks
  833.     as usual.
  834.   + No need to get files from trusted sources, instead check that
  835.     the signature belong to a trusted site. It's like buying a 
  836.     Coke in a dark bar at some unknown place in some forgotten
  837.     country. If the can is closed, you know that you have got the 
  838.     original. No need to trust the bartender, the owner, or the country.
  839.   + No need to keep separate files with signatures for archive files.
  840.     Each archive contains it's own signature.
  841.   + several signatures can be added to the same archive.
  842.   + A permanent protection against whatever virus that might
  843.     come. No quarterly update costs for any virus checker.
  844.   + If the archive still contains any virus, then you know who
  845.     to hang, and maybe it's even possible to trace the virus
  846.     source from PGP's time stamp. 
  847.   - The included BAT-files and readme, steals about 7 KB.
  848.   - The unpacker must have PGP, and the public key from the signer.
  849.  
  850.   Send me a mail for those BAT-files. Needs to be rewritten to
  851.   C, for increased smartness.
  852.  
  853.  
  854. 33) Voting with PGP.
  855.  
  856. scheme 1
  857. Everybody send in their signed and encrypted vote to the vote counter.
  858. This is the simplest scheme, where security is replaced by total
  859. trust on the vote counter. Trust him to not cheat or reveal the 
  860. votes. 
  861.  
  862. scheme 2
  863.  
  864.  > Newsgroups: alt.security.pgp
  865.  > From: jln2@cec2.wustl.edu (Sammy D.)
  866.  > Subject: Re: can pgp vote ?
  867.  > Date: Mon, 12 Jul 1993 21:26:42 GMT
  868.  >
  869.  >> How about secret voting? How can anonymousity be guaranteed
  870.  >> in electronic voting procedures based on Public Key 
  871.  >> Cryptography ?
  872.  >
  873.  > You would, I think, need a trusted third party.  Said party 
  874.  > is the Auditor, because they provide auditability of the results.
  875.  > Organization desiring a vote (called Counter), generates a list
  876.  > of disposable, one-shot, RSA secret and public keys.  Counter 
  877.  > sends list of voters and (quasi-)public keys to auditor, who 
  878.  > shuffles and sends one key to each voter.  Voter sends response 
  879.  > signed with (quasi-)public key back to Counter via Auditor, who 
  880.  > ensures message is untraceable. Counter can decrypt the messages 
  881.  > and ensure one-to-one correspondence with original list of keys.
  882.  >
  883.  > Before completion of the election, no one other than Voter, 
  884.  > Auditor and Counter must know values of any keys, public or 
  885.  > secret.  After election, all keys and votes may be disclosed 
  886.  > to audit the count.
  887.  >
  888.  > Note that everyone signs everything that passes through their
  889.  > hands, except that Voters don't sign votes with their own 
  890.  > personal keys, only with the one-shots.  Any RSA-type notary 
  891.  > can provide the auditing function.
  892.  
  893.  
  894. The vote you send in should preferably be a digit,
  895. so the length of the encrypted vote can't be used to
  896. guess your selection. Like this:
  897.  
  898. BLANK    ASC       506  contains: "this is a blank vote"
  899. BLUE     ASC       486  contains: "blue"
  900.  
  901. 34) I have changed e-mail address, how can i let the world know ?
  902.  
  903. Also useful of you want to add a change to your 
  904. userID from say, miss lonely, to Mrs married 
  905.  
  906. Lets you change your netaddress without loosing your
  907. correspondents, since the key servers (which you feed with your
  908. updated netaddress)  probably have a longer lifetime than your
  909. current netaddress.
  910. or rephrased.
  911. The key servers are the phone book, and with your keyID, everybody 
  912. can ask for your current e-mail address.
  913.  
  914. Add you new e-mail address as an alias, and yet another alias
  915. which says that the old address should be ignored.
  916. Upload your new key to the key servers.
  917.  
  918. By each change, your public key will grow bigger and bigger. 
  919. If the size becomes a problem, then create a new keypair, and
  920. certify it with your old keypair.  On your old key, add 2 final
  921. alias message saying: "get the shorter <keyID> instead"
  922. and "disable this one"
  923.  
  924. Now you start distributing your new key, and are still able to
  925. receive mail encrypted to your old key, from those who haven't
  926. received your new key. By time, your old key will be less and 
  927. less used. However, as mentioned, try in the longest to avoid
  928. several keys.
  929.  
  930. Do also check the related question:
  931. "What's a proper PGP-add. ?"
  932. --
  933. 35)  How do i make a BIG distribution list ?
  934.  
  935. Ah ... You are running a successful newspaper, and
  936. your subscribers don't fit into the command line.
  937.  
  938. try this.
  939. pgp -seat <filename> 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 \
  940. 0x9 0xa 0xb 0xc 0xd 0xe 0xf
  941.  
  942. This will encrypt to everybody in your public key.
  943. Use different public key ring's according the status
  944. of the subscribers. Like VIP's, normal, and sneak readers.
  945. And make sure the sneak reader don't tamper with your key rings 
  946. so he gets the VIP-issue. (you know, some people would do
  947. anything to save money)
  948.  
  949. details in PGPDOC2:DOC section; "selecting keys via Key ID"
  950.  
  951. If you just want to send a short christmas greeting to all your
  952. subscribers, then the recipients list will become bigger then the
  953. message alone. To reduce that overhead, just do the encryption
  954. in several parts. like this.  
  955. pgp -seat <filename> 0x0 0x1 0x2 0x3 0x4 0x5 
  956. pgp -seat <filename> 0x6 0x70 0x8 0x9 0xa
  957. pgp -seat <filename> 0xb 0xc 0xd 0xe 0xf
  958.  
  959. --
  960. 36)    Using non-English characters between MAC, PC, AMIGA, UNIX.
  961.  
  962. Translationtables between different environments.  
  963.  
  964. Details in PGPDOC2.DOC, sections;
  965. "Sending ASCII Text Files Across Different Machine Environments"
  966. "TEXTMODE - Assuming Plain text is a text file"
  967. "CHARSET - Specifies Local Character set for Text Files"
  968.  
  969. For proper CR/LF handling, the sender must specify 
  970. the -t flag in his command line,   or
  971. in CONFIG.TXT, place the line 'TEXTMODE = on'
  972.  
  973. ISO 8859-1 = latin1 = the canonical text which is used by PGP.
  974. This is also the standard for AMIGA and MS Windows.
  975.  
  976.       A table showing the decimal codes in some character sets for
  977.      some common characters in the larger Scandinavian languages.
  978.   +----------------+---------------+-------+-----------------------+
  979.   |                | IBM Code page | Apple | ISO Standard          |
  980.   | Character      |   437     850 | Mac   | 8859-1  646-SE 646-SE2|
  981.   +----------------+-------+-------+-------+-------+-------+-------+
  982.   | Left quote  << |   256 |   256 |   307 |   253 |   --- |   --- |
  983.   | Right quote >> |   257 |   257 |   310 |   273 |   --- |   --- |
  984.   | Paragraph   PI |   --- |   364 |   246 |   266 |   --- |   --- |
  985.   | Section     SE |   --- |   365 |   244 |   247 |   --- |   --- |
  986.   | A-acute     A' |   --- |   265 |   347 |   301 |   --- |   --- |
  987.   | a-acute     a' |   240 |   240 |   207 |   341 |   --- |   --- |
  988.   | A-dieresis  A: |   216 |   216 |   200 |   304 |   133 |   133 |
  989.   | a-dieresis  a: |   204 |   204 |   212 |   344 |   173 |   173 |
  990.   | A-grave     A! |   --- |   267 |   313 |   300 |   --- |   --- |
  991.   | a-grave     a! |   205 |   205 |   210 |   340 |   --- |   --- |
  992.   | AE          AE |   222 |   222 |   256 |   306 |   --- |   --- |
  993.   | ae          ae |   221 |   221 |   276 |   346 |   --- |   --- |
  994.   | A-ring      AA |   217 |   217 |   201 |   305 |   135 |   135 |
  995.   | a-ring      aa |   206 |   206 |   214 |   345 |   175 |   175 |
  996.   | E-acute     E' |   220 |   220 |   203 |   311 |   --- |   100 |
  997.   | e-acute     e' |   202 |   202 |   216 |   351 |   --- |   140 |
  998.   | Eth         -D |   --- |   321 |   --- |   320 |   --- |   --- |
  999.   | eth         -d |   --- |   320 |   --- |   360 |   --- |   --- |
  1000.   | O-dieresis  O: |   231 |   231 |   205 |   326 |   134 |   134 |
  1001.   | o-dieresis  o: |   224 |   224 |   232 |   366 |   174 |   174 |
  1002.   | O-slash     O/ |   --- |   235 |   257 |   330 |   --- |   --- |
  1003.   | o-slash     o/ |   --- |   233 |   277 |   370 |   --- |   --- |
  1004.   | Thorn       TH |   --- |   347 |   --- |   336 |   --- |   --- |
  1005.   | thorn       th |   --- |   350 |   --- |   376 |   --- |   --- |
  1006.   | U-dieresis  U: |   232 |   232 |   206 |   334 |   --- |   136 |
  1007.   | u-dieresis  u: |   201 |   201 |   237 |   374 |   --- |   176 |
  1008.   +----------------+-------+-------+-------+-------+-------+-------+
  1009.  
  1010. These "larger Scandinavian languages" also have a 7-bit
  1011. code set. This is the same as ASCII, with some replacements.
  1012. It is typically used by Unix.
  1013.  
  1014. A-dieresis  A:      [
  1015. a-dieresis  a:      {
  1016. A-ring      AA      ]
  1017. a-ring      aa      }
  1018. O-dieresis  O:      \
  1019. o-dieresis  o:      |
  1020.  
  1021. A last minute addition, wich seems to found the problem.
  1022.  > From: seggers@semyam.dinoco.de (Stefan Eggers)
  1023.  > Date: 6 Aug 93 22:07:59 +0200
  1024.  > Subject: Re: non-English characters
  1025.  >...
  1026.  >> How can non-English characters be used between MAC, PC, 
  1027.  >> AMIGA, UNIX. ? (that nasty 8-bit)
  1028.  >...
  1029.  > I  made  some  experiments  with CHARSET and CLEARSIG and discovered
  1030.  > that I can not set CHARSET on the command line.
  1031.  >
  1032.  >> ... Who has succeeded to send an 
  1033.  >> nonenglish text from PC -> MAC ? Which where the settings ?
  1034.  >
  1035.  > 1st I  signed a text with CHARSET=latin1 and CLEARSIG=on with an
  1036.  >   umlaut. (umlaut is, i guess, an AMIGA /laszlo)
  1037.  >
  1038.  > 2nd I changed (in the signed text) the code the umlaut has in latin1
  1039.  >    to the code it has in codepage 850.
  1040.  >
  1041.  > 3rd I changed CHARSET in config.txt (see above).
  1042.  >    (to codepage 850 ? /laszlo)
  1043.  >
  1044.  > 4th The signature was OK.  :-)
  1045.  >
  1046.  > I  did  not experiment with CLEARSIG=off but I expect that this will
  1047.  > work  as  expected.   Just try what I did with CLEARSIG=off and see
  1048.  > what codes PGP gives back in step 4.
  1049.  > seggers@semyam.dinoco.de
  1050.  
  1051. So. Whith a translationprogram between the different charactertables,
  1052. it should be possible to verify a signed plaintext, no matter where
  1053. it was created. Dig into your harddisk and send me your findings.
  1054.  
  1055. 37)    How do i set up a RAM-drive, and why ? (MSDOS)
  1056.  
  1057. copied from the doc's in PGPSHE22 
  1058.  
  1059. The RAM Drive
  1060. ~~~~~~~~~~~~~
  1061.  
  1062. Some people have grown up on Windows' smart drive and DOS Shells and have 
  1063. forgotten what oldish things like RAM drives are all about.  In issues 
  1064. such as privacy however, a RAM drive is an extra safety net to insure that 
  1065. your secret key is not compromised in any way.  Here's how to set one up.
  1066. Insert this line into your CONFIG.SYS file:
  1067.  
  1068.                 DEVICE=C:\DOS\RAMDRIVE.SYS 1024 /e
  1069.  
  1070. If you have a 386 or better computer, you could type "DEVICEhigh" instead
  1071. of DEVICE to load the RAMDRIVE.SYS driver into high memory, but its only
  1072. about 6K so its not crucial.  The 1024 block of memory (1 meg) is the size 
  1073. of your RAM drive, and the switch "e" (/e) means you wish to use "extended" 
  1074. memory for your virtual drive. 
  1075.  
  1076. Reboot your computer for these changes to take effect.  Your RAM drive
  1077. will be given the next letter after your physical hard drive, i.e., if
  1078. you have a single hard drive "C:" like most people, the RAM drive will
  1079. be called "D".  Type "cd d:" at the DOS prompt and you are in your RAM
  1080. drive.   
  1081.  
  1082. The advantage of creating and using a RAM drive for PGP is that the RAM
  1083. drive "D" is not physical, but located only in memory.  That way when
  1084. you shut down your computer, PGP disappears with it, and any trace of
  1085. your secret key as well.  Advanced PGP users keep the critical PGP
  1086. files (CONFIG.TXT, PGP.EXE, PUBRING.PGP, SECRING.PGP, etc.) on a floppy
  1087. that they carry around with them and only use PGP in their virtual RAM
  1088. drives.  When you want to enter a PGP session, just put the floppy in,
  1089. and type "copy a:*.* d:" and your PGP files will be in the RAM drive.
  1090.  
  1091. You can do this and still keep a copy of PGPShell in a C:\PGPSHELL directory 
  1092. to use PGP.  Before starting a PGP session, just type "set pgppath=d:" at 
  1093. the DOS prompt, (or insert this command in your AUTOEXEC.BAT file if you use 
  1094. PGP often) to tell DOS that you've put PGP in a RAM drive.  PGPShell will 
  1095. look at the DOS environment and see that PGP is located in the D: drive, 
  1096. and work on everything in there.  
  1097.  
  1098. Don't worry about loading PGPShell into your RAM drive; PGPShell itself is
  1099. harmless and contains nothing that would compromise your secret key ring.
  1100.  
  1101. Don't forget to copy the contents of the RAM drive back onto your floppy
  1102. after exiting PGPShell, especially if you've added to, deleted or otherwise
  1103. modified your keys.  Once you shut off your computer anything located
  1104. in RAM memory will be gone with it!
  1105.  
  1106. Consult those old dusty DOS manuals for more information on creating
  1107. and using RAM drives.
  1108.  
  1109.  
  1110. 38)    Can i hide PGP on my PC ? (MSDOS)
  1111.  
  1112. copied from the doc's in PGPSHE22
  1113.  
  1114. "The Hidden Directory
  1115.  ~~~~~~~~~~~~~~~~~~~~
  1116.  
  1117. The hidden directory is the oldest trick in the book (and many a bane 
  1118. to system admins trying to clean up directory trees).  Although far from 
  1119. foolproof, the hidden directory will slow down nosy co-workers who may 
  1120. be snooping on your computer while you're at lunch.  
  1121.  
  1122. Let's say you're not paranoid enough to warrant the use of a RAM drive 
  1123. but you still don't want anyone knowing you use PGP.  Here's the next  
  1124. best thing:
  1125.  
  1126. Go into a mundane directory tree like \DOS or \WINDOWS\SYSTEMS where 
  1127. no one ever looks and create a subdir called something harmless like 
  1128. "SYS" or "BIN".  Copy all of your PGP stuff into that directory 
  1129. (let's say C:\DOS\BIN for example.)  Then get back out to C:\DOS and 
  1130. type:  "ATTRIB +H BIN" from the DOS prompt.  Using the DOS "Attribute" 
  1131. command, you've hidden (+H) the BIN subdirectory from view.  Its still 
  1132. there, but someone would have to know what they were doing to find it.
  1133. (If you want to see it type "ATTRIB BIN" from the DOS prompt.)
  1134.  
  1135. When you want to use PGP, just type "set pgppath=c:\dos\bin" at a DOS
  1136. prompt and you're set.  Here's a good batch file to use (which you 
  1137. can hide as well) that can be located anywhere along the DOS path:
  1138.  
  1139.                         @echo off
  1140.                         set pgppath=c:\dos\bin
  1141.                         cd \pgpshell
  1142.                         pgpshell
  1143.  
  1144. Call the batch file something dumb like "READ_DIR.BAT" or hide it by
  1145. using ATTRIB like this:  ATTRIB +H READ_DIR.BAT so that the pgppath
  1146. statement is not compromised easily.  Whenever you want to use PGP
  1147. just type READ_DIR and everything will load for you.
  1148.  
  1149. This isn't 100%, as I stated before, but its good enough to fool most
  1150. people since they won't mess around with something that they don't 
  1151. even know is there.  If people or police are specifically looking for 
  1152. PGP or encrypted messages on your system, then you're screwed anyway; 
  1153. call a lawyer."
  1154.  
  1155. end of extracted part from the doc's to PGPSHE22.
  1156.  
  1157. An extra naming trick that works IF the co-worker dont load
  1158. Norton Comander.
  1159. Call the subdirectory; BIN <alt-255> wich will append a 
  1160. non-visible character at the end of BIN.
  1161. If he dont know about that invisible character, he wont get in.
  1162. You must also add that in-visible character in you BAT-file.
  1163.  
  1164.  
  1165. 39)    How to override the randomnumbers. (randseed.bin)
  1166.  
  1167. copied from the doc's in PGPSHE22
  1168.  
  1169. "The Paranoid Encryptor
  1170. ~~~~~~~~~~~~~~~~~~~~~~
  1171.  
  1172. This one is courtesy of the handful of paranoid people that warned me to
  1173. be careful because, as a result of PGPShell "they" will be out to get me. 
  1174.  
  1175. Nevertheless, there may be occasions when the enemy is very real, and you 
  1176. cannot afford to have your encrypted messages cracked by those naughty 
  1177. NSA Cray computers.  One way in which a computer is able to crack your 
  1178. message is by applying a consistent mathematical algorithm (a brute force 
  1179. attack) against your message until a pattern emerges that spells out words.  
  1180. Your RANDSEED.BIN 24-byte file (Random Seed Binary) is where PGP draws its
  1181. material from when it comes time to encrypt your message.  A computer is  
  1182. not able to generate truly random acts on its own, thats why PGP needed you
  1183. to monkey-type at random when you first created your personal keys.
  1184.  
  1185. If PGP can't find a RANDSEED.BIN file, it will create a seed file
  1186. "on the fly" and ask you to bang away on your keyboard just before 
  1187. encrypting.  By inserting a line at the end of the above READ_DIR batch 
  1188. file like this:  "del c:\dos\bin\randseed.bin", you'll create a new seed 
  1189. file each time you use PGP.  This will blow any pattern that could possibly 
  1190. develop over time (during which the attacker is amassing your encrypted 
  1191. messages and studying each of them for patterns).  PGP's own RANDSEED.BIN  
  1192. file does a good job of providing enough material for encryption, but 
  1193. this option is still a "safety net" of sorts for the truly paranoid."
  1194.  
  1195. Now, lets see what's in the bible; PGPDOC2.DOC section;
  1196. "Random Numbers"
  1197.  
  1198. "This random seed file should be at least slightly protected from
  1199. disclosure, to reduce the risk of an attacker deriving your next or
  1200. previous session keys. "                                    ^^^^
  1201. ^^^^^^^^ 
  1202. Does this not mean, that if i start and end every session by
  1203. encrypting a useless file, then any links to next, or previous
  1204. randomnumber is broken ? Would that not be a more convenient 
  1205. way ? Having a BAT-file doing this, there is no need to play
  1206. piano on the keyboard.
  1207.  
  1208. More from same section.
  1209. "If you feel uneasy about trusting any algorithmically derived random
  1210. number source however strong, keep in mind that you already trust the
  1211. strength of the same conventional cipher to protect your messages. 
  1212. If it's strong enough for that, then it should be strong enough to
  1213. use as a source of random numbers for temporary session keys."
  1214.  
  1215. Comments are welcome on this issue, since it comes and goes.
  1216. I for myself, will instead try to get someone to sign my key. 
  1217. THAT is a weaker point.
  1218.  
  1219.         Unsorted
  1220.  
  1221. 40) Can the Public Key concept be explained without any math ?   
  1222.   
  1223. Imagine a ordinary mailbox. People put in their mail in the top,
  1224. and the postman has a special key that opens the bottom of the mailbox.
  1225. Only the postman has this key.
  1226.  
  1227. If everybody now had a private mailbox, with a big sign telling
  1228. who the owner is, then still anyone could drop any mail into it,
  1229. and be sure that only the owner can read it. Because only the real
  1230. owner have the private key which open the bottom of the mailbox.
  1231.  
  1232. So, the label on your own mailbox is your public key, and
  1233. your private key is the key which you use to open the bottom of the
  1234. mailbox.
  1235.  
  1236. This analogy don't explain how digital signatures works, but it
  1237. is mainly the same thing but reversed. 
  1238. [does someone have a similar simple analogy for digital signatures ?]
  1239. --
  1240.  
  1241. 41) currently empty.
  1242.  
  1243. 42) What is a rubber house attack ?
  1244.  
  1245. The question might sound stupid, but is for us who don't have
  1246. English as our native language.
  1247. (this explanation came from a friend who eats detective stories,
  1248. is it correct ?)
  1249. A rubber house are those plastic/rubber tubes that are used to watering
  1250. a garden. I your are beaten with a piece of such tube, on the soft parts
  1251. of your body, it will create internal bleedings, but a minimum
  1252. of marks that can be seen.
  1253. Only heroes in films/books can withstand such an attack.
  1254. All we rest will probably sing whatever passphrase we are asked for.
  1255.  
  1256. This is the cheapest and fastest way to read your correspondence
  1257. There was a discussion about how to guard against this. 
  1258. I guess it ends up on something like; an arrangement in advance
  1259. which makes whatever you know, useless information.
  1260. Could somebody summarise that scheme ?
  1261. Is "Rubber house attack" a formal phrase ? That is; does it exists
  1262. in the index in books ? 
  1263.  
  1264. --
  1265. 43)  How safe is "for your eyes only" ?
  1266.  
  1267. No safety at all. There are a lot of utilities that could
  1268. grab that screen text, but it is convenient. No need to remember
  1269. to cleanup. (did'nt PGP created temporary files where it also
  1270. could be grabbed ?)
  1271.  
  1272. --
  1273. 44) What can a wiretapper find out about a message ?
  1274.  
  1275. Nothing more than what could be expected from a 
  1276. normal traficanalyze. But let's go trough it.
  1277. By adding the line; verbose = 2 In CONFIG.TXT he will get
  1278. these details:
  1279.  
  1280. - Who the recipient(s) keyID is. He already knows the recipients
  1281.   networkaddress from the mail packet itself.
  1282. - The time stamp of when the message was encrypted. This is usually
  1283.   close to the time stamp in the mail packet itself. 
  1284.   If you believe that the time stamp of encryption gives away
  1285.   any clues, then just randomly change the computer clock
  1286.   to an earlier date, before encryption, and keep the real
  1287.   date inside the message.
  1288.   This might on the other hand confuse utilities that rely
  1289.   on the encryption time stamp. (is there any such utility ?)
  1290. - He can se if the message is conventionally encrypted,
  1291.   or if a recipient is selected. Signed text is meant
  1292.   to be seen, so that's no secret.
  1293. - If you are asked to resend a message, maybe because it was corrupted,
  1294.   You could re encrypt it first, to not gave away a hint of that it is
  1295.   a re transmission. (don't ask me what conclusions that can be drawn from 
  1296.   the knowledge of a re transmission. but why give hints if it can be
  1297.   easily avoided)
  1298.  
  1299.            Assumptions of:
  1300. - The number of characters used in the text. To make a message 
  1301.   appear bigger than it is, append random data at the end.
  1302. - How you administrate your correspondence. If one of the keyID's
  1303.   always is yourself, he can assume that you keep an encrypted 
  1304.   backlog of your outgoing mail.
  1305.   If your keyID is NOT one of the recipients, He might assume
  1306.   that you store information in plain text, or rely on our memory.
  1307.   High volume users will probably not rely on memory.
  1308.  
  1309. --
  1310. 45) Where should problems be reported ?
  1311.  
  1312. For MSDOS related problems, send a mail to
  1313. edgar@spectrx.saigon.com (Edgar W. Swank) 
  1314.  
  1315. for MAC:
  1316.  > From: grady@netcom.com (Grady Ward)
  1317.  > Subject: MacPGP2.3 source available
  1318.  > Date: Tue, 20 Jul 1993 00:50:44 GMT
  1319.  > ...
  1320.  > The authors of this port prefer to remain anonymous.
  1321.  > Questions and comments are welcome concerning this source;
  1322.  > please direct them to alt.security.pgp [preferred], sci.crypt,
  1323.  > or comp.sys.mac.apps.
  1324.  > ...
  1325.  
  1326. For Unix-related problems, mail Colin Plumb (colin@nyx.cs.du.edu) 
  1327.  
  1328. and of course, the net, could give advices.
  1329.  
  1330. I falled into this trap recently.
  1331. Just downloaded a new version, used the old trusted version to verify
  1332. the new one, and the verification failed. I pulled the alarm bell
  1333. hard. Just to later find out that i have mixed files from the old
  1334. version into the new one. That is mr big bug. Hopefully i am forgiven.
  1335.  
  1336. --
  1337. 46) A list of non-bugs 
  1338.  
  1339. * I can remove my private key without even beeing prompted for
  1340.   a passphrase.   Then anyone could remove my private key.
  1341.  
  1342.   Yes. a simplier way is to erase your private keyring (secring.pgp)
  1343.   So therefore it's no point to protect against such key removal.
  1344.   Maybe one could add some warning message for those who don't
  1345.   have a backup against accidental removal.
  1346.  
  1347. --
  1348. 47) What's a proper PGP-add. ?
  1349.  
  1350. [any better phrase for those oneliner's that use to be in 
  1351. the .sig-file ?]
  1352.  
  1353. One suggestion is this style.
  1354.  
  1355. 32C539/90 DA 9E 3E C0 AA 59 B2  46 3B 73 81 5B 7B 83 1B
  1356.  
  1357. That one-liner says everything.
  1358.  + The first Hex-part tells what unique keyID your 
  1359.    correspondents should ask for on the key servers. 
  1360.  + The second longer part is the key fingerprint. An even 
  1361.    stronger check, In case you somehow gets a wrong 
  1362.    public key with the same keyID.
  1363.  
  1364. [there was a calculation about the statistical chance to get
  1365. 2 keyID's wich where same. Could it be reposted ?]
  1366.  
  1367. If you have several keys with different sizes, add a one-liner 
  1368. for each of them too. Also add the keysize at the beginning,
  1369. so people can select the keysize they wish to use.
  1370.  
  1371.  Do also check the related question:
  1372.  "I have changed e-mail address, how can i let the world know ?"
  1373. --
  1374. end of part1 (2)
  1375.  
  1376.  
  1377.  Part 2 (2)
  1378.  
  1379.   Hints & Tricks using PGP 
  1380.         selected topics from alt.security.pgp
  1381.  
  1382.         Files/programs
  1383.  
  1384. 50.    Existing utilities.     
  1385. 51.    patches, and utilities in pipeline
  1386. 52.    Where are the latest version ?
  1387. 53.    Which is the minimum files needed ?
  1388. 54.    Where are the language files ?
  1389. 59.    ftp-able additional readings.
  1390.  
  1391.         Yet unanswered questions
  1392. Anything official about what comes in next version ? "curious"
  1393. Where can i read old postings from alt.security.pgp ?
  1394. Does it exists a place where all utility's are stored ?
  1395. How can i activate this "kill file" thing ?
  1396.  
  1397.  
  1398.             Files/Programs
  1399.  
  1400. 50)    Existing utilities.      
  1401.     
  1402. This section will hopefully grow to contain a list of 
  1403. every utility that has been written. Could authors of 
  1404. different utilities send me a mail about latest version,
  1405. a description, if source code is available, and where to 
  1406. get it.
  1407.  
  1408. Get the source code,  pgp23srcA.zip and unpack
  1409. with 'pkunzip -d pgp23srcA.zip' to get all included utilities
  1410. to come up nicely sorted in subdirectorys.
  1411.  
  1412. Have not yet checked it's content, but
  1413. at  van-bc.wimsey.bc.ca  /pub/crypto/PGP/    there is this file;
  1414. 2028 Mar 09 12:13 pgp-interface-jason-steiner.z
  1415.  
  1416.  
  1417. "
  1418. Subject: Front End Announcement: PGP with TAPCIS
  1419. Sender: usenet@ttinews.tti.com (Usenet Admin)
  1420. Reply-To: 72027.3210@compuserve.com
  1421. Date: Tue, 3 Aug 1993 00:58:17 GMT
  1422.  
  1423. TAPCIS is a popular navigator/offline message reader used on PCs to
  1424. access CompuServe.  An add-on program, TAPPKE (TAPcis Public Key
  1425. Encryption), has been uploaded to the CompuServe TAPCIS Support Forum
  1426. library under "scripts and tools;" this program is an interface between
  1427. TAPCIS message-writing facilities and PGP.
  1428.  
  1429. When you compose messages in TAPCIS, they get collected into a batch in
  1430. a .SND file along with some control information about where and how the
  1431. messages are to be posted or mailed; next time you go online to
  1432. CompuServe, TAPCIS processes any messages waiting in its .SND files. 
  1433. The TAPPKE add-on can be run before you do this transmission step. 
  1434. TAPPKE scans messages in a .SND file, and any message that contains a
  1435. keyword (##PRIVATE## or ##SIGNATURE##) is extracted and just that
  1436. message is handed to PGP for encryption or signature, then reinserted
  1437. into the .SND file for transmission.
  1438.  
  1439. All this is a simplified interface to make it more convenient to
  1440. encrypt/sign messages while still using the normal (and familiar)
  1441. message composition features of TAPCIS.  TAPPKE doesn't do any
  1442. encryption itself, it merely invokes an external encryption engine to
  1443. perform the indicated tasks; you can even use it with encryption
  1444. programs other than PGP if you set up a few environment variables so
  1445. TAPPKE will know what encryption program to run and what command-line
  1446. arguments to feed it.  The default configuration assumes PGP.
  1447.  
  1448. I don't see any point in posting TAPPKE anywhere besides on CompuServe,
  1449. since the only people who would have any use for it are TAPCIS users,
  1450. and they by definition have access to the CompuServe TAPCIS forum
  1451. libraries.  However, it's free (I released it to the public domain,
  1452. along with source code), so anyone who wants to propagate it is welcome
  1453. to do so.
  1454. ...
  1455. Some mailers apparently munge my address; you might have to use
  1456. bsmart@bsmart.tti.com -- or if that fails, fall back to
  1457. 72027.3210@compuserve.com.  Ain't UNIX grand? "
  1458.  
  1459.  
  1460. rat-pgp.el
  1461. ==========
  1462.  
  1463. rat-pgp.el is a GNU  Emacs interface to the PGP public key system.  It lets
  1464. you easily encrypt and decrypt message, sign messages with your secret key
  1465. (to prove  that it really came from you). It  does  signature verification,
  1466. and it  provides  a number  of  other  functions.  The  package  is growing
  1467. steadily as more is added. It is my intention that it will eventually allow
  1468. as much functionality as accessing PGP directly.
  1469.  
  1470. The most recent version of rat-pgp.el is always available via anonymous FTP
  1471. at ftp.ccs.neu.edu, directory /pub/ratinox/emacs-lisp/rat-pgp.el.
  1472.  
  1473.  
  1474. mailcrypt.el  
  1475. ============
  1476.  
  1477.  > From: jsc@monolith.mit.edu (Jin S Choi)
  1478.  > Newsgroups: gnu.emacs.sources,alt.security.pgp,alt.security.ripem
  1479.  > Subject: mailcrypt.el (mail encryption/decryption using RIPEM and/or PGP)
  1480.  > Date: 01 Aug 1993 12:45:52 GMT
  1481.  > ...
  1482.  > This is an elisp package for encrypting and decrypting mail.  I wrote
  1483.  > this to provide a single interface to the two most common mail
  1484.  > encryption programs, PGP and RIPEM. You can use either or both in any
  1485.  > combination.
  1486.  > ...
  1487.  > ;; available from the elisp archive. 
  1488.  (where is that elisp archive ?)
  1489.  
  1490. At 6 Aug. the version was 0.2b. 
  1491. "Some of the new features include:
  1492.   VM mailreader support.
  1493.   Support for addresses with spaces and <>'s in them.
  1494.   Support for using an explicit path for the encryption executables.
  1495.   Key management functions.
  1496.   The ability to avoid some of the prompts when encrypting.
  1497.   Assumes mc-default-scheme unless prefixed."
  1498.  
  1499. --
  1500.  
  1501. PGPPAGER  ver. 1.1
  1502. Stored on any ftp-site ? 
  1503.  
  1504.  > Newsgroups: alt.security.pgp
  1505.  > From: abottone@minerva1.bull.it (Alessandro Bottonelli)
  1506.  > Subject: pgppager 1.1 sources
  1507.  > Date: Tue, 6 Jul 1993 11:37:06 GMT
  1508.  > 
  1509.  > ...
  1510.  > /* pgppager, designed to be possibly integrated with elm mail reader
  1511.  >  * ...
  1512.  >  * This programs reads from a specified file or from stdin if no file is
  1513.  >  * specified and creates three temporary files (header, encrypted, and 
  1514.  >  * trailer) as needed, in order to store the header portion in clear text,
  1515.  >  * the encrypted portion still in cypher text, and the trailer portion of
  1516.  >  * the clear text. Then, if applicable, the clear text header is outputted,
  1517.  >  * the encrypted portion is piped through pgp as needed, then the trailer
  1518.  >  * (if any) is outputted. THIS PROCESS IS TRANSPARENT TO NON PGP ENCRYPTED
  1519.  >  * TEXTS
  1520.  >  * ...
  1521.  >  */ "
  1522.  
  1523.         MSDOS
  1524.  
  1525. PGPSHE22
  1526.  
  1527. PGPShell v2.2 is a dramatic update to this easy-to-use program that
  1528. makes using Philip Zimmermann's Pretty Good Privacy (PGP) public-key
  1529. encryption software easy.  Supports all of PGP's command-line arguments
  1530. with a graphical user interface (GUI), mouse, windowed popup boxes with
  1531. scroll bars for easy UserID, footprint, and signature key viewing on
  1532. your public key ring.  Built-in file viewer for reading decrypted
  1533. messages.  Use your favorite text editor to compose messages then
  1534. automatically encrypt them.  Requires PGP (ver 2.0 or higher), can run
  1535. on any PC XT, AT, 286+, mono or color.  Mouse optional.  Freeware.
  1536.  
  1537. available as  65430 Aug 3 11:40 garbo.uwasa.fi [128.214.87.1]
  1538. /pc/crypt/pgpshe22.zip
  1539. and
  1540. Hieroglyphic Voodoo Machine BBS at 1.303.443.2457 
  1541. The source code for ver 1.0 is in PGPSHELL.PAS.
  1542. (source code available also for ver 2.2 ?)
  1543.  
  1544.  
  1545. MENU.ZIP Menushell for MSDOS. (Requires 4DOS or Norton's NDOS)
  1546. exists at ghost.dsi.unimi.it
  1547.  (ask archie about 4DOS, a comand.com replacement)
  1548.  
  1549.  
  1550. HPACK78  PGP-compatible archiver
  1551.  
  1552. 114243 Nov 20 07:08 garbo.uwasa.fi:/pc/arcers/hpack78.zip
  1553. 146470 Dec  3 01:01 garbo.uwasa.fi:/pc/doc-soft/hpack78d.zip
  1554. 511827 Dec  3 14:46 garbo.uwasa.fi:/pc/source/hpack78s.zip
  1555. 667464 Dec  5 16:43 garbo.uwasa.fi:/unix/arcers/hpack78src.tar.Z
  1556.  
  1557. where hpack78.zip is the MSDOS executable, hpack78d.zip is the Postscript
  1558. documentation, hpack78s.zip is the source code, and hpack78src.tar.Z is the
  1559. source code again but in tar.Z format (note that the latter is a tiny bit more
  1560. recent that hpack78s.zip and contains changes for the NeXT).  There is a
  1561. (rather primitive) Macintosh executable somewhere on garbo as well, possibly
  1562. /mac/arcers/hpack78mac.cpt.
  1563.  
  1564. OS/2 32-bit versions of HPACK available for anonymous FTP from the UK.
  1565. `ftp.demon.co.uk' [158.152.1.65] in ~/pub/ibmpc/pgp
  1566. .. 
  1567.  
  1568. pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz
  1569. peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz
  1570.                (In order of preference - one of 'ems bound to work)
  1571.  
  1572. PGPUTILS.ZIP  at ghost.dsi.unimi.it  /pub/crypt/ a collection of
  1573. BAT-files, and PIF-files for windows.
  1574.  
  1575. VMS mail script
  1576. Could the author please send me a description wich can be added here ?
  1577.  
  1578. I remember a post about a REXX script for OS/2 ? 
  1579. Where is it ? 
  1580.  
  1581. --
  1582. 51)    patches, and utilities in pipeline
  1583.  
  1584.         Patches
  1585.  
  1586. Send a mail to the author(s) to get these.
  1587.  
  1588.  > From: tri@snakemail.hut.fi (Timo Rinne)
  1589.  > Newsgroups: comp.os.386bsd.misc,alt.security.pgp
  1590.  > Subject: PGP-2.3a hide command line arguments
  1591.  > Date: 30 Jul 93 04:36:10 GMT
  1592.  > ...
  1593.  > I hacked a patch for pgp version 2.3a to hide it's command line
  1594.  > arguments so that they can not be seen from ps(1) output.  It seems to
  1595.  > work ok in 386bsd.  I haven't tested it on other systems but it should
  1596.  > work on BSD 4.3 systems that are _NOT_ based on MACH.
  1597.  > ...
  1598.  
  1599.  
  1600.         In Pipeline
  1601.  
  1602. This list will hopefully avoid double work, or maybe joined forces. 
  1603.  
  1604.  > Newsgroups: alt.security.pgp
  1605.  > From: ratinox@denali.ccs.neu.edu (Richard Pieri)
  1606.  > Subject: Re: pgp frontend for windows?
  1607.  > Date: Mon, 2 Aug 1993 16:27:51 GMT
  1608.  >...
  1609.  > Andreas> Is there a pgp frontend for windows for the bloodiest
  1610.  > Andreas> beginner to use pgp efficiently?
  1611.  >
  1612.  > There is one, but it's only in alpha/beta testing, and it does no
  1613.  > cryption yet. The bugs are being worked out of the interface first
  1614.  > before full PGP functionality is integrated. There will probably be an
  1615.  > announcement when a fully functional version is ready for public
  1616.  > consumption.
  1617.  
  1618.    
  1619. 52) Where are the latest version ?
  1620.  
  1621. The PGPDOC2.DOC, section; "Licensing and Distribution" tells you 
  1622. to send a mail to info-pgp-request@lucpul.it.luc.edu for a 
  1623. more complete ordered list. It is maintained by Hugo Miller at
  1624. hmiller@lucpul.it.luc.edu
  1625.  
  1626. He also writes:
  1627. "    For those lacking ftp connectivity to the net, nic.funet.fi also
  1628. offers the files via mail.  Send the following mail message to
  1629. mailserv@nic.funet.fi:
  1630.  
  1631.     ENCODER uuencode
  1632.     SEND pub/crypt/pgp23srcA.zip  (edited to reflect the new version)
  1633.     SEND pub/crypt/pgp23A.zip
  1634.  
  1635. This will deposit the two zipfiles, as 15 batched messages, in your mailbox
  1636. with about 24 hours.  Save and uudecode."
  1637.  
  1638. If you are in a hurry, here are some places. 
  1639.     
  1640. nic.funet.fi       (128.214.6.100)      /pub/crypt/
  1641. src.doc.ic.ac.uk                        /pub/computing/security/pgp/
  1642. black.ox.ac.uk     (129.67.1.165) /src/security/
  1643. ghost.dsi.unimi.it (149.132.2.1)        /pub/crypt/  
  1644. soda.berkeley.edu  (128.32.149.19) /pub/cypherpunk/pgp 
  1645.    (on soda, corrupted files, discovered <= 22 Jul. -93, seems 
  1646.    to be fixed, since all files are now dated 22 Jul.)
  1647.  
  1648.  
  1649. van-bc.wimsey.bc.ca;     /pub/crypto/PGP/2.3a/  (political restrictions)
  1650.     (notable with van-bc ..., is that they have all versions 
  1651.     back to 1.0 in a nice order. In /pub/crypto/PGP, there is
  1652.     also a file; 
  1653.     10144 Mar 04 12:43 pgp-sitelist 
  1654.     wich might point you to even more sites that carry pgp.
  1655.     Maybe it's hugh's list)
  1656.  
  1657.  
  1658.    filenames: 
  1659. 422851 Jul 12 09:31 macpgp2.3.cpt.hqx    (MAC executable)
  1660. 680985 Jul  8 16:15 pgp23A.tar.Z        (packed for Unix)
  1661. 221332 Jul  8 16:24 pgp23A.zip          (MSDOS executable)
  1662.  88070 Jul  8 16:29 pgp23docA.zip       (doc's only)
  1663.    998 Jul  8 16:29 pgp23sigA.asc       (signatures for authenticy)
  1664. 547178 Jul  8 16:45 pgp23srcA.zip       (source code)
  1665.  
  1666.         MAC, sourcecode
  1667. black.ox.ac.uk (129.67.1.165),   /src/security (in hqx format ?)
  1668. ghost.dsi.unimi.it          /pub/crypt/
  1669. netcom.com (192.100.81.100)      /pub/grady/
  1670. filename: 
  1671. 1027543 Jul 19 16:47 macpgp2.3src.sea.hqx.pgp
  1672.  
  1673.         OS/2 
  1674. ftp.uni-erlangen.de     /pub/pc/os2/fauern/crypt
  1675. gate.demon.co.uk.    /pub/ibmpc/pgp
  1676. 337360 Mar 12 16:47 pgp22os2.zip           (any 2.3A for OS/2 ?)
  1677.  
  1678.         AMIGA
  1679. ftp.dfv.rwth-aachen.de        /pub/amiga/comm
  1680. filename: 
  1681. 88502 Jun 19 15:36 PGP2_3Amiga.lha    (without doc's.)
  1682.  
  1683. The amiga versions 2.3 and 2.3A should exists in an official 
  1684. version, somewhere on the net. (i could not find them) 
  1685. and also in non official versions. 
  1686. (the one above could be unofficial.)
  1687. This duplication might have been corrected, when you read this.
  1688. In the meantime, to get PGPAmiga23a.lha for AMIGA, mail to
  1689. simons@peti.GUN.de (Peter Simons)
  1690.  
  1691. There is no ver 2.3A for MAC. 
  1692. Where can ATARI compiled versions be found ?
  1693. --
  1694.  
  1695. 53) Which is the minimum files needed ?
  1696.  
  1697.   PGP.EXE
  1698.   CONFIG.TXT 
  1699.   RANDSEED.BIN
  1700.   SECRING.PGP
  1701.   PUBRING.PGP
  1702.   LANGUAGE.TXT
  1703.   PGP.HLP
  1704.  
  1705. This can be reduced even more. 
  1706.  
  1707. LANGUAGE.TXT. English users can probably delete this file. 
  1708. All English messages are already inside PGP.EXE. 
  1709. Spanish/French users, edit away all messages on that 
  1710. other language you don't use. That reduces the size with 1/3.
  1711.  
  1712. PGP.HLP. Remove everything except for those commands that
  1713. you are using. 
  1714.  
  1715. CONFIG.TXT can be reduced to just a few lines.
  1716. Edit away all the information texts.
  1717.  
  1718. If you are only using conventional encryption, then PGP.EXE and 
  1719. CONFIG.TXT is all you need.
  1720.  
  1721. Finally, ZIP the files to a self extracting archive,
  1722. and the resulting size is around 100 Kb. 
  1723.  
  1724. Hint 1: Place the file on a floppy, which then acts like a smart card
  1725. for access to your files.
  1726. Hint 2: Compress with PKZIP's encryption too. 
  1727.  
  1728. --  
  1729. 54)  Where are the language files ?
  1730.  
  1731. Swedish;   contact Laszlo Baranyi <laszlo@instrlab.kth.se>
  1732. Norwegian; contact Thor Oddleif Kristoffersen <thork@ifi.uio.no> 
  1733.       (Thor's email address might change later during -93)
  1734. For other languages the doc's points you to
  1735. Colin Plumb (colin@nyx.cs.du.edu) 
  1736.  
  1737. 59) ftp-able additional readings
  1738.  
  1739. "RIPEM Frequently Asked Questions"
  1740.  maintained by <mvanheyn@cs.indiana.edu>.
  1741.  Posted monthly. Look for it in alt.security.ripem
  1742.  Especially it's section about attack forms.
  1743.  [stored where ?]
  1744.  
  1745.  A description of IDEA in postscript is 
  1746.  at ghost.dsi.unimi.it;  area;   /pub/crypt/
  1747.  filename;  92081 Jan 14  1993 IDEA.chap.3.ps.Z
  1748.  
  1749.  
  1750. "The Privacy & Anonymity on Internet"  is on  rtfm.mit.edu
  1751. area: /pub/usenet/news.answers/net-privacy/
  1752. filenames:
  1753. 60098 Jul 11 01:54 part1
  1754. 50127 Jul 11 01:54 part2
  1755. 42339 Jul 11 01:54 part3
  1756. It's loaded with pointers of where to read more on almost everything.
  1757. Like this:
  1758.  
  1759. " <6.2> How can I learn about or use cryptography?
  1760.  
  1761.   NIST (U.S. National Institute for Standards and Technology)
  1762.   publishes an introductory paper on cryptography, special
  1763.   publication 800-2 ``Public-Key Cryptograhy'' by James Nechvatal
  1764.   (April 1991).  Available via anonymous FTP from
  1765.   csrc.ncsl.nist.gov (129.6.54.11), file pub/nistpubs/800-2.txt. 
  1766.   Also via available anonymous FTP from wimsey.bc.ca as crypt.txt.Z
  1767.   in the crypto directory.  Covers technical mathematical aspects
  1768.   of encryption such as number theory."
  1769.  
  1770. and
  1771.  
  1772. " More general information can be found in a FAQ by Paul Fahn of RSA
  1773.   Laboratories via anonymous FTP from rsa.com in /pub/faq.ps.Z.  See
  1774.   the `readme' file for information on the `tex' version.  Also
  1775.   available as hard copy for $20 from   RSA Laboratories, 100 Marine
  1776.   Parkway, Redwood City, CA  94065.  Send questions to
  1777.   faq-editor@rsa.com."
  1778.  
  1779. This is 52 pages of postscript or Tex. 
  1780.  
  1781.               Answers To
  1782.         FREQUENTLY ASKED QUESTIONS
  1783.         About Today's Cryptography 
  1784.  
  1785.            September 14, 1992
  1786.  
  1787. (But if you don't have, neither postscript or Tex, i am told 
  1788. that there is a hacked version of this FAQ, which is an ascii'fied 
  1789. Tex-version, send me a mail if you want me to check it out... )
  1790.  
  1791.  
  1792. The FAQ from sci.crypt is on  rtfm.mit.edu:/pub/usenet-by-group/sci.crypt.
  1793.  
  1794.    [ Any more recommended readings ?]
  1795.  
  1796. soda.berkeley.edu, The cypherpunks FTP site,
  1797. is also loaded with text. An over view is in it's 'readme.soda'
  1798.  
  1799. They also have a mailing list, described like this, in
  1800. "The Privacy & Anonymity on Internet" 
  1801.  
  1802. " <6.3> What is the cypherpunks mailing list?
  1803.  
  1804.   Eric Hughes <hughes@toad.com> runs the `cypherpunk' mailing list
  1805.   dedicated to ``discussion about technological defenses for privacy
  1806.   in the digital domain.''  Frequent topics include voice and data 
  1807.   encryption, anonymous remailers, the Clipper chip.  Send email to
  1808.   cypherpunks-request@toad.com to be added or subtracted from the
  1809.   list. (Traffic is sometimes up to 30-40 messages per day.)  
  1810.   ..."
  1811.   
  1812. At the end of pgpdoc2.doc, there are also several pointers
  1813. to "Computer-Related Political Groups".
  1814. Also check political.doc in your PGP package.
  1815.  
  1816. --   
  1817.   Yet unanswered questions 
  1818.  
  1819. -Anything official about what comes in next version ? "curious"
  1820.  
  1821. -Where can i read old postings from alt.security.pgp ?
  1822.     Try ghost.dsi.unimi.it.
  1823.     What subdirectory ? Are there more sites ?
  1824.     (or ripem.msu.edu, for users in the  U.S. and Canada 
  1825.     who are citizens or permanent residents)
  1826.  
  1827. -Does it exists a place where all utility's are stored ?
  1828.     Currently, No. But you might try the collections at 
  1829.     ghost.dsi.unimi.it  and 
  1830.     Hieroglyphic Voodoo Machine BBS at 1.303.443.2457 
  1831.     [more suggestions ?]
  1832.  
  1833. -How can i activate this "kill file" thing ?
  1834.  
  1835. -Whats that "regexp" on the keyservers ? 
  1836.  Could someone mail an example on how to get all keys from say
  1837.  finland ?
  1838.  
  1839. end of part2 (2)
  1840.  
  1841. Subject: Hints & Tricks, correction 1
  1842. Message-ID: <1993Aug9.004807.18797@kth.se>
  1843. Date: Mon, 9 Aug 1993 00:48:07 GMT
  1844. Sender: usenet@kth.se (Usenet)
  1845. Reply-To: laszlo@kth.se (Laszlo Baranyi)
  1846. Organization: Royal Institute of Technology, Stockholm, Sweden
  1847. Lines: 29
  1848. Nntp-Posting-Host: kth.se
  1849.  
  1850. Correction to # 31 in "Hints & Tricks using PGP".
  1851.  
  1852. This is how it should be. My apologise to Edgar.
  1853.  
  1854. 31)    My signature looks so dull. Can i fix that ?
  1855.  
  1856. According to edgar@spectrx.saigon.com (Edgar W. Swank):
  1857.  
  1858.   You can add any text you like (except -----END PGP ...?) after
  1859.   BEGIN PGP SIGNATURE (either before or after Version) and before
  1860.   the blank line.  Try it. You can also enter any text you want after
  1861.   the END PGP SIGNATURE line.
  1862.  
  1863. Would a personal touch on the signature interfere with
  1864. other PGP-utilities ?
  1865.  
  1866.     I guess you mean some of the mailer-interfaces that are packaged
  1867.     with, but are not really part of, PGP.  Answer is, I don't think
  1868.     so, but you will have to test to find out. Entering text after the
  1869.     END PGP SIGNATURE line is the least likely to cause problems
  1870.     because many mailers add text there anyway (auto sig).
  1871.  
  1872.     PGP will skip any non-blank lines after BEGIN PGP SIGNATURE (or
  1873.     any BEGIN PGP ... armored code) until it reaches a blank line. But
  1874.     utilities might not follow that same standard; they might, for
  1875.     example, just look for the single Version: line which is all
  1876.     that's presently generated by PGP.
  1877.  
  1878. Laszlo
  1879.  
  1880.  
  1881.  
  1882.