Re: STEALTH OCEANS

On Wed, 23 Feb 1994, Matt Thomlinson wrote:

> I originally mailed this response to your suggestions on the cpunk list 
> about two weeks ago. You must've missed it. 
> 

Yes, I must have.  Thank you for mailing it to me!

> dos stego:
> 
> I don't think the current discussion is taking into account the fact that 
> if someone suspects you of using steganography they're going to check. 
> If what you are describing becomes a popular way of steganography, you're 
> out of luck -- they'll check that first. 
> 

It would be alright if someone checks the deleted sectors.  They would indeed
find your "noise" file; but, it would be embedded in rest of the noise
surrounding it (which would be provided by the other deleted files on the 
disk).

Thus, the original problem (ie. how to keep "noise" files inconspicuous) is
solved.

> Think about it: your 'bad-sector' stego or 'wiped-filespace' stego begins 
> gaining popularity. Wouldn't you think they'd check for funny bad sectors if 
> they were going to check your computer for contriband info? 
> 
> 

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.

> 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.

> Someone suggested you just use the end of the wiped filespace (use norton
> or other utility to defrag the disk and move empty space to the end of the
> disk, then use portion of disk furthest away from being written to. This 
> might work, except for the fact that fragmentation _does_ go on, and when 
> you were to write files to the drive (heck, I do every time I start up 
> windows and write a huge temp swapfile) you're going to be playing 
> roulette with your data. 
> 

This problem is solved by simply using a utility that writes directly to the
disk (exactly in the specified sectors, in the specified order), instead 
of letting DOS fragment your disk.

> 
> I think the point about the blank track (the one linux uses) is
> interesting;  then again, once your method becomes well-known, it is no
> longer useful. 
> 

I am not familiar with the blank track you speak of; but, of course, if 
everyone keeps hiding their data in the same location it will not remain
hidden for long.

> 
> Just thoughts; I wish I had more answers. Heck, ANY answers would be nice.
> 
> 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
> 
> 
> 

Thanks for sharing your thoughts, Matt!


Sergey

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

On Wed, 23 Feb 1994, Matt Thomlinson wrote:

> 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 

No, no.  The function of Stealth PGP is, as I understand it, to simply 
encrypt plaintext into something that is virtually indistinguishable
from noise.  Deleting those "noise" files is a seperate issue.

>                     -- 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?
>

What telltale TSR?  A program that can read and write directly to disk?
If I am not mistaken, such programs are common enough not to be
evidence of anything.  Having PGP on you is another matter, however.

> 
> > > 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? 

With a standard direct disk read/write utility.

>                                      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.
> 

Disable authorization.  Most DOSs allow direct writes without 
authorization anyway.

> 
> > 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.) 
> 

This is not necessary.  In fact, as I noted, hiding your files in the 
same place everytime lessens security.  The alternative is a simple one.
Hide your files in different places, and keep track of them.  For 
example, a file that was encrypted on 02-23-94 could be written to disk 
starting with sector 022394.  All you have to do is remember the date and 
length of the file to retrieve it successfully.

> 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. 
> 

Again, the program would be a standard utility that can write/read to/from
the disk.  One has to tell the program what tracks/sectors to 
read/write.  Having the program without the corresponding file 
address/length is useless.

> 
> 
> 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.
> 

You need _not_ have a TSR with the location.  If you keep track of the 
address/length yourself, the problem is eliminated.  The whole
automated (TSR) idea is only usefull if you are frequently accessing your 
disk.  In that case, saving your encrypted files to RAM temporarily might 
be a more elegant solution.  Otherwise, store your "noise" files 
sequentially, on a floppy that you use only for storing encrypted data.  
Guard their respective addresses/lengths as dearly as you would your secret 
key and it's corresponding password.

> 
> 
> 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. 
> 

I'm sorry, this paragraph just went over my head.  Could you restate it 
in another way, so I can attempt to comment?

> 
> 
> 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. 
> 

Absolutely!  I have anticipated this problem; and, have been awaiting an
opportunity to address it.

Steps must be taken to keep the deleted portion of your disk from looking 
too random.  In order to implement this additional level of security 
(through obscurity ;) one could:

 1 split the "noise" file into smaller parts which would be interspersed 
   randomly among the other deleted grabage.  This would make for a less 
   conspicuous disk; as, there are, normally, truely random sections of 
   the disk along with the not-so-random sections.  Your bits of noise-file
   will fit right in!

or

 2 use a steganorgraphy utility to embed the "noise" file in a section
   of the other not-so-random garbage (as some people currently use those
   same utilities to embed their PGP files in GIFs), and then delete it.
   (Owning a stegonagraphy utility would, of course, be as conspicuous
    as owning PGP.  So the same precautions would have to be applied.)

These options are very similar.  I prefer the former.  Relying on a stego 
utility seems to be as unreasonable as relying on a TSR to keep track of 
the location of your deleted "noise" files.  I would split and hide the 
"noise" file by hand, and keep track of its location by hand as well, to 
ensure maximum security.

Alternatively, one could use a "Mimic" function with a "DOS garbage" grammar.
This is effectivaly the same as option 2.

> 
> 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
> 
> 

Thanks for your input, once again, Matt!


Sergey

On Wed, 23 Feb 1994, Sergey Goldgaber wrote:

> No, no.  The function of Stealth PGP is, as I understand it, to simply 

correct. I was commenting on the ability of the stealth-pgp to create 
output not associated with PGP; I didn't mean to imply that s-pgp would 
be designed to do the deletion on its own. sorry.


> > telltale TSR hanging around?
> 
> What telltale TSR?  A program that can read and write directly to disk?
> If I am not mistaken, such programs are common enough not to be
> evidence of anything.  Having PGP on you is another matter, however.

I'd say having a TSR "hideit.com" loaded into high memory (installed size:
xxxx bytes) watching INT (whatever) would be a pretty good clues that
someone trying to determine that you were using a program to protect areas
of your disk would look for. Perhaps you could try and hide this, too; in 
any case, you address TSRs later...

> > > Simple.  You would take note of the starting address of the file.  And, 
> > > the length of the file.
> > 
> > how do you control individual writes? 
> 
> With a standard direct disk read/write utility.

uh, I don't have one. Do you?

I'm NOT talking about how to recover areas of your disk (you could use 
something like Norton Utilities to pull the noise file off the disk). 
What I'm trying to understand is how you plan to keep that area of your 
disk off limits. 

Like it or not, programs and OSs (if you can call Windows an OS) write to 
disk. Lots. Everywhere. How do you keep it from fragmenting the disk 
immediately and overwriting the space (whose address you have written 
down on that sheet of paper next to your computer?)

Try running windows with a temp swapfile. Run photoshop for windows (it 
writes its' own tempfile on the drive). Save a file from Word for Windows 
and try and control where it goes.


I'm not saying these problems can't be solved; I _am_ saying that what 
has been proposed thus far doesn't adequately address this (if you're 
looking at this as a genuine way to hide your data).


> > 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)? ) 
> 
> Disable authorization.  Most DOSs allow direct writes without 
> authorization anyway.

No, no. We _need_ to protect the noise area. 

how? change the FAT? TSR? My example above was an attempt to try and
understand what a TSR you might build would have to ask, every single time
a regular write to disk was performed. (to protect your deleted noise
file).


> You need _not_ have a TSR with the location.  If you keep track of the 
> address/length yourself, the problem is eliminated.  The whole

except for the fact that your computer will overwrite your data (which, 
in fact, is *deleted* space, waiting to be written over) in the meantime.

> be a more elegant solution.  Otherwise, store your "noise" files 
> sequentially, on a floppy that you use only for storing encrypted data.  

Ah, a floppy? this makes 10 times more sense. With a floppy you wouldn't 
have haphazard writes to disk (as you do with your harddrive). 


> > 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. 
> > 
> 
> I'm sorry, this paragraph just went over my head.  Could you restate it 
> in another way, so I can attempt to comment?

sure. two choices:

1) We must protect our noise data.
	Keep it in a location on disk, keep a TSR in memory to protect
that area from writes. 

2) We don't protect our noise data. 
	Keep our data in a location on disk, keep the spots on paper, and 
hope that by the time we need to retreive it, the data hasn't been 
written over. 

I sure wouldn't want to count on 2), and it seems as if 1) defeats the 
purpose.


> > 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. 
> > 
...

>  1 split the "noise" file into smaller parts which would be interspersed 
>    randomly among the other deleted grabage.  This would make for a less 
>    conspicuous disk; as, there are, normally, truely random sections of 
>    the disk along with the not-so-random sections.  Your bits of noise-file
>    will fit right in!

not bad. One thing to consider: we've moved all of our data to the end of 
the disk, anyway; we'd still have most of our important data at the end 
of the disk, which still might look conspicuous statistically.

>  2 use a steganorgraphy utility to embed the "noise" file in a section
>    of the other not-so-random garbage (as some people currently use those
>    same utilities to embed their PGP files in GIFs), and then delete it.
>    (Owning a stegonagraphy utility would, of course, be as conspicuous
>     as owning PGP.  So the same precautions would have to be applied.)

not bad. Takes (8 times?) more space, but should work.


Do you understand my objection to keeping track of the files' location by 
hand? It isn't that keeping track of the location/length of the file is 
hard, or retreiving it is tough; the problem is keeping the OS, etc from 
overwriting it in the meantime. 


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

On Wed, 23 Feb 1994, Matt Thomlinson wrote:

> I'd say having a TSR "hideit.com" loaded into high memory (installed size:
> xxxx bytes) watching INT (whatever) would be a pretty good clues that
> someone trying to determine that you were using a program to protect areas
> of your disk would look for. Perhaps you could try and hide this, too; in 
> any case, you address TSRs later...
> 

Again, no TSRs are necessary.  Having a simple, common utility on hand is 
all that is needed.

> > > > Simple.  You would take note of the starting address of the file.  And, 
> > > > the length of the file.
> > > 
> > > how do you control individual writes? 
> > 
> > With a standard direct disk read/write utility.
> 
> uh, I don't have one. Do you?
> 

Sure!  Norton's Disk Editor!  I think that it may be limited to doing
everything manually, one sector at a time, though.  I'm not a big MSDOS user,
so I can't direct you to a more convenient utility, but I'm sure they're 
out there.

> I'm NOT talking about how to recover areas of your disk (you could use 
> something like Norton Utilities to pull the noise file off the disk). 
> What I'm trying to understand is how you plan to keep that area of your 
> disk off limits. 
> 

You don't keep anything off limits.  If an intruder uses the standard OS 
(instead of the proper utility) to write to your disk, he might erase 
your data.  That is not a problem!  He's doing you a favor by destroying 
the evidence.

You, on the other hand, know better.  Thus, you will always use the 
utility to write to the free sectors of the disk.  You will have no 
problem, assuming you keep track of where your data is.

> Like it or not, programs and OSs (if you can call Windows an OS) write to 
> disk. Lots. Everywhere. How do you keep it from fragmenting the disk 
> immediately and overwriting the space (whose address you have written 
> down on that sheet of paper next to your computer?)
> 

You use a floppy disk that is only accessed by your utility, which 
bypasses DOS (and Windows, which is DOS based).  You keep your disk 
write-protected at all other times.

> Try running windows with a temp swapfile. Run photoshop for windows (it 
> writes its' own tempfile on the drive). Save a file from Word for Windows 
> and try and control where it goes.
> 

That's correct.  But this is only the case when you are letting DOS write 
to disk for you.  If you use _direct_ (ie. _not_ DOS) disk writes, you can
specify which sectors you write to!

> 
> I'm not saying these problems can't be solved; I _am_ saying that what 
> has been proposed thus far doesn't adequately address this (if you're 
> looking at this as a genuine way to hide your data).
> 

I disagree.  I do admit that the more security you want, the more complicated
the issue gets.  At the simplest level, all you have to do is delete your
"noise" file.  This is a solution to hiding "noise" files that is 
available to everyone.  Problems crop up only when your opponent is 
determined, knowledgable, and capable.  Although more effort will be 
required, I believe that the system I've outlined will prevent even the 
most determined opponent from finding evidence even of the existence of your
"noise" files.

> 
> > > 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)? ) 
> > 
> > Disable authorization.  Most DOSs allow direct writes without 
> > authorization anyway.
> 
> No, no. We _need_ to protect the noise area. 
> 

All the protection that is neccessary is that of your keeping track of
the location of your files.  Just don't write back to those sectors 
again, unless you want to overwrite your data.

> how? change the FAT? TSR? My example above was an attempt to try and
> understand what a TSR you might build would have to ask, every single time
> a regular write to disk was performed. (to protect your deleted noise
> file).
> 

Once again, NO TSR IS NECESSARY!  In fact, it is detrimental, for the reasons
that I have outlined in my previous messages.

> 
> > You need _not_ have a TSR with the location.  If you keep track of the 
> > address/length yourself, the problem is eliminated.  The whole
> 
> except for the fact that your computer will overwrite your data (which, 
> in fact, is *deleted* space, waiting to be written over) in the meantime.
> 

Only if you use standard DOS disk writes.  Bypass DOS and your problem is 
solved.


> > be a more elegant solution.  Otherwise, store your "noise" files 
> > sequentially, on a floppy that you use only for storing encrypted data.  
> 
> Ah, a floppy? this makes 10 times more sense. With a floppy you wouldn't 
> have haphazard writes to disk (as you do with your harddrive). 
> 

Exactly.
 
> sure. two choices:
> 
> 1) We must protect our noise data.
> 	Keep it in a location on disk, keep a TSR in memory to protect
> that area from writes. 
> 
> 2) We don't protect our noise data. 
> 	Keep our data in a location on disk, keep the spots on paper, and 
> hope that by the time we need to retreive it, the data hasn't been 
> written over. 
> 
> I sure wouldn't want to count on 2), and it seems as if 1) defeats the 
> purpose.
> 

Are you forgetting the floppy+direct-disk-writes solution?  Choice 2 makes
sense!
 
> >  1 split the "noise" file into smaller parts which would be interspersed 
> >    randomly among the other deleted grabage.  This would make for a less 
> >    conspicuous disk; as, there are, normally, truely random sections of 
> >    the disk along with the not-so-random sections.  Your bits of noise-file
> >    will fit right in!
> 
> not bad. One thing to consider: we've moved all of our data to the end of 
> the disk, anyway; we'd still have most of our important data at the end 
> of the disk, which still might look conspicuous statistically.
>

Moving all the data to the end of the disk was not a suggestion made by me.
I agree that it would be rather silly.
 
> >  2 use a steganorgraphy utility to embed the "noise" file in a section
> >    of the other not-so-random garbage (as some people currently use those
> >    same utilities to embed their PGP files in GIFs), and then delete it.
> >    (Owning a stegonagraphy utility would, of course, be as conspicuous
> >     as owning PGP.  So the same precautions would have to be applied.)
> 
> not bad. Takes (8 times?) more space, but should work.
> 

Two choices:
 
 Space sacrificed for security.  

 Or, security sacrificed for space.

> 
> Do you understand my objection to keeping track of the files' location by 
> hand? It isn't that keeping track of the location/length of the file is 
> hard, or retreiving it is tough; the problem is keeping the OS, etc from 
> overwriting it in the meantime. 
> 

I understand.  However, your objection doesn't make sense in light of the 
above conclusions.


Thanks for your prompt replies, though!  Keep 'em coming!

Sergey