From: Nickey MacDonald <i6t4@jupiter.sun.csd.unb.ca>
Date: Sun, 6 Jun 93 10:31:26 PDT
To: Mark Edward Zimmerman <zimm@alumni.cco.caltech.edu>
Subject: Re: random access into an encrypted file?
In-Reply-To: <9306061150.AA07264@alumni.cco.caltech.edu>
Message-ID: <Pine.3.05.9306061357.C11011-c100000@jupiter>
MIME-Version: 1.0
Content-Type: text/plain


Mark:

There are two possible ways to encrypt the file as they go to the disk,
and I think which you choose would determine what problems an fseek would
encounter...

As I understand the conversation so far, the talk is to make the encrypted
disk software a device driver.  Imagine what a typical device driver must
do.  The operating system wishes to see all files as long strings
(streams) of bytes and the disk drive wishes to see all "files" as a
collection of sectors (of a fixed size).  The device driver converts a
request for file position 'x' to a request to locate sector 'y'.  Even if
you only want one byte from the file, a whole sector gets read in.

So heres where you have to decide which way you are going to encrypt the
file.  If you are going to encrypt each sector in isolation, then when the
operating system requests a certain file location, that maps to a certain
sector which is read in, decrypted (in isolation from the rest of the
sectors) and then a particular byte is readily available.

If however you use a different scheme whereby the whole file is encrypted
as a single entity (which would be difficult to impossible to do using the
device driver metaphor, but there are other ways to wedge encryption into
the system) then presumably you need to decrypt from the very beginning
any time you need to seek into the file, which is what I think you were
worried about.

If you are familiar with data compression products, then here is a
comparison of the two techniques:  If you use something like stacker,
which is implemented as a device driver, then you have access to any byte
of any file at any time.  If you use something like pklite (the .exe
compressor) then you can never seek into the file (to load an overlay for
example).  You have to read the whole file and decompress it in order
access the bytes individually as uncompressed data.

(That is not a perfect metaphor, as pklite files are self decompressing
when they execute, not when the operating system accesses them, but it
does serve to show the limitations imposed my higher level file management.)

---
Nick MacDonald               | NMD on IRC
i6t4@jupiter.sun.csd.unb.ca  | PGP 2.1 Public key available via finger


On Sun, 6 Jun 1993, Mark Edward Zimmerman wrote:

> I'm enjoying the discussion of encrypting file systems, but have a
> perhaps-naive question: can the methods recently proposed here work
> for fast "random" access of bytes from the middle of a possibly-large
> file?

> Specifically, over the years I have written some free-text
> information-retrieval programs which build complete inverted indices
> to every word in a chosen text file (which may be many megabytes long,
> limited by disk space, not by RAM) --- and in order to fetch and
> display text quickly from an arbitrary point in the file, my programs
> do a lot of fseek() operations.  If a file is encrypted under various
> schemes, I wonder how long it would take to fetch byte 100,000,000?
> Could it cause me some performance problems?  :-)