Article View: alt.security.pgp
Article #17Re: .plan as verification?
From: Vernon Schryver
Date: Sun, 27 Sep 1992 16:58
Date: Sun, 27 Sep 1992 16:58
64 lines
3936 bytes
3936 bytes
In article <1992Sep27.073429.5833@muddcs.claremont.edu>, ebrandt@jarthur.claremont.edu (Eli Brandt) writes: > In article <1992Sep26.165606.1@hamp.hampshire.edu> jyanowitz@hamp.hampshire.edu writes: > > Given the all the reasonable hullabaloo about verifying keys, what do > >people think about, in the interim, placing copies of our keys in our > >.plan (on unix and vms) so when people finger you, they can see a copy > >of it. Obviously, two flaws with this method are: > >a) someone could create a fake account... > >b) someone could intercept the finger requests. > > This is what I was planning to do... (as soon as I check over my > PGP). It would be possible, I suppose, to install high-speed > search-and-replace hardware on all routers. As I don't know what > the backbone connectivity is like, I don't know how feasible this is. > Probably expensive, though I'm sure the NSA would give its eyeteeth > for that kinda setup... An "application gateway" for ports 119, 79 and 25 at only one or two routers near you would probably be sufficient to destroy the use of .plan for any particular site. Most people do not have much redundancy in how they get to the rest of the Internet. As I understand it, most people have a single link to one nearby NSS. Some of us also have links via a CIX or other exchanger. Consider the small administrative leverage (i.e. court order, bribe, threat from government agent) needed to install such code at an NSS or even at the CIX. Or even at Uunet or PSI. If you want to be paranoid, stop and think of reasons other than incompetance for the infamous slowness of the NSS's. Maybe IBM &Co. are not so dumb after all. Maybe those rings are slow because they are already filtering and tracing traffic. (Personally, I think Occam's razor applies, and that such a conspiracy would require implausible intelligence and foresight from bureaucrats.) It is a standard drill to filter packets in routers based on address and port number. It is not at all hard to do a little re-writing for slow, low volume, low speed stuff like SMTP, NNTP, and finger. (Yes, 30-60MByte/day is "low volume".) Such a filtering TCP/IP router is standard, and for news, mail or finger, easy. It is the start of an Internet "firewall." It is the beginning of the machinery used to convert between X.400 and SMTP or FTP and FTAM, etc. The obvious way would be to pass finger requests, and then capture and not forward finger response until a human had a chance to produce a useful replacement. Who would notice transient finger failures? A smart agency would continually finger hosts looking for .plan's with keys to be prepared for the first real customer. For that matter, bad guys who care could easily spend the $100k/year to have humans watching for finger requests, to make the fix in real time. How many would notice if `finger joe@foo.edu` took 30 seconds instead of 5 seconds? Still and all, this entire argument is irrelevant. The difficulty with PGP is not cryptographic security, but simple software logistics. How many people have mail user agents that can comfortably handle encrypted traffic? Do many of your correspondents? Until most mail user agents can do not just MIME, but also encrypted text, until you don't have to ask your correspondent in the clear about their crypto facilities, this worry about cryptographic security is largely academic. Vernon Schryver, vjs@sgi.com
Technical Details
Message-ID:
<qclqg5k@rhyolite.wpd.sgi.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!ames!sgi!rhyolite!vjsReferences:
<1992Sep26.165606.1@hamp.hampshire.edu> <1992Sep27.073429.5833@muddcs.claremont.edu>Show Full Headers
Complete Article Headers
Newsgroups: alt.security.pgp,sci.crypt Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!ames!sgi!rhyolite!vjs From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: .plan as verification? Message-ID: <qclqg5k@rhyolite.wpd.sgi.com> Organization: Silicon Graphics, Inc. Mountain View, CA References: <1992Sep26.165606.1@hamp.hampshire.edu> <1992Sep27.073429.5833@muddcs.claremont.edu> Date: Sun, 27 Sep 1992 16:58:08 GMT Lines: 64