Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!sdcsvax!mod-os
From: mod-os@sdcsvax.UUCP
Newsgroups: mod.os
Subject: Re: network security
Message-ID: <2425@sdcsvax.UCSD.EDU>
Date: Tue, 6-Jan-87 19:01:00 EST
Article-I.D.: sdcsvax.2425
Posted: Tue Jan  6 19:01:00 1987
Date-Received: Wed, 7-Jan-87 06:35:55 EST
References: msg fm jqj@gvax.cs.cornell.edu (j. q. johnson) re transec
Sender: darrell@sdcsvax.UCSD.EDU
Reply-To: seismo!nears!ks@sdcsvax
Organization: Decision Studies Group, Inc., Box 335, Okla. City OK 73101 USA
Lines: 25
Approved: mod-os@sdcsvax.uucp
Telephone:    +1 405 278 5257

--

In article <2416@sdcsvax.UCSD.EDU> you write:

>Re: secure transmission media.
>
>[...] On an Ethernet,
>the only way to prevent wiretapping is encryption of the data [...]

I believe it's very important for security engineering to keep its terms
in proper parlence.  Encryption of data does not prevent wiretapping, it
merely (and presumably) renders the envelope contents not-easily-readable.

This is a significant difference.  Note that the "envelope" is still
available to an intruder (packet headers, message sizes, and precedence,
if it's provided).  Armed with this information, A good TA person could
make short work of figuring out the contents, if so inclined.

Preventing wiretapping (such as putting the Ethernet* inside conduit which
is occasionally inspected for tampering, etc.) would eliminate the traffic
analysis threat (except for situations where TEMPEST equipment might be
required--which is a much more problematic setting, anyway).


--