Re: CryptoStacker, long term vision

On Thu, 3 Jun 1993, A1 ray arachelian wrote:

> > 	2) does anybody know how the hell Stacker or DoubleStor or
> > 	    whatever executes the actual interception of the read/write
> > 	    routines and stacks them?  I don't get it at all.  I am
> > 	    more than willing to learn to get this thing working though. 
> > 
> 
> Anyhow to make the story short, if I wrote an image mounter device driver which
> would be able to grab DIM files and pretend that they were on the A: or B: drive
> then we could also install the programs without breaking out the recylced disk
> box. :-)

Couldn't you just do that with the assign command in DOS?

or is that a new command?

> I never got around to it because of other projects, but, what you need to do is
> to write a device driver that becomes accessible via the IOCTL calls.  That's
> the way logical drivers (such as Stacker) install themselves.

Yeah, I am assuming that is the way I will have to organize the system.  I
want it to be totally transparant, that seems like a good way.

> Also, the program you're writing (I believe) has been already written and is
> part of Norton Utilities, but uses either DES or some other weak form of
> encryption.  You might want to buy Norton Utilities and play with that program
> and see what makes it tick.  Basically a program like MSD (Microsoft Diags)
> can tell you exactly what interrupts it patches itself into.

I have heard this from someone else.  It kind of takes the wind out of my
enthusiasm, but not too much... I still think that there is a need for a
good, strong system out there with some seriously dedicated password key
protection and such.  Also, it needs to be freeware (or shareware,
depending on how long it takes to write) so that security won't just be in
the hands of the people who can afford to buy it from companies.

I also think that it would be a lot more valuable if it were distributed
with code so that any user who wanted could inspect it for trapdoors.

> On to the sector remapping.  The way stacker and doubledisk and the other
> suite of driver level compressors work is basically, they allocate a huge
> file on the hard drive, and then do a remapping at the sector level.  That
> is you've got the data itself and an index table into the data for every
> sector.  When a sector is written to the drive, the driver compresses the
> sector, so say, it was 512 bytes, it now becomes 128 bytes (if we're lucky)
> so what Stacker does is, looks in its index table, finds 128 bytes free in
> the huge file it allocated, writes the data there, and then sticks the
> position of the data, and it's size (after compression) in the index table.
> (Of course it also marks that 128 bytes as taken.)

Umm, perhaps this is overly optimistic, but I was hoping that I would be
able to use an algorithm that did 1 byte in / 1 byte out encryption so
that I wouldn't have to deal with sector remapping.  This would greatly
speed up the process, make it more crashproof, and besides, it would be a
hell of a lot easier...  I was thinking that I would even basically leave
the FAT and such intact, or at least only slightly modified.

> I believe it also does some other funky stuff like changes the allocation
> table or the bytes free to twice the space it's got left, so that DOS
> doesn't choke when it thought it had 10,000 sectors free and the hard
> drive ran out of space when it tried to write #4,999. :-)
> 
> So you might want to do this with RSA.  But better yet, why don't you
> find a quick compressor algorithm (say some sort of LZ type method)
> and stick that in as well.  This way you are writing a public domain
> version of stacker >WITH< encryption.  (Since you'd have to remap
> the sectors anyhow, you might as well compress them too...)

I have been pointed in the direction of the IDEA engine in PGP, which will
take 1 byte in / 1 byte out.  This would be ideal (snicker) for the
reasons that I mentioned before.  

As for compressing also, that is a really good idea, but I think that I
will leave that one up to posterity, or at least to the next guy that
tries to midofy the thing, I am concerned enough with getting it to work
at all, and compression would add the problem of having to do sector
remapping, which I would like to avoid at first.

> The above is just a theory and hasn't been tested.  I believe that
> this is what Stacker does, but I'm not exactly sure. :-)  But it
> does sound logically right.

Sounds good to me, and it is consistent with the advice of others (thanks
a lot guys, I really appreciate the help) and the books that I have found
since this started two days ago...

> So if I'm wrong, let me know as you've got my curiosity up in this
> matter.


I'll keep everyone updated no problem.  How else am I going to get
suggestions and help?


-Ryan 
the Bit Wallah

>I also think that it would be a lot more valuable if it were distributed
>with code so that any user who wanted could inspect it for trapdoors.

The nature of crypto software is that is valueless unless you trust
it.  You don't have to trust a word processor, because you can see
immediately that what you typed on the screen comes out the printer.
For security software, however, breaches are invisible, or more
precisely visible only after the damage has been done.

This is the reason that I disregard DISKREET from Norton.  There's no
source, and largish companies are notorious for pushing compromised
software.  Norton's unlikely to ship source, so unless someone
decompiles it, I'm not biting.

>Umm, perhaps this is overly optimistic, but I was hoping that I would be
>able to use an algorithm that did 1 byte in / 1 byte out encryption so
>that I wouldn't have to deal with sector remapping.  

You need to do a bit of research into what a block device driver
actually does.  It deals only with blocks of characters, not with
individual ones or arbitrary length strings.  The block interface at
the driver level is different than the file access at the API level.
Don't confuse the two levels.  DOS already does the buffering required
to turn a block device into a file system.  You don't need to
replicate it.

As a result, the cipher you choose needs to be a block cipher.  DES
works on blocks of 8 bytes at a time.  A typical sector is 512 bytes.
So you are going to have 32 DES (or iterated DES) operations per
sector.

>  I was thinking that I would even basically leave
>the FAT and such intact, or at least only slightly modified.

Again, at the driver level, you don't know that a FAT even exists.
Ray Duncan's book _Advanced MSDOS Programming_ contains a good chapter
on device drivers.  You should be able to find code for a skeleton
block device driver on the net; check the msdos programming groups for
more info.

>I'll keep everyone updated no problem.  How else am I going to get
>suggestions and help?

I would also suggest that you find programming partners.  If for no
other reason than to do code review, someone else ought to be
involved.  You wouldn't want to make the group too large, but three or
four is not overlarge.  The archive at soda is available for group
work, if desired.

Eric

According to Eric Hughes:

> This is the reason that I disregard DISKREET from Norton.  There's no
> source, and largish companies are notorious for pushing compromised
> software.  Norton's unlikely to ship source, so unless someone
> decompiles it, I'm not biting.

HMMmmm.....  Well, how big is it?  Is it a .exe or .com?  It might be very 
instructive to see how they do it...

> four is not overlarge.  The archive at soda is available for group
> work, if desired.

That is very generous!
+-----------------------+-----------------------------+---------+
| J. Michael Diehl ;-)  | I thought I was wrong once. | PGP KEY |
| mdiehl@triton.unm.edu |   But, I was mistaken.      |available|
| mike.diehl@fido.org   |                             | Ask Me! |
| (505) 299-2282        +-----------------------------+---------+
|                                                               |
+------"I'm just looking for the opportunity to be -------------+
|            Politically Incorrect!"   <Me>                     |
+-----If codes are outlawed, only criminals wil have codes.-----+
+----Is Big Brother in your phone?  If you don't know, ask me---+

> > This is the reason that I disregard DISKREET from Norton.  There's no
> > source, and largish companies are notorious for pushing compromised
> > software.  Norton's unlikely to ship source, so unless someone
> > decompiles it, I'm not biting.
> 
> HMMmmm.....  Well, how big is it?  Is it a .exe or .com?  It might be very 
> instructive to see how they do it...

By the way, I have a relatively usable free 68k disassembler, and have
recently retrofitted the simple GNU portable disassembler (supporting
many processors) with an interface that should allow it to be glued
into the usable disassembler (which traces branches, creates labels,
lets you label things yourself, etc).  Anyone who would like to work
on these tools, please let me know.

The GNU `objdump' program will disassemble the entire program from any
object file format it recognizes (currently most a.out variants, most
COFF variants, ELF, ecoff, xcoff, s-records, some IEEE object files).
We have specs on the Windows object file formats, if anyone wants to 
add support for reading them.  DOS EXE and COM files would be a useful
addition, as well.

You can get a taste of the current simple disassembler by getting the
latest GNU Binutils (binary utilities) release from prep.ai.mit.edu or
ftp.uu.net.  Configure and build it on any of about twelve kinds of
Unix machines, and run "objdump -d" on itself.

	John Gilmore