PGP *2.0* available
Randy Bush
> Note that this FTP server can't be used from systems behind many
> packet-filtering gateways. It tries to contact our authd, and fails
> because we don't allow incoming connections, and the FTP connection hangs.
> Note that it *does* allow connections from systems that don't run authd, so
> it's not a security issue, it's just a poor implementation of the auth
> client.
Nope. Some folk chased this bug down. Turns out thet NET/1 distribution has
this bug where if connection B gets no host, then it kills an already existing
connection A. I.e. the firewall's denial of authd kills the ftp.
NET/2 fixed the bug. But all NET/1-derived systems will see this problem.
randy
--
ra...@psg.com ...!uunet!m2xenix!randy
David Vincenzetti
in the ~ftp/pub/crypt directory on site ghost.dsi.unimi.it.
I bet most of you already know what PGP is, anway here are two extracts
from the documentation included in the archive:
[from: readme.doc]
> Pretty Good Privacy version 2.0 - READ ME FIRST
>
>
> You are looking at the README file for PGP release 2.0. PGP, short for
> Pretty Good Privacy, is a public key encryption package; with it, you
> can secure messages you transmit against unauthorized reading and
> digitally sign them so that people receiving them can be sure they
> come from you.
>
>
[from: pgpdoc1.txt]
> Synopsis: PGP uses public-key encryption to protect E-mail and data
> files. Communicate securely with people you've never met, with no
> secure channels needed for prior exchange of keys. PGP is well
> featured and fast, with sophisticated key management, digital
> signatures, data compression, and good ergonomic design.
> [...]
> Contents
> ========
>
> Quick Overview
> Why Do You Need PGP?
> How it Works
> Installing PGP
> How to Use PGP
> To See a Usage Summary
> Encrypting a Message
> Signing a Message
> Signing and then Encrypting
> Using Just Conventional Encryption
> Decrypting and Checking Signatures
> Managing Keys
> RSA Key Generation
> Adding a Key to Your Key Ring
> Removing a Key from Your Key Ring
> Extracting (copying) a Key from Your Key Ring
> Viewing the Contents of Your Key Ring
> How to Protect Public Keys from Tampering
> How Does PGP Keep Track of Which Keys are Valid?
> How to Protect Secret Keys from Disclosure
> Revoking a Public Key
> Advanced Topics
> Sending Ciphertext Through E-mail Channels: Radix-64 Format
> Environmental Variable for Path Name
> Setting Configuration Parameters: CONFIG.TXT
> Vulnerabilities
> Trusting Snake Oil
> PGP Quick Reference
> Legal Issues
> Acknowledgments
> About the Author
>
>
>
>
> Quick Overview
> =============
>
> Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a
> high security cryptographic software application for MSDOS, Unix,
> VAX/VMS, and other computers. PGP allows people to exchange files or
> messages with privacy, authentication, and convenience. Privacy
> means that only those intended to receive a message can read it.
> Authentication means that messages that appear to be from a
> particular person can only have originated from that person.
> Convenience means that privacy and authentication are provided
> without the hassles of managing keys associated with conventional
> cryptographic software. No secure channels are needed to exchange
> keys between users, which makes PGP much easier to use. This is
> because PGP is based on a powerful new technology called "public key"
> cryptography.
>
> PGP combines the convenience of the Rivest-Shamir-Adleman (RSA)
> public key cryptosystem with the speed of conventional cryptography,
> message digests for digital signatures, data compression before
> encryption, good ergonomic design, and sophisticated key management.
> And PGP performs the public-key functions faster than most other
> software implementations. PGP is public key cryptography for the
> masses.
Ciao, David
--
David Vincenzetti -*- System Administator and C Programmer
Dip. di Scienze dell'Informazione, Internet: vi...@ghost.dsi.unimi.it
V. Comelico 41, I-20133, Milano, Italy Phone : +39 2 55006 392
($PK available by finger$) Fax : +39 2 55006 373
fr...@d012s436.sniap.mchp.sni.de
: The program Pretty Good Privacy program, version 2.0, is available
: in the ~ftp/pub/crypt directory on site ghost.dsi.unimi.it.
:
: I bet most of you already know what PGP is, anway here are two extracts
: from the documentation included in the archive:
Thanks for the pointer to the ftp site
: [from: readme.doc]
:
: > Pretty Good Privacy version 2.0 - READ ME FIRST
delete, delete
: > files. Communicate securely with people you've never met, with no
: > secure channels needed for prior exchange of keys. PGP is well
As was recently discussed here, secure exchange of public keys is in
general not possible without a secure channel. This is because
although the keys do not need to be _confidentiality_ protected,
they very often need to be _integrity_ protected.
What the PGP docs should say is that you don't need to keep your
public key _confidential_.
: David Vincenzetti -*- System Administator and C Programmer
: Dip. di Scienze dell'Informazione, Internet: vi...@ghost.dsi.unimi.it
: V. Comelico 41, I-20133, Milano, Italy Phone : +39 2 55006 392
: ($PK available by finger$) Fax : +39 2 55006 373
--
Frank O'Dwyer Disclaimer:
Siemens-Nixdorf AG I will deny everything
Tel. : +49 (89) 636-40639 Fax. : +49 (89) 636-45860
e-mail: Frank....@sniap.mchp.sni.de <--Use this, reply-to is broken
Barry Margolin
>The program Pretty Good Privacy program, version 2.0, is available
>in the ~ftp/pub/crypt directory on site ghost.dsi.unimi.it.
Note that this FTP server can't be used from systems behind many
packet-filtering gateways. It tries to contact our authd, and fails
because we don't allow incoming connections, and the FTP connection hangs.
Note that it *does* allow connections from systems that don't run authd, so
it's not a security issue, it's just a poor implementation of the auth
client.
--
Barry Margolin
System Manager, Thinking Machines Corp.
bar...@think.com {uunet,harvard}!think!barmar
Perry E. Metzger
>vi...@ghost.dsi.unimi.it (David Vincenzetti) writes:
>: The program Pretty Good Privacy program, version 2.0, is available
>: in the ~ftp/pub/crypt directory on site ghost.dsi.unimi.it.
>:
>
>general not possible without a secure channel. This is because
>although the keys do not need to be _confidentiality_ protected,
>they very often need to be _integrity_ protected.
>
>What the PGP docs should say is that you don't need to keep your
>public key _confidential_.
Having examined it, PGP has addressed this question by providing for
keys to be certified by "authorities", those being people that you
designate. This allows you to have your friends, with whom you have
securely exchanged keys (presumably in person) to in turn certify new
keys. There are also key compromise certificates. There is also neat
built in radix-64 handling, a good unix port, apparent ports for VMS,
amigas and ataris, and all sorts of other goodies, and now it uses
IDEA as its base conventional cypher instead of Bass-O-Matic. Its all
quite winningly slick. I'd look at the docs before saying "yes, but
does it do X".
--
Perry Metzger pmet...@shearson.com
--
Just say "NO!" to death and taxes.
Extropian and Proud.
Marc VanHeyningen
[ ... ]
>built in radix-64 handling, a good unix port, apparent ports for VMS,
>amigas and ataris, and all sorts of other goodies, and now it uses
>IDEA as its base conventional cypher instead of Bass-O-Matic. Its all
>quite winningly slick. I'd look at the docs before saying "yes, but
>does it do X".
It looks like a pretty decent program. I'm glad it makes a closer
attempt to comply with the RFCs than the old version, though it looks
like it was more with the objective of doing different encoding rather
than complying per se; it doesn't look possible for PGP to decrypt
messages sent by some other program, or vice-versa. It appears to have
been designed with a near-paranoid rabidity about security, which is good.
It's too bad it (through little fault of its own) fails the test of "Can
I use it without fear of being sued, fired or expelled?" for us here in
the U.S. For that matter, the addition of IDEA [depending which legal
forecasts you believe] may allow our European friends to share in this
sensation. (Would multiple DES encryptions with some padding provide
comparable security without legal clouds?)
(Oh, and there's just one "But does it..." offhand: does it allow for
authentication without encrypting or encoding the plaintext [i.e. doing
the MIC-CLEAR encryption type]?)
I wonder if it would be possible to port it to use RSAREF and make it
"legitimate". It would sort of change PGP's "flavor" though.
--
Marc VanHeyningen mvan...@whale.cs.indiana.edu MIME accepted
What's the use of a good quotation if you can't change it?
- Doctor Who
Steven L. Johnson
>I wonder if it would be possible to port it to use RSAREF and make it
>"legitimate". It would sort of change PGP's "flavor" though.
Not being familiar with "RSAREF" and assuming for purpose of argument
that PKP's patent covering "all public key" implementations is valid
why would the use of RSAREF make PGP legitimate? Is there licensing
for it that is not available for PGP or is it for some reason not
covered? I guess I'm looking for your definition of legitimate.
-Steve
Marc VanHeyningen
"Legal to use for noncommercial purposes in the United States (and maybe
Canada, I forget)."
RSAREF is an implementation of RSA for which one may obtain a license
from RSADSI. (Actually, it would be nice if, now that RSA is available
under license anyway, they would just allow licensing of PGP under the
same terms, but that would make too much sense.)
(Oh, and I guess that patent holders of IDEA aren't as shortsighted as
PKP, so the legal cloud I mentioned doesn't seem to exist. Who knows,
maybe it could get hacked into RIPEM.)
--
Marc VanHeyningen mvan...@whale.cs.indiana.edu MIME accepted
Patriotism is, in fact, the *first* refuge of the scoundrel.
Rich Winkel
>(Oh, and there's just one "But does it..." offhand: does it allow for
>authentication without encrypting or encoding the plaintext [i.e. doing
>the MIC-CLEAR encryption type]?)
It allows you to generate signatures separate from the plaintext file.
That sounds adequate for your purposes.
Rich
Gumby - The unknown user
>Not being familiar with "RSAREF" and assuming for purpose of argument
>that PKP's patent covering "all public key" implementations is valid
>why would the use of RSAREF make PGP legitimate? Is there licensing
>for it that is not available for PGP or is it for some reason not
>covered? I guess I'm looking for your definition of legitimate.
Although I hate to be a spoil-sport...
The license that you must agree to in order to obtain RSAREF is
quite restrictive. It rules out any use other than that of a
hobbyist nature.
I'm probably not the only one who destroyed their copy of this
package just because of the licensing agreement.
--
Rob McKeever VE7ICJ rmck...@sfu.ca mcke...@sfu.ca 604-463-3863
"Actually, I'm a little envious of Murphy Brown. At least she's guaranteed
of coming back this fall" - Dan Quayle, on the sitcom 'Murphy Brown'
-*- Standard Disclaimers should be adequate -*-
Nonsenso
-> public key _confidential_.
It DOES say so. The manually explicitely states that you should share your
public key with as many people/systems as possible. What you _should_ keep
confidential is your private key.
There could have been a problem with pgp 1.0 when keys could not be
certified. That way it'd be easy for anyone to forge a key on your user-ID
and sit in the middle of communications. PGP 2.0 features this
key-certification and is thus a lot stronger regarding to key-security
than the 1.0 version.
Wietse Venema
>Note that this FTP server can't be used from systems behind many
>packet-filtering gateways. It tries to contact our authd, and fails
>because we don't allow incoming connections, and the FTP connection hangs.
>
>Note that it *does* allow connections from systems that don't run authd, so
>it's not a security issue, it's just a poor implementation of the auth
>client.
It's a kernel bug. It reportedly happens with Ultrix, HP-UX and others
(ghost.dsi.unimi.it runs HP-UX). When the authd connection fails with
ICMP not reachable, these kernels zap all existing connections to that
host. The bug is there for all to see in the 4.3BSD NET/1 code.
How to find out if you have the bug:
% ftp 131.155.70.100
(suspend ftp when connection has been established)
% telnet 131.155.70.100 111
The telnet command should fail. If this messes up the ftp connection
your kernel has the bug.
Wietse
Aleksander Wittlin
PGP 2.0 as it is now, won't run on SUN3 systems.
Make is trying to use sparc.s rsalib assembler primitives
and crashes (all Suns are supposed to be sparcs!).
Is there a simple fix of that problem?
A. Wittlin
Perry E. Metzger
Yes. Just tell it not to use the sparc assembly code rsa lib and to
use the C code instead. Its just a matter of hacking the makefile
slightly.
Adam Shostack
>Hello,
> PGP 2.0 as it is now, won't run on SUN3 systems.
>Make is trying to use sparc.s rsalib assembler primitives
>and crashes (all Suns are supposed to be sparcs!).
No, they're not. All Sparcstations are based on sparc. No Sun3 is.
Sun3s are usually 68020 or 68030
>Is there a simple fix of that problem?
Yeah, learn a bit more about your machine. :)
Adam
Adam Shostack ad...@das.harvard.edu
What a terrible thing to have lost one's .sig. Or not to have a .sig
at all. How true that is.
Terry Ritter
In <71601551...@utopia.hacktic.nl> Nons...@utopia.hacktic.nl
(Nonsenso) writes:
>There could have been a problem with pgp 1.0 when keys could not be
>certified. That way it'd be easy for anyone to forge a key on your user-ID
>and sit in the middle of communications. PGP 2.0 features this
>key-certification and is thus a lot stronger regarding to key-security
>than the 1.0 version.
Really? So how do we "certify" a key without already having a
previously-certified key from the other end?
How does the first guy certify his key to others so they can certify
their keys to him?
---
Terry Ritter rit...@cactus.org
Jyrki Kuoppala
>In article <1992Sep7.1...@ghost.dsi.unimi.it>,
>vi...@ghost.dsi.unimi.it (David Vincenzetti) writes:
>
>> The program Pretty Good Privacy program, version 2.0, is available
>> in the ~ftp/pub/crypt directory on site ghost.dsi.unimi.it.
It is also available on host nic.funet.fi, directory
pub/unix/security/crypt (in both MS-DOG and Unix versions).
Nic.funet.fi might have better connectivity to the net than the host
in Italy - at least I had some trouble ftp'ing to Italy. Your mileage
may vary.
//Jyrki
Perry E. Metzger
You and your friend Alice get together and sign each others keys in
person. Later, Bob sends you a key of his, signed by Alice. Since you
know Alice's key to be valid, you suspect that Bob's is. This way, a
small number of people you trust can validate a large number of other
people who you can't meet in person.
I'd just read the manual. Most questions are answered.
Aleksander Wittlin
>A. Wittlin
Indeed it is! Thanks to Stephan <neu...@informatik.uni-kl.de> for the following patch to
Makefile:
*** Makefile.sun3 Fri Sep 11 13:12:16 1992
--- Makefile Tue Sep 8 00:07:06 1992
***************
*** 97,113 ****
sunspc:
$(MAKE) all CC="ccspc -B/1.8.6/sun4 -ansi -w -I/usr/include" \
! CFLAGS="-O -DUNIX -DHIGHFIRST -DPORTABLE -DMPORTABLE"
# Sun with gcc
sungcc:
! $(MAKE) all CC=gcc LD=gcc \
! CFLAGS="-O -DUNIX -DHIGHFIRST -DPORTABLE -DMPORTABLE"
# Sun with standard cc: compile with unproto
suncc: unproto/cpp
! $(MAKE) all CC=cc LD=cc \
! CFLAGS="-Qpath unproto -O -DUNIX -DHIGHFIRST -DPORTABLE -DMPORTABLE"
sysv:
$(MAKE) all CPP=/usr/lib/cpp \
--- 97,114 ----
sunspc:
$(MAKE) all CC="ccspc -B/1.8.6/sun4 -ansi -w -I/usr/include" \
! CFLAGS="-O -DUNIX -DHIGHFIRST -DUNIT32 -DMERRITT" \
! OBJS_EXT=sparc.o
# Sun with gcc
sungcc:
! $(MAKE) all CC=gcc LD=gcc OBJS_EXT=sparc.o \
! CFLAGS="-O -DUNIX -DHIGHFIRST -DUNIT32 -DMERRITT" \
# Sun with standard cc: compile with unproto
suncc: unproto/cpp
! $(MAKE) all CC=cc LD=cc OBJS_EXT=sparc.o \
! CFLAGS="-Qpath unproto -O -DUNIX -DHIGHFIRST -DUNIT32 -DMERRITT"
sysv:
$(MAKE) all CPP=/usr/lib/cpp \
-----------------
A. Wittlin
Perry E. Metzger
>In article <1992Sep7.1...@ghost.dsi.unimi.it>,
>vi...@ghost.dsi.unimi.it (David Vincenzetti) writes:
>
>> in the ~ftp/pub/crypt directory on site ghost.dsi.unimi.it.
>> David Vincenzetti -*- System Administator and C Programmer
>
>verified using PRZ's public key. Ver2.0 doesn't seem to do this. Does
>this bother anybody?
Remember, PRZ is under legal orders not to have anything to do with
new PGP development. The DOS executable of the new distribution does
come signed by Branko Lankester, the ring leader of the overseas
development effort. Admittedly, there is no way to know if Branko's
signature is trustworthy.
Ari Juhani Huttunen
! Remember, PRZ is under legal orders not to have anything to do with
! new PGP development. The DOS executable of the new distribution does
! come signed by Branko Lankester, the ring leader of the overseas
! development effort. Admittedly, there is no way to know if Branko's
! signature is trustworthy.
Would it not be possible for Branko Lankester to publish his public
key in the BYTE Magazine (for example)? I don't know what a 1/4 page
advertisement costs, but it can't be that much. And the key would have
to be published only once.
--
...............................................................................
Ari Huttunen Any similarity to other alien life forms
is purely coincidental.
<Alien 3 misquote>
Bill Stewart 908-949-0705 erebus.att.com!wcs
] Would it not be possible for Branko Lankester to publish his public
] key in the BYTE Magazine (for example)? I don't know what a 1/4 page ad[...]
You don't really need to do that - broadcasting to the net can be adequate,
provided the ostensible author of the broadcast has the opportunity to
repudiate fake broadcasts, and to receive enough separate transmissions
of the broadcast that it's unlikely they've all been spoofed on their
way back to him. Spread it around by ftp...
--
Pray for peace; Bill
#Bill Stewart 908-949-0705 w...@anchor.ho.att.com AT&T Bell Labs 4M312 Holmdel NJ
# Any technology distinguishable from magic is not sufficiently advanced ...
Rob Stampfli
>verified using PRZ's public key. Ver2.0 doesn't seem to do this. Does
>this bother anybody?
>
>I don't have an absolutely trustable certificate of PRZ's public key.)
Yeah, I wondered about this, too. The probable answer is that Phil does
not officially have anything to do with pgp2.0. He could, of course,
give his secret key to the current developers, but I suspect his
attorneys probably advised him not to do anything such that this release
could be linked back to him.
It would be nice if the current folk would issue their own signature.
Another reason may be that they are using MD5 in 2.0. Does anyone know
if pgp2.0 is compatible with pgp1.0?
--
Rob Stampfli r...@colnet.cmhnet.org The neat thing about standards:
614-864-9377 HAM RADIO: kd...@n8jyv.oh There are so many to choose from.
Ragnar Nielsen
>Another reason may be that they are using MD5 in 2.0. Does anyone know
>if pgp2.0 is compatible with pgp1.0?
No, according to the documentation it's not. Looks like we all have to
distribute and collect new keys.
Hardly surprising, as one of the great new features of version 2.0 is
key authentification, where a trusted third party can vouch for a to you
unknown public key. Lack of key authentification was a serious deficiency
in PGP 1.0, and I guess the key layout had to be changed in order to
incorporate this feature.
Note: I haven't studied the source too closelyy, so I might be in error
on this one, but it seems logical to me.
The good news is that the authors of version 2.0 have said that they
intend to do what they can to keep future versions of PGP key-compatible
with version 2.0.
regards,
ragnar
Hugh Miller
>Another reason may be that they are using MD5 in 2.0. Does anyone know
>if pgp2.0 is compatible with pgp1.0?
Not key-compatible, i.e., you can't use your old keys & keyrings
with the new version, and there is no conversion utility. You've got to
redo your keyrings from the ground up.
This was intentional. The idea is that with the new keyring
management features, you will more or less automatically build a good
level of security in the right way -- the FIRST time.
-=- Hugh
--
Hugh Miller | Dept. of Philosophy | Loyola University of Chicago
Voice: 312-508-2727 | FAX: 312-508-2292 | hmi...@lucpul.it.luc.edu
In this world of sin and sorrow, there is always something to be thankful
for; as for me, I rejoice that I am not a Republican. -- H. L. Mencken
Seth Robertson
There appears to be a minor bug in PGP which can cause PGP to
reference element -1 in an array. When I compiled it with gcc -O on
my Sun, it caused PGP to go into an infinite loop, though of course
anything could happen.
I came across it when, er, satisfying my intellectual curiosity.
The patch is in unified diff format (see the latest version of patch
on prep.ai.mit.edu).
--- config.c~ Sat Sep 5 04:46:51 1992
+++ config.c Sat Sep 12 15:27:22 1992
@@ -309,9 +309,12 @@
}
}
+
/* Skip trailing whitespace and add der terminador */
- while( ( theCh = inBuffer[ lineBufCount - 1 ] ) == ' ' || theCh == '\t' )
- lineBufCount--;
+ if (lineBufCount)
+ while( ( theCh = inBuffer[ lineBufCount - 1 ] ) == ' ' || theCh == '\t' )
+ lineBufCount--;
+
inBuffer[ lineBufCount ] = '\0';
/* Process the line unless its a blank or comment line */
Greg - Byrd
Although I have not been involved in the infringement side of patent law, I'd
like to make a few observations. If any of my comments are wrong, please corre
ct
me since I'm no patent person.
My understanding of hobbyist use of patented technology is that you are free to
build a unit for your own use, regardless of whether it is patented. This is
essential in order to foster a creative environment. You are not allowed to
make money off it, nor to distribute your unit to third parties. As an example
I
have certainly read magazine articles detailing how to build a hobbyist project
based on patented technology. The entire patent system is designed to *disclos
e*
and dessiminate technology. If you want to keep it secret don't patent it ;=)
The concept of patented algorhythms seems flaky at best. But the law is aimed
at preventing unfair commercial competition against the developer. As long as
the law accomplishes that, I shouldn't think there is anything to worry about.
Well, this is further astray than the lock disussion. (Which I liked. Anyone
know how to defeat sidebar locks like Medecos? Email me! ;=)
Don't let me sidetrack the discussion, but I welcome email from anyone who
knows the law to work differently from my understanding stated above. I'll
share any significant variation which affect PGP distribution.
Greg Byrd ---> Bell (803) 686-4575
Snail Island Technical Group / 3 Cardinal Ct. #619
Hilton Head Island / SC 29926
Email gr...@cup.portal.com
----- Uh, I didn't say that. My boss said it! Yeah. Yeah. That's it. -----
Hugh Miller
Probably best to move this discussion to misc.legal.computing or
comp.patents (or both), since sci.crypt isn't set up for such. Meet you
there.
PeterClaus Gutmann
se...@startide.ctr.columbia.edu (Seth Robertson) write:
>There appears to be a minor bug in PGP which can cause PGP to
>reference element -1 in an array. When I compiled it with gcc -O on
>my Sun, it caused PGP to go into an infinite loop, though of course
>anything could happen.
>
>[patch for config.c, ~line 310]
Gack! I recognize that code (turns bright red). I actually ripped it out of
another program I've been working on and it seems to have lost something in
the translation. The original line of code (before it got stuck into PGP) reads
(sound of dusty archives being searched):
while( bufCount && \
( theCh = buffer[ bufCount - 1 ] ) == ' ' || theCh == '\t' )
bufCount--;
Apologies to anyone who's been inconvenienced by this problem....
Peter.
--
pg...@cs.aukuni.ac.nz || pet...@kcbbs.gen.nz || pe...@nacjack.gen.nz
(In order of preference)
Marc Thibault
(Rob Stampfli) writes:
...
> It would be nice if the current folk would issue their own signature.
It's hard to believe they don't read this group - how about it
guys? Just a short message with your public keys for comparison.
>
> Another reason may be that they are using MD5 in 2.0. Does anyone know
> if pgp2.0 is compatible with pgp1.0?
It isn't, but they have put in the hooks to assure upward
compatibility in future versions.
MOREOVER:
To get the value of this, it seems to me that we all should take
the earliest opportunity to begin broadcasting public keys and
maybe convincing some ftp archives to start collecting them. I'm a
newbie on Usenet so I have no idea how best to do this.
Re spoofing: If I'm worried that someone's got a wedge in my mail,
I could send messages to a number of people who have published
their keys. The message would be encrypted with their public key
and contain copies of my public key inside and out. The message
would include instructions like "Please reply with a single word
'tomato' if both are the same and 'asparagus' if they are not,"
using a different pair of words for each message.
Whoever is spoofing would have no way of knowing what to do,
unless they were also spoofing everybody else. The best they could
do is stop the replies entirely, which would tell me what I needed
to know. At this point I would send my public key under cover to a
bunch of people with a request to broadcast it, along with a
disclaimer on the spoofer's key.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0
mQBNAiqxYTkAAAECALfeHYp0yC80s1ScFvJSpj5eSCAO+hihtneFrrn+vuEcSavh
AAUwpIUGyV2N8n+lFTPnnLc42Ms+c8PJUPYKVI8ABRG0I01hcmMgVGhpYmF1bHQg
PG1hcmNAdGFuZGEuaXNpcy5vcmc+
=HLnv
-----END PGP PUBLIC KEY BLOCK-----
---
Marc Thibault | | Any Warming,
ma...@tanda.isis.org | Oxford Mills, Ontario | Global or otherwise,
CIS:71441,2226 | Canada | appreciated.
bo...@ids.net
>
> guys? Just a short message with your public keys for comparison.
Ok, here's mine.
> To get the value of this, it seems to me that we all should take
> the earliest opportunity to begin broadcasting public keys and
> maybe convincing some ftp archives to start collecting them. I'm a
> newbie on Usenet so I have no idea how best to do this.
I'm pretty new myself, (actually this is my first reply <G>)
but isn't the idea with PGP that a centralized place for keys
isn't needed or perhaps...wanted? I thought the whole idea is
that we personally trust the person acting as an "introducer".
> Re spoofing: If I'm worried that someone's got a wedge in my mail,
> I could send messages to a number of people who have published
> their keys. The message would be encrypted with their public key
> and contain copies of my public key inside and out. The message
> would include instructions like "Please reply with a single word
> 'tomato' if both are the same and 'asparagus' if they are not,"
> using a different pair of words for each message.
>
> Whoever is spoofing would have no way of knowing what to do,
> unless they were also spoofing everybody else. The best they could
> do is stop the replies entirely, which would tell me what I needed
> to know. At this point I would send my public key under cover to a
> bunch of people with a request to broadcast it, along with a
> disclaimer on the spoofer's key.
>
Whew! This is all new to me but I don't see the point in sending
a public key "under cover". It would seem to defeat the whole
purpose of having a public key. From what I read in the docs for
PGP20, it's totally up to me to make sure a public key is valid.
If I add a key to my keyring, I better make sure I know where I
got it from. And...no one that has my "real" public key can read
my stuff unless I lose control of my secret key. Again, all based
on levels of trust.
If I have this all wrong, I'll be more than willing to listen to
someone who knows more about public-key encryption than I do.
(which includes just about everyone <G>)
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0
mQCNAiq3Le4AAAEEAMZWWqB9U3zPOMjc9tQZEU9BViMqIjx0eY/g8ciWGmbhyInZ
3QRUF9I62iPU+R+GrGNpKSC8vNtVpAa5lzcMi/mvHlqhwt3Dk6okuWqgh/VnLXZT
7D/R8vUsKpfEL8i10sqlChxmIiaqGg0lNnsS2dVZeAxsCXNhgo/6FY8KKUyLAAUR
tC9Cb2IgRmF5bmUgPEJvYiBGYXluZS0+Q1lCRVJaT05FPjxib2JmZUBpZHMubmV0
Pg==
=3cYE
-----END PGP PUBLIC KEY BLOCK-----
Bob
~~~
Bob Fayne <bo...@ids.net>
Terry Ritter
In <57331154...@tanda.isis.org> ma...@tanda.isis.org (Marc Thibault)
writes:
> To get the value of this, it seems to me that we all should take
> the earliest opportunity to begin broadcasting public keys and
> maybe convincing some ftp archives to start collecting them. I'm a
> newbie on Usenet so I have no idea how best to do this.
This is incredibly dangerous.
No one can keep the same key forever; the only question is, "How
soon will the key be changed?" (Things happen: People leave,
strangers appear, fires occur, divorces happen, partnerships fail,
enemies are made, equipment is repaired, hackers get in, serious
investigations do "bag jobs" while the target is asleep, on vacation,
at a movie, etc., etc.)
Nor should anyone *want* to keep the same key: "Occasional" key
changes are *necessary* to terminate any access which somehow has
been "acquired" without the user's knowledge. Even more importantly,
key changes are necessary to limit the amount of data which could be
revealed by a *future* insecurity. The meaning of "occasional" is
the individual balance between the difficulty of key management and
the amount of information a user is willing to lose from a *single
insecure event.*
Without a protocol for assuring that any particular key is current,
accumulating public keys can only result in a file which is
increasingly composed of old keys, some of which will have been
disclosed. Any users who get disclosed keys will be completely at
risk. Nor can an old key be used to validate a new key (unless one
is willing to allow a single past (or future!) insecurity to disclose
all future data).
> Re spoofing: If I'm worried that someone's got a wedge in my mail,
> I could send messages to a number of people who have published
> their keys. The message would be encrypted with their public key
> and contain copies of my public key inside and out. The message
You may have some "published" keys, but you cannot know