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.
participants (3)
-
Douglas R. Floyd
-
iang@cs.berkeley.edu
-
tcmay@got.net