1994-02-24 - Re: STEALTH OCEANS

Header Data

From: Matt Thomlinson <phantom@u.washington.edu>
To: Sergey Goldgaber <sergey@delbruck.pharm.sunysb.edu>
Message Hash: 729e475aceee247d5ed5422e82e3f3129a463a3c4a255c022d8281c7cbd94bcb
Message ID: <Pine.3.89.9402231824.A3563-0100000@stein3.u.washington.edu>
Reply To: <Pine.3.89.9402232157.A2157-0100000@delbruck.pharm.sunysb.edu>
UTC Datetime: 1994-02-24 03:18:59 UTC
Raw Date: Wed, 23 Feb 94 19:18:59 PST

Raw message

From: Matt Thomlinson <phantom@u.washington.edu>
Date: Wed, 23 Feb 94 19:18:59 PST
To: Sergey Goldgaber <sergey@delbruck.pharm.sunysb.edu>
Subject: Re: STEALTH OCEANS
In-Reply-To: <Pine.3.89.9402232157.A2157-0100000@delbruck.pharm.sunysb.edu>
Message-ID: <Pine.3.89.9402231824.A3563-0100000@stein3.u.washington.edu>
MIME-Version: 1.0
Content-Type: text/plain


On Wed, 23 Feb 1994, Sergey Goldgaber wrote:

> They would.  But, combined with "Stealth PGP" (ie. encryption without 
> telltale headers) searching through all the deleted noise (which could be 
> legitimate for all they know) would be futile.

I can see how a stealth-PGP would allow you to hide messages on your disk 
in "wiped" filespace -- it'd look like garbage (maybe -- see Aside), if 
anyone took a look. What does this buy you, though, if you've got a 
telltale TSR hanging around?


> > Another thing that has bothered me: if you didn't have the sectors marked,
> > you'd need to remember where they were (so you could protect them from
> > writes). You wouldn't necessarily want to do this on the computer; it'd be
> > there for the picking. How to do it?
> > 
> 
> Simple.  You would take note of the starting address of the file.  And, 
> the length of the file.


how do you control individual writes? You've got to know where they are 
vs. where your data is kept. Authorize each write by hand? (PROGMAN.EXE 
is attempting to write to cylinder 12, track 14. Authorize (y/N)? ) 

Icky. 
Do it another way? See below.


> everyone keeps hiding their data in the same location it will not remain
> hidden for long.


exactly my point. It seems you've got to have one of two things with your 
system: 

1) a standard place where you hide your noise file (for example, use 
norton to defrag and compress your disk, then ALWAYS write your noise 
file on the last two cylinders.) 

Problem: Needs some program to revive the info; this is a tip-off... Also,
once your stealth system becomes known, the reason for hiding the noise 
file is gone -- the tracks/cyl will be checked if they find the reviving 
program. Instant noise file. 



2) a non-standard place/way to hide your noise file (for example, using a 
TSR with the areas not to write being protected; using the TSR when you 
need to restore the data later). 

Problem: Needs program in memory (or info on disk about where it resides) 
to revive the data later. A tip-off that again defeats the purpose of 
hiding the noise file.



Analysis: It seems with the systems I can think of you need to have the
area the noise file stored in either 1) standard (ick) or 2) kept in
memory so you don't overwrite it. If you don't protect it, I wouldn't
expect your noise file to have a very large half-life. :l Keeping the area
in memory (under protection) defeats the system. 



Aside: By the way, isn't the "noise" in your noise file is going to be
more random looking than other deleted areas of your disk? PGP compresses
and then encrypts; I'll bet that it is possible to distinguish pgp's
output bit frequencies from those of a binary or text file, which is what
the rest of the wiped space would most likely be. 


mt

Matt Thomlinson                               Say no to the Wiretap Chip!
University of Washington, Seattle, Washington.
Internet: phantom@u.washington.edu      	    phone: (206) 548-9804
PGP 2.2  key available via email or finger phantom@hardy.u.washington.edu






Thread