1993-06-03 - RE: CryptoStacker - Suggestions

Header Data

From: pat@tstc.edu (Patrick E. Hykkonen)
To: cypherpunks@toad.com
Message Hash: 37192deb498b20fc144e540c797188f42cb1199907b0b1e7dfe7d3ba5b22d7be
Message ID: <9306031827.AA05452@tstc.edu>
Reply To: <9306031512.AA25490@soda.berkeley.edu>
UTC Datetime: 1993-06-03 18:27:14 UTC
Raw Date: Thu, 3 Jun 93 11:27:14 PDT

Raw message

From: pat@tstc.edu (Patrick E. Hykkonen)
Date: Thu, 3 Jun 93 11:27:14 PDT
To: cypherpunks@toad.com
Subject: RE: CryptoStacker - Suggestions
In-Reply-To: <9306031512.AA25490@soda.berkeley.edu>
Message-ID: <9306031827.AA05452@tstc.edu>
MIME-Version: 1.0
Content-Type: text/plain

> This model of using a device driver means that there is going to have
> to be at least two partitions on the disk: one to boot from, and one
> to be encrypted.  The device driver itself and the operating system
> can't be on the encrypted disk, because those components must be
> loaded before the encrypted disk is accessible.  Most people are not
> going to go out and buy a new disk to be the encrypted partition.
> Thus, this is going to mean a full backup of the existing disk, an
> operation with FDISK to do the partitioning, then, assuming the driver
> works right the first time, restoring everything else on the encrypted
> partition.  What is the effect of _this_ on user acceptance?

Why not have the device driver create a file (possibly of varying sizes) on 
the hard drive which the encryption device driver then makes look like another
drive?!?  This is how the compression programs work, seems to me a pretty
viable way to solve the encrypted drive problem as well.  A good place to start
on this would be something like DOS's VDISK device driver, it maps a portion
of RAM into a RAM-disk... a good way to understand how a DOS device driver 
should map something that has no disk-like characteristics into disk-like