Ä Area: altsecpgp ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Msg#: 28 Date: 08-08-93 17:26 From: Laszlo Baranyi Read: Yes Replied: No To: All Mark: Subj: Hints & Tricks using PGP ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Path: tatertot!netcomsv!netcom.com!netcomsv!decwrl!olivea!news.bu.edu!bloom-beacon.mi t.edu!eru.mt.luth.se!kth.se!kth.se!laszlo From: laszlo@kth.se (Laszlo Baranyi) Newsgroups: alt.security.pgp Subject: Hints & Tricks using PGP 1(2) Message-ID: <1993Aug8.172620.12979@kth.se> Date: Sun, 8 Aug 1993 17:26:20 GMT Sender: usenet@kth.se (Usenet) Reply-To: laszlo@kth.se (Laszlo Baranyi) Organization: Royal Institute of Technology, Stockholm, Sweden Lines: 1353 Nntp-Posting-Host: kth.se Hello pgp-fans. Here comes my attempt to become a global fool. These 2 postings are a release of Hints & Tricks using PGP (ver. 00) beta selected topics from alt.security.pgp ---------------------------- cut here ------------------- Suggested archive filename: MSDOS: HTPGP00 UNIX : hint_trick_pgp00 wich consists of: HTPGP00.1 HTPGP00.2 -- Hints & Tricks using PGP (ver. 00) beta selected topics from alt.security.pgp 6 Aug -93 laszlo@instrlab.kth.se Content Part 1 (2) (this file) 10. Introduction Keymanegment 11. I forgot the passphrase to my keyring. Is that bad ? 12. My secret keyring has been copied. Is that bad ? 13. How much effort is required to find out my passphrase ? 14. Can i create a sparekey, IF i should forgot my passphrase ? 15. (dis)advantages with several keys and key sizes. 16. What is the speed / key size ratio ? 17. Why on earth should i encrypt files to myself ? 18. Why do some people sign their own keys ? 19. Some ways to get your key signed. (remotly) Key servers 20. Can i avoid to be added to the public key servers ? 21. Where are those key servers ? 22. What can be known about me from the key servers ? 23. Can my BBS act like a key server ? 24. Statistics about all the keys. Procedures 30. How to verify your PGP version. 31. My signature looks so dull. Can i fix that ? 32. Signed archive against virus. 33. Voting with PGP. 34. I have changed e-mail address, how can i let the world know ? 35. How do i make a BIG distribution list ? 36. Using non-English characters between MAC, PC, AMIGA, UNIX. 37. How do i set up a RAM-drive, and why ? (MSDOS) 38. Can i hide PGP on my PC ? (MSDOS) 39. How to override the randomnumbers. (randseed.bin) Unsorted 40. Can the Public Key concept be explained without any math ? 42. What is a rubber house attack ? 43. How safe is "for your eyes only" ? 44. What can a wiretapper find out about a message ? 45. Where should problems be reported ? 46. A list of non-bugs 47. What's a proper PGP-add. ? Part 2 (2) (next file) Files/programs 50. Existing utilities. 51. patches, and utilities in pipeline 52. Where are the latest version ? 53. Which is the minimum files needed ? 54. Where are the language files ? 59. ftp-able additional readings. Yet unanswered questions Anything official about what comes in next version ? "curious" Where can i read old postings from alt.security.pgp ? Does it exists a place where all utility's are stored ? How can i activate this "kill file" thing ? Whats that "regexp" on the keyservers ? 10) Introduction. This started as a collection of note's on topics from alt.security.pgp. An easier way to find information than storing and searching in backlogs. Also, new readers don't have any backlog, so goodies are lost into the digital grave. If i have misunderstood some topic, or if you have some additional information, just let me know, so we can improve the quality in the next version. Sneakpreviews has been sent out, all answers are not yet in, but if we should wait for a perfect version, then it wont ever get out. So, instead, find all errors, and those answer the questions that are un the text, and we will by time get something with quality. Any topics that should be added/removed ? The doc's for PGP is still the bible. This is just additional comments, or rephrased questions about what's already answered in the doc's. There is more text in pipeline, but first i wanted to check if this is interesting at all. English is not my primary language, so corrections on phrasing is also wanted. And: to let you weight the information in a correct way: i have no formal education on cryptography, is not part of the PGP development team, and thus have no inside information. Just yet another PGP-fan. So off to work we go. -- Keymanegment 11) I forgot my password to my keyring. Is that bad ? Yes. Check PGPDOC1.DOC, "What If You Lose Your Secret Key?" for details. Actions: * Destroy copies of your old secret keyring (secring.pgp) Thus avoid a massive password attack on it. * Create a new keypair. * Now, here comes the catch 22. How can you convince the rest of the world that you no longer are yourself ? Why should they believe you ? Are you trying to take over anothers identity ? Some attempts to get around. You need a bunch of friends to sign your new key. Their total trustworthiness should preferably be higher than your own single trustworthiness. (the majority wins) If your old key was signed, then preferably it should be the same persons who sign's your new key. Or try this. Send them (encrypted with your new key) parts of your earlier conversation. Things that could not have been collected by a wiretapper. If your net friend believes that you store information in decrypted form, then this wont work, since someone could have taken a copy of your harddisk. check "Some ways to get your key signed. (remotly)" for more ideas. * On your new key, maybe you even can use the field which is normally used for your alias, by adding a short notice there instead. Like "KeyID: 123abcxyz is invalid from or "Disable KeyID: 123abcxyz" * Publish the new key and a signed statement that your old key is no longer valid. Also send it to everybody you have correspondence with and tell them to disable your key. Note; The key should be disabled, (pgp -kd) not removed. A removed key will most probably come back again from some other sources that has not received your message. and/or publish your statement in some news group where you are active. Your correspondent can assume that if nobody complains, then maybe you really are yourself. It might be a good idea to not accept such a key immediately. The real owner could be on vacation. * Upload the new key to the key server. Currently there is nothing that automatically invalidates a key by the time, so your old key will stay disabled on a lot of key rings, or float around as a useless piece of data. You might even receive messages encrypted with your old key, which you naturally cant read. -- 12) My secret keyring has been copied. Is that bad ? The secret keyring is stored in encrypted form and is only useful together with your passphrase. If you have a lousy passphrase, start swetting now. However, the secret keyring is 1/2 of your protection. And that is now lost. The passphrase is the other half. To regain full protection, Issue a "Key Compromise Certificate" Check PGPDOC1.DOC section; "How to protect Secret keys from Disclosure" for details. If you want to make your revoked key real fancy. Before you revoke your old key, you add a message in the alias field wich says "new keyID: 123abc from " Then whenever somone sees your revoked key, he thus have a convenient pointer of what the new key is. -- 13) How much effort is required to find out my passphrase ? That depends on if you have selected a good passphrase. The list below is from the manual to PKZIP, ver 2.04g. section; "Using Data Encryption" "All forms of encryption, including the one used by PKZIP, are open to "brute force" attacks. This form of attack is simply the trying of many passwords until you find one that works. In order to help you protect your data from this sort of attack we present figures on how long a brute force attack, using a computer, would take. The scenario we present here assumes that your encrypted .ZIP file is being assaulted by a program which is designed specifically to do this. An encryption key may contain any valid ASCII character, not just A-Z in upper and lower case and punctuation marks. However, most people will just use the latter. The following table is indexed by the complexity of the password. Across the top is the range of characters used. The simplest assumes that only lower case letters from a to z were used. The next column assumes that all printable characters were used (a to z in upper and lower case, punctuation, brackets, etc.). The last column assumes a password containing the complete range of ASCII characters. The vertical index is the length of the password used. This impacts the strength of the password greatly. Think of it as a combination lock. A combination lock with only two numbers would be much easier to break than one with three or four numbers. We recommend that if you need a truly secure encrypted file, use an encryption key of at least six characters. The last assumption made is about the speed of the attacking program. For the purposes of this table, we assume that 10,000 possible keys are being attempted per second. Password "Hacking" Time -------------------------------------------------------------- | Key | 26 characters | 96 characters | 256 characters | | Length | (a-z) | (a-z,A-Z,etc) | (All ASCII) | --------------------------------------------------------------- | 3 | 2 seconds | 1 minute | 27 minutes | --------------------------------------------------------------- | 4 | 1 minute | 2.35 hours | 4 days | --------------------------------------------------------------- | 5 | 19 minutes | 9 days | 3 years | --------------------------------------------------------------- | 6 | 8.6 hours | 2 years | 891 years | --------------------------------------------------------------- | 7 | 9 days | 238 years | 2283 centuries | --------------------------------------------------------------- | 8 | 241 days | 228 centuries | 584,546 cent. | --------------------------------------------------------------- | 9 | 17 years | 21,945 cent. | 149,643,989 cent. | --------------------------------------------------------------- | 10 | 447 years | 2,106,744 | 38,308,861,211 | | | | centuries | centuries | --------------------------------------------------------------- Choose the complexity that you feel meets your needs, but keep in mind all that has been mentioned about losing and forgetting passwords. These figures represent the state of technology today. PKWARE Inc. cannot predict future technologies which may allow faster attempts at decryption of a .ZIP file. Note that the above figures do not include the time needed to actually try all valid passwords. This would increase the time by several hundred percent, dependent upon the length of the file. " [I don't understand PKZIP's phrase: "...above figures do not include the time needed to actually try all valid passwords." Isn't a brute force attack meant to try all combinations ?] Note the different advises you get for your passphrase; PKZIP has a big sign saying: "DO NOT TRUST YOUR MEMORY ALONE. WRITE IT DOWN." And PGPDOC2.DOC, section "Compromised Pass Phase and Secret Key" Says that a written down passphrase is probably the simplest attack. Do also check PGPDOC1, section; "How to Protect Secret Keys from Disclosure" -- 14) Can i create a sparekey, IF i should forgot my passphrase ? Yes. Create an extra keypair, where you user name is reversed (or something similar, umique for you). So if your name is say, Joe Public, then use Public Joe as your userID on that spare key. Let your normal userID; Joe Public, certify that Public Joe really exists. Store the spare key at some safe place. Maybe encrypt it and send it to a god friend. If you forgot the passphrase to your normal key, then contact your friend to get the spare key. Hopefully you have not forgot that passphrase too. Now you can continue as usual. You can also now create yet another spare key. Just in case ... The key size of your sparekey should preferably not be shorter than your ordinary key. Check section; "(dis)advantages with several keys." about how the shortest key can become the weakest link. For an example on this method, check Zimmermans both keys with the commands pgp -kc prz@acm pgp -kc prz@sage An edited output will show you this. Key ring: 'pubring.pgp', looking for user ID "prz@acm". Type bits/keyID Date User ID pub 1024/A966DD 1993/05/21 Philip R. Zimmermann searching key ring file 'pubring.pgp' for keyID 67F70B sig! 67F70B 1993/05/21 Philip R. Zimmermann Key ring: 'pubring.pgp', looking for user ID "prz@sage". pub 1024/67F70B 1992/07/22 Philip R. Zimmermann An interpretation of this means that Zimmerman has used his good old key, to certify this newer one, And what if i lose the spare key ? Then you could convince everybody (with a signed statement) from your ordinary key, that the sparekey should be disabled. If the sparekey is not used, then don't register it on the key servers. It just adds unneccecary confusion, like mail encrypted to your sparekey. [Is there any advantage to not let the two keys certify each other ?] -- 15) (dis)advantages with several keys and key sizes. Besides of being guarded against a lost passphrase, here is a more farfetched application. If you are in an unexpected situation where your signature is needed, but you have your keypair at home. Then create a new keypair and sign that urgent thing with it. When you get home, certify your newly created keypair with your ordinary key, and upload the certified new keypair to the key servers. One disadvantage by playing with to many keypair's, is the need to remember even more pass phrases. But if you have several keys with different sizes, there are more aspects to think of. If a short key, sign's a statement where the owners longer key should be disabled, should we trust that shorter key ? or rephrased: If it becomes accepted, that keys could ask for (your) other key to be disabled, then the shortest key is a weak link. Signing postings to discussion meetings, could have a shorter, faster, and less secure key, than the one you use to encrypt private mail with. The shorter key might even be on the owners UNIX account. The owner could have made this trade off between security/convenience. Since you don't know this, his convenience becomes your insecurity. People who wants to send you a private mail will probably use that shorter key. But if they knew that you had a longer key, they might have preferred to use that one. You could also expect some irritation from your correspondents. They must keep track of which of your say, 5, keys that should be used in what situation. You could give them a hint by using the alias field for messages. Like: userID: Joe Public alias: This one is for Usenet postings alias: get for private mail. -- 16) What is the speed / key size ratio ? > Newsgroups: alt.security.pgp > From: res@colnet.cmhnet.org (Rob Stampfli) > Subject: Re: Shorter keys and faster encryption > Date: Tue, 13 Jul 1993 04:29:18 GMT > ... >> What is the difference (ratio) in encryption time (roughly) >> between, say, a 384 byte and 1024 byte key. 2x, 4x, 1000x? > > Doubling the number of bits in the key theoretically doubles > the time it takes to perform the RSA step in the encryption > process or verification of signature. It quadruples the RSA > decryption time, and the time it takes to sign a file. It > increases by a factor of 8 the time it takes to generate a key. and another answer. > From: seggers@semyam.dinoco.de (Stefan Eggers) > Date: 13 Jul 93 18:09:56 +0200 > Subject: Re: Shorter keys and faster encryption > Newsgroups: alt.security.pgp > ... > I tried it on my Amiga 500 (68000, 7 MHz). > > 384 bits 15 seconds > 512 bits 25 seconds > 768 bits 60 seconds > > These results are for a short text (I may have used > different text when I tried it with 768 bits) and are not exact. > > I didn't try it with 1024 bits because the key generations > takes far too much time and this key would be unusable for me. Are there more benchmarks out there ? And now comes a sidestep to "strange keysizes" that can be seen in "Statistics about all the keys." >> Where did the keys less than 384 bits come from? PGP2.3 won't even >> create these; maybe an earlier version would. > > Change the limits in the source and recompile. Then you should be > able to create keys with 256 bits and 1240 bits. > > seggers@semyam.dinoco.de -- 17) Why on earth should i encrypt files to myself ? To protect against a situation where your harddisk has been stolen/copied. If you store all your outgoing mail and replies in plain text, It should not be to hard to figure out the subjects of your incoming mail. It also good for administrative purposes to keep an identical copy of messages that has been sent. To always encrypt a copy of outgoing mail and replies to yourself, check PGPDOC2.DOC, section; "Encrypting a Message to Multiple Recipients" The most convenient way is to append these lines in your CONFIG.TXT: # Make every encrypted message also readable by sender. EncryptToSelf=ON # An undocumented feature. (In ver 2.3A) -- 18) Why do some people sign their own keys ? There was a bug in ver. 2.1, which made it possible for someone else to change your userID, and spread a false key. By signing your own key, the userID was "locked" . It's now fixed. But the signatures are still around and keeps new users wondering. 19) Some ways to get your key signed. (remotly) The best is to find a friend. But in this networld, the friends are more often at the other end of a long cable. We dont even know how they look like. Ask the keyserver for PGP users that might live near you and ask for a meeting. They are easiest to find if your e-mail address ends with a .country. Or if you live near a Univerity, search for .edu. Check "Statistics about all the keys." and you will se that the chances to find a pgp user nearby are good. Exchange a symbolic amount of money through a bank. Then both netter's trusts the bank to really check the identity of the receiver. In advance, you have both exchanged your accountnumber in a signed messages. Archive that signed message. If there later is any doubt about the real identity, you at least have a theoretical chanse to ask the bank who the owner is to that account. The notarie method. You want your key signed by your netfriend. He checks in the phone book for a notarius publicus in your city, and selects one on random. You go there with a printout of your key's fingerprint. (pgp -kvc your_name > outfile) You identify yourself, notaire verifies that your name is the same on the printout, and your identificationpapers. You handsign your printout, wich he verifies against your identification papers. He puts on a big oldfashion timestamp, and signs it. Send these handsigned papers to your netfriends who now can sign your key. While you are at the office, why not have him stamp a few more papers. You maybe even can trade the expense for an explanation of how that fingerprint can be locked to your identity. In PGPDOC2.DOC, "Verifying a Public Key Over the Phone" there are details on how to do if your net friends recognises your voice. But why is this method is limited to voice recognition ? Could we not ask the phone company or the phonebook about the owners name and address, and then just send a snail to that address ? If he can repeat the content in the mail, then he has physical acsess to the address and phone. Key servers -- 20) Can i avoid to be added to the public key servers ? Technically. No. You cant prevent someone to add your public key there. Instead, if you don't want your public key to become "public" tell your net friends to keep it tight. -- 21) Where are those key servers ? To get more info, send an empty mail with the word HELP in the subject line to any of these sites. PGP Public Key servers which allow one to exchange public keys running through the Internet and UUCP mail systems. As of 15-Jun-93, these sites are running this system: Internet connected sites: pgp-public-keys@pgp.iastate.edu pgp-public-keys@toxicwaste.mit.edu pgp-public-keys@phil.utmb.edu pgp-public-keys@demon.co.uk pgp-public-keys@cs.tamu.edu pgp-public-keys@chao.sw.oz.au UUCP connected site: pgp-public-keys@jpunix.com pgp-public-keys@proxima.alt.za -- 22) What can be known about me from the key servers ? - The date when you started using PGP. - If you are currently using PGP. (by fingering your .plan) Assumptions about who trusts who, like: - Which your friends are. If your key is signed, it's probably done by your friends. - The hierarchy within a group by checking who is signing who's key. (psychologists has made this to an art) - How the hierarchy changes, by repeatedly checking if you have got any additional signatures. - If a group is isolated, or if there are signature links to other groups. - The growing rate of a group, by checking the date of when the members created their keys. - The geographical spreading of the group by the email addresses. What happened to those cypherpunk signing sessions in England ? A neutral trusted person, who signs keys, would remove most of the assumptions above. -- 23) Can my BBS act like a key server ? You might choose not to do so, after this reading. The source code from the real key servers are free, but it's written in pearl, and uses UNIX shells. A BBS is usually using MSDOS, so you must rewrite the code. Having independent, standalone, key servers would remove the big benefits with them. Namely ONE big keyring which always is up to date, and mirrored at several ftp-sites. For that, your BBS should also be fully connected to Internet, and be included in their mirroring scheme for the frequently exchange of keys. That's more coding work. Now you now longer have a BBS, you are an ftp-site. That sounds expensive. And finally; There seems to be work going on in PGP's keymanegment which might change the way keymanegment are handled. There maybe is some clever way after all to make the BBS environment be able to also use something like key servers. So; The cheapest and easiest way for now is to have a connection from one BBS in your network, as a link to the existing key servers. -- 24) Statistics about all the keys. The question about how many pgp users there is comes and goes. These figures below dont answers; How many keys are abandomed ? How many keys are used, but not registered ? How big is the use outside internet ? on BBS:es ? Just an example. In Stockholms BBS:world there is a discussion meeting on, TCL-net, echotag: TCL_KRYPTO, There are a handful of keys and voices. But 14 BBS:es are receiving it, just listening. So there is an interest from the silent mass, but it's impossible to measure it. " From: mikeingl@news.delphi.com (MIKEINGLE@DELPHI.COM) Subject: Server stats, signature bug? Date: 4 Aug 1993 05:27:57 -0400 ... Key server statistics as of 8/2/93 Total public keys: 1582 Total signatures: 1962 Total revocations: 48 ... Common domains: Name # keys Name # keys Name # keys .edu 455 .gov 20 .ch 7 .com 332 .net 16 .il 5 .uk 105 .se 15 .fr 3 .org 97 .su 15 .bitnet 3 .de 54 .it 14 .mil 3 .au 39 .dk 11 .at 3 .ca 34 .no 10 .br 2 .fi 32 .za 9 .pl 2 .nl 31 .lv 9 .us 23 .uucp 8 Signatures: Although some keys have numerous signatures, over half of all keys are still unsigned. # sigs # keys # sigs # keys 0 855 12 5 1 353 13 4 2 148 14 2 3 77 15 1 4 48 16 1 5 26 17 2 6 27 19 1 7 6 20 2 8 6 30 1 9 7 32 1 10 5 36 1 11 3 Key sizes: Most users have stuck with the default sizes, especially the 1024- bit key. There are some odd sizes as well. Why are 510 and 1022 bits so popular? Is there some particular advantage to these? Where did the keys less than 384 bits come from? PGP2.3 won't even create these; maybe an earlier version would. Size # Size # Size # Size # 376 1 510 50 777 1 1022 77 379 3 512 408 800 1 1023 9 380 1 524 1 896 1 1024 858 381 1 600 4 959 1 1026 1 382 6 640 1 997 2 1029 1 384 72 666 1 998 1 1032 1 500 1 700 4 999 1 1035 1 504 1 709 1 1016 1 1048 1 505 6 716 1 1017 4 1116 1 506 4 750 1 1018 1 1119 1 507 4 756 1 1019 7 1136 2 508 4 766 1 1020 11 1250 1 509 1 768 8 1021 9 " -- Procedures 30) How to verify your PGP version. type pgp keys.asc (appends a sample of keys to your keyring.) pgp keys.asc pgp.exe (verifies pgp.exe itself) The archives itself is also protected by a signature so you can be sure you have got the real one. They are in a file named; pgp23sigA.asc. Here it is. -- Here are the byte sizes and signatures on the PGP distribution files: 221332 pgp23A.zip -----BEGIN PGP MESSAGE----- Version: 2.3a iQBgAgUALDamv8o9of2GWqfzAQGvxwJY1JGKdQjcPSjV1CUU1AxcMvVwzKcVO4QO vxHL0839qW/P+Sj2YmRot4bsh48PbmW2KsUJ72L7mIu/i6GiLCYaNM00yXRWwjkI uocX =tHOr -----END PGP MESSAGE----- 547178 pgp23srcA.zip -----BEGIN PGP MESSAGE----- Version: 2.3a iQBgAgUALDanLco9of2GWqfzAQFhWwJXYF+1/vgA7kAEwWNKaLnAhFmAHgM9RDpf nJXOJCYD7zhHHegS4hMSro/E5fcshcPNmrpZSOpbooa7pV+Q7Dql6EXb4heweplf nWYL =n6A2 -----END PGP MESSAGE----- 680985 pgp23A.tar.Z -----BEGIN PGP MESSAGE----- Version: 2.3a iQBgAgUALDanZco9of2GWqfzAQEjBAJYuwyfs8rauWOmxuEJ8uXCk5SExkp1aQpN Onby3PCZ0z4KXw82D3EDk1yKc37BRb5soz/7iGYzWkHMAI3tcHq9HxnW0bkXJyEY 28eK =JlB2 -----END PGP MESSAGE----- 88070 pgp23docA.zip -----BEGIN PGP MESSAGE----- Version: 2.3a iQBgAgUALDangso9of2GWqfzAQHrsQJYq4HWvuenOBJ0PpVd3CnwdvtHo4H7EVvF CqLNk//TIB+mkGQMgN8i8RuPwcDQ75dBFMPYLzslnBy4ECNITngLzxyNqp0/4jqo lKJg =euMl -----END PGP MESSAGE----- If you want verify even more, you will se that there is a signature link that goes like this. Colin Plumb (colin@nyx.cs.du.edu) (who signed the archives) is certified by (Zimmermans new key) wich in turn is certified by (Zimmermans old key) This last key exists on every keyring since ver 2.0. so just get an older version and check if it matches. (I don't remember any conversion utility between ver 1.0 -> 2.0) We end up with that it is the same Zimmerman through all versions. If this sounds complicated, then just imagine the math behind. Info about how to verify the MAC-source code. Do also check for an additional file which should contain the signature for the MAC-version. > Newsgroups: alt.security.pgp,sci.crypt,comp.sys.mac.apps > From: grady@netcom.com (Grady Ward) > Subject: Re: MacPGP2.3 source available > Date: Tue, 20 Jul 1993 14:13:09 GMT > > Remember that if do *not* use PGP to verify the digital > signature for the BinHexed file, you will need to globally > change all occurrences of '- -' (hyphen space hyphen) to > simply '-' (hyphen) when the - - occurs at the beginning > of a line. > > Otherwise you will be unable to de-BinHex the source. > -- > grady@netcom.com Moby lexicons voice/fax (707) 826-7715 -- 31) My signature looks so dull. Can i fix that ? The signature below, with the initials in it, belongs to edgar@spectrx.saigon.com (Edgar W. Swank) On a question of how he did, here's his method. > The strange "Version" in my post is because I recompiled PGP and > I wanted to differentiate that version from any published version. > I had only wanted to affect the initial console message, but Version > is a global variable and affects armored file output as well. > > You can add any text you like (except -----END PGP ...?) after > BEGIN PGP SIGNATURE (either before or after Version) and before > the blank line. Try it. You can also enter any text you want after > the END PGP SIGNATURE line. Would a personal touch on the signature interfere with other PGP-utilities ? -----BEGIN PGP SIGNATURE----- Version: 2.3a.1/EWS iQCVAgUBLEkCet4nNf3ah8DHAQE53AP/ecGsGp09rX1y1CqcMI02utJ4hdcRTCTk tUYOnyCIo4drPEZQ7oPaR0XN+IaU9mSTDouO6z3PszuVj+AZVlBum6GTNw5wFaZu K38pLHTUyTIJc/nxf2mhXo1Xv3gU1eWvhgnpxI8qrih8N8xZimE0vKWHL26SIWOS uRJl0FwSQtw= =M37F -----END PGP SIGNATURE----- 32) Signed archive against virus. Suggestion to ftp-site's and BBS:es. They already have routines that scans uploaded archives for any virus. If it's clean, then that archive is placed in some public area for download. If PGP is involved in this routines, then whenever a trusted site has verified that the archive is good, then why not also sign it ? I do. I have BAT-files that puts my signature into an extra ZIP-file which goes into the archive. + No renaming of the original filename. + If the unpacker don't care about verifying, he just unpacks as usual. + No need to get files from trusted sources, instead check that the signature belong to a trusted site. It's like buying a Coke in a dark bar at some unknown place in some forgotten country. If the can is closed, you know that you have got the original. No need to trust the bartender, the owner, or the country. + No need to keep separate files with signatures for archive files. Each archive contains it's own signature. + several signatures can be added to the same archive. + A permanent protection against whatever virus that might come. No quarterly update costs for any virus checker. + If the archive still contains any virus, then you know who to hang, and maybe it's even possible to trace the virus source from PGP's time stamp. - The included BAT-files and readme, steals about 7 KB. - The unpacker must have PGP, and the public key from the signer. Send me a mail for those BAT-files. Needs to be rewritten to C, for increased smartness. 33) Voting with PGP. scheme 1 Everybody send in their signed and encrypted vote to the vote counter. This is the simplest scheme, where security is replaced by total trust on the vote counter. Trust him to not cheat or reveal the votes. scheme 2 > Newsgroups: alt.security.pgp > From: jln2@cec2.wustl.edu (Sammy D.) > Subject: Re: can pgp vote ? > Date: Mon, 12 Jul 1993 21:26:42 GMT > >> How about secret voting? How can anonymousity be guaranteed >> in electronic voting procedures based on Public Key >> Cryptography ? > > You would, I think, need a trusted third party. Said party > is the Auditor, because they provide auditability of the results. > Organization desiring a vote (called Counter), generates a list > of disposable, one-shot, RSA secret and public keys. Counter > sends list of voters and (quasi-)public keys to auditor, who > shuffles and sends one key to each voter. Voter sends response > signed with (quasi-)public key back to Counter via Auditor, who > ensures message is untraceable. Counter can decrypt the messages > and ensure one-to-one correspondence with original list of keys. > > Before completion of the election, no one other than Voter, > Auditor and Counter must know values of any keys, public or > secret. After election, all keys and votes may be disclosed > to audit the count. > > Note that everyone signs everything that passes through their > hands, except that Voters don't sign votes with their own > personal keys, only with the one-shots. Any RSA-type notary > can provide the auditing function. The vote you send in should preferably be a digit, so the length of the encrypted vote can't be used to guess your selection. Like this: BLANK ASC 506 contains: "this is a blank vote" BLUE ASC 486 contains: "blue" 34) I have changed e-mail address, how can i let the world know ? Also useful of you want to add a change to your userID from say, miss lonely, to Mrs married Lets you change your netaddress without loosing your correspondents, since the key servers (which you feed with your updated netaddress) probably have a longer lifetime than your current netaddress. or rephrased. The key servers are the phone book, and with your keyID, everybody can ask for your current e-mail address. Add you new e-mail address as an alias, and yet another alias which says that the old address should be ignored. Upload your new key to the key servers. By each change, your public key will grow bigger and bigger. If the size becomes a problem, then create a new keypair, and certify it with your old keypair. On your old key, add 2 final alias message saying: "get the shorter instead" and "disable this one" Now you start distributing your new key, and are still able to receive mail encrypted to your old key, from those who haven't received your new key. By time, your old key will be less and less used. However, as mentioned, try in the longest to avoid several keys. Do also check the related question: "What's a proper PGP-add. ?" -- 35) How do i make a BIG distribution list ? Ah ... You are running a successful newspaper, and your subscribers don't fit into the command line. try this. pgp -seat 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 \ 0x9 0xa 0xb 0xc 0xd 0xe 0xf This will encrypt to everybody in your public key. Use different public key ring's according the status of the subscribers. Like VIP's, normal, and sneak readers. And make sure the sneak reader don't tamper with your key rings so he gets the VIP-issue. (you know, some people would do anything to save money) details in PGPDOC2:DOC section; "selecting keys via Key ID" If you just want to send a short christmas greeting to all your subscribers, then the recipients list will become bigger then the message alone. To reduce that overhead, just do the encryption in several parts. like this. pgp -seat 0x0 0x1 0x2 0x3 0x4 0x5 pgp -seat 0x6 0x70 0x8 0x9 0xa pgp -seat 0xb 0xc 0xd 0xe 0xf -- 36) Using non-English characters between MAC, PC, AMIGA, UNIX. Translationtables between different environments. Details in PGPDOC2.DOC, sections; "Sending ASCII Text Files Across Different Machine Environments" "TEXTMODE - Assuming Plain text is a text file" "CHARSET - Specifies Local Character set for Text Files" For proper CR/LF handling, the sender must specify the -t flag in his command line, or in CONFIG.TXT, place the line 'TEXTMODE = on' ISO 8859-1 = latin1 = the canonical text which is used by PGP. This is also the standard for AMIGA and MS Windows. A table showing the decimal codes in some character sets for some common characters in the larger Scandinavian languages. +----------------+---------------+-------+-----------------------+ | | IBM Code page | Apple | ISO Standard | | Character | 437 850 | Mac | 8859-1 646-SE 646-SE2| +----------------+-------+-------+-------+-------+-------+-------+ | Left quote << | 256 | 256 | 307 | 253 | --- | --- | | Right quote >> | 257 | 257 | 310 | 273 | --- | --- | | Paragraph PI | --- | 364 | 246 | 266 | --- | --- | | Section SE | --- | 365 | 244 | 247 | --- | --- | | A-acute A' | --- | 265 | 347 | 301 | --- | --- | | a-acute a' | 240 | 240 | 207 | 341 | --- | --- | | A-dieresis A: | 216 | 216 | 200 | 304 | 133 | 133 | | a-dieresis a: | 204 | 204 | 212 | 344 | 173 | 173 | | A-grave A! | --- | 267 | 313 | 300 | --- | --- | | a-grave a! | 205 | 205 | 210 | 340 | --- | --- | | AE AE | 222 | 222 | 256 | 306 | --- | --- | | ae ae | 221 | 221 | 276 | 346 | --- | --- | | A-ring AA | 217 | 217 | 201 | 305 | 135 | 135 | | a-ring aa | 206 | 206 | 214 | 345 | 175 | 175 | | E-acute E' | 220 | 220 | 203 | 311 | --- | 100 | | e-acute e' | 202 | 202 | 216 | 351 | --- | 140 | | Eth -D | --- | 321 | --- | 320 | --- | --- | | eth -d | --- | 320 | --- | 360 | --- | --- | | O-dieresis O: | 231 | 231 | 205 | 326 | 134 | 134 | | o-dieresis o: | 224 | 224 | 232 | 366 | 174 | 174 | | O-slash O/ | --- | 235 | 257 | 330 | --- | --- | | o-slash o/ | --- | 233 | 277 | 370 | --- | --- | | Thorn TH | --- | 347 | --- | 336 | --- | --- | | thorn th | --- | 350 | --- | 376 | --- | --- | | U-dieresis U: | 232 | 232 | 206 | 334 | --- | 136 | | u-dieresis u: | 201 | 201 | 237 | 374 | --- | 176 | +----------------+-------+-------+-------+-------+-------+-------+ These "larger Scandinavian languages" also have a 7-bit code set. This is the same as ASCII, with some replacements. It is typically used by Unix. A-dieresis A: [ a-dieresis a: { A-ring AA ] a-ring aa } O-dieresis O: \ o-dieresis o: | A last minute addition, wich seems to found the problem. > From: seggers@semyam.dinoco.de (Stefan Eggers) > Date: 6 Aug 93 22:07:59 +0200 > Subject: Re: non-English characters >... >> How can non-English characters be used between MAC, PC, >> AMIGA, UNIX. ? (that nasty 8-bit) >... > I made some experiments with CHARSET and CLEARSIG and discovered > that I can not set CHARSET on the command line. > >> ... Who has succeeded to send an >> nonenglish text from PC -> MAC ? Which where the settings ? > > 1st I signed a text with CHARSET=latin1 and CLEARSIG=on with an > umlaut. (umlaut is, i guess, an AMIGA /laszlo) > > 2nd I changed (in the signed text) the code the umlaut has in latin1 > to the code it has in codepage 850. > > 3rd I changed CHARSET in config.txt (see above). > (to codepage 850 ? /laszlo) > > 4th The signature was OK. :-) > > I did not experiment with CLEARSIG=off but I expect that this will > work as expected. Just try what I did with CLEARSIG=off and see > what codes PGP gives back in step 4. > seggers@semyam.dinoco.de So. Whith a translationprogram between the different charactertables, it should be possible to verify a signed plaintext, no matter where it was created. Dig into your harddisk and send me your findings. 37) How do i set up a RAM-drive, and why ? (MSDOS) copied from the doc's in PGPSHE22 The RAM Drive ~~~~~~~~~~~~~ Some people have grown up on Windows' smart drive and DOS Shells and have forgotten what oldish things like RAM drives are all about. In issues such as privacy however, a RAM drive is an extra safety net to insure that your secret key is not compromised in any way. Here's how to set one up. Insert this line into your CONFIG.SYS file: DEVICE=C:\DOS\RAMDRIVE.SYS 1024 /e If you have a 386 or better computer, you could type "DEVICEhigh" instead of DEVICE to load the RAMDRIVE.SYS driver into high memory, but its only about 6K so its not crucial. The 1024 block of memory (1 meg) is the size of your RAM drive, and the switch "e" (/e) means you wish to use "extended" memory for your virtual drive. Reboot your computer for these changes to take effect. Your RAM drive will be given the next letter after your physical hard drive, i.e., if you have a single hard drive "C:" like most people, the RAM drive will be called "D". Type "cd d:" at the DOS prompt and you are in your RAM drive. The advantage of creating and using a RAM drive for PGP is that the RAM drive "D" is not physical, but located only in memory. That way when you shut down your computer, PGP disappears with it, and any trace of your secret key as well. Advanced PGP users keep the critical PGP files (CONFIG.TXT, PGP.EXE, PUBRING.PGP, SECRING.PGP, etc.) on a floppy that they carry around with them and only use PGP in their virtual RAM drives. When you want to enter a PGP session, just put the floppy in, and type "copy a:*.* d:" and your PGP files will be in the RAM drive. You can do this and still keep a copy of PGPShell in a C:\PGPSHELL directory to use PGP. Before starting a PGP session, just type "set pgppath=d:" at the DOS prompt, (or insert this command in your AUTOEXEC.BAT file if you use PGP often) to tell DOS that you've put PGP in a RAM drive. PGPShell will look at the DOS environment and see that PGP is located in the D: drive, and work on everything in there. Don't worry about loading PGPShell into your RAM drive; PGPShell itself is harmless and contains nothing that would compromise your secret key ring. Don't forget to copy the contents of the RAM drive back onto your floppy after exiting PGPShell, especially if you've added to, deleted or otherwise modified your keys. Once you shut off your computer anything located in RAM memory will be gone with it! Consult those old dusty DOS manuals for more information on creating and using RAM drives. 38) Can i hide PGP on my PC ? (MSDOS) copied from the doc's in PGPSHE22 "The Hidden Directory ~~~~~~~~~~~~~~~~~~~~ The hidden directory is the oldest trick in the book (and many a bane to system admins trying to clean up directory trees). Although far from foolproof, the hidden directory will slow down nosy co-workers who may be snooping on your computer while you're at lunch. Let's say you're not paranoid enough to warrant the use of a RAM drive but you still don't want anyone knowing you use PGP. Here's the next best thing: Go into a mundane directory tree like \DOS or \WINDOWS\SYSTEMS where no one ever looks and create a subdir called something harmless like "SYS" or "BIN". Copy all of your PGP stuff into that directory (let's say C:\DOS\BIN for example.) Then get back out to C:\DOS and type: "ATTRIB +H BIN" from the DOS prompt. Using the DOS "Attribute" command, you've hidden (+H) the BIN subdirectory from view. Its still there, but someone would have to know what they were doing to find it. (If you want to see it type "ATTRIB BIN" from the DOS prompt.) When you want to use PGP, just type "set pgppath=c:\dos\bin" at a DOS prompt and you're set. Here's a good batch file to use (which you can hide as well) that can be located anywhere along the DOS path: @echo off set pgppath=c:\dos\bin cd \pgpshell pgpshell Call the batch file something dumb like "READ_DIR.BAT" or hide it by using ATTRIB like this: ATTRIB +H READ_DIR.BAT so that the pgppath statement is not compromised easily. Whenever you want to use PGP just type READ_DIR and everything will load for you. This isn't 100%, as I stated before, but its good enough to fool most people since they won't mess around with something that they don't even know is there. If people or police are specifically looking for PGP or encrypted messages on your system, then you're screwed anyway; call a lawyer." end of extracted part from the doc's to PGPSHE22. An extra naming trick that works IF the co-worker dont load Norton Comander. Call the subdirectory; BIN wich will append a non-visible character at the end of BIN. If he dont know about that invisible character, he wont get in. You must also add that in-visible character in you BAT-file. 39) How to override the randomnumbers. (randseed.bin) copied from the doc's in PGPSHE22 "The Paranoid Encryptor ~~~~~~~~~~~~~~~~~~~~~~ This one is courtesy of the handful of paranoid people that warned me to be careful because, as a result of PGPShell "they" will be out to get me. Nevertheless, there may be occasions when the enemy is very real, and you cannot afford to have your encrypted messages cracked by those naughty NSA Cray computers. One way in which a computer is able to crack your message is by applying a consistent mathematical algorithm (a brute force attack) against your message until a pattern emerges that spells out words. Your RANDSEED.BIN 24-byte file (Random Seed Binary) is where PGP draws its material from when it comes time to encrypt your message. A computer is not able to generate truly random acts on its own, thats why PGP needed you to monkey-type at random when you first created your personal keys. If PGP can't find a RANDSEED.BIN file, it will create a seed file "on the fly" and ask you to bang away on your keyboard just before encrypting. By inserting a line at the end of the above READ_DIR batch file like this: "del c:\dos\bin\randseed.bin", you'll create a new seed file each time you use PGP. This will blow any pattern that could possibly develop over time (during which the attacker is amassing your encrypted messages and studying each of them for patterns). PGP's own RANDSEED.BIN file does a good job of providing enough material for encryption, but this option is still a "safety net" of sorts for the truly paranoid." Now, lets see what's in the bible; PGPDOC2.DOC section; "Random Numbers" "This random seed file should be at least slightly protected from disclosure, to reduce the risk of an attacker deriving your next or previous session keys. " ^^^^ ^^^^^^^^ Does this not mean, that if i start and end every session by encrypting a useless file, then any links to next, or previous randomnumber is broken ? Would that not be a more convenient way ? Having a BAT-file doing this, there is no need to play piano on the keyboard. More from same section. "If you feel uneasy about trusting any algorithmically derived random number source however strong, keep in mind that you already trust the strength of the same conventional cipher to protect your messages. If it's strong enough for that, then it should be strong enough to use as a source of random numbers for temporary session keys." Comments are welcome on this issue, since it comes and goes. I for myself, will instead try to get someone to sign my key. THAT is a weaker point. Unsorted 40) Can the Public Key concept be explained without any math ? Imagine a ordinary mailbox. People put in their mail in the top, and the postman has a special key that opens the bottom of the mailbox. Only the postman has this key. If everybody now had a private mailbox, with a big sign telling who the owner is, then still anyone could drop any mail into it, and be sure that only the owner can read it. Because only the real owner have the private key which open the bottom of the mailbox. So, the label on your own mailbox is your public key, and your private key is the key which you use to open the bottom of the mailbox. This analogy don't explain how digital signatures works, but it is mainly the same thing but reversed. [does someone have a similar simple analogy for digital signatures ?] -- 41) currently empty. 42) What is a rubber house attack ? The question might sound stupid, but is for us who don't have English as our native language. (this explanation came from a friend who eats detective stories, is it correct ?) A rubber house are those plastic/rubber tubes that are used to watering a garden. I your are beaten with a piece of such tube, on the soft parts of your body, it will create internal bleedings, but a minimum of marks that can be seen. Only heroes in films/books can withstand such an attack. All we rest will probably sing whatever passphrase we are asked for. This is the cheapest and fastest way to read your correspondence There was a discussion about how to guard against this. I guess it ends up on something like; an arrangement in advance which makes whatever you know, useless information. Could somebody summarise that scheme ? Is "Rubber house attack" a formal phrase ? That is; does it exists in the index in books ? -- 43) How safe is "for your eyes only" ? No safety at all. There are a lot of utilities that could grab that screen text, but it is convenient. No need to remember to cleanup. (did'nt PGP created temporary files where it also could be grabbed ?) -- 44) What can a wiretapper find out about a message ? Nothing more than what could be expected from a normal traficanalyze. But let's go trough it. By adding the line; verbose = 2 In CONFIG.TXT he will get these details: - Who the recipient(s) keyID is. He already knows the recipients networkaddress from the mail packet itself. - The time stamp of when the message was encrypted. This is usually close to the time stamp in the mail packet itself. If you believe that the time stamp of encryption gives away any clues, then just randomly change the computer clock to an earlier date, before encryption, and keep the real date inside the message. This might on the other hand confuse utilities that rely on the encryption time stamp. (is there any such utility ?) - He can se if the message is conventionally encrypted, or if a recipient is selected. Signed text is meant to be seen, so that's no secret. - If you are asked to resend a message, maybe because it was corrupted, You could re encrypt it first, to not gave away a hint of that it is a re transmission. (don't ask me what conclusions that can be drawn from the knowledge of a re transmission. but why give hints if it can be easily avoided) Assumptions of: - The number of characters used in the text. To make a message appear bigger than it is, append random data at the end. - How you administrate your correspondence. If one of the keyID's always is yourself, he can assume that you keep an encrypted backlog of your outgoing mail. If your keyID is NOT one of the recipients, He might assume that you store information in plain text, or rely on our memory. High volume users will probably not rely on memory. -- 45) Where should problems be reported ? For MSDOS related problems, send a mail to edgar@spectrx.saigon.com (Edgar W. Swank) for MAC: > From: grady@netcom.com (Grady Ward) > Subject: MacPGP2.3 source available > Date: Tue, 20 Jul 1993 00:50:44 GMT > ... > The authors of this port prefer to remain anonymous. > Questions and comments are welcome concerning this source; > please direct them to alt.security.pgp [preferred], sci.crypt, > or comp.sys.mac.apps. > ... For Unix-related problems, mail Colin Plumb (colin@nyx.cs.du.edu) and of course, the net, could give advices. I falled into this trap recently. Just downloaded a new version, used the old trusted version to verify the new one, and the verification failed. I pulled the alarm bell hard. Just to later find out that i have mixed files from the old version into the new one. That is mr big bug. Hopefully i am forgiven. -- 46) A list of non-bugs * I can remove my private key without even beeing prompted for a passphrase. Then anyone could remove my private key. Yes. a simplier way is to erase your private keyring (secring.pgp) So therefore it's no point to protect against such key removal. Maybe one could add some warning message for those who don't have a backup against accidental removal. -- 47) What's a proper PGP-add. ? [any better phrase for those oneliner's that use to be in the .sig-file ?] One suggestion is this style. 32C539/90 DA 9E 3E C0 AA 59 B2 46 3B 73 81 5B 7B 83 1B That one-liner says everything. + The first Hex-part tells what unique keyID your correspondents should ask for on the key servers. + The second longer part is the key fingerprint. An even stronger check, In case you somehow gets a wrong public key with the same keyID. [there was a calculation about the statistical chance to get 2 keyID's wich where same. Could it be reposted ?] If you have several keys with different sizes, add a one-liner for each of them too. Also add the keysize at the beginning, so people can select the keysize they wish to use. Do also check the related question: "I have changed e-mail address, how can i let the world know ?" -- end of part1 (2) Part 2 (2) Hints & Tricks using PGP selected topics from alt.security.pgp Files/programs 50. Existing utilities. 51. patches, and utilities in pipeline 52. Where are the latest version ? 53. Which is the minimum files needed ? 54. Where are the language files ? 59. ftp-able additional readings. Yet unanswered questions Anything official about what comes in next version ? "curious" Where can i read old postings from alt.security.pgp ? Does it exists a place where all utility's are stored ? How can i activate this "kill file" thing ? Files/Programs 50) Existing utilities. This section will hopefully grow to contain a list of every utility that has been written. Could authors of different utilities send me a mail about latest version, a description, if source code is available, and where to get it. Get the source code, pgp23srcA.zip and unpack with 'pkunzip -d pgp23srcA.zip' to get all included utilities to come up nicely sorted in subdirectorys. Have not yet checked it's content, but at van-bc.wimsey.bc.ca /pub/crypto/PGP/ there is this file; 2028 Mar 09 12:13 pgp-interface-jason-steiner.z " Subject: Front End Announcement: PGP with TAPCIS Sender: usenet@ttinews.tti.com (Usenet Admin) Reply-To: 72027.3210@compuserve.com Date: Tue, 3 Aug 1993 00:58:17 GMT TAPCIS is a popular navigator/offline message reader used on PCs to access CompuServe. An add-on program, TAPPKE (TAPcis Public Key Encryption), has been uploaded to the CompuServe TAPCIS Support Forum library under "scripts and tools;" this program is an interface between TAPCIS message-writing facilities and PGP. When you compose messages in TAPCIS, they get collected into a batch in a .SND file along with some control information about where and how the messages are to be posted or mailed; next time you go online to CompuServe, TAPCIS processes any messages waiting in its .SND files. The TAPPKE add-on can be run before you do this transmission step. TAPPKE scans messages in a .SND file, and any message that contains a keyword (##PRIVATE## or ##SIGNATURE##) is extracted and just that message is handed to PGP for encryption or signature, then reinserted into the .SND file for transmission. All this is a simplified interface to make it more convenient to encrypt/sign messages while still using the normal (and familiar) message composition features of TAPCIS. TAPPKE doesn't do any encryption itself, it merely invokes an external encryption engine to perform the indicated tasks; you can even use it with encryption programs other than PGP if you set up a few environment variables so TAPPKE will know what encryption program to run and what command-line arguments to feed it. The default configuration assumes PGP. I don't see any point in posting TAPPKE anywhere besides on CompuServe, since the only people who would have any use for it are TAPCIS users, and they by definition have access to the CompuServe TAPCIS forum libraries. However, it's free (I released it to the public domain, along with source code), so anyone who wants to propagate it is welcome to do so. ... Some mailers apparently munge my address; you might have to use bsmart@bsmart.tti.com -- or if that fails, fall back to 72027.3210@compuserve.com. Ain't UNIX grand? " rat-pgp.el ========== rat-pgp.el is a GNU Emacs interface to the PGP public key system. It lets you easily encrypt and decrypt message, sign messages with your secret key (to prove that it really came from you). It does signature verification, and it provides a number of other functions. The package is growing steadily as more is added. It is my intention that it will eventually allow as much functionality as accessing PGP directly. The most recent version of rat-pgp.el is always available via anonymous FTP at ftp.ccs.neu.edu, directory /pub/ratinox/emacs-lisp/rat-pgp.el. mailcrypt.el ============ > From: jsc@monolith.mit.edu (Jin S Choi) > Newsgroups: gnu.emacs.sources,alt.security.pgp,alt.security.ripem > Subject: mailcrypt.el (mail encryption/decryption using RIPEM and/or PGP) > Date: 01 Aug 1993 12:45:52 GMT > ... > This is an elisp package for encrypting and decrypting mail. I wrote > this to provide a single interface to the two most common mail > encryption programs, PGP and RIPEM. You can use either or both in any > combination. > ... > ;; available from the elisp archive. (where is that elisp archive ?) At 6 Aug. the version was 0.2b. "Some of the new features include: VM mailreader support. Support for addresses with spaces and <>'s in them. Support for using an explicit path for the encryption executables. Key management functions. The ability to avoid some of the prompts when encrypting. Assumes mc-default-scheme unless prefixed." -- PGPPAGER ver. 1.1 Stored on any ftp-site ? > Newsgroups: alt.security.pgp > From: abottone@minerva1.bull.it (Alessandro Bottonelli) > Subject: pgppager 1.1 sources > Date: Tue, 6 Jul 1993 11:37:06 GMT > > ... > /* pgppager, designed to be possibly integrated with elm mail reader > * ... > * This programs reads from a specified file or from stdin if no file is > * specified and creates three temporary files (header, encrypted, and > * trailer) as needed, in order to store the header portion in clear text, > * the encrypted portion still in cypher text, and the trailer portion of > * the clear text. Then, if applicable, the clear text header is outputted, > * the encrypted portion is piped through pgp as needed, then the trailer > * (if any) is outputted. THIS PROCESS IS TRANSPARENT TO NON PGP ENCRYPTED > * TEXTS > * ... > */ " MSDOS PGPSHE22 PGPShell v2.2 is a dramatic update to this easy-to-use program that makes using Philip Zimmermann's Pretty Good Privacy (PGP) public-key encryption software easy. Supports all of PGP's command-line arguments with a graphical user interface (GUI), mouse, windowed popup boxes with scroll bars for easy UserID, footprint, and signature key viewing on your public key ring. Built-in file viewer for reading decrypted messages. Use your favorite text editor to compose messages then automatically encrypt them. Requires PGP (ver 2.0 or higher), can run on any PC XT, AT, 286+, mono or color. Mouse optional. Freeware. available as 65430 Aug 3 11:40 garbo.uwasa.fi [128.214.87.1] /pc/crypt/pgpshe22.zip and Hieroglyphic Voodoo Machine BBS at 1.303.443.2457 The source code for ver 1.0 is in PGPSHELL.PAS. (source code available also for ver 2.2 ?) MENU.ZIP Menushell for MSDOS. (Requires 4DOS or Norton's NDOS) exists at ghost.dsi.unimi.it (ask archie about 4DOS, a comand.com replacement) HPACK78 PGP-compatible archiver 114243 Nov 20 07:08 garbo.uwasa.fi:/pc/arcers/hpack78.zip 146470 Dec 3 01:01 garbo.uwasa.fi:/pc/doc-soft/hpack78d.zip 511827 Dec 3 14:46 garbo.uwasa.fi:/pc/source/hpack78s.zip 667464 Dec 5 16:43 garbo.uwasa.fi:/unix/arcers/hpack78src.tar.Z where hpack78.zip is the MSDOS executable, hpack78d.zip is the Postscript documentation, hpack78s.zip is the source code, and hpack78src.tar.Z is the source code again but in tar.Z format (note that the latter is a tiny bit more recent that hpack78s.zip and contains changes for the NeXT). There is a (rather primitive) Macintosh executable somewhere on garbo as well, possibly /mac/arcers/hpack78mac.cpt. OS/2 32-bit versions of HPACK available for anonymous FTP from the UK. `ftp.demon.co.uk' [158.152.1.65] in ~/pub/ibmpc/pgp .. pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz (In order of preference - one of 'ems bound to work) PGPUTILS.ZIP at ghost.dsi.unimi.it /pub/crypt/ a collection of BAT-files, and PIF-files for windows. VMS mail script Could the author please send me a description wich can be added here ? I remember a post about a REXX script for OS/2 ? Where is it ? -- 51) patches, and utilities in pipeline Patches Send a mail to the author(s) to get these. > From: tri@snakemail.hut.fi (Timo Rinne) > Newsgroups: comp.os.386bsd.misc,alt.security.pgp > Subject: PGP-2.3a hide command line arguments > Date: 30 Jul 93 04:36:10 GMT > ... > I hacked a patch for pgp version 2.3a to hide it's command line > arguments so that they can not be seen from ps(1) output. It seems to > work ok in 386bsd. I haven't tested it on other systems but it should > work on BSD 4.3 systems that are _NOT_ based on MACH. > ... In Pipeline This list will hopefully avoid double work, or maybe joined forces. > Newsgroups: alt.security.pgp > From: ratinox@denali.ccs.neu.edu (Richard Pieri) > Subject: Re: pgp frontend for windows? > Date: Mon, 2 Aug 1993 16:27:51 GMT >... > Andreas> Is there a pgp frontend for windows for the bloodiest > Andreas> beginner to use pgp efficiently? > > There is one, but it's only in alpha/beta testing, and it does no > cryption yet. The bugs are being worked out of the interface first > before full PGP functionality is integrated. There will probably be an > announcement when a fully functional version is ready for public > consumption. 52) Where are the latest version ? The PGPDOC2.DOC, section; "Licensing and Distribution" tells you to send a mail to info-pgp-request@lucpul.it.luc.edu for a more complete ordered list. It is maintained by Hugo Miller at hmiller@lucpul.it.luc.edu He also writes: " For those lacking ftp connectivity to the net, nic.funet.fi also offers the files via mail. Send the following mail message to mailserv@nic.funet.fi: ENCODER uuencode SEND pub/crypt/pgp23srcA.zip (edited to reflect the new version) SEND pub/crypt/pgp23A.zip This will deposit the two zipfiles, as 15 batched messages, in your mailbox with about 24 hours. Save and uudecode." If you are in a hurry, here are some places. nic.funet.fi (128.214.6.100) /pub/crypt/ src.doc.ic.ac.uk /pub/computing/security/pgp/ black.ox.ac.uk (129.67.1.165) /src/security/ ghost.dsi.unimi.it (149.132.2.1) /pub/crypt/ soda.berkeley.edu (128.32.149.19) /pub/cypherpunk/pgp (on soda, corrupted files, discovered <= 22 Jul. -93, seems to be fixed, since all files are now dated 22 Jul.) van-bc.wimsey.bc.ca; /pub/crypto/PGP/2.3a/ (political restrictions) (notable with van-bc ..., is that they have all versions back to 1.0 in a nice order. In /pub/crypto/PGP, there is also a file; 10144 Mar 04 12:43 pgp-sitelist wich might point you to even more sites that carry pgp. Maybe it's hugh's list) filenames: 422851 Jul 12 09:31 macpgp2.3.cpt.hqx (MAC executable) 680985 Jul 8 16:15 pgp23A.tar.Z (packed for Unix) 221332 Jul 8 16:24 pgp23A.zip (MSDOS executable) 88070 Jul 8 16:29 pgp23docA.zip (doc's only) 998 Jul 8 16:29 pgp23sigA.asc (signatures for authenticy) 547178 Jul 8 16:45 pgp23srcA.zip (source code) MAC, sourcecode black.ox.ac.uk (129.67.1.165), /src/security (in hqx format ?) ghost.dsi.unimi.it /pub/crypt/ netcom.com (192.100.81.100) /pub/grady/ filename: 1027543 Jul 19 16:47 macpgp2.3src.sea.hqx.pgp OS/2 ftp.uni-erlangen.de /pub/pc/os2/fauern/crypt gate.demon.co.uk. /pub/ibmpc/pgp 337360 Mar 12 16:47 pgp22os2.zip (any 2.3A for OS/2 ?) AMIGA ftp.dfv.rwth-aachen.de /pub/amiga/comm filename: 88502 Jun 19 15:36 PGP2_3Amiga.lha (without doc's.) The amiga versions 2.3 and 2.3A should exists in an official version, somewhere on the net. (i could not find them) and also in non official versions. (the one above could be unofficial.) This duplication might have been corrected, when you read this. In the meantime, to get PGPAmiga23a.lha for AMIGA, mail to simons@peti.GUN.de (Peter Simons) There is no ver 2.3A for MAC. Where can ATARI compiled versions be found ? -- 53) Which is the minimum files needed ? PGP.EXE CONFIG.TXT RANDSEED.BIN SECRING.PGP PUBRING.PGP LANGUAGE.TXT PGP.HLP This can be reduced even more. LANGUAGE.TXT. English users can probably delete this file. All English messages are already inside PGP.EXE. Spanish/French users, edit away all messages on that other language you don't use. That reduces the size with 1/3. PGP.HLP. Remove everything except for those commands that you are using. CONFIG.TXT can be reduced to just a few lines. Edit away all the information texts. If you are only using conventional encryption, then PGP.EXE and CONFIG.TXT is all you need. Finally, ZIP the files to a self extracting archive, and the resulting size is around 100 Kb. Hint 1: Place the file on a floppy, which then acts like a smart card for access to your files. Hint 2: Compress with PKZIP's encryption too. -- 54) Where are the language files ? Swedish; contact Laszlo Baranyi Norwegian; contact Thor Oddleif Kristoffersen (Thor's email address might change later during -93) For other languages the doc's points you to Colin Plumb (colin@nyx.cs.du.edu) 59) ftp-able additional readings "RIPEM Frequently Asked Questions" maintained by . Posted monthly. Look for it in alt.security.ripem Especially it's section about attack forms. [stored where ?] A description of IDEA in postscript is at ghost.dsi.unimi.it; area; /pub/crypt/ filename; 92081 Jan 14 1993 IDEA.chap.3.ps.Z "The Privacy & Anonymity on Internet" is on rtfm.mit.edu area: /pub/usenet/news.answers/net-privacy/ filenames: 60098 Jul 11 01:54 part1 50127 Jul 11 01:54 part2 42339 Jul 11 01:54 part3 It's loaded with pointers of where to read more on almost everything. Like this: " <6.2> How can I learn about or use cryptography? NIST (U.S. National Institute for Standards and Technology) publishes an introductory paper on cryptography, special publication 800-2 ``Public-Key Cryptograhy'' by James Nechvatal (April 1991). Available via anonymous FTP from csrc.ncsl.nist.gov (129.6.54.11), file pub/nistpubs/800-2.txt. Also via available anonymous FTP from wimsey.bc.ca as crypt.txt.Z in the crypto directory. Covers technical mathematical aspects of encryption such as number theory." and " More general information can be found in a FAQ by Paul Fahn of RSA Laboratories via anonymous FTP from rsa.com in /pub/faq.ps.Z. See the `readme' file for information on the `tex' version. Also available as hard copy for $20 from RSA Laboratories, 100 Marine Parkway, Redwood City, CA 94065. Send questions to faq-editor@rsa.com." This is 52 pages of postscript or Tex. Answers To FREQUENTLY ASKED QUESTIONS About Today's Cryptography September 14, 1992 (But if you don't have, neither postscript or Tex, i am told that there is a hacked version of this FAQ, which is an ascii'fied Tex-version, send me a mail if you want me to check it out... ) The FAQ from sci.crypt is on rtfm.mit.edu:/pub/usenet-by-group/sci.crypt. [ Any more recommended readings ?] soda.berkeley.edu, The cypherpunks FTP site, is also loaded with text. An over view is in it's 'readme.soda' They also have a mailing list, described like this, in "The Privacy & Anonymity on Internet" " <6.3> What is the cypherpunks mailing list? Eric Hughes runs the `cypherpunk' mailing list dedicated to ``discussion about technological defenses for privacy in the digital domain.'' Frequent topics include voice and data encryption, anonymous remailers, the Clipper chip. Send email to cypherpunks-request@toad.com to be added or subtracted from the list. (Traffic is sometimes up to 30-40 messages per day.) ..." At the end of pgpdoc2.doc, there are also several pointers to "Computer-Related Political Groups". Also check political.doc in your PGP package. -- Yet unanswered questions -Anything official about what comes in next version ? "curious" -Where can i read old postings from alt.security.pgp ? Try ghost.dsi.unimi.it. What subdirectory ? Are there more sites ? (or ripem.msu.edu, for users in the U.S. and Canada who are citizens or permanent residents) -Does it exists a place where all utility's are stored ? Currently, No. But you might try the collections at ghost.dsi.unimi.it and Hieroglyphic Voodoo Machine BBS at 1.303.443.2457 [more suggestions ?] -How can i activate this "kill file" thing ? -Whats that "regexp" on the keyservers ? Could someone mail an example on how to get all keys from say finland ? end of part2 (2) Subject: Hints & Tricks, correction 1 Message-ID: <1993Aug9.004807.18797@kth.se> Date: Mon, 9 Aug 1993 00:48:07 GMT Sender: usenet@kth.se (Usenet) Reply-To: laszlo@kth.se (Laszlo Baranyi) Organization: Royal Institute of Technology, Stockholm, Sweden Lines: 29 Nntp-Posting-Host: kth.se Correction to # 31 in "Hints & Tricks using PGP". This is how it should be. My apologise to Edgar. 31) My signature looks so dull. Can i fix that ? According to edgar@spectrx.saigon.com (Edgar W. Swank): You can add any text you like (except -----END PGP ...?) after BEGIN PGP SIGNATURE (either before or after Version) and before the blank line. Try it. You can also enter any text you want after the END PGP SIGNATURE line. Would a personal touch on the signature interfere with other PGP-utilities ? I guess you mean some of the mailer-interfaces that are packaged with, but are not really part of, PGP. Answer is, I don't think so, but you will have to test to find out. Entering text after the END PGP SIGNATURE line is the least likely to cause problems because many mailers add text there anyway (auto sig). PGP will skip any non-blank lines after BEGIN PGP SIGNATURE (or any BEGIN PGP ... armored code) until it reaches a blank line. But utilities might not follow that same standard; they might, for example, just look for the single Version: line which is all that's presently generated by PGP. Laszlo