Re: Opiated file systems

At 8:05 AM 7/18/96, jim bell wrote:

>It has long occurred to me, considering the size and low power of the
>typical 3.5" hard drive compared with the size of the typical house or
>apartment, that it might be an interesting project to remotely connect such
>a (hidden) drive to your computer using a reasonably surreptious link that
>is difficult to trace.  Say, an IR optical link, a single bare (unjacketed)
>optical fiber, a LAN with hidden nodes, or a similar system.  Maybe an
>inductive pickup.  In any raid, they'll have to decide what to take, and
>chances are very good that they won't find every hidden item.

I think the druggies call this a "rat line": two apartments next to each
other, with the humans living in one and the drugs stored in the other. The
drugs are gotten through a hole in the wall.

(Hey, I'm not saying it works, or that it stops raids, prosecutions,
convictions, etc. Just noting the existence.)

Any multi-unit apartment can do this already, with data. The hard disk can
be upstairs and two units away, connected with Ethernet (as many apartment
buildings out here in California already are), or whatever. Any raid on
Unit 3B, for example, finds that no files are stored locally. A separate
investigation and/or search warrant for whereever the files actually are
stored would be of course problematic and/or delayed.

(Friends of mine have worked on "remote storage" ideas for exactly such
applications. Clearly there are many options: storage in other local sites,
storage in offshore sites, encrypted storage, even storage by a "priest"
functionary ("Son, I am ready to receive your digitally transmitted
confession.").)

Lots of possibilities. For various reasons, few have been pursued. (Mostly
because, I think, there have been relatively few raids on data, and when
there have been raids, there were usually other HUMINT-type factors
involved. E.g., few child porn rings are going to be broken only on the
basis of seized disks. As this situation changes, expect more "data
archival" services to evolve.)

--Tim May

Boycott "Big Brother Inside" software!
We got computers, we're tapping phone lines, we know that that ain't allowed.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Licensed Ontologist         | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

> 
> (Friends of mine have worked on "remote storage" ideas for exactly such
> applications. Clearly there are many options: storage in other local sites,
> storage in offshore sites, encrypted storage, even storage by a "priest"
> functionary ("Son, I am ready to receive your digitally transmitted
> confession.").)

The problem I ran into firsthand with archive sites is that they tend to
turn into porn or pirated software servers.  One could then have the
software delete after a download.  Anyway, one is always open to a denial
of service attack where someone just throws chunks of /dev/random at you.

(About last April when I wrote an offsite secure storage program, I was
testing it on another site.  Some 2 bit children found out about it and
decided to turn it into a porn server, causing major bandwidth to be taken
up.  I then set it to delete any files grabbed when one specifies the MD5
hash.  This stopped the onrush of outgoing stuff, however I got a
bunch of people dumping large amounts of random junk just to deny others
service out of spite.  To foil this, I set a per megabyte limit.  Then,
they just anon-remailed bunches of little files.  I got tired of the abuse
and pulled the plug on it.  It didn't even reach beta testing.)

If someone has any ideas on how to slow down attacks like this, please
E-mail me.  It would be nice to have an offsite storage place, but without
the necessity of giving a bunch of personal info (as with Mcaffee's
WebStor).

-----BEGIN PGP SIGNED MESSAGE-----

In article <199607182213.RAA10532@pentagon.io.com>,
Douglas R. Floyd <dfloyd@IO.COM> wrote:
>If someone has any ideas on how to slow down attacks like this, please
>E-mail me.  It would be nice to have an offsite storage place, but without
>the necessity of giving a bunch of personal info (as with Mcaffee's
>WebStor).

Charge ecash?

   - Ian

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMfFXfkZRiTErSPb1AQF9YAQAk/mY+nAp9iGeGwZh+lC7Q0RPK+xjFs6d
dT+mu/WiS9UP13IJLe+Rs2i3AFRry/lD4XPdL/CDTgDC5nH+Yalb8MSVJr9WJTvM
iiZk6twYNXygTK0kF+u3g5QCCofSQoJXTDp0gL1Qkd+gw2kFzYo5xkK6TsPtbZWh
Ld08fPu15Gc=
=QHCI
-----END PGP SIGNATURE-----

> In article <199607182213.RAA10532@pentagon.io.com>,
> Douglas R. Floyd <dfloyd@IO.COM> wrote:
> >If someone has any ideas on how to slow down attacks like this, please
> >E-mail me.  It would be nice to have an offsite storage place, but without
> >the necessity of giving a bunch of personal info (as with Mcaffee's
> >WebStor).
> 
> Charge ecash?
> 
>    - Ian

Nice idea, but the purpose of this is to make a reliable reference
implementation.  I will worry about charging after there are reliable
OSSS's in existance.

Footnote:  I cannot call this site once it is constructed a data haven due
to the fact that it has no armor (read that its physical location can be
found out).  That is why I tend to call it an offsite secure storage
server.