gnu@hoptoad.uucp (John Gilmore) (07/19/90)
Within the last two months I have had to warn two different sites
about passing proprietary traffic via hoptoad.
One was a computer company that was sending complete product plans for
a future product (still in development). They had routed the message
via sun, apple, and me, among others!
Another was a peripheral company which appeared to be sending the
C source code for the firmware that runs inside the peripheral. This
site had more sense, only sending it via pacbell and hoptoad, neither
of which is in the peripheral market. It turns out that they expected
there to be a direct link, but uucp was temporarily broken by the sysadmin,
and it got handed off to a mail router, which sent it indirectly.
System administrators should strongly remind their users that info sent
via ordinary Usenet or Internet mail is NOT private. It can be disclosed
at multiple locations along the way, either intentionally or by accident.
On many sites it can be read by ordinary users while parked there in
transit. There are no guarantees of privacy here, folks.
And I strongly suggest that any site that sends sensitive traffic,
NOT run an automatic uucp router. The router doesn't know what's an
internal site, what's an innocuous site, and what's a competitor's site.
--
John Gilmore {sun,pacbell,uunet,pyramid}!hoptoad!gnu gnu@toad.com
The Gutenberg Bible is printed on hemp (marijuana) paper. So was the July 2,
1776 draft of the Declaration of Independence. Why can't we grow it now?Makey@Logicon.COM (Jeff Makey) (07/20/90)
In article <11613@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >On many sites it can be read by ordinary users while parked there in >transit. On many sites in-transit mail can be *modified* by ordinary users, too. It's time to start encrypting mail, I guess. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
eps@toaster.SFSU.EDU (Eric P. Scott) (07/20/90)
...and you wonder why commercial sites are clamoring to get on the Internet. -=EPS=-
jim@ezx.uucp (Jim Littlefield) (07/20/90)
In article <11613@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >Within the last two months I have had to warn two different sites >about passing proprietary traffic via hoptoad. > > [deleted] > >And I strongly suggest that any site that sends sensitive traffic, >NOT run an automatic uucp router. The router doesn't know what's an >internal site, what's an innocuous site, and what's a competitor's site. One would expect that a site needing to send sensitive traffic would use some form of encryption. You never really knows what path e-mail will actually take to get to the target site. -- Jim Littlefield == ...!uunet!ezx!jim == Sunrise Software Systems, Inc.
shawn@marilyn.UUCP (Shawn P. Stanley) (07/21/90)
In article <11613@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >Within the last two months I have had to warn two different sites >about passing proprietary traffic via hoptoad. Maybe they should be passing it encrypted, if they don't want to drop the convenience of the net. -- Shawn P. Stanley shawn@marilyn.marilyn.mn.org bungia!marilyn!shawn {rosevax,crash}!orbit!marilyn!shawn
nanook@rwing.UUCP (Robert Dinse) (07/22/90)
In article <11613@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > System administrators should strongly remind their users that info sent > via ordinary Usenet or Internet mail is NOT private. It can be disclosed > at multiple locations along the way, either intentionally or by accident. > On many sites it can be read by ordinary users while parked there in > transit. There are no guarantees of privacy here, folks. The way I've handled this is to agree verbally on a password then crypt the message before sending it. Crypted data seems to make it through uucp ok and I've not seen too many systems that lack crypt. I'm sure it's not 100% secure, but it at least makes it difficult for ordinary users who weren't previously employeed by the NSA to look at it.
ralphs@halcyon.wa.com (Ralph Sims) (07/22/90)
nanook@rwing.UUCP (Robert Dinse) writes: > In article <11613@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: >> System administrators should strongly remind their users that info sent >> via ordinary Usenet or Internet mail is NOT private. It can be disclosed > The way I've handled this is to agree verbally on a password then crypt > the message before sending it. Crypted data seems to make it through uucp ok > and I've not seen too many systems that lack crypt. I'm sure it's not 100% > secure, but it at least makes it difficult for ordinary users who weren't > previously employeed by the NSA to look at it. ARC has a 'garble' feature that allows compressing a file and then allowing a password to be assigned to that file for un-arc'ing. This file can then be uu{xx}encoded and imported to a message. This may work for a large variety of systems, but I would imagine ARC hasn't been ported to _every_ platform. Also, I think some countries prohibit the transportation of encrypted data within their jurisdiction. I guess this may need to be addressed if one uses a path that uses a re-router in these areas. But if crypt could be distributed with Unix in these countries... (or is it?). -- Of all the things I've lost, I miss my mind the most...
ches@alice.UUCP (Bill Cheswick) (07/23/90)
> it at least makes it difficult for ordinary users who weren't > previously employeed by the NSA to look at it. It doesn't take the NSA to break crypt. It is quite easy, and there is software floating around that will help. (We moved crypt to /usr/games.) If you must use email for proprietary info, use DES encryption and avoid sites running pathalias. Bill Cheswick postmaster@research.att.com
celvin@EE.Surrey.Ac.UK (Chris Elvin) (07/23/90)
In article <716@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: >In article <11613@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >>On many sites it can be read by ordinary users while parked there in >>transit. > >On many sites in-transit mail can be *modified* by ordinary users, >too. It's time to start encrypting mail, I guess. > > :: Jeff Makey Encryption of mail won't stop users modifying it, just stop them making sense of it. How is the encryption key passed? Make the mail spooling area unreadable by 'joe user' and this problem is minimised. Better still, have a separate machine for hanging modems off. I use a 3/280 for ALL external network traffic, mail routing etc. NO user has access to this machine. C. -- Chris Elvin C.Elvin@EE.Surrey.Ac.UK "Beware of low flying butterflies!" Dept of Elec. Eng, University of Surrey, Guildford, Surrey, GU2 5XH. England. PHONE: +44 483 509104 FAX: +44 483 34139
ralphs@halcyon.wa.com (Ralph Sims) (07/24/90)
celvin@EE.Surrey.Ac.UK (Chris Elvin) writes: > In article <716@logicon.com> Makey@Logicon.COM (Jeff Makey) writes: >>In article <11613@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >>>On many sites it can be read by ordinary users while parked there in >>>transit. >>On many sites in-transit mail can be *modified* by ordinary users, >>too. It's time to start encrypting mail, I guess. > Encryption of mail won't stop users modifying it, just stop them making sense > of it. How is the encryption key passed? Good point to Part A, and for Part B: one form would be to use a 'scramble' of the message id number. This is unique from message to message, as far as I can tell. One means would be to swap the first and last two characters and increment the ascii code of everything in between by one, etc. Taking a CRC of the message id and adding your birthdate, etc. There's any number of schemes. > I use a 3/280 for ALL external network traffic, mail routing etc. NO user > has access to this machine. In-transit mail is more vulnerable than stored mail, I'd think. An unscrupulous organization could set themselves up as a host ("We'll forward ALL your mail for you--on OUR dime") and copy every bit of mail that passes through. Needless to say, this could be embarassing, expensive, etc. to the sender/recipient. The best defense is NOT to pass sensitive data via a 'public' network. Maybe this is a discussion for alt.security, and related groups. -- Of all the things I've lost, I miss my mind the most...
chris@vision.UUCP (Chris Davies) (07/24/90)
In article <118@rwing.UUCP> nanook@rwing.UUCP (Robert Dinse) writes: [discussing how to send company-confidential email] > The way I've handled this is to agree verbally on a password then crypt >the message before sending it. Crypted data seems to make it through uucp ok >and I've not seen too many systems that lack crypt. I'm sure it's not 100% >secure, but it at least makes it difficult for ordinary users who weren't >previously employeed by the NSA to look at it. The program 'crypt' does not exist outside the US, thanks to the DoD. Some systems have the crypt(3) library call, but by no means all. Thus Joe User has the additional hassle of writing their own crypt/decrpyt program... Crazy isn't it! Chris -- VISIONWARE LTD | UK: chris@vision.uucp JANET: chris%vision.uucp@ukc 57 Cardigan Lane | US: chris@vware.mn.org OTHER: chris@vision.co.uk LEEDS LS4 2LE | BANGNET: ...{backbone}!ukc!vision!chris England | VOICE: +44 532 788858 FAX: +44 532 304676 -------------- "VisionWare: The home of DOS/UNIX/X integration" --------------
karl@ficc.ferranti.com (Karl Lehenbauer) (07/24/90)
Regardless of the security problems, it is a violation of netiquette to do intra-company business over Usenet except by direct link, via uunet or after you have cleared it with all intervening sites. For inter-company business, I suppose using Usenet is OK for making initial contacts and seldom-sent low volume transfers (email to a site asking for more information, like uunet, for example), but not for lots of data, which would be abusive to your neighbors. Usenet mail isn't a valid tool for conducting important business, anyway, since it is unreliable. -- -- uunet!ficc!karl "I am here by the will of the people and I won't leave uunet!sugar!karl until I get my raincoat back." -- Metrophage
ergo@netcom.UUCP (Isaac Rabinovitch) (07/25/90)
In <118@rwing.UUCP> nanook@rwing.UUCP (Robert Dinse) writes: >In article <11613@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > The way I've handled this is to agree verbally on a password then crypt >the message before sending it. Crypted data seems to make it through uucp ok >and I've not seen too many systems that lack crypt. I'm sure it's not 100% >secure, but it at least makes it difficult for ordinary users who weren't >previously employeed by the NSA to look at it. I'm out of date on encryption software, but didn't there use to be "public key" algorithms? You make up a private key, pass it through a special procedure to produce a public key. You then publish the public key. Anybody who knows the public key can send you an encrypted message, but you need the private key to decrypt the message. Seems tailor-made for this problem. -- ergo@netcom.uucp Isaac Rabinovitch atina!pyramid!apple!netcom!ergo Silicon Valley, CA uunet!mimsy!ames!claris!netcom!ergo "I hate quotations. Tell me what you know!" -- Ralph Waldo Emerson
henry@zoo.toronto.edu (Henry Spencer) (07/25/90)
In article <1145@vision.UUCP> chris@vision.UUCP (Chris Davies) writes: >The program 'crypt' does not exist outside the US, thanks to the DoD... Au contraire, any Unix site that was in business early on has it, at least on an old distribution tape. Its export was perfectly routine until certain, uh, persons decided to get an Official Opinion on it, at which point the doors slammed shut. >... Thus Joe User >has the additional hassle of writing their own crypt/decrpyt program... There is quite a bit of crypto software, including implementations of DES and other relatively good cryptosystems (crypt(1) was poor), in circulation outside the US. Only DoD thinks that us furriners are incapable of writing crypto software ourselves. -- NFS: all the nice semantics of MSDOS, | Henry Spencer at U of Toronto Zoology and its performance and security too. | henry@zoo.toronto.edu utzoo!henry
shwake@raysnec.UUCP (Ray Shwake) (07/26/90)
ches@alice.UUCP (Bill Cheswick) writes: >It doesn't take the NSA to break crypt. It is quite easy, and there is software >floating around that will help. (We moved crypt to /usr/games.) If you must >use email for proprietary info, use DES encryption and avoid sites running >pathalias. The problem isn't pathalias per se, but smart mailers on intermediate sites who audaciously insist on second guessing source routing based on their own notion of "best path from here to ultimate destination".
karl_kleinpaste@cis.ohio-state.edu (07/27/90)
shwake@raysnec.uucp writes:
The problem isn't pathalias per se, but smart mailers on intermediate
sites who audaciously insist on second guessing source routing based
on their own notion of "best path from here to ultimate destination".
"au-da-cious \o-'dA-shus\ adj ... 1 a: intrepidly daring : adventurous
b: recklessly bold : rash 2: contemptuous of law, religion, or
decorum : insolent 3: maked by originality and verve"
If you send mail on a pass-through basis through my site, you'll darn
well put up with my idea of appropriate expenditures. I don't dial
California on a whim for just anybody. I'm not second-guessing at
all; I'm in charge here, so I'm first-guessing -- YOU are
second-guessing at what you think I'll let get through here.
If that's "audacity," so be it. Personally, I find it pretty @#$%
audacious that anyone thinks they can tell me how we at my site are
supposed to spend our money. Sheesh!
I don't run pathalias. I do maintain a paths file.
--karlbattan@qtc.UUCP (Jim Battan) (07/28/90)
While I agree with John and others that you shouldn't think of multi-hop
UUCP links as safe, I question John's propriety of looking at the
contents of the traffic passing through his site. Looking at other's
mail is an ethical breach, IMHO.
--
Jim Battan {uunet!sequent,sun!nosun}!qtc!battan +1 503 626 3081
Quantitative Technology Corp 8700 SW Creekside Place Beaverton, OR 97005
"Trees don't grow on trees, you know."matt@cds1.UUCP (Mathew Di Nicola) (07/28/90)
ergo@netcom.UUCP (Isaac Rabinovitch) writes: > I'm out of date on encryption software, but didn't there use to be > "public key" algorithms? You make up a private key, pass it through > a special procedure to produce a public key. You then publish the > public key. Anybody who knows the public key can send you an > encrypted message, but you need the private key to decrypt the > message. Seems tailor-made for this problem. > -- Yeah, the public key cipher that I'm familiar with is called RSA (Rivest Shamir Adelman) and was developed in 1978 at MIT. The program generates three 80-200 digit prime numbers. The first two can be published to all the world, and are used to encrypt data only. The only way to decrypt it is to use the third (secret) key. It works quite well, because you don't have to deal with DES-type single-key encryption/decryption. There's only one drawback -- encrypting, decrypting, and generating RSA keys takes a long time. Math coprocessors and 386s help a lot (everyone has a 386 with a coprocessor, right? ha ha...), but if security is desired, that's the way to go. Incidentally, with a 50-digit key, cryptanalasys takes 3.9 hours. With a 100-digit key, cryptanalasys takes 74 years (WITH a computer), and if you REALLY want security, a 500-digit key takes 4.2 * 10^25 years (the universe is only 1.5 * 10^10 years (roughly). If anyone is interested, I have a Shareware program for MS-DOS that will do RSA, DES and a few others.... e-mail me, and I'll figure out a way to get it to you. --Matt ------------------------------------------------------------------------------ Mathew Di Nicola Sacramento, CA, USA UUCP= pacbell!sactoh0!cds1!matt ------------------------------------------------------------------------------
henry@zoo.toronto.edu (Henry Spencer) (07/30/90)
In article <6iZZm1w162w@cds1.UUCP> matt@cds1.UUCP (Mathew Di Nicola) writes: >There's only one drawback -- encrypting, decrypting, and generating RSA >keys takes a long time... There is another: RSA is patented in the US, and the patent owners are actively defending it against infringement. (There is *no* "fair use" exemption for patents, so it does not matter what you are using it for, by the way.) -- The 486 is to a modern CPU as a Jules | Henry Spencer at U of Toronto Zoology Verne reprint is to a modern SF novel. | henry@zoo.toronto.edu utzoo!henry
gordon@sneaky.UUCP (Gordon Burditt) (07/31/90)
>>There's only one drawback -- encrypting, decrypting, and generating RSA >>keys takes a long time... > >There is another: RSA is patented in the US, and the patent owners are >actively defending it against infringement. (There is *no* "fair use" >exemption for patents, so it does not matter what you are using it for, >by the way.) Is there any legit way to use RSA? Assume two dozen people who have no affiliation with any government, cannot positively prove they are not Drug Dealers (tm), and live in the USA want to use RSA to communicate. Assume one of them has written a program to implement RSA. Now, does there exist a method by which these people, with their hands out offering the price of an IBM PC each to anyone (RSA Data Security?) who can legitimize their use of their own program, can be licensed to use RSA in a reasonable time (e.g. 30 days) without running out of the money on legal fees or NSA paperwork or lawsuits? Is the RSA key distribution scheme described in RFC 1113-1115 real and in operation, or is it someone's pipe dream that the NSA will never permit to exist? Gordon L. Burditt sneaky.lonestar.org!gordon
lear@turbo.bio.net (Eliot) (07/31/90)
Do you really want to take a less than optimal path in order to avoid a site that gets your mail delivered in a prompter, less expensive method? Do you know of any sites that are registered that are losing mail because of rerouting? -- Eliot Lear [lear@turbo.bio.net]
matt@cds1.UUCP (Mathew Di Nicola) (07/31/90)
henry@zoo.toronto.edu (Henry Spencer) writes: > In article <6iZZm1w162w@cds1.UUCP> matt@cds1.UUCP (Mathew Di Nicola) writes: > >There's only one drawback -- encrypting, decrypting, and generating RSA > >keys takes a long time... > > There is another: RSA is patented in the US, and the patent owners are > actively defending it against infringement. (There is *no* "fair use" > exemption for patents, so it does not matter what you are using it for, > by the way.) Hmmmm... that is interesting! This perticular program was written in England, and is being released as shareware in the U.S. This is very confusing since someone earlier mentioned that DES type encryption (and I assume the rest) can't be exported outside the U.S. Who currently holds the patents? --Matt ------------------------------------------------------------------------------ Mathew Di Nicola Sacramento, CA, USA UUCP= pacbell!sactoh0!cds1!matt ------------------------------------------------------------------------------
karl_kleinpaste@cis.ohio-state.edu (07/31/90)
fitz@wang.com writes:
Could you publish what you're willing to do, then, so that UUCP sites
aren't forced to second-guess?
DARR. That's all, just a preference for rightmost domain.frotz@drivax.UUCP (Frotz) (08/01/90)
fitz@wang.com (Tom Fitzgerald) writes:
] If you just mean you'll shortcut to the last FQDN in the path, never mind,
] I think that's pretty well understood by everyone.
OK. I'll byte. What is FQDN? I have not seen this before and
neither has anyone else locally.
--
Frotzkarl_kleinpaste@charcoal.com (08/01/90)
frotz@drivax.uucp writes: fitz@wang.com (Tom Fitzgerald) writes: ] If you just mean you'll shortcut to the last FQDN in the path, never mind, ] I think that's pretty well understood by everyone. OK. I'll byte. What is FQDN? I have not seen this before and neither has anyone else locally. FQDN == fully-qualified domain name, i.e., a dot-separated group of names which describe (e.g.) a host hierarchically within the universe of all hosts. "mesquite.charcoal.com," "tut.cis.ohio-state.edu," "turbo.bio.net," and "rutgers.edu" are FQDNs. "drivax" is an unqualified hostname (occasionally "OWHN," a one-word host name), as typically found in UUCP subsystems. "drivax.uucp" is a fake domain name, in that there is no top-level ".uucp" domain registered in the DNS (Domain Name System). It is frequently (usually?) recognized by convention (as is ".bitnet") but strictly-conforming Internet sites do not recognize it. I think I'm going to include a glossary of this stuff when I finish the FAQ articles on domain registration.
dww@stl.stc.co.uk (David Wright) (08/02/90)
In article <Tee6m2w162w@cds1.UUCP> matt@cds1.UUCP (Mathew Di Nicola) writes:
#confusing since someone earlier mentioned that DES type encryption (and
#I assume the rest) can't be exported outside the U.S.
You cannot export implementations (HW or SW) of the DES algorithm outside
the US without a licence (this is a COCOM regulation to make sure those
nasty Russions don't get it - no :-) !). But as the algorithm is public
its quite possible for people elsewhere to write their own implementation,
and people in Australia, Finland, the UK and (no doubt) many more have done
so. At least two are public-domain. So I could export them where I like.
But you (Matthew in California) couldn't.
It doesn't make sense, but its a Government regulation, it doesn't have to.
Regards, "None shall be enslaved by poverty, ignorance or conformity"
David Wright STL, London Road, Harlow, Essex CM17 9NA, UK
dww@stl.stc.co.uk <or> ...uunet!mcsun!ukc!stl!dww <or> PSI%234237100122::DWW
<or> /g=David/s=Wright/org=STC Technology Ltd/prmd=STC plc/admd=Gold 400/co=GB" Maynard) (08/02/90)
In article <KARL.90Jul31204311@mesquite.charcoal.com> karl_kleinpaste@charcoal.com writes: >I think I'm going to include a glossary of this stuff when I finish >the FAQ articles on domain registration. While you're at it, please include a section on how to update info, too. I need to change a few things in my domain registration, and have no concept of how to go about it - and I'm not willing to pay uunet another $35 to make the change, now that I have direct Internet access (though not from this machine). -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. "It's a hardware bug!" "It's a +---------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_
karl_kleinpaste@cis.ohio-state.edu (08/02/90)
jay@splut.conmicro.com writes:
While you're at it, please include a section on how to update info, too.
I need to change a few things in my domain registration, and have no
concept of how to go about it...
Just drop a note to hostmaster@nic.ddn.mil and tell them what you want
done. The folks at the NIC are very helpful.