Ä 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 <date>
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 <date>"
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 <prz@acm.org>
searching key ring file 'pubring.pgp' for keyID 67F70B
sig! 67F70B 1993/05/21 Philip R. Zimmermann <prz@sage.cgd.ucar.edu>
Key ring: 'pubring.pgp', looking for user ID "prz@sage".
pub 1024/67F70B 1992/07/22 Philip R. Zimmermann <prz@sage.cgd.ucar.edu>
An interpretation of this means that Zimmerman has used his
good old key, <prz@sage.cgd.ucar.edu>
to certify this newer one, <prz@acm.org>
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 <keyID> 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 <univerity>.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
<prz@acm.org> (Zimmermans new key)
wich in turn is certified by
<prz@sage.cgd.ucar.edu> (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 <keyID> 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 <filename> 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 <filename> 0x0 0x1 0x2 0x3 0x4 0x5
pgp -seat <filename> 0x6 0x70 0x8 0x9 0xa
pgp -seat <filename> 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 <alt-255> 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 <laszlo@instrlab.kth.se>
Norwegian; contact Thor Oddleif Kristoffersen <thork@ifi.uio.no>
(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 <mvanheyn@cs.indiana.edu>.
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 <hughes@toad.com> 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
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
