Re: STEALTH OCEANS

This is my first post to this list, so please don't flame me if I make
some trivial mistake. %->


IDEA Re: making random noise files "undetectable"...
~~~~~~~  On many machines the file system allows users to "delete" files
         without actually deleting them.  This is usually accomplished by
         simply marking the disk blocks that make up the file as free.
         Thus it should be possible to write an encrypted (noise) file on 
         to disk, pad the rest of the disk with more noise and "delete" the
         whole thing, making the disk look blank to all casual observers.

PROBLEM: If the above idea is implemented, one could not write on to the
~~~~~~~  the disk for fear of accidentaly overwriting the "free" disk blocks.

SOLUTION: Knowing the _exact_ location and size of the file, one could write 
~~~~~~~~  directly to those block which are _really_ free.

2nd PROBLEM: In order to decrypt the file, one needs to know it's 
~~~~~~~~~~~  _exact_ location and size (or use some undelete util)...
             Which brings me to the...

3rd PROBLEM: An undelete utility could make recovering the encrypted
~~~~~~~~~~~  file trivial for _anyone_.

SOLUTION: Make the file undetectable to udelete utilitys by modifying
~~~~~~~~  the FAT table, or equivalent.  One would, of course, have to keep
          track of the file in some other, non-standard, way.

FINAL(?) PROBLEM: Implementing the above idea is trivial for the average
~~~~~~~~~~~~~~~~  user.  Making and recovering truely undetectable files 
                  may not be.


                                 All feedback welcome,

                                     Sergey

Specific comment:

Sergey Goldgaber suggests hiding files amongst the disk blocks
marked "deleted" by the filesystem.  

This sounds practically equivalent to implementing an alternative file 
system with its own FAT, etc.  In addition to the problems and solutions
Sergey mentioned, the true/surface/original filesystem must be slightly
modified so that it doesn't bash the hidden filesystem in the
process of making new files.  Of course, it will look rather funny
when the disk runs out of space several tens of megabytes below
the manufacturer's specs.  

This hidden file system feature might fit in naturally with
SecureDrive which implements an encrypted file system.

General comments:

Encryption and mimicry are both a matter of economics.
Unfortuneately, as with most mimicry, the effort needed to
find the hidden filesystem is easier than the effort needed
to implement and maintain the hidden filesystem.  ("Effort"
here is primarily programmer and user effort, not computer
resources).

It also costs to hide encrypted data in noise; in this case
the cost is mostly bandwidth.  This must be traded off with the
fact that nobody is going to be either (a) banning compression or
noise-containing data or (b) sampling significant fractions of 
compressed and noisy files that cross the net to see if they're 
actually encrypted.  Both passage and enforcement of anti-cryptography 
laws will be greatly discouraged by widespread use of mimicry
(including steganography).

This is also a good opportunity to put in my plug _in favor_
of "security through obscurity" as a good practical solution to
some problems.  For example, the task of scanning the net gets 
super-linearly more expensive with the number of data formats used 
(since the cost of implementing software is super-linear with its raw 
complexity).  Simply having a wide variety of fax, compression, sound, 
video, encryption, etc. formats will quickly make the cost of
automated scanning efforts prohibitive.  Interoperability
favors standardization, but security and privacy favor
incompatability with the popular formats used by the snoopers.  

Nick Szabo				szabo@netcom.com

On Fri, 18 Feb 1994, Nick Szabo wrote:
 
> Sergey Goldgaber suggests hiding files amongst the disk blocks
> marked "deleted" by the filesystem.  
> 
> This sounds practically equivalent to implementing an alternative file 
> system with its own FAT, etc.  

Actually, in it's simplest form, it is much easier to hide files by 
deleting them than by implementing an alternative file system.  
Theoretically, the former method should be enough for most of those 
concerned with having telltale "noise" files on their disks.  Using an 
alternative file system might, for them, be almost as revealing as having 
"noise" files.

>                                In addition to the problems and solutions
> Sergey mentioned, the true/surface/original filesystem must be slightly
> modified so that it doesn't bash the hidden filesystem in the
> process of making new files.  

We can assume that the legitimate user would be aware of this drawback, 
and would take measures not to write over the files he has hidden.
I see no absolute _need_ to modify the filesystem.  A simple utility that 
can write files to specific disk locations is all that is required.

>                               Of course, it will look rather funny
> when the disk runs out of space several tens of megabytes below
> the manufacturer's specs.  
> 

This is only a problem if you modify the filesystem.  The standard 
filesystem will simply write over the deleted files; or, if one is using 
the above mentioned utility, one would write onto a truely free portion 
of the disk.  We can assume that the only an intruder would unknowingly 
write a file onto the disk without using the special utility (thus 
overwriting the hidden encrypted file, and doing the legitimate user a 
favor by destroying the evidence).

-- STUFF DELETED --

                 
                  All feedback welcome,

                       Sergey


PS: I agree with your statement about "security through obscurity"
    sometimes being a good practical solution.