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
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
characteristics.
Return to June 1993
Return to “RYAN Alan Porter <ryan@rtfm.mlb.fl.us>”