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
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
Return to February 1994
Return to “Sergey Goldgaber <sergey@delbruck.pharm.sunysb.edu>”