Back to the main page

Mailing List Logs for ShadowRN

From: Paul Gettle <pgettle@********.NET>
Subject: Fiber Optics [was: Re: FAB Revisited]
Date: Thu, 14 May 1998 12:08:40 -0400
-----BEGIN PGP SIGNED MESSAGE-----

At 12:27 PM 5/14/98 +0100, Spike wrote:
>Oh, that's simple.
>In fact, having transmit or receive only datalines in electronics is
>INCREDIBLY simple. The only difficulty would be... How to you get in
to see
>them? (Unless the ASIST uses some form of redirection protocol to
maintain
>contact or the datalines are the only routes for the data to go, but
the
>ASIST lines run in parralel, allowing you to see the nodes and
manipulate
>them, but only allows data from/to the node via the data-lines....

Redirection protocol would work, except in cases where the only
dataline to a node is a one-way dataline. (Which happens to be the
first practical example in the section about one-way datalines).

Running a bi-directional 'sideband' line between nodes to allow decker
simsense to travel around a one-way dataline bottleneck is possible,
but it pokes a big security hole into some of the suggested
applications for one-way datalines. Say there were a datastore to be
used as a secure data dump. Data goes in, but it's not supposed to
come back out. A decker gets to the datastore, and finds that since
it's only connected by a one-way dataline, he can't transfer the
needed files back to his deck. Plan B, the decker performs a 'read'
operation in the datastore on the particular file, and the data that
wasn't supposed to get out of the datastore comes down the simsense
pipe to him. (I will grant you that 'read' formats the data into a
form usable by simsense, which means you can't normally save it, but
there are fairly simple ways around that.)

The other difficulty I see by having a parallel line for decker
simsense, it'd be a lot easier to tell if you've got a rogue decker in
your system. If the simsense signals travel the same datalines as the
rest of the data, the decker's signals get hidden in the noise of the
massive datapacket traffic of a normal system.
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3

iQCVAwUBNVsXA82C0fERRVM5AQF2fAP+PKHzE4aSo2iWeyamLSHx4hkBObuTsI3w
/kYFDtmxDcUfCCmvU/nPIczFDm6A2ddJFZcKp6cYhEaBc1lUtn5EFJ1o2ufVbTfU
kokG4jCk0ycnLV82LuxdQ0U43aobLxgXCrG4/ctFbFcaepODvxWA5ZH+T5bg1u8A
iBjSzRLgpJU=
=agU/
-----END PGP SIGNATURE-----

--
-- Paul Gettle (pgettle@********.net)
PGP Fingerprint, Key ID:11455339 (RSA 1024, created 97/08/08)
625A FFF0 76DC A077 D21C 556B BB58 00AA

Disclaimer

These messages were posted a long time ago on a mailing list far, far away. The copyright to their contents probably lies with the original authors of the individual messages, but since they were published in an electronic forum that anyone could subscribe to, and the logs were available to subscribers and most likely non-subscribers as well, it's felt that re-publishing them here is a kind of public service.