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? :-)